Collab Network Test 0317E: Difference between revisions
Jump to navigation
Jump to search
(t) |
|||
Line 13: | Line 13: | ||
* At 235.07, the laptop multicasts another mDNS query, and again at 235.11, 235.365, 235.62, 235.82, etc. |
* 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 236.952, the laptop queries the school DNS server |
||
* At 237.14, the laptop establishes a connection with ejabberd, which continues to be the main source of traffic for the rest of the trace. |
* 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.25, the laptop makes another DNS request (conference.schoolserver ?) |
||
* At 237.41, the laptop checks in with NTP |
* At 237.41, the laptop checks in with NTP |
Revision as of 03:14, 20 March 2008
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
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