IPW-Treiber
Nachdem ich jetzt stolzer Besitzer eines Samsung-Laptops bin und 2.6.13-grml auch schon am Laufen ist, bin ich jetzt natürlich fest am Testen. Es klappt eigentlich alles tadellos, aaaber: die IPW-Treiber haben mich jetzt einiges an Nerv^WDebugging gekostet.
Ich hab ja schon geschrieben, dass sich ipw2200 bei mir komisch verhält, genauer: es braucht ein ‘rmmod ipw2200’ und anschliessendes Neuladen des Moduls, andernfalls gibt es ein “ipw-2.3-boot.fw load failed: Reason -2”. Im Sourcecode lässt sich herauslesen, dass das firmware_class-Modul beim Laden der Firmware versagt hat. Also habe ich das Timeout erstmal wie in $KERNEL/Documentation/firmware_class/README zu lesen ist via:
# echo 100 > /sys/class/firmware/timeout
erhöht. Ok, aber interessanterweise bekomme ich keine IP-Adresse via DHCP, huch? Ich hab einen Kernelbuild mit den ipw2200-Patches von Bernard Blackham probiert, aber auch dort das gleiche Problem. Ein Fallback auf Version 1.0.4 lieferte interessanterweise eine furchtbar hohe Load auf meinem System, ~70% CPU-Load durch ipw2200 und ein syslog voll mit:
Sep 2 17:38:02 grml kernel: ipw2200: Firmware error detected. Restarting.
Huch?! Ok, einmal mit:
# modprobe ipw2200 debug=0x43fff
probiert, aber so richtig erleuchtet hat mich auch das nicht. Nun hab ich gegoogelt sowie http://news.gmane.org/gmane.linux.drivers.ipw2100.devel durchstöbert.
Und für den ieee80211-Netzwerkstack hab ich einen Patch gefunden: ieee80211-1.0.3-skb_corrupt.patch (patch description: […] correct a problem encountered by some users when the ieee80211 subsystem overwrote the ethernet header in SKBs set for transmission). Allerdings hat der Patch alleine auch noch nicht das Problem behoben. :-/
Nachdem ich jetzt schon diverse ipw-Versionen und die verschiedensten Patches durchprobiert habe, Google und die einschlägigen Foren auch nicht mehr weiterhelfen, habe ich mich in #ipw2100 gemeldet und Peter Jones hat mir kompetent weitergeholfen: broadcast.patch. Ein ‘iwlist eth1 scanning’ ist zwar notwendig um aus “unassociated” ein “IEEE 802.11g” mit Verbindung zum Access-Point zu machen, aber dann läuft auch ein ‘dhclient eth1’ sauber durch.
Nun gibt es also ein ipw2200-modules-2.6.13-grml_1.0.6-2_i386.deb und ich werde jetzt versuchen, das sauber in grml zu integrieren. Sauber im Sinne von: works not only for me. ;-)
Ach ja (ich häng hier an einem AP namens D-Link DI-624):
* pjones points out that the APs that have this problem are doing something that's technically allowed, but totally braindead.
September 10th, 2005 at 14:06
Great, thanks for this info – this solved my problems when installing the 2.6.13 (stable kernel no patches). This is what I did:
Install ipw2200 version 1.0.6:
Download from ipw2200.sf.net
# tar xzf ieee80211-1.0.3.tgz
# cd ieee80211-1.0.3
# patch
Things seems to work with 64 bits 10 hex digits WEP encryption with my Linksys wrt54g (Firmware Version: v3.01.3 – HyperWRT 2.0), and NetworkManager 0.4, but
/var/log/messages
gives errors like this:Sep 10 13:51:10 localhost NetworkManager: DHCP: Got some data of length 1514.
Sep 10 13:51:10 localhost NetworkManager: DHCP: Reply message had mismatch in length (IP header said 4196, packet was really 1514), won’t use it.
…
Sep 10 13:51:10 localhost NetworkManager: DHCP: Got some data of length 52.
Sep 10 13:51:10 localhost NetworkManager: DHCP: Reply message was not UDP (ip_hdr->protocol = 6, IPPROTO_UDP = 17), won’t use it.
Sep 10 13:51:10 localhost NetworkManager: DHCP: Got some data of length 100.
Sep 10 13:51:10 localhost NetworkManager: DHCP: Reply message was not UDP (ip_hdr->protocol = 6, IPPROTO_UDP = 17), won’t use it.
Sep 10 13:51:10 localhost NetworkManager: DHCP: Got some data of length 1514.
Sep 10 13:51:10 localhost NetworkManager: DHCP: Reply message had mismatch in length (IP header said 4196, packet was really 1514), won’t use it.
…
Sep 10 13:51:11 localhost NetworkManager: DHCP: Got some data of length 116.
Sep 10 13:51:11 localhost NetworkManager: DHCP: Reply message was not UDP (ip_hdr->protocol = 6, IPPROTO_UDP = 17), won’t use it.
…
Sep 10 13:52:00 localhost NetworkManager: (): org.freedesktop.NetworkManagerInfo.BadNetworkData raised ‘NetworkManagerInfo::getNetworkProperties could not access essid for network ‘networks”
But, it seems to work – I’m writing this wirelessly with the setup described here :)