yahoo-eng-team team mailing list archive

[Launchpad Bug Tracker <1635765@xxxxxxxxxxxxxxxxxx>]

[Expired for neutron because there has been no activity for 60 days.]

** Changed in: neutron
       Status: Incomplete => Expired

-- 
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:
  Expired

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