FabFi Wireless: July 2009

Friday, July 31, 2009

Thursday, July 23, 2009

FF2.0 seems to be coming along nicely (would be nicer if it wasn't 3am). I now have a config that happily meshes across wired and wireless connections, has good throughput, and (I think) can support multiple/changing gateways (though I haven't tried it yet).

Stuff still to be done, in no particular order:

Write a cron job to adjust the settings of the nameservice plugin so that it only announces a real DNS server when it has an uplink
Tweak wireless parameters
Add WEP (or better)
Write an autoconfig script
Set up SNMP
Torture test

Here's a zip file with configs for the four boxes I have running right now. Note that in addition to the backup files, there are a few other files I hacked and need to be added to new installs manually:

/etc/init.d/olsrd and /etc/init.d/dnsmasq: Added a check in the start section of each to ensure that dnsmasq always starts before olsrd. Otherwise DNS blows up.
/lib/wifi/broadcom.sh: Added a patch that allows rts and frag to be specified in the wireless config file.

Note for people playing with the linked configs: Fabfi1 is the dedicated uplink (DNS isn't happy about dynamic uplinks yet)

Lickety Split!

Google has all the answers, if you look hard enough.

It seems the throughput problem belabored in the last few posts only manifests itself in the 54gl only when the wireless is bridged. Why? As far as I can tell nobody knows.

The wireless works fine, however, when running two different mesh vlans, both with OLSR--one for wireless and one for wired--so be it!

Next challenge? Making the LANs talk...

results and configs to come.

Tuesday, July 21, 2009

All your drivers are belong to us.

After some more hacking in the fabfi trenches yesterday, a few more tidbits were revealed:

Having the routers too close together was not the problem
There's unlikely to be an interference problem from other devices in our lab, despite the walls being practically made out of electronics. See Baseline trace and Bandwidth test trace (both 3min. Test trace had data on the link for just over 2min. Baseline had devices off)
Switching to infrastructure mode completely nullifies the problem (so it's not an OLSR issue), though doing so does break part of the the zero-config goal we have for v2.

Thanks, Broadcom, for not releasing useful driver information to developers so when we use your products they perform like 1976 Chevy Chevettes. You guys are swell...

Monday, July 20, 2009

Sniff, Sniff, Sniff, Sniff...

...Still working on the wireless throughput problem. Since I haven't been making any progress in with the config and haven't gotten any responses to my post on the forum. I did a little sniffing around on the radio to see what's happening.

It's fairly straightforward to turn a 54g into a packet sniffing drone by installing kismet_drone and wl on WhiteRussian 0.9 (I couldn't get it to work with any other version). The only thing to change from the default setting is the ip addresses it will allow connections from. I had mine set up so that the kismet_server resided on a computer on the LAN of the sniffer box so I didn't have to play with the firewall.

On your other linux box of choice, configure kismet to look for your drone. The line in the config will be something like:

source=kismet_drone,[ip]:[port],mydrone

You might also want to decrease the interval on which kismet writes to disk and/or the output location--all in the kismet.conf file.

Anyway, long story short, you run the drone and the server, get a dump file and then read it with ethereal (wireshark) to get this output.

As you can see there's a lot of duplicate TCP traffic. What does that mean? I have no idea. How does one fix it? I have no idea. Suggestions are welcome...