Comments on: Fr-eee-dom: roaming on the bus with wpa_supplicant http://syn.theti.ca/2007/12/25/fr-eee-dom-roaming-on-the-bus-with-wpa_supplicant/ debian, eeepc, kids & f/oss software Fri, 05 Mar 2010 01:02:40 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: Ben Armstrong http://syn.theti.ca/2007/12/25/fr-eee-dom-roaming-on-the-bus-with-wpa_supplicant/comment-page-1/#comment-78 Ben Armstrong Wed, 30 Nov -0001 00:00:00 +0000 More than one person pointed out I should use wext, not madwifi, so I have changed that in my own configuration and edited the instructions above. I'll see the next time I'm out on a bus if that helps me connect any quicker. Also, Kel Modderman says that in a future version (e.g. the one in svn) I should be able to do away with sudo and use the netdev group instead to use wpa_cli to connect to the supplicant. More than one person pointed out I should use wext, not madwifi, so I have changed that in my own configuration and edited the instructions above. I’ll see the next time I’m out on a bus if that helps me connect any quicker. Also, Kel Modderman says that in a future version (e.g. the one in svn) I should be able to do away with sudo and use the netdev group instead to use wpa_cli to connect to the supplicant.

]]> By: Paul Sladen http://syn.theti.ca/2007/12/25/fr-eee-dom-roaming-on-the-bus-with-wpa_supplicant/comment-page-1/#comment-79 Paul Sladen Wed, 30 Nov -0001 00:00:00 +0000 The big delay in re-association maybe the DHCP acquistion... I currently use a modified config that takes the timeouts down to the minimum (so request retransmits happen within 1second). dhcpd was designed with reliable but slow-to-answer networks in mind... whereas most of the networks you're using are very high-speed with the DHCP server only 1 hop away. with 50% packet loss you need to send ~8 initial packets to get through the three way DHCP handshake. Aswell as modifying dhcpd to go bang-bang-bang-(x8)... at 100ms intervals you really need a way to starting using addresses before renewal ( eg. the same lease you got yesterday even if it theoretically ran out 23hours ago. You could also try run something the equivalent of NSTX, but, ignoring the DNS encapsulation any success "poll" from client to your server, will result in a reply of any pending data. It should be possible to do the entire scan-associate-fa{ke,st}DHCP-poll-reply transaction in under 1 second, but probably not with the software as it stands at the moment. (Open networks only, the WPA setup is too long). Also, hack the client and server (netfilter level) to send each packet twice... this should help count dropped packets. Happy tinkering! The big delay in re-association maybe the DHCP acquistion… I currently use a modified config that takes the timeouts down to the minimum (so request retransmits happen within 1second).

dhcpd was designed with reliable but slow-to-answer networks in mind… whereas most of the networks you’re using are very high-speed with the DHCP server only 1 hop away. with 50% packet loss you need to send ~8 initial packets to get through the three way DHCP handshake. Aswell as modifying dhcpd to go bang-bang-bang-(x8)… at 100ms intervals you really need a way to starting using addresses before renewal ( eg. the same lease you got yesterday even if it theoretically ran out 23hours ago.

You could also try run something the equivalent of NSTX, but, ignoring the DNS encapsulation any success “poll” from client to your server, will result in a reply of any pending data. It should be possible to do the entire scan-associate-fa{ke,st}DHCP-poll-reply transaction in under 1 second, but probably not with the software as it stands at the moment. (Open networks only, the WPA setup is too long).

Also, hack the client and server (netfilter level) to send each packet twice… this should help count dropped packets.
Happy tinkering!

]]> By: Psyklops http://syn.theti.ca/2007/12/25/fr-eee-dom-roaming-on-the-bus-with-wpa_supplicant/comment-page-1/#comment-80 Psyklops Wed, 30 Nov -0001 00:00:00 +0000 Thanks for the help in IRC today. Here's what we learned along the way: If you're having trouble getting it to work, you can run wpa_supplicant by itself `sudo wpa_supplicant -iath0 -c/etc/wpa_supplicant/wpa_supplicant.conf -Dwext` This will give you error output so you can diagnose. The config can't be rewritten in one line as network={ key_mgmt=NONE } all whitespace is not equal. Installing wpagui is a good idea if you want a more standard interface to your network connection, it's as good as Gnome's network manager IMO. By default, the font is slightly too big and the 'add network' screen gets cut off. You'll need to adjust the font using 'sudo qtconfig', at 8pt it's a perfect fit. Thanks for the help in IRC today.

Here’s what we learned along the way:
If you’re having trouble getting it to work, you can run wpa_supplicant by itself `sudo wpa_supplicant -iath0 -c/etc/wpa_supplicant/wpa_supplicant.conf -Dwext` This will give you error output so you can diagnose.

The config can’t be rewritten in one line as network={ key_mgmt=NONE } all whitespace is not equal.

Installing wpagui is a good idea if you want a more standard interface to your network connection, it’s as good as Gnome’s network manager IMO. By default, the font is slightly too big and the ‘add network’ screen gets cut off. You’ll need to adjust the font using ‘sudo qtconfig’, at 8pt it’s a perfect fit.

]]>