LinuxQuestions.org - Issue connecting to a linksys router.

- Linux - Wireless Networking (https://www.linuxquestions.org/questions/linux-wireless-networking-41/)

- - Issue connecting to a linksys router. (https://www.linuxquestions.org/questions/linux-wireless-networking-41/issue-connecting-to-a-linksys-router-610717/)

Issue connecting to a linksys router.

I'm trying to connect my Linux/Windows pc to a wireless net being served by a Linksys WRT54G router. The administrator is not using encryption, but he is using MAC address filtering to grant permission only to PCs in his list. When I am in windows mode, I connect just fine. When I am in Linux mode, with my wifi device's MAC address entered properly onto his permission list, I cannot connect. In both cases the KDE desktop wireless assistant sees his network with plenty of strength. I am also able to completly associate with the AP I just cannot get out to the internet with it. The filtering blocks me.

I have checked MULTIPLE times that the Hwaddr is properly entered, and the MAC is proper... I am at a complete loss as to what to do.

Any tips on how to fix this MAC filtering issue? Is it possible for wireless assistant to grab the wrong MAC address on my side?
Many thanks.

Can you connect the wireless router at all?

If you are able to connect to the router, but not able to access the internet, perhaps it's not getting correct IP information, i.e. default gateway and/or DNS IP addresses.

Try configuring with static IP and manually enter the default gateway and DNS address, and see if that makes a difference.

Hello Liam123

To narrow down where the problem is occurring I would try the following.

Ping the ip address of the router.

Ping a site on the internet by ip address, try ping 212.58.251.206

Ping the same site by name: ping www.bbc.co.uk

In your web browser address bar type: http://212.58.251.206

The results of those should give you a pretty clear idea of just where the failure is happening.

Thanks guys very much for your help, new problem however. You see, I was very VERY stupid in assuming the router was actually in fact a router... it's actually just an access point, that is unfortunately governed by VERY expensive Fortinet routers that have UBER dhcp servers.. now what i think was going on is that these Fortinet routers were set to somehow disallow anything requesting an ip that was not based on the windows protocol... Now as I said, I forced my ip using the ifconfig wlan0 command and forced my netmask. Problem is not 30 secs after doing so (and a good ./network restart), the wlan0 script I had been using magically began to work.... issue is I now have an (in linux not windows) an ip of 192.168.1.68 whilst in windows i have an ip of 192.168.1.32 ...

To anybody who understands dhcp it would appear as though I have been put on a network split, network. Now I am concerned that this network is highly monitored by the fine folks at Fortinet.. Anybody got a clue as to how tell if this is the case?? without the obvious way of deliberately attracting attention to myself....

Any help is GREATLY appreciated. Thanks again to you both who helped me.

-Liam

I wonder it their DHCP server tracks both MAC addresses and HOSTNAMEs or the VENDER CLASS ID in the dhcp client's request. On my system the value in /etc/HOSTNAME is sent to the server. You may have an option to do so as well, and different behavior by the client could result in different IP addresses being defined. For example, does your windows client send a vender class ID?

Code:

from my /etc/sysconfig/dhcp configuration file:

## Type:        string("dhcpcd dhclient")

## Default:    ""

#

# specify a vendor class ID ( -i option)

#

# Specifies the vendor class identifier string.  dhcpcd uses the default vendor

# class identifier string (system name, system release, and machine type) if it

# is not specified.

#

DHCLIENT_VENDOR_CLASS_ID=""

Their server may be using this string to determine the OS of the system making a request.

Another possibility is that your client isn't waiting long enough for the process before it fails:

Code:

## Type:        integer

## Default:    5

#

# When the DHCP client is started at boot time, the boot process will stop

# until the interface is successfully configured, but at most for

# DHCLIENT_WAIT_AT_BOOT seconds.

#

DHCLIENT_WAIT_AT_BOOT="5"

There are different dhcp clients and associated configuration files. You system may read a single config file such as /etc/sysconfig/dhcp and use this info to construct the actual config file that your particular client looks for. Or you may need to determine which client your system uses and read it's config file and the man page for the config file if it exists. With some tweaking, you may be able to supply what their system expects.

Thank you so much. I will test all that right now.