CODEWITHSUNDEEP
sockets
Pavel Kozlov
Pavel Kozlov

Reputation: 1003

SO_REUSEADDR option affects fragmentation?

I've faced with an interesting behavior of UDP socket with SO_REUSEADDR option set...

If I send 1472 bytes over IP/UDP I get it all in one frame - that' expected...

BUT for 1473 fragmentation differs with/without that option. Does anyone has a clue why that occurs (I'm using Debian 2.6.32-5-amd64)?

SO_REUSEADDR Enabled:

FRAME#1

Internet Protocol Version 4, Src: 173.59.3.22 (173.59.3.22), Dst: 173.70.1.5 (173.70.1.5)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
    Total Length: **1476**
    Identification: 0x214d (8525)
    Flags: 0x01 (More Fragments)
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set
        ..1. .... = More fragments: Set
    Fragment offset: 0
    Time to live: 64
    Protocol: UDP (17)
    Header checksum: 0xd53f [correct]
        [Good: True]
        [Bad: False]
    Source: 173.59.3.22 (173.59.3.22)
    Destination: 173.70.1.5 (173.70.1.5)
    [Source GeoIP: Unknown]
    [Destination GeoIP: Unknown]
User Datagram Protocol (**8** bytes)
    Source port: icl-twobase1 (25000)
    Destination port: 5000 (5000)
    Length: **1481**
    Checksum: 0x3cac [unchecked, not all data available]
        [Good Checksum: False]
        [Bad Checksum: False]
Data (**1448** bytes)

FRAME#2

Internet Protocol Version 4, Src: 173.59.3.22 (173.59.3.22), Dst: 173.70.1.5 (173.70.1.5)br/>
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
    Total Length: **45**
    Identification: 0x214d (8525)
    Flags: 0x00
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set
        ..0. .... = More fragments: Not set
    Fragment offset: 1456
    Time to live: 64
    Protocol: UDP (17)
    Header checksum: 0xfa20 [correct]
        [Good: True]
        [Bad: False]
    Source: 173.59.3.22 (173.59.3.22)
    Destination: 173.70.1.5 (173.70.1.5)
    [Source GeoIP: Unknown]
    [Destination GeoIP: Unknown]
Data (**25** bytes)

SO_REUSEADDR Disabled:

FRAME#1

Internet Protocol Version 4, Src: 173.59.3.22 (173.59.3.22), Dst: 173.70.1.5 (173.70.1.5)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
    Total Length: **1500**
    Identification: 0x214a (8522)
    Flags: 0x01 (More Fragments)
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set
        ..1. .... = More fragments: Set
    Fragment offset: 0
    Time to live: 64
    Protocol: UDP (17)
    Header checksum: 0xd52a [correct]
        [Good: True]
        [Bad: False]
    Source: 173.59.3.22 (173.59.3.22)
    Destination: 173.70.1.5 (173.70.1.5)
    [Source GeoIP: Unknown]
    [Destination GeoIP: Unknown]

User Datagram Protocol (**8** bytes)
    Source port: icl-twobase1 (25000)
    Destination port: 5000 (5000)
    Length: **1481**
    Checksum: 0x3cac [unchecked, not all data available]
        [Good Checksum: False]
        [Bad Checksum: False]
Data (**1472** bytes)

FRAME#2

Internet Protocol Version 4, Src: 173.59.3.22 (173.59.3.22), Dst: 173.70.1.5 (173.70.1.5)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
    Total Length: **21**
    Identification: 0x214a (8522)
    Flags: 0x00
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set
        ..0. .... = More fragments: Not set
    Fragment offset: 1480
    Time to live: 64
    Protocol: UDP (17)
    Header checksum: 0xfa38 [correct]
        [Good: True]
        [Bad: False]
    Source: 173.59.3.22 (173.59.3.22)
    Destination: 173.70.1.5 (173.70.1.5)
    [Source GeoIP: Unknown]
    [Destination GeoIP: Unknown]
Data (**1** byte)

Upvotes: 3

Views: 498

Answers (1)

Pavel Kozlov
Pavel Kozlov

Reputation: 1003

The answer is NO - SO_REUSEADDR doesn't affect fragmentation...


The clue is MTU Discovery and Don't Fragment Flag in IP Header.
In case of sending of 1472 bytes with MTU Discovery = ON:
1500 bytes sent with Don't Frag Flag ON => I get ICMP:

Internet Control Message Protocol
Type: 3 (Destination unreachable)
Code: 4 (Fragmentation needed)
 Checksum: 0x90db [correct]
MTU of next hop: 1480

After that the sender does fragmentation for all packets to fit 1480 MTU while route\arp cache info is kept for that receiver (5 min for route and 30 sec for arp - defaults configured on my system).

That's why I saw unexpected for me fragmentation of 1473 bytes (1456 + 25 bytes in two frames) (SO_REUSEADDR was ON in that experiment)...

Next time I tried sending the same 1473 bytes (SO_REUSEADDR was OFF) route\arp cache freed the info about the receiver and I saw that different confusing fragmentation (1480 + 1 bytes in two frames).

Sorry for everyone for the confusion...
However that was pretty cognitive for me to dig into such behavior and clarify things I observed. No miracles here.

Upvotes: 1

Related Questions