Collab Network Test 0317E

This is a forum for discussion about the packet traces obtained in test 0317E.

Packet Traces: Chan 1, Chan 11, Chan 6

Channel 1

Following one laptop: 00:17:c4:11:08:04 (a.k.a. 172.18.11.252)

• At 234.590, the laptop broadcasts a DHCP DISC request
• At 234.592, it receives a DHCP reply for 172.18.11.252
• At 234.88, the laptop multicasts an IGMP membership report
• At 234.974, the laptop multicasts to mDNS a packet with three queries. Unfortunately, the packet dump truncates the packet right before the interesting bits...
• At 235.07, the laptop multicasts another mDNS query, and again at 235.11, 235.365, 235.62, 235.82, etc.
• At 236.952, the laptop queries the school DNS server
• At 237.14, the laptop establishes a TCP connection with the school ejabberd, which continues to be the main source of this laptop's traffic for the rest of the trace.
• At 237.25, the laptop makes another DNS request (conference.schoolserver ?)
• At 237.41, the laptop checks in with NTP
• At 462.14, the laptop renews its DHCP lease

Looking for failed DHCP requests, we don't see any! In particular, we see successful BOOTP requests from 21 laptops -- the laptop stops sending BOOTP broadcasts before the 20 second timeout -- in the period from 230 sec to 281 sec. We don't see any other requests until 492 seconds, when I started clicking on mesh 1 to restart the discovery process. Then we see the eight remaining laptops successfully DHCP.

Something to note is that this period of time (260 to 280 sec.), when the laptops are all discovering their network, is the most congested of the whole trace.

Unused Channels

The unused channels (6 and 11) don't have a school server mesh portal point in this test, so they provide a picture of a laptop searching unsuccessfully for a school server.

Taking channel 6, and applying a filter:

wlan.sa == 00:17:c4:11:81:5a

The following behavior is seen on this laptop:

• We see Beacons sent out at irregular intervals (around 2 - 5 sec)
• At time 66.85, we see a request for IPv6 RADV (actually two, sent with two different BSS IDs), sent at 2 Mb/s. These continue to appear at roughly every 0.25 sec.
• At time 67.47, we see the RREQ go out for the first DHCP request. It is sent at four different rates.
• At 68.615, a RREQ message is relayed for laptop 00:17:c4:0d:37:f5, again at 69.68, 72.69, ...
• At 68.71 an RREQ for the DHCP server anycast MAC is resent
• At 71.72, an RREQ for the DHCP server is resent
• At 72.25, an RREQ is relayed for laptop 00:17:c4:0d:00:01, again at 73.27, ...
• At 72.54, an RREQ is relayed for laptop 00:17:c4:11:01:f0, again at 74.54, ...
• At 75.72, an RREQ for the DHCP server is resent
• Numerous RREQs for other laptops are relayed
• At 82.72, an RREQ for the DHCP server is resent
• At 134.61, we see an omen of future problems, as an ARP request from the school server (transmitted on channel 1!) is relayed.
• Again at 135.99, we see another channel 1 relay, an RREQ from the school server.
• At 158 sec, we leave this channel for the next one.
• Overall, roughly 90 seconds were spent on this channel!

For a closer look at "bleed through" from channel 1, try this filter:

wlan.sa == 00:50:43:28:26:2d || wlan.da == 00:50:43:28:26:2d