Interesting Traces - Duplicate Broadcasts

I started out looking at broadcast packets (trace 1) and realized that the packets from 192.168.1.3 are duplicated. I know they are duplicated because the IP Identification and Time to live values are the same. My first thought was a layer 2 loop but if that were the case then why just 2 duplicates and not a flood. Also why just from 192.168.1.3.

  21664 66.529654   192.168.1.2   192.168.1.255  UDP  Source port: 138  Destination port: 138                     
    Identification: 0x1926 (6438)
    Time to live: 128

  51960 194.493035  192.168.1.4   192.168.1.255  UDP  Source port: 138  Destination port: 138
    Identification: 0x4446 (17478)
    Time to live: 128

  53917 206.181097  192.168.1.3   192.168.1.255  UDP  Source port: 138  Destination port: 138
    Identification: 0x1b81 (7041)
    Time to live: 128

  53918 206.181113  192.168.1.3   192.168.1.255  UDP  Source port: 138  Destination port: 138
    Identification: 0x1b81 (7041)
    Time to live: 128

 119989 307.286191  192.168.1.1   192.168.1.255  UDP  Source port: 138  Destination port: 138
    Identification: 0x5f5a (24410)
    Time to live: 128

 165541 518.100110  192.168.1.1   192.168.1.255  UDP  Source port: 138  Destination port: 138
    Identification: 0x5bd2 (23506)
    Time to live: 128

 199680 557.796006  192.168.1.6   192.168.1.255  UDP  Source port: 138  Destination port: 138
    Identification: 0x6930 (26928)
    Time to live: 128

 271202 788.026835  192.168.1.2   192.168.1.255  UDP  Source port: 138  Destination port: 138
    Identification: 0x726a (29290)
    Time to live: 128

 333178 912.769761  192.168.1.4   192.168.1.255  UDP  Source port: 138  Destination port: 138
    Identification: 0xbf42 (48962)
    Time to live: 128

 334968 925.577518  192.168.1.3   192.168.1.255  UDP  Source port: 138  Destination port: 138
    Identification: 0x4249 (16969)
    Time to live: 128

 334969 925.577534  192.168.1.3   192.168.1.255  UDP  Source port: 138  Destination port: 138
    Identification: 0x4249 (16969)
    Time to live: 128

 358737 1028.817609 192.168.1.1   192.168.1.255  UDP  Source port: 138  Destination port: 138
    Identification: 0x0433 (1075)
    Time to live: 128

Trace #1 - eth.dst == ff:ff:ff:ff:ff:ff

I then took a look at traffic from 192.168.1.3 and noted that only it was only the broadcast packets that were duplicated. Non-broadcast packets are only seen once.

  53904 206.096530  192.168.1.3   192.168.1.2    TCP  3687 > 1421 [PSH, ACK] Seq=83210 Ack=69861 Win=64187 Len=131
    Identification: 0x1b7a (7034)

  53906 206.097116  192.168.1.3   192.168.1.2    TCP  3687 > 1421 [PSH, ACK] Seq=83341 Ack=70081 Win=65535 Len=131
    Identification: 0x1b7b (7035)

  53908 206.097620  192.168.1.3   192.168.1.2    TCP  3687 > 1421 [PSH, ACK] Seq=83472 Ack=70222 Win=65394 Len=291
    Identification: 0x1b7c (7036)

  53910 206.098268  192.168.1.3   192.168.1.2    TCP  3687 > 1421 [PSH, ACK] Seq=83763 Ack=70363 Win=65253 Len=349
    Identification: 0x1b7d (7037)

  53912 206.115233  192.168.1.3   192.168.1.2    TCP  3687 > 1421 [PSH, ACK] Seq=84112 Ack=70504 Win=65112 Len=274
    Identification: 0x1b7e (7038)

  53914 206.115852  192.168.1.3   192.168.1.2    TCP  3687 > 1421 [PSH, ACK] Seq=84386 Ack=70645 Win=64971 Len=268
    Identification: 0x1b7f (7039)

  53916 206.116390  192.168.1.3   192.168.1.2    TCP  3687 > 1421 [PSH, ACK] Seq=84654 Ack=70786 Win=64830 Len=191
    Identification: 0x1b80 (7040)

  53917 206.181097  192.168.1.3   192.168.1.255  UDP  Source port: 138  Destination port: 138
    Identification: 0x1b81 (7041)

  53918 206.181113  192.168.1.3   192.168.1.255  UDP  Source port: 138  Destination port: 138
    Identification: 0x1b81 (7041)

  53921 206.410939  192.168.1.3   172.16.111.82  TCP  4708 > 3158 [PSH, ACK] Seq=6469 Ack=5665 Win=64605 Len=494
    Identification: 0x1b82 (7042)

  53923 206.423855  192.168.1.3   172.16.111.82  TCP  4708 > 3158 [PSH, ACK] Seq=6963 Ack=5806 Win=64464 Len=473
    Identification: 0x1b83 (7043)

  53925 206.469809  192.168.1.3   192.168.1.2    TCP  1169 > 2169 [PSH, ACK] Seq=4008 Ack=7927 Win=64573 Len=14
    Identification: 0x1b84 (7044)

  53927 206.470522  192.168.1.3   192.168.1.2    TCP  1169 > 2169 [PSH, ACK] Seq=4022 Ack=8039 Win=64461 Len=20
    Identification: 0x1b85 (7045)

  53929 206.473852  192.168.1.3   192.168.1.2    TCP  1169 > 2169 [PSH, ACK] Seq=4042 Ack=8060 Win=64440 Len=47
    Identification: 0x1b86 (7046)

Trace #2 - ip.src == 192.168.1.3

The trace was captured using a PC connected to a span port on a switch. I was told that the span was set up with the following command

set span 4/8 2/1 both session 1 inpkts enable learning enable multicast enable

Note that 192.168.1.3 is connected to port 4/8. I believe the "inpkts enable" causes this. All packets received at switch port 4/8 (transmitted from 192.168.1.3) are output to the span destination port of 2/1. The broadcast packet is also output on that port because its a broadcast and goes to all ports. I have to admit that the same logic in reverse could apply to broadcasts transmitted from switch port 4/8 (going to 192.168.1.3). I am assuming it does not because the code handling the duplication of packets between the two ports has special cased that condition. If anyone has a definitive explanation I would love to hear it.

This page was last modified on 09-04-23

Send comments and suggestions
to ndav1@cox.net