Hi the router is actually is a linux running on RHEL6.8 (2.6.32-642.4.2.el6.x86_64). it uses iptables to do SNAT aand DNAT forward. On Tue, Feb 21, 2017 at 11:53 PM, Xin Long <lucien.xin@xxxxxxxxx> wrote: > On Tue, Feb 21, 2017 at 12:26 PM, Sun Paul <paulrbk@xxxxxxxxx> wrote: >> Hi, >> >> sorry to get back late, the platform is running on KVM. and this >> problem is resolved by moving to VMware environment, however, a new >> problem is coming out, we noticed that the HB REQ is being ABORT from >> client. >> >> >> 03:32:35.233572 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1) >> [HB REQ] (from server to sctp router) >> 03:32:35.233603 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1) >> [HB REQ] (from sctp router to client) >> 03:32:35.233852 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1) >> [ABORT] (from client to sctp router) >> >> 03:32:37.928679 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1) [HB REQ] >> 03:32:37.928717 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1) [HB REQ] >> 03:32:37.929247 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1) [ABORT] >> >> For the above packet flow, 10.165.250.22 is the server and >> 192.168.2.13 is the client, the server 10.165.250.22 sends HB REQ to >> client 192.168.2.13 through 192.168.2.14 (the SCTP router), and the >> SCTP router change the src address before forward the HB REQ to the >> client. >> >> But somehow the client is ABORT the HB REQ, any idea? is it related to >> the HEARTBEAT information? or the checksum again>? > The incorrect checksum won't cause ABORT, but the abnormal HB REQ > could be, if HB information was modified when calculating the checksum > on router, the ABORT may be caused in client process. > > is your SCTP router linux ? if yes, what's the kernel version ? > >> >> On Fri, Jan 13, 2017 at 9:19 PM, Michael Tuexen >> <Michael.Tuexen@xxxxxxxxxxxxxxxxx> wrote: >>>> On 13 Jan 2017, at 10:43, Michael Tuexen <Michael.Tuexen@xxxxxxxxxxxxxxxxx> wrote: >>>> >>>> Your router does NOT change any field in the SCTP packet, but the >>>> SCTP checksum was modified from >>>> Checksum: 0xbaea49e5 (not verified) >>>> to >>>> Checksum: 0xa9a86d3f (not verified) >>>> At least one of these is wrong. Read the tracefiles in wireshark and >>>> enable checksum validation and wireshark will tell you which one is >>>> correct. (That is why I asked for .pcap file instead of a .txt). >>>> >>>> My guess is that the initial checksum is correct and your box middlebox >>>> not only changes the destination address and ttl field and header >>>> checksum in the IP-header (which is expected) but also incorrectly the >>>> SCTP checksum. Since no field in the SCTP packet has changed, the checksum >>>> must be the same. >>> At the server have a look at the SNMP counters: >>> cat /proc/net/sctp/snmp >>> You should find a line staring with >>> SctpChecksumErrors >>> If the number reported there is positive, the node received packets >>> with checksum errors. >>> >>> Best regards >>> Michael >>>> >>>> Best regards >>>> Michael >>>>> On 13 Jan 2017, at 04:29, Sun Paul <paulrbk@xxxxxxxxx> wrote: >>>>> >>>>> Frame 2: 98 bytes on wire (784 bits), 98 bytes captured (784 bits) >>>>> Encapsulation type: Ethernet (1) >>>>> Arrival Time: Jan 6, 2017 16:52:49.662321000 Malay Peninsula Standard Time >>>>> [Time shift for this packet: 0.000000000 seconds] >>>>> Epoch Time: 1483692769.662321000 seconds >>>>> [Time delta from previous captured frame: 0.000179000 seconds] >>>>> [Time delta from previous displayed frame: 0.000179000 seconds] >>>>> [Time since reference or first frame: 0.000179000 seconds] >>>>> Frame Number: 2 >>>>> Frame Length: 98 bytes (784 bits) >>>>> Capture Length: 98 bytes (784 bits) >>>>> [Frame is marked: False] >>>>> [Frame is ignored: False] >>>>> [Protocols in frame: eth:ethertype:ip:sctp] >>>>> Ethernet II, Src: Vmware_81:41:6b (00:50:56:81:41:6b), Dst: >>>>> Vmware_81:a6:a3 (00:50:56:81:a6:a3) >>>>> Destination: Vmware_81:a6:a3 (00:50:56:81:a6:a3) >>>>> Address: Vmware_81:a6:a3 (00:50:56:81:a6:a3) >>>>> .... ..0. .... .... .... .... = LG bit: Globally unique >>>>> address (factory default) >>>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast) >>>>> Source: Vmware_81:41:6b (00:50:56:81:41:6b) >>>>> Address: Vmware_81:41:6b (00:50:56:81:41:6b) >>>>> .... ..0. .... .... .... .... = LG bit: Globally unique >>>>> address (factory default) >>>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast) >>>>> Type: IPv4 (0x0800) >>>>> Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.66 >>>>> 0100 .... = Version: 4 >>>>> .... 0101 = Header Length: 20 bytes (5) >>>>> Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0)) >>>>> 0000 00.. = Differentiated Services Codepoint: Default (0) >>>>> .... ..10 = Explicit Congestion Notification: ECN-Capable >>>>> Transport codepoint '10' (2) >>>>> Total Length: 84 >>>>> Identification: 0x0000 (0) >>>>> Flags: 0x02 (Don't Fragment) >>>>> 0... .... = Reserved bit: Not set >>>>> .1.. .... = Don't fragment: Set >>>>> ..0. .... = More fragments: Not set >>>>> Fragment offset: 0 >>>>> Time to live: 63 >>>>> Protocol: SCTP (132) >>>>> Header checksum: 0x1d3d [validation disabled] >>>>> [Good: False] >>>>> [Bad: False] >>>>> Source: 192.168.206.83 >>>>> Destination: 192.168.206.66 >>>>> [Source GeoIP: Unknown] >>>>> [Destination GeoIP: Unknown] >>>>> Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst >>>>> Port: 3868 (3868) >>>>> Source port: 50001 >>>>> Destination port: 3868 >>>>> Verification tag: 0x00000000 >>>>> [Assocation index: 0] >>>>> Checksum: 0xa9a86d3f (not verified) >>>>> >>>>> INIT chunk (Outbound streams: 3000, inbound streams: 3000) >>>>> Chunk type: INIT (1) >>>>> 0... .... = Bit: Stop processing of the packet >>>>> .0.. .... = Bit: Do not report >>>>> Chunk flags: 0x00 >>>>> Chunk length: 52 >>>>> Initiate tag: 0xe79f40cb >>>>> Advertised receiver window credit (a_rwnd): 62464 >>>>> Number of outbound streams: 3000 >>>>> Number of inbound streams: 3000 >>>>> Initial TSN: 176990880 >>>>> IPv4 address parameter (Address: 192.168.206.83) >>>>> Parameter type: IPv4 address (0x0005) >>>>> 0... .... .... .... = Bit: Stop processing of chunk >>>>> .0.. .... .... .... = Bit: Do not report >>>>> Parameter length: 8 >>>>> IP Version 4 address: 192.168.206.83 >>>>> IPv4 address parameter (Address: 192.168.1.83) >>>>> Parameter type: IPv4 address (0x0005) >>>>> 0... .... .... .... = Bit: Stop processing of chunk >>>>> .0.. .... .... .... = Bit: Do not report >>>>> Parameter length: 8 >>>>> IP Version 4 address: 192.168.1.83 >>>>> Supported address types parameter (Supported types: IPv6, IPv4) >>>>> Parameter type: Supported address types (0x000c) >>>>> 0... .... .... .... = Bit: Stop processing of chunk >>>>> .0.. .... .... .... = Bit: Do not report >>>>> Parameter length: 8 >>>>> Supported address type: IPv6 address (6) >>>>> Supported address type: IPv4 address (5) >>>>> ECN parameter >>>>> Parameter type: ECN (0x8000) >>>>> 1... .... .... .... = Bit: Skip parameter and continue >>>>> processing of the chunk >>>>> .0.. .... .... .... = Bit: Do not report >>>>> Parameter length: 4 >>>>> Forward TSN supported parameter >>>>> Parameter type: Forward TSN supported (0xc000) >>>>> 1... .... .... .... = Bit: Skip parameter and continue >>>>> processing of the chunk >>>>> .1.. .... .... .... = Bit: Do report >>>>> Parameter length: 4 >>>> >>>> -- >>>> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in >>>> the body of a message to majordomo@xxxxxxxxxxxxxxx >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
