Linux - Wireless NetworkingThis forum is for the discussion of wireless networking in Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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.
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.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.