Passive ARP listener task

[micolous]

There is a branch passive-refresh which contains this feature. It is mostly implemented however needs:

• rebasing against current tollgate
• testing under load
• rate limiting for duplicated events (as lots of ARP traffic can quickly overwhelm the application)

This feature implements a feature in the backend which causes it to generate DBus events whenever it recieves ARP packets.

This is then listened to by a frontend management command (listen_arp) which will cause NetworkHosts to be onlined automatically as soon as any traffic is received, and offline a host in case of recycling.

This has the upshot of eliminating some of the need for manual scanning of hosts, but makes it much more difficult to offline a host in the event of IP recycling.

The reason for this was primarily to deal with broken Apple DHCP client behaviour (on recent versions of iOS and Mac OS X) which deliberately violate DHCP standards by using an IP without requesting a lease if it is detected an IP is available for use. The reason for this is to "improve the experience" when connecting to networks with slow embedded DHCP servers, by breaking good, fast DHCP servers.

At the moment I'm a bit torn about whether to encourage broken Apple behaviour by patching around it, or if there is a way to make the DHCP client in Apple devices actually follow standards.

More background on this:

• http://www.net.princeton.edu/apple-ios/ios41-allows-lease-to-expire-keeps-using-IP-address.html
• http://cafbit.com/entry/rapid_dhcp_or_how_do

[micolous]

One other way the issue could be addressed is that the Apple devices will check to see if their requested IP address is available by ARP first. We could run a daemon on the server that looks for any non-leased IP addresses, and respond to this ARP request with a false address.

This would probably cause the Apple device to not try to use the address, and go through a full DHCP request before continuing.

This is the "work around by causing bad behaviour to be punished" attitude, as opposed to the passive-refresh branch's "allow bad behaviour to continue" attitude. The bonus with passive-refresh is that statically-assigned addresses will continue to work, but this isn't always desireable. In most party situtations, we don't want clients to setup their IP addressing manually to get "desirable addresses", as this risks conflicts and is entirely pointless with a proper DNS setup.

There's software like dhcparpd which helps to mitigate spoofing issues on primarily wireless networks, and this software could be modified to make non-leased addresses unusable.