Posted: Thu May 18, 2006 9:09 pm Post subject: Wireless problems
OK. Here's the deal. I have a Netgear Wireless router: WGT624. I have it set up to WPA security and can connect normally when I boot into Windows.
However, I am having problems with wireless under Debian. The first problem I had is that this laptop has a Broadcom card which wpa_supplicant doesn't support, and as such you have to use ndiswrapper as the driver or run WEP. I didn't want to do that so I waited until the bug in ndiswrapper for the 64 bit kernel I am running was fixed.
So, I installed ndiswrapper this morning and dnsiwrapper to install the bcmwl5.inf file. That went fine. Then I installed wpa_supplicant and started configuring it, along with ifplugd.
Here's where I'm at. The wlan0 interface comes up and runs DHCPDISCOVER. I get no dhcp offers from my wireless router. However, my wireless router is connected to my wired network on which I have a dchp server running. I also have access control set up on my wireless router so that only the MAC addresses I enter can connect to it. The wireless router also gets its network settings from the dhcp server on my wired network. However, the subnet on the wireless lan is 192.168.2.0 where the wired subnet is 192.168.1.0, both with class c subnet masks.
Here's where things get really weird. The wireless router shows that the MAC address for the wlan0 interface is connected to it, but it shows no IP address for it. However, the wlan0 interface is getting its IP address from the dhcp server on the wired network, not the dhcp server on the wireless router.
Here is the appropriate part of my /etc/network/interfaces file:
wpa_supplicant is running. I can find it running ps -A.
I'm pretty thoroughly confused as to what is going on here. If I hook up a wired connection to my wireless router from my laptop (eth0) I get an IP address for eth0 from the wireless router.
Anyone have any ideas as to what is going on here?
Well, I don't know what happened, but I booted into Windows, let it hook into the wireless router, rebooted back into Debian, and everything works now.
This is just too weird. I've been working on this for hours today, and it just heals itself. I'd booted into Windows several other times and it hadn't changed anything.
Joined: Aug 23, 2005 Posts: 391 Location: Greensboro, NC, USA
Posted: Fri May 19, 2006 1:03 am Post subject:
No, no, no!
You're supposed to say "I solved it!"
And then:
"I'd tell you how but I don't think you need to know!"
I went through something like this trying to configure dual monitors on my ATI vid card. I wanted one big screen that I could move windows across on, but instead I got two completely independent desktops, Desktop and Desktop1. I don't really know how I did it, I didn't mean to, but I decided that I liked it a lot better, and it gave me good performance.
Oops . I mean, "I solved it! I'd tell you how but I don't think you need to know!"
LOL. Seems to me that wireless is at least 50% voodoo. I can't tell you how many times I had tried the same combination that finally worked and it wouldn't work....
How I could get an IP address through a non-existent connection to another subnet just baffles me.
assuming that the wireless router can route between 192.168.1.0 and 192.168.2.0, and
assuming the wireless router is running a dhcp-relay-agent to allow dhcp broadcast to pass from one subnet to another :
when wlan0 comes up, it sends a DHCPDISCOVER broadcast to find a dhcp server. Any dhcp server can reply (DHCPOFFER). wlan0 will get it's networkconfig from the first dhcpserver to DHCPOFFER.
So: maybe wired_network_dhcpserver was a bit faster in making a dhcpoffer than wireless_router_dhcpserver ...
Next, wlan0 will, when its dhcp-lease is halfway epired, request a renewal from the dhcpserver that made the initial dhcp offer, so it will ignore wireless_router_dhcpserver ... unless the lease completely expires -- then wlan0 will start all over with DHCPDISCOVER and wireless_router_dhcpserver has a chance to be the first to DHCPOFFER.
Does that make sense ?
If I'm not mistaking, the problem could show up again. However, I think there are options/parameters in dhcpserver and/or dhcpclient to work around this. (RFC 2131 explains how dhcp works, but there may be resources that are easier to read)
I had thought about that, but the sticking point to me is that why would the wireless router allow traffic through it to the wired dhcp server when it wouldn't allow a connection to it, i.e. wouldn't offer an IP address to DHCP requests?
What would happen is that the DHCPDISCOVER would go through its entire routine, wlan0 would go to sleep because of no DHCP offers, and then the second or third time through the routine, several minutes later, the wireless card would get its IP address from the wired DHCP server.
This seems like a security hole to me as I can't understand why it would pass DHCP requests upstream after refusing to respond to the request itself. I know there was plenty of signal as when the connection was finally made the network monitor showed 100% signal strenth and "iwlist scan" would show up not only my "cell" but a couple of other ones too.
As to this problem showing up later, well, I kinda doubt it. I've booted multiple times (10 times or so) into Debian since it first started to work and the wireless has connected properly every time. The wireless DHCP server would never offer a lease before, and I had tried probably 50 or 60 times.
Since this happened I did some more reading and several of the articles I read on Debian wireless say that if you're sure everything is set right and you still can't get a connection that shutting down your computer, walking away for 10 minutes or so, and then coming back fixes things. It seems as if some of these wireless routers and cards don't respond to configuration changes immediately, so maybe it was some change I had made previously finally worked its way through the system. I really don't know.
As I said previously, sometimes I think wireless is part voodoo.
... the sticking point to me is that why would the wireless router allow traffic through it to the wired dhcp server when it wouldn't allow a connection to it, i.e. wouldn't offer an IP address to DHCP requests?
(...)
This seems like a security hole to me as I can't understand why it would pass DHCP requests upstream after refusing to respond to the request itself.
Careful there, you're mixing things up. Obviously, your router does allow your Debian box to connect. The dhcpserver running on that appliance is just not not offering a lease. The dhcp-relay (not necessarily the same process as the dhcp server) transfers the DHCPDISCOVER to the next network, where there happens to be a more willing dhcp server.
DHCP can be strange sometimes. I've seen real workstations get leases from dhcpservers in a virtual test environment in a different IP-range while there was a perfectly good physical production dhcpserver available on the subnet. It's often a matter of timing : first is first, and if the dhcpserver takes to long to make an offer (eg while looking for available addresses), an other one may get there faster.
Still, it is kinda weird, and I have to admit I've seen similar things happen : you make a configuration that you know is correct, and it doesn't work. Then, when you come back later to have an other go, you find everything is working as it should be. Really frustrating.
Careful there, you're mixing things up. Obviously, your router does allow your Debian box to connect. The dhcpserver running on that appliance is just not not offering a lease.
No. I'm not mixing things up. To me it's a security problem that the router would allow a connection and pass dhcp requests through it when it refuses to answer a DHCP request. That means it can allow anyone else in the world to connect to my internal network even though it won't let them on the wireless network.
You don't see a problem there? I do. A very large one.
That means it can allow anyone else in the world to connect to my internal network
Yes and No.
So far, this was a dhcp story. So limiting it to dhcp:
The fact that your wireless workstation gets dhcpoffers from the wired LAN only indicates that it allows dhcp broadcasts, i.e. udp on ports 67 and 68. It doesn't say anything about other connections/communications
Secondly, routers normally don't pass on dhcp broadcasts and therefore dhcp negotiations are limited to 1 subnet. If you do want dhcp broadcast to travers subnet boundaries (i.e. routers) you need to enable an additional feature, a dhcp relay agent, to make that happen. It is possible that Netgear comes with dhcp relay enabled and that is indeed kinda sloppy - but it is not (or shouldn't be) standard practise. You also don't need it since you have a dedicated dhcp server for each of your subnets.
Looking at the broader picture, beyound the dhcp story:
The fact that your router routes is independent of the fact that its dhcp server does or doesn't give out leases. It routes, and from what i hear you say, it routes between your wired network, your wireless network, and the internet. That's what routers do. If you want to change its behaviour, you'll need to configure it (routes, acces control lists, packet filters, other firewalling measures, ...). It would be rather unusual to have access to your network depend on the fact whether or not a client can get an address fom your dhcp server ...
In protocol stack terms (TCP/IP suite, e.g. http://www.linux-tutorial.info/modules.php?name=Tutorial&pageid=142
-routing happens on the 'network' or 'IP' layer
-connections happen on the 'transport' or 'TCP/UDP'layer (unless you're talking about media access / datalink eg. your wireless NIC being able to 'see' the wireless router - that's layer 1 in TCP/IP (network access layer), layers 1 and 2 (physical + datalink) in OSI)
-dhcp and other services happen on the application layer
and these layers are independent of each other, they're not even aware of each other. So the fact that a client connects (layer 1) to your router, the fact that your router routes (layer 2), and the fact that communication is established between the wirded_server and that client (layer 3) does not (and should not) depend on whether or not a dhcp server is offering leases.
I suppose that you don't mind comuinication between your wireless LAN and the wired LAN. You obviously don't want anyone else, wired or not, to use your router to gain access to the private LANs connected to it.
If such access is possible, that is indeed a security problem, but it's not a dhcp issue, it's routing and firewalls.
suppose that you don't mind comuinication between your wireless LAN and the wired LAN. You obviously don't want anyone else, wired or not, to use your router to gain access to the private LANs connected to it.
If such access is possible, that is indeed a security problem, but it's not a dhcp issue, it's routing and firewalls.
The reason for setting up access security on a wireless network is to keep unauthorized computers from accessing your network. The fact that even though a wireless computer wasn't configured correctly to gain access to the wireless network and its dhcp request is forwarded to another subnet is very problematic. And, there are no settings to deny this behavior on this router that I can see.
The way I understand this a dhcp request will not be honored to a computer that is not correctly onfigured. Yet, my router passed that request on.
I'm not saying that this is the fault of dhcp, but that this is a problem on this router. I can't believe this is possible.
The reason for setting up access security on a wireless network is to keep unauthorized computers from accessing your network.
that would be layer 1 : communication between the wireless access point and the wireless NIC. You secured it by setting the access point the allow the MAC of the NIC. NICs and MAC addresses are clearly layer 1 items.
Your wireless computer was allowed to make such connection. Other computers are not (I suppose), so on the wireless side you're secure.
The wired ports of your router don't have this access level (layer 1) security, so there you need to arrange your security on layer 3 (packet filtering, statefull inspection) or on the application layer (authentication, ...)
The flaw in your router is indeed that it relays dhcp broadcasts while it shouldn't.
I searched the reference guide for your netgear, but couldn't find any reference to turning of the dhcp relay. It does get mentioned in the manuals for other netgear appliances though.
Still, blocking ports 67 and 68 (udp) between the appropriate networks should also do the trick
Posted: Tue Jul 27, 2010 3:27 pm Post subject: Re: Wireless Problem
gyrertr wrote:
We have used wire less network so create a many problem while list of problem are as under.
1) Install a repeater
2) Upgrade your router’s firmware
3) Get a high-gain antenna for your wireless router
4) Try changing your router’s broadcast channel
5) Update the network adapter on your computer
Ummm.... This is a 4 year old thread.
1. A repeater wouldn't have done anything to fix this problem. I was in the same room as the wireless router and had 100% signal strength.
2. I tried it and it was already the latest firmware.
3. Of no use. See 1.
4. Did that to no avail.
5. Why should I change out a good wireless card that works?
Your troubleshooting suggestions smack of the "change parts until something works" variety of troubleshooting problems, which is, in all reality, not a form of troubleshooting at all. It's a form of guessing, not a procedure for working systematically through problems.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.
Forum FAQ
Search
Usergroups
Profile
Log in to check your private messages
Log in
. I mean, "I solved it! I'd tell you how but I don't think you need to know!"
