1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

WRT inserting TCP RST.. oh my..

Discussion in 'HyperWRT Firmware' started by pbostley, Nov 28, 2005.

  1. pbostley

    pbostley Guest

    Ok, here is the setup:
    Code:
    <linux1>---------                             <PC1>
                           |                                |
    <PC2>-------<WRT1>----------------<WRT2>----<linux2>
                           |                                |
                       <tivo>                        [Internet]
    
    Linux1, linux2, and PC2 are hardwired. PC1, and tivo are wireless, and Tivo can't see WRT2 and PC1 can't see WRT1. The internet is hardwired on the WAN port (duh).. Sprinkle in a couple laptops, but they wander around...

    Both WRTs are WRT54Gv4 running "v4.70.6 - HyperWRT 2.1b1 - Thibor, Nov. 20, 2005" (ie. hacked up as WRT54GS'). Both are in WDS-AP mode. I have no security turned on, and I havn't done any "startup scripts" since the "nvram erase; reboot" one.

    Almost everything appears to be happy. All machines can see/ping each other on the network. Most applications are running well. Rsync (backups), email, web, steam, various games, vpn's etc..

    Here is the bizarre part: If an SSH session is started from PC2 to linux2, and left to do something that generates output (ie. top, ping etc..), and I do "something else" on PC2 to connect to the internet (ie. start steam, or firefox), WRT2 appears to be inserting a TCP RESET in to the SSH stream to PC2. (Clearly incorrect behavior)

    I have TCP dumps from linux2 and PC2 that confirm that PC2 is receiving a spurious reset, which linux2 is not sending.
    The ethernet mac source address is that of WRT2 not of linux2 like all the other traffic PC2 is receiving from that SSH session.

    At the end of this message are the last 3 packets of that stream (captured from PC2), with the last being the RESET. On the linux2 side the ack (frame 327 below) never arrives. (Also ignore the "TCP Checksum incorrect" message, an this network card does TCP checksum offloading)

    Anyone have any ideas? The "logreset" iptables rule in WRT2 still has a count of 0. I can reproduce this on linux1 also, but not apparently from PC1. Turning off frame bursting doesn't help.

    If I put WRT1 into WET mode the problem goes away, but it also cuts <tivo> out of the network.

    Code:
    No.     Time        Source                Destination           Protocol Info
        326 71.655977   192.168.1.10          192.168.1.51          SSH      Encrypted response packet len=52
    
    Frame 326 (106 bytes on wire, 106 bytes captured)
        Arrival Time: Nov 27, 2005 17:14:09.601705000
        Time delta from previous packet: 0.000532000 seconds
        Time since reference or first frame: 71.655977000 seconds
        Frame Number: 326
        Packet Length: 106 bytes
        Capture Length: 106 bytes
        Protocols in frame: eth:ip:tcp:ssh
    Ethernet II, Src: 192.168.1.10 (00:80:c8:b9:15:49), Dst: 192.168.1.51 (00:04:61:98:eb:72)
        Destination: 192.168.1.51 (00:04:61:98:eb:72)
        Source: 192.168.1.10 (00:80:c8:b9:15:49)
        Type: IP (0x0800)
    Internet Protocol, Src: 192.168.1.10 (192.168.1.10), Dst: 192.168.1.51 (192.168.1.51)
        Version: 4
        Header length: 20 bytes
        Differentiated Services Field: 0x10 (DSCP 0x04: Unknown DSCP; ECN: 0x00)
            0001 00.. = Differentiated Services Codepoint: Unknown (0x04)
            .... ..0. = ECN-Capable Transport (ECT): 0
            .... ...0 = ECN-CE: 0
        Total Length: 92
        Identification: 0xb609 (46601)
        Flags: 0x04 (Don't Fragment)
            0... = Reserved bit: Not set
            .1.. = Don't fragment: Set
            ..0. = More fragments: Not set
        Fragment offset: 0
        Time to live: 64
        Protocol: TCP (0x06)
        Header checksum: 0x00f5 [correct]
            Good: True
            Bad : False
        Source: 192.168.1.10 (192.168.1.10)
        Destination: 192.168.1.51 (192.168.1.51)
    Transmission Control Protocol, Src Port: 22 (22), Dst Port: 1260 (1260), Seq: 1708956614, Ack: 4145404806, Len: 52
        Source port: 22 (22)
        Destination port: 1260 (1260)
        Sequence number: 1708956614
        Next sequence number: 1708956666
        Acknowledgement number: 4145404806
        Header length: 20 bytes
        Flags: 0x0018 (PSH, ACK)
            0... .... = Congestion Window Reduced (CWR): Not set
            .0.. .... = ECN-Echo: Not set
            ..0. .... = Urgent: Not set
            ...1 .... = Acknowledgment: Set
            .... 1... = Push: Set
            .... .0.. = Reset: Not set
            .... ..0. = Syn: Not set
            .... ...0 = Fin: Not set
        Window size: 8576
        Checksum: 0xddc2 [correct]
    SSH Protocol
        Encrypted Packet: 0F378C15A04A1A13F01606C5D24D050E03ABF31CD8D0D223...
    
    No.     Time        Source                Destination           Protocol Info
        327 71.655997   192.168.1.51          192.168.1.10          TCP      1260 > 22 [ACK] Seq=4145404806 Ack=1708956666 Win=25596 [TCP CHECKSUM INCORRECT] Len=0
    
    Frame 327 (54 bytes on wire, 54 bytes captured)
        Arrival Time: Nov 27, 2005 17:14:09.601725000
        Time delta from previous packet: 0.000020000 seconds
        Time since reference or first frame: 71.655997000 seconds
        Frame Number: 327
        Packet Length: 54 bytes
        Capture Length: 54 bytes
        Protocols in frame: eth:ip:tcp
    Ethernet II, Src: 192.168.1.51 (00:04:61:98:eb:72), Dst: 192.168.1.10 (00:80:c8:b9:15:49)
        Destination: 192.168.1.10 (00:80:c8:b9:15:49)
        Source: 192.168.1.51 (00:04:61:98:eb:72)
        Type: IP (0x0800)
    Internet Protocol, Src: 192.168.1.51 (192.168.1.51), Dst: 192.168.1.10 (192.168.1.10)
        Version: 4
        Header length: 20 bytes
        Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
            0000 00.. = Differentiated Services Codepoint: Default (0x00)
            .... ..0. = ECN-Capable Transport (ECT): 0
            .... ...0 = ECN-CE: 0
        Total Length: 40
        Identification: 0x594d (22861)
        Flags: 0x04 (Don't Fragment)
            0... = Reserved bit: Not set
            .1.. = Don't fragment: Set
            ..0. = More fragments: Not set
        Fragment offset: 0
        Time to live: 128
        Protocol: TCP (0x06)
        Header checksum: 0x1df5 [correct]
            Good: True
            Bad : False
        Source: 192.168.1.51 (192.168.1.51)
        Destination: 192.168.1.10 (192.168.1.10)
    Transmission Control Protocol, Src Port: 1260 (1260), Dst Port: 22 (22), Seq: 4145404806, Ack: 1708956666, Len: 0
        Source port: 1260 (1260)
        Destination port: 22 (22)
        Sequence number: 4145404806
        Acknowledgement number: 1708956666
        Header length: 20 bytes
        Flags: 0x0010 (ACK)
            0... .... = Congestion Window Reduced (CWR): Not set
            .0.. .... = ECN-Echo: Not set
            ..0. .... = Urgent: Not set
            ...1 .... = Acknowledgment: Set
            .... 0... = Push: Not set
            .... .0.. = Reset: Not set
            .... ..0. = Syn: Not set
            .... ...0 = Fin: Not set
        Window size: 25596
        Checksum: 0x83a8 [incorrect, should be 0xeed4]
        SEQ/ACK analysis
            This is an ACK to the segment in frame: 326
            The RTT to ACK the segment was: 0.000020000 seconds
    
    No.     Time        Source                Destination           Protocol Info
        328 71.657577   192.168.1.10          192.168.1.51          TCP      22 > 1260 [RST] Seq=1708956666 Ack=0 Win=0 Len=0
    
    Frame 328 (60 bytes on wire, 60 bytes captured)
        Arrival Time: Nov 27, 2005 17:14:09.603305000
        Time delta from previous packet: 0.001580000 seconds
        Time since reference or first frame: 71.657577000 seconds
        Frame Number: 328
        Packet Length: 60 bytes
        Capture Length: 60 bytes
        Protocols in frame: eth:ip:tcp
    Ethernet II, Src: 192.168.1.1 (00:14:bf:31:02:96), Dst: 192.168.1.51 (00:04:61:98:eb:72)
        Destination: 192.168.1.51 (00:04:61:98:eb:72)
        Source: 192.168.1.1 (00:14:bf:31:02:96)
        Type: IP (0x0800)
        Trailer: 00000C89EFAC
    Internet Protocol, Src: 192.168.1.10 (192.168.1.10), Dst: 192.168.1.51 (192.168.1.51)
        Version: 4
        Header length: 20 bytes
        Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
            0000 00.. = Differentiated Services Codepoint: Default (0x00)
            .... ..0. = ECN-Capable Transport (ECT): 0
            .... ...0 = ECN-CE: 0
        Total Length: 40
        Identification: 0x4769 (18281)
        Flags: 0x04 (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: TCP (0x06)
        Header checksum: 0x70d9 [correct]
            Good: True
            Bad : False
        Source: 192.168.1.10 (192.168.1.10)
        Destination: 192.168.1.51 (192.168.1.51)
    Transmission Control Protocol, Src Port: 22 (22), Dst Port: 1260 (1260), Seq: 1708956666, Ack: 0, Len: 0
        Source port: 22 (22)
        Destination port: 1260 (1260)
        Sequence number: 1708956666
        Header length: 20 bytes
        Flags: 0x0004 (RST)
            0... .... = Congestion Window Reduced (CWR): Not set
            .0.. .... = ECN-Echo: Not set
            ..0. .... = Urgent: Not set
            ...0 .... = Acknowledgment: Not set
            .... 0... = Push: Not set
            .... .1.. = Reset: Set
            .... ..0. = Syn: Not set
            .... ...0 = Fin: Not set
        Window size: 0
        Checksum: 0x257a [correct]
    
    NEW INFO 11/28/05
    I rolled the software to Tofu10 and the problem still occurs, so its not speed booster related. If I turn WEP ON the problem goes away, so atleast I have a fix for now, but...

    If I swap out WRT1 with a WAP54G (in WDS mode) the problem also goes away.
     

Share This Page