WLAN: Access Point works, but no data transmitted

[cmoder]

I am using Knoppix 4.0 with a Fiberline USB stick (driver: zd1211 (http://sourceforge.net/projects/zd1211)). The module loads perfectly, the WLAN access point can be reached (iwconfig shows the correct parameters), DHCP works - but then, no data can be transmitted.

ifconfig shows a suitable IP address (192.168.1.xx), /etc/resolv.conf contains the IP address of the gateway (192.168.1.1), and also if I set the route correctly (route add default gw 192.168.1.1) no IP traffic is possible. I can neither ping the access point (192.168.1.1) nor any other internal or external computer.

Does anyone have an idea what could be wrong? Btw, with Knoppix 3.8 it worked.
Thanks, Christoph

[Harry Kuhman]

DHCP works - but then,.....
If DHCP works then data certainly can be transfered, something bogus is afoot.

Please post make and model of the router or access point. Are you currently using a security setting like wep or wpa? Please post all details, even ones that you think we don't need. For example, in ifconfig shows a suitable IP address (192.168.1.xx), there was really no reason to hide that IP address. This is likely to be something totally off the wall, so having as much information as we can will help.

My only guess right now is that maybe you have a feature enabled in the router that limits access by MAC address. Because you didn't post the router make and model I can't even say for sure if your hardware has that feature. I don't know if it would stop DHCP or not (I would have expected it to but you indicate that you did get a good DHCP setup). But it would certainly stop a ping (to the router, maybe not to other local compures even when going through the router with some models), and it's one of the few things that would stop a ping after a sucessful DHCP setup.

Also, are you 100% certain that the DHCP setup is coming from your router? I have seen cases where wifi users end up connecting to another router in the neighborhood and then can't understand the problems they are seeing. It is worth confirming what you are connecing to if you are in a location where there might be other wifi near.

[whoeverheis]

Always turn-off firewalls, encryption, router options untill you get things working. Then you can bring them back one at a time to see where the problem is. Harrys comment about picking up someone elses network rings true. I wasn't paying attention once and wondered why my cable connection was so slow. I was using my neighbors dialup!

[cmoder]

Thank you all for your suggestions. The router is a ZyXEL Prestige 660 HW 67 (http://www.zyxel.com/product/model.php?indexcate=1079416368&indexcate1=1021877946&indexFlagvalue=1021873638), I use WEP (128 bit), and the firewall is deactivated (in the router and also on the PC, see the output from iptables below). Also, no MAC filtering is done. Since the router can be contacted without problems and DCHP seems to work, I guess the problem lies somewhere in the network layer of Linux. But I have only few knowledge of network tools like arp so I cannot find out more.

from dmesg:

zd1211 - version 5000
Release Ver = 4330
EEPORM Ver = 4330
NET: Registered protocol family 23
usbcore: registered new driver zd1211

iwconfig:

wlan0 802.11b/g NIC ESSID:"MyESSID"
Mode:Managed Frequency=2.452 GHz Access Point: 00:A0:C5:D5:87:F8
Bit Rate:11 Mb/s
Retry:off RTS thr=2432 B Fragment thr:off
Power Management:off
Link Quality=64/92 Signal level=30/154 Noise level=161/154
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0

ifconfig:

lo Protokoll:Lokale Schleife
inet Adresse:127.0.0.1 Maske:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:8 errors:0 dropped:0 overruns:0 frame:0
TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:0
RX bytes:400 (400.0 b) TX bytes:400 (400.0 b)

wlan0 Protokoll:Ethernet Hardware Adresse 00:11:E2:02:2F:0D
inet Adresse:192.168.1.35 Bcast:192.168.1.255 Maske:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:22 errors:0 dropped:0 overruns:0 frame:0
TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX bytes:5624 (5.4 KiB) TX bytes:1504 (1.4 KiB)

Network Setup:

iwconfig wlan0 essid "MyESSID" key "s:MYPASSWORD"; pump -i wlan0

route:

Kernel IP Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
192.168.1.0 * 255.255.255.0 U 0 0 0 wlan0
default 192.168.1.1 0.0.0.0 UG 0 0 0 wlan0

/etc/resolv.conf:

nameserver 192.168.1.1

/proc/bus/usb/devices:

T: Bus=04 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 3 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=ff(vend.) Sub=ff Prot=ff MxPS=64 #Cfgs= 1
P: Vendor=0ace ProdID=1211 Rev=43.30
S: Manufacturer=ZyDAS
S: Product=USB2.0 WLAN
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA
I: If#= 0 Alt= 0 #EPs= 4 Cls=ff(vend.) Sub=00 Prot=00 Driver=zd1211
E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=83(I) Atr=03(Int.) MxPS= 64 Ivl=125us
E: Ad=04(O) Atr=03(Int.) MxPS= 64 Ivl=125us

iptables --list:

Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Thank you for your help, greetings, Christoph

[Harry Kuhman]

Since the router can be contacted without problems and DCHP seems to work, I guess the problem lies somewhere in the network layer of Linux. But I have only few knowledge of network tools like arp so I cannot find out more.

I wouldn't be so fast to point a finger at the Linux network layer. I've seen one router (a Belkin) that has DHCP problems with Linux (I blame the router), but all of the routers I've tested here (about 10) and several at friend's locations all work with Linux. Even the Belkin after I manually did a netcardconfig. I haven't seen this reported from other router users here either. I just gave a friend a DVD last night. Curious non-network related error message when he first booted, but then he rebooted and all was well, he was on the network right away. Linux is used on more web servers that Microsoft, it's network layer is pretty mature and stable.

Firewalls on other systems certainly can stop you from pinging them. But they have nothing to do with your reported problem of not being able to ping the router.

We are talking about Knoppix run right from the disc and not Knoppix run from the hard disk, are we not? I pitty the fool who installs Knoppix to hard disk, but I don't get involved in trouble shooting the many problems it introduces.

You should certainly do testing with network encryption disabled and only turn it back on after you have the rest of the system working. Encryption can be an issue and it's best to get things working in layers, not all at once, particluarly when there is a problem and you don't know the source.

One tool that might help at this point is ethereal (http://www.ethereal.com/). It's right on your Knoppix disc. It will let you watch the wire (or, in the case of monitoring one's own system, what the device interface thinks is on the "wire") and see at a low level what is really happening when the ping is lost. It's best to use with a third computer and a hub to really watch the packet exchange between two wired systems but you can learn an awful lot just by using it to look at your own network card's packets. Hopefully it will work with a USB device.

My guess is that it is not the network layer at all. I think it is much more likely a USB issue. I'm not at all surprised when wireless devices don't work under Linux, but I am intrigued by this where you say the DHCP worked but after that the device did not work.

[cmoder]

Short answer: You were right.


Linux is used on more web servers that Microsoft, it's network layer is pretty mature and stable.
I didn't assume an error in the Linux's networking code, but some kind of silly misconfiguration on my computer.


We are talking about Knoppix run right from the disc and not Knoppix run from the hard disk, are we not? I pitty the fool who installs Knoppix to hard disk, but I don't get involved in trouble shooting the many problems it introduces.
Oh, no, I am indeed running Knoppix from the hard disk. But I almost haven't changed anything, I have only installed the zd1211 WLAN driver which worked flawlessly.
I am using Knoppix for the disk installation because of its good hardware detection; with other distributions I had to spend a lot of time to get all the hardware configured. Why do you say that installing Knoppix on the hard disk creates so many problems?

Back to my problem: Everything seemed to work well, but it didn't. For example the WLAN driver is loaded without problems, DHCP seemed to work (no error, and a suitable IP address was assigned), and it was also possible to ping my own IP address (not 127.x.y.z, but the address associated to the wlan0 device). Using ethereal I discovered that although all that seemed to work, even DHCP just reported an old IP address. (As far as I remember, on other Linux installations there was always a delay of several seconds and then an error message if DHCP didn't work, this was not the case here.) No error messages at all, although not a single byte could be transmitted.

Thus, the problem is not in the network layer, but somewhere below. I guess the USB system does not work correctly. The USB mouse makes no problems, but the WLAN stick seems to be more delicate. Even worse, the behaviour of the USB system is not really deterministic; sometimes it workes better, sometimes worse, so I have to reboot. I have had these problems already with a previous Knoppix installation, but with the new Knoppix 4.0 it seemed to work much better, but it is the opposite. I was indeed able to establish a connection to the internet over my WLAN stick, but it lasted only a minute or so (yes, ethereal did show a handful IP packets). Of course there was no error message, but suddenly the wlan0 device had disappeared, and after bringing it up again the network did not work anymore, even after rebooting the computer several times. Maybe the saved settings (e.g. DHCP) come from such a situation when the WLAN accidentially worked for a short time.

I have found some websites saying that there are problems with some VIA USB chipset and the kernel 2.6 (and that the chipset is to blame). As there is no firmware update available for my BIOS, I will buy a new USB controller and see if things get better afterwards. So thank you for your help; it looked like a network problem but it seems to be somewhere deeper...

Christoph

[hairy.plotter]

I have exactly the same problem, DHCP works fine, tcpdump only shows UDP traffic, no TCP traffic at all.
I boot directly from 4.0 DVD, no custom configuration
Hardware name shown in iwconfig eth0 is ipw2100, aka, centrino 1, built-in wireless.
iwconfig output is normal. ifconfig output is normal, AP is a linksys router, open access, no encryption.
Everything used to work fine with exactly the same hardware in knoppix 3.9, 3.8, 3.7 .... etc.
I am sure I am connected to the right AP, based on the associated MAC on iwconfig
I guess the fact that UDP works fine is the reason DHCP works.
I can see broadcast traffic from other computers too with tcpdump, the problem is TCP doesn't work.
ethereal shows only UDP and ARP working. TCP output is 0 even when I try to telnet to port 80 of the router.

[bobeltomate]

I had a similar problem setting up my network, but for me it turned out i had the wrong IP address for my gateway in the routing table. sounds like you all may have already looked at that, but it never hurts to check in case you haven't yet (as i found out the hard way).

[hairy.plotter]

I had a similar problem setting up my network, but for me it turned out i had the wrong IP address for my gateway in the routing table. sounds like you all may have already looked at that, but it never hurts to check in case you haven't yet (as i found out the hard way).

Since DHCP worked, I wonder how you got a wrong IP address in your routing table, can you elaborate?

All I have to do is to use 3.9 instead of 4.0 then it works. But I have yet to figure out what the problem is with tcp.

[hairy.plotter]

Problem is still there with 4.02, have to go back to 3.9.