yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #58072
[Bug 1635765] [NEW] UDP checksum incorrectly generated on Fragmented UDP packets
Public bug reported:
HP Helion Openstack 2.1 (Kilo), but also exhibited in Liberty on
multiple instances.
SIP over UDP with packets larger than the MTU set on instance in tenant.
Instance fragments packets and forwards to neutron router where NAT
performed. Because the NAT changes the source IP address from 10.0.4.6
to 172.30.225.135, the UDP checksum has to be recomputed (using all
packet fragments), and put into the checksum field in the UDP header in
the packet. The computation of the checksum is incorrect. The UDP
packet is captured at the destination and seen to have an incorrect UDP
checksum, so the packet is dropped and never reaches the application.
UDP packets that are not fragmented that pass through the neutron router
and are NATed have the correct UDP checksum computed and put in the
packet, so the problem is only when UDP packets are fragmented.
In this example the MTU size on instance, 1400, is less than MTU size of
the of physical network, 1500, and packet is less than MTU size of
physical network. Because of this, the packet is reassembled on router
and sent as 1 packet [which I don't believe is relevant, but I mention
for completeness].
Below are the header information of the packet captures at the source
and the destination. Note on the destination packet capture that the
UDP checksum is flagged as incorrect/bad.
When "Reassemble fragmented IPv4 datagrams" selected in Wireshark IPv4
settings, the 0x0ba6 UDP Checksum is show as correct, but below when
both packets are shown individually, Wireshark shows the checksum as
unverified because it would need to include both packets in computing
the checksum and the Reassemble fragmented IPv4 datagrams" is unselected
(so that the headers could be shown as they actually are)
Packet capture at Source:
No. Time Source Destination Protocol Length Info
1 0.000000 10.0.4.6 10.202.126.219 SIP/SDP 1410 Request: INVITE sip:7039710421@10.202.126.219;user=phone |
Frame 1: 1410 bytes on wire (11280 bits), 1410 bytes captured (11280 bits)
Ethernet II, Src: fa:16:3e:0d:dc:d6 (fa:16:3e:0d:dc:d6), Dst: fa:16:3e:40:22:5b (fa:16:3e:40:22:5b)
Internet Protocol Version 4, Src: 10.0.4.6, Dst: 10.202.126.219
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x10 (DSCP: Unknown, ECN: Not-ECT)
Total Length: 1396
Identification: 0x3d0f (15631)
Flags: 0x01 (More Fragments)
Fragment offset: 0
Time to live: 64
Protocol: UDP (17)
Header checksum: 0x80af [correct]
[Header checksum status: Good]
[Calculated Checksum: 0x80af]
Source: 10.0.4.6
Destination: 10.202.126.219
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: 5060, Dst Port: 5060
Source Port: 5060
Destination Port: 5060
Length: 1451
Checksum: 0x0ba6 [unverified]
[Checksum Status: Unverified]
[Stream index: 0]
Session Initiation Protocol (INVITE)
Request-Line: INVITE sip:7039710421@10.202.126.219;user=phone SIP/2.0
Message Header
Message Body
No. Time Source Destination Protocol Length Info
2 0.000012 10.0.4.6 10.202.126.219 IPv4 109 Fragmented IP protocol (proto=UDP 17, off=1376, ID=3d0f)
Frame 2: 109 bytes on wire (872 bits), 109 bytes captured (872 bits)
Ethernet II, Src: fa:16:3e:0d:dc:d6 (fa:16:3e:0d:dc:d6), Dst: fa:16:3e:40:22:5b (fa:16:3e:40:22:5b)
Internet Protocol Version 4, Src: 10.0.4.6, Dst: 10.202.126.219
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x10 (DSCP: Unknown, ECN: Not-ECT)
Total Length: 95
Identification: 0x3d0f (15631)
Flags: 0x00
Fragment offset: 1376
Time to live: 64
Protocol: UDP (17)
Header checksum: 0xa518 [correct]
[Header checksum status: Good]
[Calculated Checksum: 0xa518]
Source: 10.0.4.6
Destination: 10.202.126.219
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
Data (75 bytes)
Packet capture at Destination
No. Time Source Destination Protocol Length Info
1 0.000000 172.30.225.135 10.202.126.219 SIP/SDP 1487 Request: INVITE sip:7039710421@10.202.126.219;user=phone |
Frame 1: 1487 bytes on wire (11896 bits), 1487 bytes captured (11896 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 172.30.225.135, Dst: 10.202.126.219
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x10 (DSCP: Unknown, ECN: Not-ECT)
Total Length: 1471
Identification: 0x3d0f (15631)
Flags: 0x00
Fragment offset: 0
Time to live: 57
Protocol: UDP (17)
Header checksum: 0x27c4 [correct]
[Header checksum status: Good]
[Calculated Checksum: 0x27c4]
Source: 172.30.225.135
Destination: 10.202.126.219
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: 5060, Dst Port: 5060
Source Port: 5060
Destination Port: 5060
Length: 1451
Checksum: 0x8c05 [incorrect, should be 0x0ba6](maybe caused by "UDP checksum offload"?)
[Checksum Status: Bad]
[Stream index: 0]
Session Initiation Protocol (INVITE)
** Affects: neutron
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1635765
Title:
UDP checksum incorrectly generated on Fragmented UDP packets
Status in neutron:
New
Bug description:
HP Helion Openstack 2.1 (Kilo), but also exhibited in Liberty on
multiple instances.
SIP over UDP with packets larger than the MTU set on instance in
tenant. Instance fragments packets and forwards to neutron router
where NAT performed. Because the NAT changes the source IP address
from 10.0.4.6 to 172.30.225.135, the UDP checksum has to be recomputed
(using all packet fragments), and put into the checksum field in the
UDP header in the packet. The computation of the checksum is
incorrect. The UDP packet is captured at the destination and seen to
have an incorrect UDP checksum, so the packet is dropped and never
reaches the application.
UDP packets that are not fragmented that pass through the neutron
router and are NATed have the correct UDP checksum computed and put in
the packet, so the problem is only when UDP packets are fragmented.
In this example the MTU size on instance, 1400, is less than MTU size
of the of physical network, 1500, and packet is less than MTU size of
physical network. Because of this, the packet is reassembled on
router and sent as 1 packet [which I don't believe is relevant, but I
mention for completeness].
Below are the header information of the packet captures at the source
and the destination. Note on the destination packet capture that the
UDP checksum is flagged as incorrect/bad.
When "Reassemble fragmented IPv4 datagrams" selected in Wireshark IPv4
settings, the 0x0ba6 UDP Checksum is show as correct, but below when
both packets are shown individually, Wireshark shows the checksum as
unverified because it would need to include both packets in computing
the checksum and the Reassemble fragmented IPv4 datagrams" is
unselected (so that the headers could be shown as they actually are)
Packet capture at Source:
No. Time Source Destination Protocol Length Info
1 0.000000 10.0.4.6 10.202.126.219 SIP/SDP 1410 Request: INVITE sip:7039710421@10.202.126.219;user=phone |
Frame 1: 1410 bytes on wire (11280 bits), 1410 bytes captured (11280 bits)
Ethernet II, Src: fa:16:3e:0d:dc:d6 (fa:16:3e:0d:dc:d6), Dst: fa:16:3e:40:22:5b (fa:16:3e:40:22:5b)
Internet Protocol Version 4, Src: 10.0.4.6, Dst: 10.202.126.219
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x10 (DSCP: Unknown, ECN: Not-ECT)
Total Length: 1396
Identification: 0x3d0f (15631)
Flags: 0x01 (More Fragments)
Fragment offset: 0
Time to live: 64
Protocol: UDP (17)
Header checksum: 0x80af [correct]
[Header checksum status: Good]
[Calculated Checksum: 0x80af]
Source: 10.0.4.6
Destination: 10.202.126.219
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: 5060, Dst Port: 5060
Source Port: 5060
Destination Port: 5060
Length: 1451
Checksum: 0x0ba6 [unverified]
[Checksum Status: Unverified]
[Stream index: 0]
Session Initiation Protocol (INVITE)
Request-Line: INVITE sip:7039710421@10.202.126.219;user=phone SIP/2.0
Message Header
Message Body
No. Time Source Destination Protocol Length Info
2 0.000012 10.0.4.6 10.202.126.219 IPv4 109 Fragmented IP protocol (proto=UDP 17, off=1376, ID=3d0f)
Frame 2: 109 bytes on wire (872 bits), 109 bytes captured (872 bits)
Ethernet II, Src: fa:16:3e:0d:dc:d6 (fa:16:3e:0d:dc:d6), Dst: fa:16:3e:40:22:5b (fa:16:3e:40:22:5b)
Internet Protocol Version 4, Src: 10.0.4.6, Dst: 10.202.126.219
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x10 (DSCP: Unknown, ECN: Not-ECT)
Total Length: 95
Identification: 0x3d0f (15631)
Flags: 0x00
Fragment offset: 1376
Time to live: 64
Protocol: UDP (17)
Header checksum: 0xa518 [correct]
[Header checksum status: Good]
[Calculated Checksum: 0xa518]
Source: 10.0.4.6
Destination: 10.202.126.219
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
Data (75 bytes)
Packet capture at Destination
No. Time Source Destination Protocol Length Info
1 0.000000 172.30.225.135 10.202.126.219 SIP/SDP 1487 Request: INVITE sip:7039710421@10.202.126.219;user=phone |
Frame 1: 1487 bytes on wire (11896 bits), 1487 bytes captured (11896 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 172.30.225.135, Dst: 10.202.126.219
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x10 (DSCP: Unknown, ECN: Not-ECT)
Total Length: 1471
Identification: 0x3d0f (15631)
Flags: 0x00
Fragment offset: 0
Time to live: 57
Protocol: UDP (17)
Header checksum: 0x27c4 [correct]
[Header checksum status: Good]
[Calculated Checksum: 0x27c4]
Source: 172.30.225.135
Destination: 10.202.126.219
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: 5060, Dst Port: 5060
Source Port: 5060
Destination Port: 5060
Length: 1451
Checksum: 0x8c05 [incorrect, should be 0x0ba6](maybe caused by "UDP checksum offload"?)
[Checksum Status: Bad]
[Stream index: 0]
Session Initiation Protocol (INVITE)
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1635765/+subscriptions
Follow ups
