Click here to go to the first RED TEAM post in this thread.   Thread: Socket times out?

Reply to Thread
Results 1 to 10 of 10
  1. #1 Socket times out? 
    After a few hundred commands I get fatal error on the socket connection:
    An existing connection was forcibly closed by the remote host.
    I've got "Keep Alive" set to true on my socket.

    It also seems to be traffic dependent with lots of traffic hundreds of packets per minute it takes about 35 seconds to get dropped. With only a handful of packets I get almost exactly a minute.
    Reply With Quote  
     

  2.   Click here to go to the next RED TEAM post in this thread.
  #2  
    How are you connected to the camera, Ethernet, REDLINK BRIDGE, etc?
    Reply With Quote  
     

  3. #3  
    Ethernet through a Gigabit switch.
    Reply With Quote  
     

  4.   Click here to go to the next RED TEAM post in this thread.
  #4  
    Is the LAN indicator on the bottom bar of your camera GREEN or YELLOW? Do you have the "Enable External Control" checkbox checked in the Communication/Ethernet dialog?
    Reply With Quote  
     

  5. #5  
    Green.

    And Yep.
    Reply With Quote  
     

  6. #6  
    Here is the trigger:

    Code:
    No.     Time           Source                Destination           Protocol Length Info
       2097 38.894772000   192.168.94.174        192.168.94.37         TCP      60     [TCP ACKed unseen segment] lmsocialserver > 61083 [RST, ACK] Seq=128642 Ack=1610136541 Win=256 Len=0
    
    Frame 2097: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface 0
        Interface id: 0
        Encapsulation type: Ethernet (1)
        Arrival Time: Mar  9, 2015 17:17:07.237573000 Pacific Daylight Time
        [Time shift for this packet: 0.000000000 seconds]
        Epoch Time: 1425946627.237573000 seconds
        [Time delta from previous captured frame: 1.101056000 seconds]
        [Time delta from previous displayed frame: 1.101056000 seconds]
        [Time since reference or first frame: 38.894772000 seconds]
        Frame Number: 2097
        Frame Length: 60 bytes (480 bits)
        Capture Length: 60 bytes (480 bits)
        [Frame is marked: False]
        [Frame is ignored: False]
        [Protocols in frame: eth:ip:tcp]
        [Coloring Rule Name: ___conversation_color_filter___02]
        [Coloring Rule String: ip.addr eq 192.168.94.174 and ip.addr eq 192.168.94.37]
    Ethernet II, Src: RedDigit_02:39:03 (2c:b6:9d:02:39:03), Dst: AsustekC_c8:eb:f9 (c8:60:00:c8:eb:f9)
        Destination: AsustekC_c8:eb:f9 (c8:60:00:c8:eb:f9)
            Address: AsustekC_c8:eb:f9 (c8:60:00:c8:eb:f9)
            .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
            .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        Source: RedDigit_02:39:03 (2c:b6:9d:02:39:03)
            Address: RedDigit_02:39:03 (2c:b6:9d:02:39:03)
            .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
            .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        Type: IP (0x0800)
        Padding: 000000000000
    Internet Protocol Version 4, Src: 192.168.94.174 (192.168.94.174), Dst: 192.168.94.37 (192.168.94.37)
        Version: 4
        Header length: 20 bytes
        Differentiated Services Field: 0x10 (DSCP 0x04: Unknown DSCP; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
            0001 00.. = Differentiated Services Codepoint: Unknown (0x04)
            .... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
        Total Length: 40
        Identification: 0xbf84 (49028)
        Flags: 0x00
        Fragment offset: 0
        Time to live: 128
        Protocol: TCP (6)
        Header checksum: 0x3d17 [validation disabled]
        Source: 192.168.94.174 (192.168.94.174)
        Destination: 192.168.94.37 (192.168.94.37)
        [Source GeoIP: Unknown]
        [Destination GeoIP: Unknown]
    Transmission Control Protocol, Src Port: lmsocialserver (1111), Dst Port: 61083 (61083), Seq: 128642, Ack: 1610136541, Len: 0
        Source port: lmsocialserver (1111)
        Destination port: 61083 (61083)
        [Stream index: 0]
        Sequence number: 128642    (relative sequence number)
        Acknowledgment number: 1610136541    (relative ack number)
        Header length: 20 bytes
        Flags: 0x014 (RST, ACK)
            000. .... .... = Reserved: Not set
            ...0 .... .... = Nonce: Not set
            .... 0... .... = Congestion Window Reduced (CWR): Not set
            .... .0.. .... = ECN-Echo: Not set
            .... ..0. .... = Urgent: Not set
            .... ...1 .... = Acknowledgment: Set
            .... .... 0... = Push: Not set
            .... .... .1.. = Reset: Set
            .... .... ..0. = Syn: Not set
            .... .... ...0 = Fin: Not set
        Window size value: 256
        [Calculated window size: 256]
        [Window size scaling factor: -2 (no window scaling used)]
        Checksum: 0x9fe6 [validation disabled]
            [Good Checksum: False]
            [Bad Checksum: False]
        [SEQ/ACK analysis]
            [TCP Analysis Flags]
                [This frame ACKs a segment we have not seen]
    That seems to freak out my socket and cause everything to breakdown. Trying to identify if it's in my code or if it's in the RCP server.
    Reply With Quote  
     

  7.   Click here to go to the next RED TEAM post in this thread.
  #7  
    Quote Originally Posted by Gavin Greenwalt View Post
    Here is the trigger:

    Code:
    No.     Time           Source                Destination           Protocol Length Info
       2097 38.894772000   192.168.94.174        192.168.94.37         TCP      60     [TCP ACKed unseen segment] lmsocialserver > 61083 [RST, ACK] Seq=128642 Ack=1610136541 Win=256 Len=0
    
    Frame 2097: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface 0
        Interface id: 0
        Encapsulation type: Ethernet (1)
        Arrival Time: Mar  9, 2015 17:17:07.237573000 Pacific Daylight Time
        [Time shift for this packet: 0.000000000 seconds]
        Epoch Time: 1425946627.237573000 seconds
        [Time delta from previous captured frame: 1.101056000 seconds]
        [Time delta from previous displayed frame: 1.101056000 seconds]
        [Time since reference or first frame: 38.894772000 seconds]
        Frame Number: 2097
        Frame Length: 60 bytes (480 bits)
        Capture Length: 60 bytes (480 bits)
        [Frame is marked: False]
        [Frame is ignored: False]
        [Protocols in frame: eth:ip:tcp]
        [Coloring Rule Name: ___conversation_color_filter___02]
        [Coloring Rule String: ip.addr eq 192.168.94.174 and ip.addr eq 192.168.94.37]
    Ethernet II, Src: RedDigit_02:39:03 (2c:b6:9d:02:39:03), Dst: AsustekC_c8:eb:f9 (c8:60:00:c8:eb:f9)
        Destination: AsustekC_c8:eb:f9 (c8:60:00:c8:eb:f9)
            Address: AsustekC_c8:eb:f9 (c8:60:00:c8:eb:f9)
            .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
            .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        Source: RedDigit_02:39:03 (2c:b6:9d:02:39:03)
            Address: RedDigit_02:39:03 (2c:b6:9d:02:39:03)
            .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
            .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        Type: IP (0x0800)
        Padding: 000000000000
    Internet Protocol Version 4, Src: 192.168.94.174 (192.168.94.174), Dst: 192.168.94.37 (192.168.94.37)
        Version: 4
        Header length: 20 bytes
        Differentiated Services Field: 0x10 (DSCP 0x04: Unknown DSCP; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
            0001 00.. = Differentiated Services Codepoint: Unknown (0x04)
            .... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
        Total Length: 40
        Identification: 0xbf84 (49028)
        Flags: 0x00
        Fragment offset: 0
        Time to live: 128
        Protocol: TCP (6)
        Header checksum: 0x3d17 [validation disabled]
        Source: 192.168.94.174 (192.168.94.174)
        Destination: 192.168.94.37 (192.168.94.37)
        [Source GeoIP: Unknown]
        [Destination GeoIP: Unknown]
    Transmission Control Protocol, Src Port: lmsocialserver (1111), Dst Port: 61083 (61083), Seq: 128642, Ack: 1610136541, Len: 0
        Source port: lmsocialserver (1111)
        Destination port: 61083 (61083)
        [Stream index: 0]
        Sequence number: 128642    (relative sequence number)
        Acknowledgment number: 1610136541    (relative ack number)
        Header length: 20 bytes
        Flags: 0x014 (RST, ACK)
            000. .... .... = Reserved: Not set
            ...0 .... .... = Nonce: Not set
            .... 0... .... = Congestion Window Reduced (CWR): Not set
            .... .0.. .... = ECN-Echo: Not set
            .... ..0. .... = Urgent: Not set
            .... ...1 .... = Acknowledgment: Set
            .... .... 0... = Push: Not set
            .... .... .1.. = Reset: Set
            .... .... ..0. = Syn: Not set
            .... .... ...0 = Fin: Not set
        Window size value: 256
        [Calculated window size: 256]
        [Window size scaling factor: -2 (no window scaling used)]
        Checksum: 0x9fe6 [validation disabled]
            [Good Checksum: False]
            [Bad Checksum: False]
        [SEQ/ACK analysis]
            [TCP Analysis Flags]
                [This frame ACKs a segment we have not seen]
    That seems to freak out my socket and cause everything to breakdown. Trying to identify if it's in my code or if it's in the RCP server.
    I haven't seen anything like this before. Can you capture it with a tool like Wireshark?
    Reply With Quote  
     

  8. #8  
    Here are two Wireshark captures:
    http://www.mediafire.com/download/uy...nect_01.pcapng
    http://www.mediafire.com/download/l8...nect_01.pcapng

    I also tried taking it off of the main network and put it onto a dedicated network and it performed the same on the different switch.
    Reply With Quote  
     

  9. #9  
    Ok, I'm 99% certain this is an application bug on my end. It looks like there is a buffer in my app not being cleared. For some reason I just noticed the window buffer size is perpetually shrinking. The last ACK always puts the WIN at less than the LEN of the next expected packet. So when RCP needs to send a new packet it's used up the entire receiving buffer in the app as indicated by a window size of like "13" so RCP properly kills the connection instead of sending a doomed packet.
    Reply With Quote  
     

  10.   This is the last RED TEAM post in this thread.   #10  
    Quote Originally Posted by Gavin Greenwalt View Post
    Ok, I'm 99% certain this is an application bug on my end. It looks like there is a buffer in my app not being cleared. For some reason I just noticed the window buffer size is perpetually shrinking. The last ACK always puts the WIN at less than the LEN of the next expected packet. So when RCP needs to send a new packet it's used up the entire receiving buffer in the app as indicated by a window size of like "13" so RCP properly kills the connection instead of sending a doomed packet.
    I'm glad you are getting somewhere in your debugging, unfortunately I hadn't had time to look through your captures yet.
    Reply With Quote  
     

Posting Permissions
  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts