[Dextrose] identify XOs on network

[Sascha Silbe]

Sridhar Dhanapalan <sridhar at laptop.org.au> writes:

> Is there a way to identify an XO from HTTP traffic, particularly when
> doing activities and OS updates?

Depending on how far on the network stack you can go, identifying them
by MAC address may be an option. If you need it to be absolutely
accurate, you'll need to feed the proxy with a list of MAC addresses of
all XOs in your deployment (I'm assuming it can be easily extracted from
some database you're using for activation). If having some non-XOs
access the network without authentication is acceptable, just comparing
the vendor code is enough. For the units I have here that would be
00:17:C4 = Quanta for XO-1, 1C:65:9D = LiteOn for XO-1.5 and 20:7C:8F =
Quanta for XO-1.75. There may be a couple of other vendor codes used,
but it's a rather small set and thus easy to maintain. The catch (as
hinted at above) is that there's a good chance the same vendor number is
used by a couple of other laptop models manufactured at
Quanta. Generating the list at the school server during registration
should be possible and would address this concern even without a global
list of MAC addresses, but is probably more work to set up, especially
if school server and proxy server are separate.

The MAC address is forgeable, but not quite as easily as the User-Agent
HTTP header. The false-positive rate is going to be comparable, as
several of the sources of HTTP traffic on the XO don't provide a custom
User-Agent header. The MAC address is fixed over the lifetime of the XO
(or at least it's WLAN module), whereas the User-Agent header could
change on any software update.


> I had this question from a schools network admin. If we can identify
> the XOs, we can set up special proxy rules for them to make things
> easier for users (e.g. to avoid proxy authentication).

You could also add a NetworkManager hook that does one-time
authentication at the proxy. Make sure the DHCP lease time and the proxy
authentication timeout are sufficiently long (say at least a day) so
that the chance of a regular HTTP request happening before the proxy
authentication is finished is low enough.

An interesting hack may be to use a different default gateway that has a
different firewall setup. Either have the DHCP server assign it
differently based on MAC address (basically the same idea as above, but
configured on the DHCP server rather than the proxy server) or use a
NetworkManager hook to alter the default route.

Sascha

-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <http://lists.sugarlabs.org/archive/dextrose/attachments/20120504/51a179a3/attachment.pgp>