Been a while…
But 420 is officially over, for me at least. Here’s a link to my final report, which is just about to be printed and handed in.
Add comment October 28th, 2005
Posts filed under '420 General'
Working madwifi
Got madwifi working on Monday after building on a woody chroot.
Very nice performance so far, around 6Mbit/s in 802.11b and 17-18Mbit/s in 802.11g and a modes. Ad-hoc mode seems to be working correctly, although it seems that the cards can take a wee while to settle before joining the correct cell. Changing parameters on the cards causes them to create their own BSS before joining an existing one, and this process can take anywhere from a few seconds to a minute. But all in all, it’s pretty sweet.
Add comment July 22nd, 2005
More madwifi
Turned out building on sarge was a bad idea, so MattB set me up a woody chroot on puck to do the building on. Will get them onto the hardware tomorrow once I get to Ruakura.
Add comment July 17th, 2005
First look at new madwifi
madwifi recently merged the BSD branch of the driver for Atheros based wireless chipsets into HEAD, which means that HEAD is up to date with all of the latest developments. Additionally, development will continue in HEAD instead of BSD, which has been deprecated.
The main feature of the latest versions of the driver is proper support for Ad-Hoc mode, which is something that I really need for rapid deploy.
I pulled the 20050712 CVS snapshot today and compiled it against MattB’s 2.4.29 kernel which has crypto support (necessary for madwifi) after finding that I wasn’t able to compile it on Voodoo as it’s a 64-bit machine, and, well, something about that doesn’t work. Computers are stupid 
Puck managed to compile it fine, albiet slower than it would have been on voodoo. Oh well. I upgraded the two rapid deploy test nodes to 2.4.29 and there were no problems. After installing and modprobing the new madwifi drivers, dmesg showed that the cards were recognised and the versions matched. The ath0 device was created, and ifconfig and iwconfig both saw the card. However, when trying to bring the interface up with ifconfig it spat back a “Network is down” message. Well, of course it was down…
Atheros cards need to be “up” for them to accept iwconfig commands and the like, so I tried assigning an IP address via ifconfig and it hung. SSH’d back into the machine, and ifconfig was in a “D” state, according to ‘ps’. Killing it did nothing. Further attempts to configure the card (either with if or iwconfig) resulted in the program hanging.
I assume this is to do with wireless-tools version mismatches, so I will re-compile wireless-tools to the new 2.4.29 kernel and see what happens. However, I’m going to Wellington in the morning, so it will have to wait till next week.
Add comment July 13th, 2005
Better quagga interaction
Changed rnetd so that it doesn’t rely on the quagga initscript to stop and start it. Instead, it will kill quagga and zebra on startup if running, write it’s configs to /var and then start quagga and zebra manually, passing the config dir as a command line option. This just means less messing around during install time, so you can have an instance of Quagga installed on the system and configured how you want it, and rnetd will just go and use it’s own settings, etc. It also means that if it turns out that there isn’t a fix for quagga’s interface state inconsistency bugs, then I can easily stop/start quagga manually whenever I need to. Yuck, but oh well. Tomorrow I plan to test the netlink-buffersize options with quagga, but I need to get my hands on some more Soekri and wireless cards first.
Add comment July 11th, 2005
Socket madness
OK, now I’m confused… I open a UDP socket and bind it to a local address. I then send it some data and it receives it fine. Good. I then send the broadcast address some data (after figuring out to make a call to setsockopt to allow this first), but the listening socket doesn’t get any data. Huh? tcpdump shows that it’s coming through fine, so I try calling setsockopt on the listening socket to try and “allow” it to hear broadcasts. No effect. So, I’m guessing that I need two sockets open - one for the host address and one for the broadcast address… That just seems… odd. Oh well.
Add comment July 6th, 2005
Discussions
Talked with MattB and Perry today about IP addressing and such. It’s pretty much a given that IPv6 would be awesome and fix pretty much all of the problems, but it doesn’t fix the fact that client devices like laptops, PDAs, etc would sometimes not work. Bugger.
So, I might try out this system:
Generate a random 16 bit number. Use this as the node ID. Broadcast my nodeID and MAC address to the network every minute or five, along with a sequence number. If I every get a reply from another node saying that the ID is in use, the lowest MAC address changes its node ID number and re-numbers any links and DHCP leases. This relies on giving out short leases to clients so that they can renumber relatively quickly. So, if a node establishes a connection to an existing network, the link _must_ be allocated from the remote node’s address pool, as we assume that the existing network has already resolved any ID conflicts, and so we can get a new ID from it. Yay.
Problem is, this breaks active connections like VoIP sessions. Bleh. It also takes down links in the network and forces the entire network to change its routing tables. Bleh.
I wish I could use IPv6, to be honest. IPv4 just plain sucks. Maybe I will, maybe I won’t… I don’t know. Lots to think about, and not enough time to think about it and implement something as well.
Add comment July 6th, 2005
Compass Success
It’s amazing what a lack of classes/exams and an excessive amount of chocolate can get achieved. Success with the compass conversion code! So now I’ve got a Python module written that can convert output from the Dinsmore compass sensors into actual compass bearings. However, in order to actually use the compass sensor I need to wait for Matt Jervis to finish the Serial Mux/AD Converter board for me, however it sounds like that part is coming along nicely, and should be ready soon(ish).
Add comment July 5th, 2005
Wordpress Upgrade
Just upgraded Wordpress to 1.5.1.3 to take care of an XML-RPC bug. It was much easier than I expected
Add comment July 5th, 2005
Unique Node IDs
A bit of a rant here.. just to get thoughts down on “paper”…
One of the problems with the rnet software so far is the way it allocates IP address space to nodes. At present, we allocate a 10.10.nodeID/24 network to each node to allocate IPs from, for both clients connecting via any APs on the node and for allocating to new point-to-point networks between nodes. This works quite well, assuming that the nodeID can be set on each node to be globally (by global we mean network-wide) unique. However, this is only possible in two situations:
- Assume we want a user to have no knowledge of nodeIDs: John buys a few nodes, and the dealer sets the nodeIDs, keeping a record of them. Further purchases have their nodeIDs set by the dealer to be non-conflicting. This requires a dealer to maintain a list of nodeIDs for a certain client, which is a Bad Thing. However, it hides the nodeID issue from John completely, which is a Good Thing.
- Assume we let users deal with nodeIDs: John obtains several nodes, which then ask him for unique nodeIDs as they start up. This requires John to know that nodes need unique IDs and also requires him to keep a record of IDs he has allocated or organise the teams setting up nodes to allocate specific IDs.
Both of the cases above are far from ideal. We want a system that removes the need for the user or any central authority (the dealer in this case) to deal with nodeIDs.
The current implementation uses preset 8-bit nodeID values, 0-255. A simple random number is not sufficient with such a small number space. The 8-bit value also restricts a rapid deploy network to 256 nodes which while in development seems like quite a few, we do not want to have to place such “artificial” restrictions on the size of a rapid deploy network. As an aside, multiple rapid deploy networks could internetwork assuming that they in turn use a globally unique IP prefix, e.g. 10.10/16, 10.11/16, …
The class A network is fixed. The rapid deploy network will always run on 10/8. We could, however, make the nodeID 16- instead of 8-bits long, pushing into the class B identifier. Instead of allocating 10.10.nodeID/24 to a node, we could allocate 10.nodeIDhi.nodeIDlo/24. This immediately helps the situation. With 2^16 (65,536) nodeIDs now available we have a much better chance at random allocation of nodeIDs - although still not perfect.
However, with 16-bits we could do more sophisticated nodeID allocation. For example, MAC addresses are 48-bits long. Assuming that rapid deploy nodes are always based on certain hardware platforms (e.g. Soekris) we could use the lower 12-bits of the MAC address and a 4-bit clock-based offset to generate a (probably - I can’t be bothered working out the math right now) unique ID. This idea is similar to the method used in version 1 Universally Unique Identifiers (UUIDs), which are 128-bits long (see http://en.wikipedia.org/wiki/UUID).
While this is a promising start, taking over the class B portion of the address means that the rapid deploy network could interfere with other networks, for example, currently we plug a rapid deploy node into CRCnet to act as a gateway. While it does NAT (so external routing would remain fine) if nodes on the network were allocating themselves nodeIDs that conflicted with existing class B networks on CRCnet, then the rapid deploy network would not be able to “see” the outside network with that conflicting prefix.
So,
- 8-bits is too short.
- > 8-bits causes problems.
- We don’t want to decrease the IP pool for each node, so extending the nodeID the other way isn’t desirable.
- Even if we accepted a decrease in the size of the IP pool for each node, we would only gain probably one or two bits before making the IP pool too small.
We need more bits.
So, here’s a suggestion, and keep in mind that I’m suggesting something that I have no idea about: IPv6. IPv6 gives us more than enough bits to make a globally unique nodeID. Of course, I am blatantly assuming that it is possible for the point-to-point networks to run on IPv6 while the Access Point interfaces run on IPv4 and still have routing work. I’m also assuming that an IPv4 client could talk to an IPv4 endpoint outside of the network with the IPv6 bit in between being completely transparent. Although, I guess we could just hand out IPv6 addresses from the AP - does Windows(R) XP(TM) support IPv6 DHCP leases? If the network, APs and clients were all IPv6, could the gateway then convert anything going out to IPv4 and anything coming in back to IPv6? Is this idea worth thinking about at all? Maybe it’s something that could be done later (i.e. next year) once things are looking a bit better.
Ah - I feel much better getting all that off my chest now.
2 comments July 1st, 2005