Circumvent WiFi broadcast filters

[gardners]

Many phones set their WiFi drivers to deliberately drop incoming broadcast packets (eg, while the screen is off due to inactivity, the phone does not want broadcast traffic to keep waking it up), so we can't do peer discovery, or announce rhizome advertisements.

One solution is to periodically poke the addresses in our ARP table so that they can add us to their peer list. They will do the same for us, and so it should all work.

[gardners]

There may be a much better way: acquire a multicast lock from Android. This should allow either multicast, and possibly also broadcast packet reception. See, for example: http://answers.unity3d.com/questions/250732/android-build-is-not-receiving-udp-broadcasts.html

[gardners]

Apparently it might only work for Android 2.3.7+ devices:
http://stackoverflow.com/questions/3623143/multicast-on-android-2-2

Looking into it more.

If this proves a possible fix, then the solution goes into batphone, not serval-dna.

[gardners]

More useful information here: http://code.google.com/p/boxeeremote/wiki/AndroidUDP

It seems that a multicast lock may not work on some devices, but it does work on many, and allows broadcast reception in the process. On those devices where the multicast lock doesn't work, it won't facilitate multicast or broadcast.

[lakeman]

No. We're not going to do that. We certainly don't want to send n^2 unicast packets every second, for neighbours who can hear broadcast packets. Setting up a unicast link should be the last resort, when we have eliminated other options.

Instead we're going to extend the set of routing states.

The current set of routing states are;
NONE - no path, though we may relay via a directory service node
DIRECT - reachable via 1-hop broadcast IP packets
UNICAST - reachable via an explicitly addressed IPv4 packet
INDIRECT - reachable via another node
BROADCAST - might be reachable via 2-hop overlay broadcast flood

We need an explicit state between NONE and UNICAST anyway when we deal with 2-way NAT traversal. We need to acknowledge receipt of a unicast packet before we attempt to route other payloads across that link.

And BROADCAST needs to revert to NONE if it doesn't end up working.

I'm going to replace BROADCAST with BROADCAST_DISCOVERY and UNICAST_DISCOVERY.

When you receive a packet, and the current state of the sender is NONE;

• always record the source IPv4 address
• if the source address matches the netmask of the interface, and there is no explicit route for that node, transition to BROADCAST_DISCOVERY
• otherwise transition to UNICAST_DISCOVERY

In UNICAST_DISCOVERY mode, set an alarm that queues an outgoing probe payload that should only be sent via unicast. No other payload types should be sent via unicast though we may send payloads via a directory service node.

When we receive a probe payload, respond with an acknowledgement. When we receive the acknowledgement, transition to UNICAST.

When we send a packet to a node in either DISCOVERY state, decrement a counter. After sending 3- 5 packets, or after a timeout, transition to the next state; BROADCAST_DISCOVERY -> UNICAST_DISCOVERY -> NONE.

If we do transition back to NONE, we should reuse the timeout to prevent entering DISCOVERY again.

In future we may setup an index from IPv4 address to subscriber, so we can read the ARP table and start trying to discover peers that we didn't know about. But we need to be very careful not to spam the network.

[gardners]

Official Android multicast lock doco: http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html