Collab Network Test 0321D: Difference between revisions

From OLPC
Jump to navigation Jump to search
No edit summary
 
(8 intermediate revisions by the same user not shown)
Line 14: Line 14:


== Channel 1 ==
== Channel 1 ==
The school server has MAC address of 00:50:43:28:26:2d.
The [[School server]] has MAC address of 00:50:43:28:26:2d.


=== Laptop X59 ===
=== Laptop X59 ===
This laptop has MAC address 00:17:c4:11:01:f0.
This laptop has MAC address 00:17:c4:11:01:f0. The [http://xs-dev.laptop.org/mesh/test0321/x71_server_log school server logs] show no record of a successful DHCP in the test period.


The filter most useful in this search was:
The filter most useful in this search was:
Line 25: Line 25:
''All times in packet trace time, unless otherwise noted''
''All times in packet trace time, unless otherwise noted''


* At 64.215, beacons from X59 start appearing. This probably corresponds to power up, five seconds before main processor boot at roughly 5:19:15 laptop time, giving an offset from laptop kernel time to packet trace of roughly 50 to 55 sec.
* At 64.215, beacons from X59 start appearing. This probably corresponds to power up, five seconds before main processor boot at roughly 5:18:20 laptop time, giving an offset from laptop kernel time to packet trace of roughly 55 sec., but I'm having trouble correlating the laptop log with what I see in the packet traces...
* From 72.930 to 79.523, the laptop issues six IPv6 nearest neighbor discovery requests
* From 72.930 to 79.523, the laptop issues six IPv6 nearest neighbor discovery requests
* At 78.097, it relays an RREQ from 00:17:c4:0d:08:46
* At 78.097, it relays an RREQ from 00:17:c4:0d:08:46
* From the laptop logs, it issued a DHCP discover at time 5:20:28 -> 125 to 130 sec packet trace time
* From the laptop logs, it issued a DHCP discover at time 5:19:32 (74 sec. laptop kernel time) -> 130 sec packet trace time
* We don't see the laptop issue an RREQ, even though we see it relay another laptops RREQ at 129.370
* We don't see the laptop issue an RREQ, even though we see it rebroadcast another laptops RREQ at 129.370
* Between 130.9986 and 131.0167 , a number of laptops repeat an RREQ from X59
* Between 130.9986 and 131.0167, a number of laptops rebroadcast an RREQ from X59
* A number of RREPs are sent by the school server starting at 131.018, to 00:17:c4:11:50:c2, '''but we don't see it ever sending the RREP on to X59'''
* A number of RREPs are sent by the school server starting at 131.018, to 00:17:c4:11:50:c2, '''but we don't see it ever sending the RREP on to X59'''
* Two additional DHCP DISCOVER packets are sent at one second intervals, then one is sent 8 sec. after the first (138 packet trace time), then a last one 18 seconds after the first (148 sec. packet trace time).
* According to the laptop logs, additional DHCP DISCOVER packets were sent at 76 sec. kernel time (132 sec. packet trace time), 80 sec. (136 sec. packet trace time), and 88 sec. (144 sec. packet trace time).
* From 154.500 to 154.523, we see a number of laptops relaying an RREQ from X59
* From 154.500 to 154.523, we see a number of laptops rebroadcasting an RREQ from X59
* From 172.474 to 172.503, we see a number of laptops relaying an RREQ from X59
* From 172.474 to 172.503, we see a number of laptops rebroadcasting an RREQ from X59
* At 172.5029, '''we even see the school server relay the RREQ''' from X59, but never see it issue a RREP.
* At 172.5029, '''we even see the school server relay the RREQ''' from X59, but never see it issue a RREP.
* From 175.650 to 176.416, X59 relays a number of RREQs from other laptops
* From 175.650 to 176.416, X59 rebroadcasts a number of RREQs from other laptops
* At 176.468, we see X59 send out an RREQ barrage (4 frames at varying speeds)
* At 176.468, we see X59 send out an RREQ barrage (4 frames at varying speeds)
* At 176.489, we see X59 send out another RREQ barrage.
* At 176.489, we see X59 send out another RREQ barrage.
* From 176.495 to 176.632 we see a number of laptops relaying the RREQs from X59, '''including the school server''' at 176.546, 176.551, 176.555, 176.558, 176.566, and 176.570.
* From 176.495 to 176.632 we see a number of laptops rebroadcasting the RREQs from X59, '''including the school server''' at 176.546, 176.551, 176.555, 176.558, 176.566, and 176.570.
* ''No RREP from the school server is seen''
* '''No RREP from the school server is seen'''
* At 176.580 and 176.656 see X59 relaying RREQs for other laptops
* At 176.580 and 176.656 see X59 rebroadcasting RREQs for other laptops
* At 177.039, it relays a broadcast ARP request for the school server
* At 177.039, it rebroadcasts an ARP request for the school server
* At 178.471, we see X59 send out an RREQ barrage
* At 178.471, we see X59 send out an RREQ barrage
* From 178.476 to 179.?? we see a number of laptop relaying the RREQs from X59
* From 178.476 to 178.651 we see a number of laptop rebroadcasting the RREQs from X59
* '''No RREP from the school server is seen'''
* At 183.495, we see X59 send out an RREQ barrage
* From 183.500 to 183.521 we see a number of laptop rebroadcasting the RREQs from X59
* '''No RREP from the school server is seen'''
* At 191.475, we see X59 send out an RREQ barrage
* From 191.479 to 191.515 we see a number of laptop rebroadcasting the RREQs from X59
* '''No RREP from the school server is seen'''
* ...

Appears to be a case of the school server not responding to RREQs from this laptop.


=== Laptop X71 ===
=== Laptop X71 ===
The laptop has a MAC address of 00:17:c4:11:0b:17.


* The typical situation, lots of RREQs rebroadcast at the beginning.
* At 97.767 is a message you don't see very often: a barrage of route errors, sent from X71 to the school server.
* At 105.596 we see a rebroadcast version of an RREQ from X71
* From 105.597 to 105.608, the school server sends an RREP to X71 via another laptop, but no retransmission to X71 was captured.
:Can anybody tell me why there the same RREP is transmitted eight times by the school server, each time at 1 Mb/s ?
::I'm told this is retransmitted until the frame is acknowledged.
* From 115.582 to 115.601, we again see a number of laptops rebroadcasting an RREQ from X71
* At 115.603, the school server sends an RREP to X71 via another laptop. No retransmission to X71 was captured.
:This time, it was four identical packets, sent at 1 Mb/s
* From 115.607 to 115.612, we see more laptops rebroadcasting the same RREQ from X71
* At 115.612, the school server sends another burst of RREPs to X71 via another laptop. No retransmission to X71 was captured.
* From 126.623 to 126.647, we again see a number of laptops rebroadcasting an RREQ from X71
* At 126.644, the school server sends an RREP to X71 via another laptop. No retransmission to X71 was captured.
* From 170.599 to 170.642, we again see a number of laptops rebroadcasting an RREQ from X71
* At 170.6228, we see the school server rebroadcasting an RREQ it should be responding to. We see this again at 170.6273, 170.6293, and 170.6330.
:As the packet has an ANYCAST address, I guess it is reasonable that the school server continues to rebroadcast it ?
* From 175.638 to 175.662, we again see a number of laptops rebroadcasting an RREQ from X71. Again, the school server is one of the relaying nodes.

* ...
* From 214.192 to 214.194, and again from 214.278 to 214.280, X71 rebroadcasts another laptops's RREQ.
* At 214.337, X71 issues a barrage of RREQs for the DHCP ANYCAST address.
* From 214.342 to 214.479, a number of laptops rebroadcast the RREQ from X71, '''including the school server'''
* '''No RREPs are seen'''
* At 214.609, X71 issues a barrage of RREQs for the DHCP ANYCAST address.
* From 214.631 to 214.705, a number of laptops rebroadcast the RREQ from X71
* '''No RREPs are seen'''
* At 215.611, X71 issues a barrage of RREQs for the DHCP ANYCAST address.
* From 215.613 to 215.643, a number of laptops rebroadcast the RREQ from X71, '''including the school server'''
* '''No RREPs are seen'''
* ...

X71 can be seen relaying RREPs from the school server to other laptops. Are we missing the RREPs which are then ignored by the firmware/driver on the laptop ? Possibly.

During the period of time that these laptops seemingly failed to receive an RREP, the school server did properly respond to some other laptops.


=== Working Laptop ===
=== Working Laptop ===

We trace a working laptop, X69 aka '''00:17:c4:0d:00:01''' aka 172.18.10.248, for comparison.

* At 65.237, a beacon from X69 is first seen.
* At 79.309, X69 rebroadcasts an ARP request from the school server
* From 80.211 to 85.888, X69 sends out IPv6 nearest neighbor requests
* At 86.812 and 87.967, X69 is seen rebroadcasting RREQs from other laptops
* From 92.459 to 92.472, we see other laptops rebroadcasting an RREQ for the mesh portal ANYCAST address from X69
* At 92.4785, the school server sends an RREP to X69 via another laptop (00:17:c4:'''11:1a:f3''')
* At 92.4994, laptop 00:17:c4:'''11:1a:f3''' sends an RREP to laptop 00:17:c4:'''0d:3a:29'''.
* From 92.5023 to 92.5143, laptop 00:17:c4:'''0d:3a:29''' sends a barrage of RREPs to laptop 00:17:c4:'''11:50:c2'''
: Again, why nine identical packets at 1 Mb/s ?
::I'm told this is retransmitted until the frame is acknowledged...
* No retransmission to X69 was captured.
* From 93.406 to 93.433, a number of laptops rebroadcast an RREQ from X69.
* At 93.4256, we see an RREP from the school server, sent to X69 via laptop 00:17:c4'''10:c7:5b'''
* At 93.4534, we see laptop 00:17:c4'''10:c7:5b''' relay the RREP to laptop 00:17:c4'''10:e0:d3'''
* From 93.486 to 93.497, laptop 00:17:c4:'''10:e0:d3''' sends a barrage of RREPs to laptop 00:17:c4:'''10:f6:e8'''
* No retransmission to X69 was captured.
* ...
* At 94.404, 96.400, and 102.312 similar exchanges occur, with the RREP routed to different laptops
* ...
* At 115.594, X69 rebroadcasts an RREQ for 00:17:c4:11:0b:17 (X71) !
* At 116.471, X69 issues a barrage of RREQs for the mesh portal ANYCAST address
* From 116.473 to 116.483, we see other laptops rebroadcasting the RREQ from X69
* At 116.505, the school server issues an RREP direct to X69
* At 116.511, X69 issues a BOOTP request
* At 116.531, the school server issues an RREQ for X69 (echoed from 116.539 to 116.610)
* At 116.564, X69 issues an RREP direct to the school server
* At 116.6260, the school server makes a DHCP offer of 172.18.10.248 to X69
* At 116.6265, X69 again issues a BOOTP request
* At 116.633, the school server again makes a DHCP offer of 172.18.10.248 to X69
* At 116.979, X69 issues an IGMP Membership Report (using an IP address of 172.18.10.248)
* At 117.084, X69 makes an mDNS query
* At 117.184, X69 announces itself using mDNS
* At 117.218, X69 makes another mDNS query
* At 117.516, the school server issues an ARP request for 172.18.10.248 (X69)
* At 117.541, X69 replies to the school server's ARP request
* Networking continues...

I would call that barely working !


== Other Channels ==
== Other Channels ==


The other channels were not supported by the school server. Any traffic on them is either laptops looking for a school server or bleed-over from channel 1.
The other channels were not supported by the [[School server]]. Any traffic on them is either laptops looking for a school server or bleed-over from channel 1.

Latest revision as of 16:49, 25 March 2008

This is a forum for discussion about the packet traces obtained in test 0321D.

Logs

Packet Traces: Chan 1, Chan 11, Chan 6

Laptop X59 logs: All, dmesg, /var/log/messages, Telepathy/Sugar

Laptop X71 logs: All, dmesg, /var/log/messages, Telepathy/Sugar

Server logs: /var/log/messages, Laptop List

It appears clear that the logging mechanism doesn't record every frame in the air at every location!

Channel 1

The School server has MAC address of 00:50:43:28:26:2d.

Laptop X59

This laptop has MAC address 00:17:c4:11:01:f0. The school server logs show no record of a successful DHCP in the test period.

The filter most useful in this search was:

wlan.sa==00:17:c4:11:01:f0 || wlan.da==00:17:c4:11:01:f0 || wlan_mgt.fixed.sa==00:17:c4:11:01:f0 || wlan_mgt.fixed.da==00:17:c4:11:01:f0

All times in packet trace time, unless otherwise noted

  • At 64.215, beacons from X59 start appearing. This probably corresponds to power up, five seconds before main processor boot at roughly 5:18:20 laptop time, giving an offset from laptop kernel time to packet trace of roughly 55 sec., but I'm having trouble correlating the laptop log with what I see in the packet traces...
  • From 72.930 to 79.523, the laptop issues six IPv6 nearest neighbor discovery requests
  • At 78.097, it relays an RREQ from 00:17:c4:0d:08:46
  • From the laptop logs, it issued a DHCP discover at time 5:19:32 (74 sec. laptop kernel time) -> 130 sec packet trace time
  • We don't see the laptop issue an RREQ, even though we see it rebroadcast another laptops RREQ at 129.370
  • Between 130.9986 and 131.0167, a number of laptops rebroadcast an RREQ from X59
  • A number of RREPs are sent by the school server starting at 131.018, to 00:17:c4:11:50:c2, but we don't see it ever sending the RREP on to X59
  • According to the laptop logs, additional DHCP DISCOVER packets were sent at 76 sec. kernel time (132 sec. packet trace time), 80 sec. (136 sec. packet trace time), and 88 sec. (144 sec. packet trace time).
  • From 154.500 to 154.523, we see a number of laptops rebroadcasting an RREQ from X59
  • From 172.474 to 172.503, we see a number of laptops rebroadcasting an RREQ from X59
  • At 172.5029, we even see the school server relay the RREQ from X59, but never see it issue a RREP.
  • From 175.650 to 176.416, X59 rebroadcasts a number of RREQs from other laptops
  • At 176.468, we see X59 send out an RREQ barrage (4 frames at varying speeds)
  • At 176.489, we see X59 send out another RREQ barrage.
  • From 176.495 to 176.632 we see a number of laptops rebroadcasting the RREQs from X59, including the school server at 176.546, 176.551, 176.555, 176.558, 176.566, and 176.570.
  • No RREP from the school server is seen
  • At 176.580 and 176.656 see X59 rebroadcasting RREQs for other laptops
  • At 177.039, it rebroadcasts an ARP request for the school server
  • At 178.471, we see X59 send out an RREQ barrage
  • From 178.476 to 178.651 we see a number of laptop rebroadcasting the RREQs from X59
  • No RREP from the school server is seen
  • At 183.495, we see X59 send out an RREQ barrage
  • From 183.500 to 183.521 we see a number of laptop rebroadcasting the RREQs from X59
  • No RREP from the school server is seen
  • At 191.475, we see X59 send out an RREQ barrage
  • From 191.479 to 191.515 we see a number of laptop rebroadcasting the RREQs from X59
  • No RREP from the school server is seen
  • ...

Appears to be a case of the school server not responding to RREQs from this laptop.

Laptop X71

The laptop has a MAC address of 00:17:c4:11:0b:17.

  • The typical situation, lots of RREQs rebroadcast at the beginning.
  • At 97.767 is a message you don't see very often: a barrage of route errors, sent from X71 to the school server.
  • At 105.596 we see a rebroadcast version of an RREQ from X71
  • From 105.597 to 105.608, the school server sends an RREP to X71 via another laptop, but no retransmission to X71 was captured.
Can anybody tell me why there the same RREP is transmitted eight times by the school server, each time at 1 Mb/s ?
I'm told this is retransmitted until the frame is acknowledged.
  • From 115.582 to 115.601, we again see a number of laptops rebroadcasting an RREQ from X71
  • At 115.603, the school server sends an RREP to X71 via another laptop. No retransmission to X71 was captured.
This time, it was four identical packets, sent at 1 Mb/s
  • From 115.607 to 115.612, we see more laptops rebroadcasting the same RREQ from X71
  • At 115.612, the school server sends another burst of RREPs to X71 via another laptop. No retransmission to X71 was captured.
  • From 126.623 to 126.647, we again see a number of laptops rebroadcasting an RREQ from X71
  • At 126.644, the school server sends an RREP to X71 via another laptop. No retransmission to X71 was captured.
  • From 170.599 to 170.642, we again see a number of laptops rebroadcasting an RREQ from X71
  • At 170.6228, we see the school server rebroadcasting an RREQ it should be responding to. We see this again at 170.6273, 170.6293, and 170.6330.
As the packet has an ANYCAST address, I guess it is reasonable that the school server continues to rebroadcast it ?
  • From 175.638 to 175.662, we again see a number of laptops rebroadcasting an RREQ from X71. Again, the school server is one of the relaying nodes.
  • ...
  • From 214.192 to 214.194, and again from 214.278 to 214.280, X71 rebroadcasts another laptops's RREQ.
  • At 214.337, X71 issues a barrage of RREQs for the DHCP ANYCAST address.
  • From 214.342 to 214.479, a number of laptops rebroadcast the RREQ from X71, including the school server
  • No RREPs are seen
  • At 214.609, X71 issues a barrage of RREQs for the DHCP ANYCAST address.
  • From 214.631 to 214.705, a number of laptops rebroadcast the RREQ from X71
  • No RREPs are seen
  • At 215.611, X71 issues a barrage of RREQs for the DHCP ANYCAST address.
  • From 215.613 to 215.643, a number of laptops rebroadcast the RREQ from X71, including the school server
  • No RREPs are seen
  • ...

X71 can be seen relaying RREPs from the school server to other laptops. Are we missing the RREPs which are then ignored by the firmware/driver on the laptop ? Possibly.

During the period of time that these laptops seemingly failed to receive an RREP, the school server did properly respond to some other laptops.

Working Laptop

We trace a working laptop, X69 aka 00:17:c4:0d:00:01 aka 172.18.10.248, for comparison.

  • At 65.237, a beacon from X69 is first seen.
  • At 79.309, X69 rebroadcasts an ARP request from the school server
  • From 80.211 to 85.888, X69 sends out IPv6 nearest neighbor requests
  • At 86.812 and 87.967, X69 is seen rebroadcasting RREQs from other laptops
  • From 92.459 to 92.472, we see other laptops rebroadcasting an RREQ for the mesh portal ANYCAST address from X69
  • At 92.4785, the school server sends an RREP to X69 via another laptop (00:17:c4:11:1a:f3)
  • At 92.4994, laptop 00:17:c4:11:1a:f3 sends an RREP to laptop 00:17:c4:0d:3a:29.
  • From 92.5023 to 92.5143, laptop 00:17:c4:0d:3a:29 sends a barrage of RREPs to laptop 00:17:c4:11:50:c2
Again, why nine identical packets at 1 Mb/s ?
I'm told this is retransmitted until the frame is acknowledged...
  • No retransmission to X69 was captured.
  • From 93.406 to 93.433, a number of laptops rebroadcast an RREQ from X69.
  • At 93.4256, we see an RREP from the school server, sent to X69 via laptop 00:17:c410:c7:5b
  • At 93.4534, we see laptop 00:17:c410:c7:5b relay the RREP to laptop 00:17:c410:e0:d3
  • From 93.486 to 93.497, laptop 00:17:c4:10:e0:d3 sends a barrage of RREPs to laptop 00:17:c4:10:f6:e8
  • No retransmission to X69 was captured.
  • ...
  • At 94.404, 96.400, and 102.312 similar exchanges occur, with the RREP routed to different laptops
  • ...
  • At 115.594, X69 rebroadcasts an RREQ for 00:17:c4:11:0b:17 (X71) !
  • At 116.471, X69 issues a barrage of RREQs for the mesh portal ANYCAST address
  • From 116.473 to 116.483, we see other laptops rebroadcasting the RREQ from X69
  • At 116.505, the school server issues an RREP direct to X69
  • At 116.511, X69 issues a BOOTP request
  • At 116.531, the school server issues an RREQ for X69 (echoed from 116.539 to 116.610)
  • At 116.564, X69 issues an RREP direct to the school server
  • At 116.6260, the school server makes a DHCP offer of 172.18.10.248 to X69
  • At 116.6265, X69 again issues a BOOTP request
  • At 116.633, the school server again makes a DHCP offer of 172.18.10.248 to X69
  • At 116.979, X69 issues an IGMP Membership Report (using an IP address of 172.18.10.248)
  • At 117.084, X69 makes an mDNS query
  • At 117.184, X69 announces itself using mDNS
  • At 117.218, X69 makes another mDNS query
  • At 117.516, the school server issues an ARP request for 172.18.10.248 (X69)
  • At 117.541, X69 replies to the school server's ARP request
  • Networking continues...

I would call that barely working !

Other Channels

The other channels were not supported by the School server. Any traffic on them is either laptops looking for a school server or bleed-over from channel 1.