WRT54GX2: TCP packets blocked (except SYN/SYN-ACK) to internet

I'm using WRT54GX2 with latest FW 1.01.22 and I've been running into internet connectivity with one of my laptop (Toshiba MX35-S149 using Atheros). From this laptop DNS/ping works to the internet (UDP/ICMP) but all of the TCP data packets from the internet are being blocked by the router (I think). All of the other PC's continue to work with no problem.
Rebooting the router (power cycle) causes thing to work again for this laptop but after some time (15-20 minutes or so) once again the problem comes back. I've already spent about 3 hours with support on this but no luck.
 I did a packet capture on the laptop and any HTTP request show TCP SYN, SYN-ACK packets but no data packets. The laptop continues to do the retransmission. At this point I can still PING and DNS resolve any of the names.
The HTTP to the router's page (192.168.1.1) continues to work without any problem (still using the wireless NIC). Hard-wiring the laptop to router works fine.
I asked the support if I can do a packet capture on the router itself but I was told "That is not possible".
I'll add the packet capture files later today.
Any help is appreciated as I don't think I'll get any help from the tech-support.
TIA,
Navras

Interesting - I have a similar problem however I am trying to block packets going out. So you say that it allows the TCP for a little while then later it is blocked.
Why are you trying to pass TCP into the computer specifically?
Do you have a firewall on your laptop that you can check the logs off?
I have been with support for my issue which is basically the BLOCKED SERVICES options are all greyed out. I need to block udp/tcp packets from going out on exactly the same router, same firmware as yours. They just read scripts from their help desk manuals and do not really seem to understand problems that are NOT in the scripts. Too bad I was hoping after cisco took over linksys would get better at customer support, not the other way.
I saw a post previously that states that the same router DOES NOT HAVE the blocked services as a function. The manual and screen seem to indicate otherwise.
Interesting...let us know what happens.
danee

Similar Messages

  • Non-global zone sending TCP SYN-ACK packet over wrong interface.

    After spending many hours looking at ipmon/ethereal logs, I believe I've found
    a explanation (a bug?) for the following strange behaviour (Solaris 10u1):
    I've got a non-global zone with Apache2 with dedicated IP and bound to interface e1000g2 of a Sun X4200 box. The global zone has a different dedicated IP bound to a different interface e1000g0.
    When I point a browser at the web site, the HTML page often comes up immediately, but sometimes it will hang and only load when I press the reload browser button one or multiple times. This is reproducible with different browsers from different networks with or without DNS resolution. It's reproducible with other non-local zones configured alike and running different TCP based services (namely SSH or non-Apache HTTP).
    This is what happens in a failing case (Ethereal client dump "dump_failed.txt" and IPF log "att1.txt" lines 1-3 pp): the incoming TCP SYN comes over interface e1000g2 (correct) and is passed by IPF. However, the non-global zone sends the TCP SYN-ACK package back over interface e1000g0, which is wrong and causes IPF to fail to build a correct state entry. Then, afterwards, the response packets from the webserver will be filtered by IPF, since it has no state entry.
    In the success case (Ethereal client dump "dump_success.txt" and IPF log "att1.txt" lines 19-21 pp), the incoming TCP SYN is answered correctly by a TCP SYN-ACK both over interface e1000g2. IPF can build a state entry and all subsequent packets from the webserver reach the client.
    =====
    The non-global zone has this setup:
    zonecfg:ws1> info
    ...snip...
    net:
    address: 62.146.25.34
    physical: e1000g2
    zonecfg:ws1>
    =====
    The relevant (as of the IPF log) IPF rules are:
    rule 1: block out log all
    rule 16: pass in log quick proto tcp from any to 62.146.25.34 port = 80 keep state
    =====
    If I didn't miss an important point, I suspect this to be a bug in Zones and/or IPF.
    Any hints?
    Thx,
    Tobias
    "att1.txt":
    LINE     PACKET_DT     PACKET_FS     PACKET_IFC     RULE_NUMBER     RULE_ACTION     SOURCE_IP     SOURCE_PORT     DEST_IP     DEST_PORT     PROTOCOL     TCP_FLAGS
    1     08.05.2006 21:24:09     786741     e1000g2     16     p     84.56.16.159     60693     62.146.25.34     80     tcp     S
    2     08.05.2006 21:24:09     786863     e1000g0     16     p     62.146.25.34     80     84.56.16.159     60693     tcp     AS
    3     08.05.2006 21:24:09     808218     e1000g2     16     p     84.56.16.159     60693     62.146.25.34     80     tcp     A
    4     08.05.2006 21:24:09     837170     e1000g2     16     p     84.56.16.159     60693     62.146.25.34     80     tcp     AP
    5     08.05.2006 21:24:09     837189     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     A
    6     08.05.2006 21:24:09     837479     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     AP
    7     08.05.2006 21:24:12     823801     e1000g2     16     p     84.56.16.159     60693     62.146.25.34     80     tcp     AP
    8     08.05.2006 21:24:12     823832     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     A
    9     08.05.2006 21:24:13     210039     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     AP
    10     08.05.2006 21:24:18     839318     e1000g2     16     p     84.56.16.159     60693     62.146.25.34     80     tcp     AP
    11     08.05.2006 21:24:18     839351     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     A
    12     08.05.2006 21:24:19     970040     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     AP
    13     08.05.2006 21:24:24     840073     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     AF
    14     08.05.2006 21:24:30     870503     e1000g2     16     p     84.56.16.159     60693     62.146.25.34     80     tcp     AP
    15     08.05.2006 21:24:30     870538     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     A
    16     08.05.2006 21:24:33     480059     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     AFP
    17     08.05.2006 21:24:45     347464     e1000g2     16     p     84.56.16.159     60693     62.146.25.34     80     tcp     AF
    18     08.05.2006 21:24:45     347498     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     A
    19     08.05.2006 21:24:47     857068     e1000g2     16     p     84.56.16.159     60694     62.146.25.34     80     tcp     S
    20     08.05.2006 21:24:47     857118     e1000g2     16     p     62.146.25.34     80     84.56.16.159     60694     tcp     AS
    21     08.05.2006 21:24:47     878257     e1000g2     16     p     84.56.16.159     60694     62.146.25.34     80     tcp     A
    22     08.05.2006 21:24:47     907630     e1000g2     16     p     84.56.16.159     60694     62.146.25.34     80     tcp     AP
    23     08.05.2006 21:24:47     907644     e1000g2     16     p     62.146.25.34     80     84.56.16.159     60694     tcp     A
    24     08.05.2006 21:24:47     907892     e1000g2     16     p     62.146.25.34     80     84.56.16.159     60694     tcp     AP
    25     08.05.2006 21:24:47     976361     e1000g2     16     p     84.56.16.159     60694     62.146.25.34     80     tcp     AP
    26     08.05.2006 21:24:47     976375     e1000g2     16     p     62.146.25.34     80     84.56.16.159     60694     tcp     A
    27     08.05.2006 21:24:47     976487     e1000g2     16     p     62.146.25.34     80     84.56.16.159     60694     tcp     AP
    28     08.05.2006 21:24:48     127599     e1000g2     16     p     84.56.16.159     60694     62.146.25.34     80     tcp     A
    29     08.05.2006 21:24:54     932569     e1000g2     16     p     84.56.16.159     60693     62.146.25.34     80     tcp     AFP
    30     08.05.2006 21:24:54     932595     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     A
    31     08.05.2006 21:25:00     490052     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     AFP
    32     08.05.2006 21:25:02     980057     e1000g2     16     p     62.146.25.34     80     84.56.16.159     60694     tcp     AF
    33     08.05.2006 21:25:03     1890     e1000g2     16     p     84.56.16.159     60694     62.146.25.34     80     tcp     A
    34     08.05.2006 21:25:09     907916     e1000g2     16     p     84.56.16.159     60694     62.146.25.34     80     tcp     AF
    35     08.05.2006 21:25:09     907949     e1000g2     16     p     62.146.25.34     80     84.56.16.159     60694     tcp     A
    36     08.05.2006 21:25:42     948502     e1000g2     16     p     84.56.16.159     60693     62.146.25.34     80     tcp     AFP
    37     08.05.2006 21:25:42     948535     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     A
    38     08.05.2006 21:25:54     500051     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     AFP
    39     08.05.2006 21:26:54     510046     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     AFP
    40     08.05.2006 21:27:54     520041     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     AFP
    41     08.05.2006 21:28:54     530040     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     AFP
    42     08.05.2006 21:29:54     540039     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     AFP
    43     08.05.2006 21:30:54     550039     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     AFP
    44     08.05.2006 21:31:54     560041     e1000g2     1     b     62.146.25.34     80     84.56.16.159     60693     tcp     AFP
    "dump_failed.txt":
    No. Time Source Destination Protocol Info
    1 0.000000 192.168.1.101 62.146.25.34 TCP 1079 > http [SYN] Seq=0 Len=0 MSS=1460
    Frame 1 (62 bytes on wire, 62 bytes captured)
    Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
    Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    Total Length: 48
    Identification: 0x0269 (617)
    Flags: 0x04 (Don't Fragment)
    Fragment offset: 0
    Time to live: 128
    Protocol: TCP (0x06)
    Header checksum: 0xde9d [correct]
    Source: 192.168.1.101 (192.168.1.101)
    Destination: 62.146.25.34 (62.146.25.34)
    Transmission Control Protocol, Src Port: 1079 (1079), Dst Port: http (80), Seq: 0, Len: 0
    Source port: 1079 (1079)
    Destination port: http (80)
    Sequence number: 0 (relative sequence number)
    Header length: 28 bytes
    Flags: 0x0002 (SYN)
    Window size: 65535
    Checksum: 0x5c3c [correct]
    Options: (8 bytes)
    No. Time Source Destination Protocol Info
    2 0.022698 62.146.25.34 192.168.1.101 TCP http > 1079 [SYN, ACK] Seq=0 Ack=1 Win=49368 Len=0 MSS=1452
    Frame 2 (62 bytes on wire, 62 bytes captured)
    Ethernet II, Src: D-Link_9b:09:44 (00:0d:88:9b:09:44), Dst: FujitsuS_81:79:ea (00:30:05:81:79:ea)
    Internet Protocol, Src: 62.146.25.34 (62.146.25.34), Dst: 192.168.1.101 (192.168.1.101)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    Total Length: 48
    Identification: 0x002f (47)
    Flags: 0x04 (Don't Fragment)
    Fragment offset: 0
    Time to live: 50
    Protocol: TCP (0x06)
    Header checksum: 0x2ed8 [correct]
    Source: 62.146.25.34 (62.146.25.34)
    Destination: 192.168.1.101 (192.168.1.101)
    Transmission Control Protocol, Src Port: http (80), Dst Port: 1079 (1079), Seq: 0, Ack: 1, Len: 0
    Source port: http (80)
    Destination port: 1079 (1079)
    Sequence number: 0 (relative sequence number)
    Acknowledgement number: 1 (relative ack number)
    Header length: 28 bytes
    Flags: 0x0012 (SYN, ACK)
    Window size: 49368
    Checksum: 0xd017 [correct]
    Options: (8 bytes)
    No. Time Source Destination Protocol Info
    3 0.022749 192.168.1.101 62.146.25.34 TCP 1079 > http [ACK] Seq=1 Ack=1 Win=65535 [TCP CHECKSUM INCORRECT] Len=0
    Frame 3 (54 bytes on wire, 54 bytes captured)
    Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
    Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    Total Length: 40
    Identification: 0x026a (618)
    Flags: 0x04 (Don't Fragment)
    Fragment offset: 0
    Time to live: 128
    Protocol: TCP (0x06)
    Header checksum: 0xdea4 [correct]
    Source: 192.168.1.101 (192.168.1.101)
    Destination: 62.146.25.34 (62.146.25.34)
    Transmission Control Protocol, Src Port: 1079 (1079), Dst Port: http (80), Seq: 1, Ack: 1, Len: 0
    Source port: 1079 (1079)
    Destination port: http (80)
    Sequence number: 1 (relative sequence number)
    Acknowledgement number: 1 (relative ack number)
    Header length: 20 bytes
    Flags: 0x0010 (ACK)
    Window size: 65535
    Checksum: 0x19dc [incorrect, should be 0xbdac]
    No. Time Source Destination Protocol Info
    4 0.022919 192.168.1.101 62.146.25.34 HTTP GET / HTTP/1.1
    Frame 4 (476 bytes on wire, 476 bytes captured)
    Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
    Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    Total Length: 462
    Identification: 0x026b (619)
    Flags: 0x04 (Don't Fragment)
    Fragment offset: 0
    Time to live: 128
    Protocol: TCP (0x06)
    Header checksum: 0xdcfd [correct]
    Source: 192.168.1.101 (192.168.1.101)
    Destination: 62.146.25.34 (62.146.25.34)
    Transmission Control Protocol, Src Port: 1079 (1079), Dst Port: http (80), Seq: 1, Ack: 1, Len: 422
    Source port: 1079 (1079)
    Destination port: http (80)
    Sequence number: 1 (relative sequence number)
    Next sequence number: 423 (relative sequence number)
    Acknowledgement number: 1 (relative ack number)
    Header length: 20 bytes
    Flags: 0x0018 (PSH, ACK)
    Window size: 65535
    Checksum: 0x1b82 [incorrect, should be 0xcda5]
    Hypertext Transfer Protocol
    No. Time Source Destination Protocol Info
    5 3.013084 192.168.1.101 62.146.25.34 HTTP [TCP Retransmission] GET / HTTP/1.1
    Frame 5 (476 bytes on wire, 476 bytes captured)
    Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
    Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    Total Length: 462
    Identification: 0x0276 (630)
    Flags: 0x04 (Don't Fragment)
    Fragment offset: 0
    Time to live: 128
    Protocol: TCP (0x06)
    Header checksum: 0xdcf2 [correct]
    Source: 192.168.1.101 (192.168.1.101)
    Destination: 62.146.25.34 (62.146.25.34)
    Transmission Control Protocol, Src Port: 1079 (1079), Dst Port: http (80), Seq: 1, Ack: 1, Len: 422
    Source port: 1079 (1079)
    Destination port: http (80)
    Sequence number: 1 (relative sequence number)
    Next sequence number: 423 (relative sequence number)
    Acknowledgement number: 1 (relative ack number)
    Header length: 20 bytes
    Flags: 0x0018 (PSH, ACK)
    Window size: 65535
    Checksum: 0x1b82 [incorrect, should be 0xcda5]
    SEQ/ACK analysis
    Hypertext Transfer Protocol
    No. Time Source Destination Protocol Info
    6 9.029003 192.168.1.101 62.146.25.34 HTTP [TCP Retransmission] GET / HTTP/1.1
    Frame 6 (476 bytes on wire, 476 bytes captured)
    Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
    Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    Total Length: 462
    Identification: 0x027f (639)
    Flags: 0x04 (Don't Fragment)
    Fragment offset: 0
    Time to live: 128
    Protocol: TCP (0x06)
    Header checksum: 0xdce9 [correct]
    Source: 192.168.1.101 (192.168.1.101)
    Destination: 62.146.25.34 (62.146.25.34)
    Transmission Control Protocol, Src Port: 1079 (1079), Dst Port: http (80), Seq: 1, Ack: 1, Len: 422
    Source port: 1079 (1079)
    Destination port: http (80)
    Sequence number: 1 (relative sequence number)
    Next sequence number: 423 (relative sequence number)
    Acknowledgement number: 1 (relative ack number)
    Header length: 20 bytes
    Flags: 0x0018 (PSH, ACK)
    Window size: 65535
    Checksum: 0x1b82 [incorrect, should be 0xcda5]
    SEQ/ACK analysis
    Hypertext Transfer Protocol
    No. Time Source Destination Protocol Info
    7 21.060827 192.168.1.101 62.146.25.34 HTTP [TCP Retransmission] GET / HTTP/1.1
    Frame 7 (476 bytes on wire, 476 bytes captured)
    Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
    Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    Total Length: 462
    Identification: 0x0284 (644)
    Flags: 0x04 (Don't Fragment)
    Fragment offset: 0
    Time to live: 128
    Protocol: TCP (0x06)
    Header checksum: 0xdce4 [correct]
    Source: 192.168.1.101 (192.168.1.101)
    Destination: 62.146.25.34 (62.146.25.34)
    Transmission Control Protocol, Src Port: 1079 (1079), Dst Port: http (80), Seq: 1, Ack: 1, Len: 422
    Source port: 1079 (1079)
    Destination port: http (80)
    Sequence number: 1 (relative sequence number)
    Next sequence number: 423 (relative sequence number)
    Acknowledgement number: 1 (relative ack number)
    Header length: 20 bytes
    Flags: 0x0018 (PSH, ACK)
    Window size: 65535
    Checksum: 0x1b82 [incorrect, should be 0xcda5]
    SEQ/ACK analysis
    Hypertext Transfer Protocol
    No. Time Source Destination Protocol Info
    8 35.561984 192.168.1.101 62.146.25.34 TCP 1079 > http [FIN, ACK] Seq=423 Ack=1 Win=65535 [TCP CHECKSUM INCORRECT] Len=0
    Frame 8 (54 bytes on wire, 54 bytes captured)
    Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
    Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    Total Length: 40
    Identification: 0x029a (666)
    Flags: 0x04 (Don't Fragment)
    Fragment offset: 0
    Time to live: 128
    Protocol: TCP (0x06)
    Header checksum: 0xde74 [correct]
    Source: 192.168.1.101 (192.168.1.101)
    Destination: 62.146.25.34 (62.146.25.34)
    Transmission Control Protocol, Src Port: 1079 (1079), Dst Port: http (80), Seq: 423, Ack: 1, Len: 0
    Source port: 1079 (1079)
    Destination port: http (80)
    Sequence number: 423 (relative sequence number)
    Acknowledgement number: 1 (relative ack number)
    Header length: 20 bytes
    Flags: 0x0011 (FIN, ACK)
    Window size: 65535
    Checksum: 0x19dc [incorrect, should be 0xbc05]
    "dump_success.txt":
    No. Time Source Destination Protocol Info
    1 0.000000 192.168.1.101 62.146.25.34 TCP 1083 > http [SYN] Seq=0 Len=0 MSS=1460
    Frame 1 (62 bytes on wire, 62 bytes captured)
    Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
    Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    Total Length: 48
    Identification: 0x02a3 (675)
    Flags: 0x04 (Don't Fragment)
    Fragment offset: 0
    Time to live: 128
    Protocol: TCP (0x06)
    Header checksum: 0xde63 [correct]
    Source: 192.168.1.101 (192.168.1.101)
    Destination: 62.146.25.34 (62.146.25.34)
    Transmission Control Protocol, Src Port: 1083 (1083), Dst Port: http (80), Seq: 0, Len: 0
    Source port: 1083 (1083)
    Destination port: http (80)
    Sequence number: 0 (relative sequence number)
    Header length: 28 bytes
    Flags: 0x0002 (SYN)
    Window size: 65535
    Checksum: 0x70ca [correct]
    Options: (8 bytes)
    No. Time Source Destination Protocol Info
    2 0.020553 62.146.25.34 192.168.1.101 TCP http > 1083 [SYN, ACK] Seq=0 Ack=1 Win=49368 Len=0 MSS=1452
    Frame 2 (62 bytes on wire, 62 bytes captured)
    Ethernet II, Src: D-Link_9b:09:44 (00:0d:88:9b:09:44), Dst: FujitsuS_81:79:ea (00:30:05:81:79:ea)
    Internet Protocol, Src: 62.146.25.34 (62.146.25.34), Dst: 192.168.1.101 (192.168.1.101)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    Total Length: 48
    Identification: 0x006b (107)
    Flags: 0x04 (Don't Fragment)
    Fragment offset: 0
    Time to live: 50
    Protocol: TCP (0x06)
    Header checksum: 0x2e9c [correct]
    Source: 62.146.25.34 (62.146.25.34)
    Destination: 192.168.1.101 (192.168.1.101)
    Transmission Control Protocol, Src Port: http (80), Dst Port: 1083 (1083), Seq: 0, Ack: 1, Len: 0
    Source port: http (80)
    Destination port: 1083 (1083)
    Sequence number: 0 (relative sequence number)
    Acknowledgement number: 1 (relative ack number)
    Header length: 28 bytes
    Flags: 0x0012 (SYN, ACK)
    Window size: 49368
    Checksum: 0xb530 [correct]
    Options: (8 bytes)
    No. Time Source Destination Protocol Info
    3 0.020599 192.168.1.101 62.146.25.34 TCP 1083 > http [ACK] Seq=1 Ack=1 Win=65535 [TCP CHECKSUM INCORRECT] Len=0
    Frame 3 (54 bytes on wire, 54 bytes captured)
    Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
    Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    Total Length: 40
    Identification: 0x02a4 (676)
    Flags: 0x04 (Don't Fragment)
    Fragment offset: 0
    Time to live: 128
    Protocol: TCP (0x06)
    Header checksum: 0xde6a [correct]
    Source: 192.168.1.101 (192.168.1.101)
    Destination: 62.146.25.34 (62.146.25.34)
    Transmission Control Protocol, Src Port: 1083 (1083), Dst Port: http (80), Seq: 1, Ack: 1, Len: 0
    Source port: 1083 (1083)
    Destination port: http (80)
    Sequence number: 1 (relative sequence number)
    Acknowledgement number: 1 (relative ack number)
    Header length: 20 bytes
    Flags: 0x0010 (ACK)
    Window size: 65535
    Checksum: 0x19dc [incorrect, should be 0xa2c5]
    No. Time Source Destination Protocol Info
    4 0.020746 192.168.1.101 62.146.25.34 HTTP GET / HTTP/1.1
    Frame 4 (476 bytes on wire, 476 bytes captured)
    Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
    Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    Total Length: 462
    Identification: 0x02a5 (677)
    Flags: 0x04 (Don't Fragment)
    Fragment offset: 0
    Time to live: 128
    Protocol: TCP (0x06)
    Header checksum: 0xdcc3 [correct]
    Source: 192.168.1.101 (192.168.1.101)
    Destination: 62.146.25.34 (62.146.25.34)
    Transmission Control Protocol, Src Port: 1083 (1083), Dst Port: http (80), Seq: 1, Ack: 1, Len: 422
    Source port: 1083 (1083)
    Destination port: http (80)
    Sequence number: 1 (relative sequence number)
    Next sequence number: 423 (relative sequence number)
    Acknowledgement number: 1 (relative ack number)
    Header length: 20 bytes
    Flags: 0x0018 (PSH, ACK)
    Window size: 65535
    Checksum: 0x1b82 [incorrect, should be 0xb2be]
    Hypertext Transfer Protocol
    No. Time Source Destination Protocol Info
    5 0.071290 62.146.25.34 192.168.1.101 TCP http > 1083 [ACK] Seq=1 Ack=423 Win=49368 Len=0
    Frame 5 (60 bytes on wire, 60 bytes captured)
    Ethernet II, Src: D-Link_9b:09:44 (00:0d:88:9b:09:44), Dst: FujitsuS_81:79:ea (00:30:05:81:79:ea)
    Internet Protocol, Src: 62.146.25.34 (62.146.25.34), Dst: 192.168.1.101 (192.168.1.101)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    Total Length: 40
    Identification: 0x006c (108)
    Flags: 0x04 (Don't Fragment)
    Fragment offset: 0
    Time to live: 50
    Protocol: TCP (0x06)
    Header checksum: 0x2ea3 [correct]
    Source: 62.146.25.34 (62.146.25.34)
    Destination: 192.168.1.101 (192.168.1.101)
    Transmission Control Protocol, Src Port: http (80), Dst Port: 1083 (1083), Seq: 1, Ack: 423, Len: 0
    Source port: http (80)
    Destination port: 1083 (1083)
    Sequence number: 1 (relative sequence number)
    Acknowledgement number: 423 (relative ack number)
    Header length: 20 bytes
    Flags: 0x0010 (ACK)
    Window size: 49368
    Checksum: 0xe046 [correct]
    No. Time Source Destination Protocol Info
    6 0.075838 62.146.25.34 192.168.1.101 HTTP HTTP/1.1 200 OK (text/html)
    Frame 6 (413 bytes on wire, 413 bytes captured)
    Ethernet II, Src: D-Link_9b:09:44 (00:0d:88:9b:09:44), Dst: FujitsuS_81:79:ea (00:30:05:81:79:ea)
    Internet Protocol, Src: 62.146.25.34 (62.146.25.34), Dst: 192.168.1.101 (192.168.1.101)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    Total Length: 399
    Identification: 0x006d (109)
    Flags: 0x04 (Don't Fragment)
    Fragment offset: 0
    Time to live: 50
    Protocol: TCP (0x06)
    Header checksum: 0x2d3b [correct]
    Source: 62.146.25.34 (62.146.25.34)
    Destination: 192.168.1.101 (192.168.1.101)
    Transmission Control Protocol, Src Port: http (80), Dst Port: 1083 (1083), Seq: 1, Ack: 423, Len: 359
    Source port: http (80)
    Destination port: 1083 (1083)
    Sequence number: 1 (relative sequence number)
    Next sequence number: 360 (relative sequence number)
    Acknowledgement number: 423 (relative ack number)
    Header length: 20 bytes
    Flags: 0x0018 (PSH, ACK)
    Window size: 49368
    Checksum: 0x29b8 [correct]
    Hypertext Transfer Protocol
    Line-based text data: text/html
    No. Time Source Destination Protocol Info
    7 0.095473 192.168.1.101 62.146.25.34 HTTP GET /favicon.ico HTTP/1.1
    Frame 7 (407 bytes on wire, 407 bytes captured)
    Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
    Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    Total Length: 393
    Identification: 0x02aa (682)
    Flags: 0x04 (Don't Fragment)
    Fragment offset: 0
    Time to live: 128
    Protocol: TCP (0x06)
    Header checksum: 0xdd03 [correct]
    Source: 192.168.1.101 (192.168.1.101)
    Destination: 62.146.25.34 (62.146.25.34)
    Transmission Control Protocol, Src Port: 1083 (1083), Dst Port: http (80), Seq: 423, Ack: 360, Len: 353
    Source port: 1083 (1083)
    Destination port: http (80)
    Sequence number: 423 (relative sequence number)
    Next sequence number: 776 (relative sequence number)
    Acknowledgement number: 360 (relative ack number)
    Header length: 20 bytes
    Flags: 0x0018 (PSH, ACK)
    Window size: 65176
    Checksum: 0x1b3d [incorrect, should be 0x1e0c]
    Hypertext Transfer Protocol
    No. Time Source Destination Protocol Info
    8 0.139786 62.146.25.34 192.168.1.101 TCP http > 1083 [ACK] Seq=360 Ack=776 Win=49368 Len=0
    Frame 8 (60 bytes on wire, 60 bytes captured)
    Ethernet II, Src: D-Link_9b:09:44 (00:0d:88:9b:09:44), Dst: FujitsuS_81:79:ea (00:30:05:81:79:ea)
    Internet Protocol, Src: 62.146.25.34 (62.146.25.34), Dst: 192.168.1.101 (192.168.1.101)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    Total Length: 40
    Identification: 0x006e (110)
    Flags: 0x04 (Don't Fragment)
    Fragment offset: 0
    Time to live: 50
    Protocol: TCP (0x06)
    Header checksum: 0x2ea1 [correct]
    Source: 62.146.25.34 (62.146.25.34)
    Destination: 192.168.1.101 (192.168.1.101)
    Transmission Control Protocol, Src Port: http (80), Dst Port: 1083 (1083), Seq: 360, Ack: 776, Len: 0
    Source port: http (80)
    Destination port: 1083 (1083)
    Sequence number: 360 (relative sequence number)
    Acknowledgement number: 776 (relative ack number)
    Header length: 20 bytes
    Flags: 0x0010 (ACK)
    Window size: 49368
    Checksum: 0xdd7e [correct]
    No. Time Source Destination Protocol Info
    9 0.144850 62.146.25.34 192.168.1.101 HTTP HTTP/1.1 404 Not Found (text/html)
    Frame 9 (464 bytes on wire, 464 bytes captured)
    Ethernet II, Src: D-Link_9b:09:44 (00:0d:88:9b:09:44), Dst: FujitsuS_81:79:ea (00:30:05:81:79:ea)
    Internet Protocol, Src: 62.146.25.34 (62.146.25.34), Dst: 192.168.1.101 (192.168.1.101)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    Total Length: 450
    Identification: 0x006f (111)
    Flags: 0x04 (Don't Fragment)
    Fragment offset: 0
    Time to live: 50
    Protocol: TCP (0x06)
    Header checksum: 0x2d06 [correct]
    Source: 62.146.25.34 (62.146.25.34)
    Destination: 192.168.1.101 (192.168.1.101)
    Transmission Control Protocol, Src Port: http (80), Dst Port: 1083 (1083), Seq: 360, Ack: 776, Len: 410
    Source port: http (80)
    Destination port: 1083 (1083)
    Sequence number: 360 (relative sequence number)
    Next sequence number: 770 (relative sequence number)
    Acknowledgement number: 776 (relative ack number)
    Header length: 20 bytes
    Flags: 0x0018 (PSH, ACK)
    Window size: 49368
    Checksum: 0x7a71 [correct]
    Hypertext Transfer Protocol
    Line-based text data: text/html
    No. Time Source Destination Protocol Info
    10 0.269307 192.168.1.101 62.146.25.34 TCP 1083 > http [ACK] Seq=776 Ack=770 Win=64766 [TCP CHECKSUM INCORRECT] Len=0
    Frame 10 (54 bytes on wire, 54 bytes captured)
    Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
    Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    Total Length: 40
    Identification: 0x02af (687)
    Flags: 0x04 (Don't Fragment)
    Fragment offset: 0
    Time to live: 128
    Protocol: TCP (0x06)
    Header checksum: 0xde5f [correct]
    Source: 192.168.1.101 (192.168.1.101)
    Destination: 62.146.25.34 (62.146.25.34)
    Transmission Control Protocol, Src Port: 1083 (1083), Dst Port: http (80), Seq: 776, Ack: 770, Len: 0
    Source port: 1083 (1083)
    Destination port: http (80)
    Sequence number: 776 (relative sequence number)
    Acknowledgement number: 770 (relative ack number)
    Header length: 20 bytes
    Flags: 0x0010 (ACK)
    Window size: 64766
    Checksum: 0x19dc [incorrect, should be 0x9fbe]

    lev wrote:This performance regression renders openvpn with a tun adapter unusable if client and server use kernel 3.14 .
    Thus I created a bug report: https://bugs.archlinux.org/task/40089
    i actually noticed it to be an "either-or" type of thing; my Windows clients were seeing the same thing coming off a 3.14 openvpn server.
    yeah, weird issue. like i noticed spurts of even-powers-of-2 sized packets
    Client connecting to 10.10.10.6, TCP port 5001
    TCP window size: 416 KByte
    [ 3] local 10.10.10.1 port 40643 connected with 10.10.10.6 port 5001
    [ ID] Interval Transfer Bandwidth
    [ 3] 0.0- 2.0 sec 512 KBytes 2.10 Mbits/sec
    [ 3] 2.0- 4.0 sec 0.00 Bytes 0.00 bits/sec
    [ 3] 4.0- 6.0 sec 0.00 Bytes 0.00 bits/sec
    [ 3] 6.0- 8.0 sec 0.00 Bytes 0.00 bits/sec
    [ 3] 8.0-10.0 sec 128 KBytes 524 Kbits/sec
    [ 3] 10.0-12.0 sec 128 KBytes 524 Kbits/sec
    [ 3] 12.0-14.0 sec 512 KBytes 2.10 Mbits/sec
    [ 3] 14.0-16.0 sec 128 KBytes 524 Kbits/sec
    [ 3] 16.0-18.0 sec 512 KBytes 2.10 Mbits/sec
    [ 3] 18.0-20.0 sec 128 KBytes 524 Kbits/sec
    [ 3] 20.0-22.0 sec 384 KBytes 1.57 Mbits/sec
    [ 3] 22.0-24.0 sec 256 KBytes 1.05 Mbits/sec
    [ 3] 24.0-26.0 sec 512 KBytes 2.10 Mbits/sec
    [ 3] 26.0-28.0 sec 384 KBytes 1.57 Mbits/sec
    [ 3] 28.0-30.0 sec 256 KBytes 1.05 Mbits/sec
    [ 3] 30.0-32.0 sec 128 KBytes 524 Kbits/sec
    [ 3] 32.0-34.0 sec 640 KBytes 2.62 Mbits/sec
    [ 3] 34.0-36.0 sec 384 KBytes 1.57 Mbits/sec
    [ 3] 36.0-38.0 sec 384 KBytes 1.57 Mbits/sec
    [ 3] 38.0-40.0 sec 384 KBytes 1.57 Mbits/sec
    [ 3] 40.0-42.0 sec 128 KBytes 524 Kbits/sec

  • TCP packet out of state: First packet isn't SYN & Outlook is trying to retrieve data from the Microsoft Exchange Server [CAS-ARray]

    We are transitioning from Exchange 2003 to Exchange 2010.  We found Outlook online mode (non-cached mode) have many warning "Outlook is trying to retrieve data from the Microsoft Exchange Server [CAS-ARray]", usually happen when users tried to open
    address book but sometimes even normal operation like click the Send button.  The problem does not affect OWA and extremely rare when Outlook is running in cached mode.  Check the firewall logs, we notice a lot of "TCP Packet Out of State" drops.
    We have a lot from the CAS/HT to DC/GC on TCP_3268 and LDAP.  And the errors are "TCP packet out of state: First packet isn't SYN" with tcp_flags FIN-ACK, PUSH-ACK.
    We also have a lot from CAS/HT to the Outlook Clients on the static RPC port (TCP_59933).   And the errors are "TCP packet out of state: First packet isn't SYN" with tcp_flags FIN-ACK, PUSH-ACK and RST-ACK, ACK.
    This happens even on Outlook 2010 which I though it has TCP Keep Alive implmented to keep the session active within 1 hour. 
    Can somebody tell me if these out-of-state are the cause of our problem?  And how to fix it?
    THANK 1,000,000

    Hello AndyHWC,
    I did some consulting with our CAS team and received the following feedback to your post:
    It is difficult to determine what is causing resets without seeing the captures first hand however, the concern is that you are seeing dropped packets on the firewall logs.  Where is this firewall located?
    Based on the description "Check the firewall logs, we notice a lot of "TCP Packet Out of State" drops." and "We have a lot from the CAS/HT to DC/GC on TCP_3268 and
    LDAP." indicates to me that the firewall is between CAS and GC.  This not supported under any circumstances and would explain the issue they are seeing with clients trying to "retrieve data from the GC".
    If there is not a firewall between the GC and CAS then a Microsoft support engineer would need to have concurrent Netmon Captures from client, CAS, GC during the
    issue to analyze.  If only one GC exists consider adding another GC to handle the client requests and for fault tolerance.
    Also verify that all NIC card drivers are updated to the latest driver version
    More information about firewalls with Exchange 2007/2010
    http://msexchangeteam.com/archive/2009/10/21/452929.aspx
    http://technet.microsoft.com/en-us/library/bb232184(EXCHG.80).aspx
    You can install the Client Access server role on an Exchange 2007 computer that is running any other server roles except for the Edge Transport server role. You
    cannot install the Client Access server role on a computer that is installed in a cluster. Installation of a Client Access server in a perimeter network is not supported.
    http://technet.microsoft.com/en-us/library/dd577077(EXCHG.80).aspx
    “The Installation of a Client Access Server in a Perimeter Network Is Not Supported
    Issue You may want to install an Exchange 2007 Client Access server in a perimeter network. However, this type of installation is not supported in Exchange
    2007.
    Cause The Exchange 2007 Client Access server role is not supported in any configuration in which a firewall is located between the Client Access server
    and a Mailbox server or a domain controller. This includes firewall devices, firewall programs, or any program or device that is designed to restrict traffic between two network locations.
    For correct operation, Client Access servers require typical domain connectivity to domain controllers and global catalog servers. Because any devices
    or programs that restrict or reduce access to domain controllers or global catalog servers may affect the correct operation of the Client Access server, we do not support this type of configuration.
    Resolution To resolve this issue, move the Client Access servers to the internal network. For more information about the ports that Exchange 2007 uses
    for various services, see Data Path Security Reference.”
    Thanks,
    Kevin Ca - MSFT
    Kevin Ca - MSFT

  • Asp drop - First TCP packet not SYN (tcp-not-syn)

    I have many tcp-not-syn:
    First TCP packet not SYN (tcp-not-syn)                                46841247
    For sure it is not a routing issue cause ie 10.32.3.230 usually can connect to 192.168.16.2 which is a proxy server. Sometimes it can't and I get the
    tcp-not-syn error. So after a capture I got the following,
    ASA# capture asp-drop type asp-drop tcp-not-syn
    ASA# sh capture asp-drop | i 10.32.3.230
    2397: 16:11:31.904295 802.1Q vlan#8 P0 10.32.3.230.2322 > 192.168.16.2.8080: R 556133793:556133793(0) win 0
    2398: 16:11:31.905272 802.1Q vlan#8 P0 10.32.3.230.2322 > 192.168.16.2.8080: R 556133793:556133793(0) win 0
    2400: 16:11:31.908583 802.1Q vlan#8 P0 10.32.3.230.2320 > 192.168.16.2.8080: R 55902087:55902087(0) win 0
    2401: 16:11:31.908613 802.1Q vlan#8 P0 10.32.3.230.2320 > 192.168.16.2.8080: R 55902087:55902087(0) win 0
    2402: 16:11:31.908629 802.1Q vlan#8 P0 10.32.3.230.2320 > 192.168.16.2.8080: R 55902087:55902087(0) win 0
    2403: 16:11:31.908659 802.1Q vlan#8 P0 10.32.3.230.2320 > 192.168.16.2.8080: R 55902087:55902087(0) win 0
    2404: 16:11:31.908766 802.1Q vlan#8 P0 10.32.3.230.2320 > 192.168.16.2.8080: R 55902087:55902087(0) win 0
    2405: 16:11:31.908796 802.1Q vlan#8 P0 10.32.3.230.2320 > 192.168.16.2.8080: R 55902087:55902087(0) win 0
    2406: 16:11:31.908812 802.1Q vlan#8 P0 10.32.3.230.2320 > 192.168.16.2.8080: R 55902087:55902087(0) ack 4258924744 win 0
    2407: 16:11:31.909071 802.1Q vlan#8 P0 10.32.3.230.2320 > 192.168.16.2.8080: R 55902087:55902087(0) win 0
    2408: 16:11:31.909102 802.1Q vlan#8 P0 10.32.3.230.2320 > 192.168.16.2.8080: R 55902087:55902087(0) win 0
    2409: 16:11:31.909132 802.1Q vlan#8 P0 10.32.3.230.2320 > 192.168.16.2.8080: R 55902087:55902087(0) win 0
    2410: 16:11:31.910490 802.1Q vlan#8 P0 10.32.3.230.2321 > 192.168.16.2.8080: R 1839687588:1839687588(0) win 0
    2411: 16:11:31.910521 802.1Q vlan#8 P0 10.32.3.230.2321 > 192.168.16.2.8080: R 1839687588:1839687588(0) win 0
    2412: 16:11:31.910551 802.1Q vlan#8 P0 10.32.3.230.2321 > 192.168.16.2.8080: R 1839687588:1839687588(0) win 0
    2413: 16:11:31.910566 802.1Q vlan#8 P0 10.32.3.230.2321 > 192.168.16.2.8080: R 1839687588:1839687588(0) win 0
    2414: 16:11:31.911192 802.1Q vlan#8 P0 10.32.3.230.2321 > 192.168.16.2.8080: R 1839687588:1839687588(0) win 0
    2415: 16:11:31.911207 802.1Q vlan#8 P0 10.32.3.230.2321 > 192.168.16.2.8080: R 1839687588:1839687588(0) win 0
    2416: 16:11:31.911238 802.1Q vlan#8 P0 10.32.3.230.2321 > 192.168.16.2.8080: R 1839687588:1839687588(0) win 0
    2417: 16:11:31.915205 802.1Q vlan#8 P0 10.32.3.230.2321 > 192.168.16.2.8080: R 1839687588:1839687588(0) win 0
    2418: 16:11:31.915235 802.1Q vlan#8 P0 10.32.3.230.2321 > 192.168.16.2.8080: R 1839687588:1839687588(0) win 0
    2419: 16:11:31.915296 802.1Q vlan#8 P0 10.32.3.230.2321 > 192.168.16.2.8080: R 1839687588:1839687588(0) win 0
    2420: 16:11:31.915327 802.1Q vlan#8 P0 10.32.3.230.2320 > 192.168.16.2.8080: R 55902087:55902087(0) win 0
    2421: 16:11:31.915357 802.1Q vlan#8 P0 10.32.3.230.2320 > 192.168.16.2.8080: R 55902087:55902087(0) win 0
    2422: 16:11:31.915815 802.1Q vlan#8 P0 10.32.3.230.2320 > 192.168.16.2.8080: R 55902087:55902087(0) win 0
    2432: 16:11:33.102426 802.1Q vlan#8 P0 10.32.3.230.2317 > 192.168.16.2.8080: R 4189536219:4189536219(0) win 0
    2433: 16:11:33.102457 802.1Q vlan#8 P0 10.32.3.230.2317 > 192.168.16.2.8080: R 4189536219:4189536219(0) win 0
    2434: 16:11:33.102487 802.1Q vlan#8 P0 10.32.3.230.2317 > 192.168.16.2.8080: R 4189536219:4189536219(0) win 0
    syslog message says:
    deny tcp (no connection) from 10.32.3.78/1646 to 192.168.16.2/8080 flags RST on interface inside
    The question is how can I define it is:
    1. the proxy 192.168.16.2 itself is too slow responding to the syn packet sent from the client 10.32.3.78
    2. a reset is sent by the proxy 192.168.16.2 and then forwarded by the ASA to the client 10.32.3.78
    3. an idle timeout tuning needed on firewall
    4. anything else
    Thanks

    Hi,
    Since it is a RST packet coming from client IP destined to proxy server IP on ASA's interface (of course with no associated connection in ASA state table), ASA will drop it as first tcp packet not syn.
    When a packet arrives on ASA, it checks to see if it belongs to an existing flow, if not, it has to be a new connection but since SYN flag is not set here, it gets dropped under above reason code.
    Now, you would probabaly want to capture the entire traffic stream from client to server on ASA interface to understand what caused those resets. May be client sent some new requests (SYN's) and proxy was too busy to respond. Again, complete capture in pcap would be needed for further analysis.
    Regards,
    Sourav Kakkar

  • False negative for syn ack scan

    Our sensors are false negative on all syn ack scans that are received. Is there a signature current on the ids that will capture the following?
    1 2006-11-14 14:27:04.287620 202.103.178.165 my.net.163.77 TCP http > 21129 [SYN, ACK] Seq=0 Ack=0 Win=0 Len=0 MSS=0
    cut
    10 2006-11-14 14:27:06.868677 202.103.178.165 my.net.251.125 TCP http > 606 [SYN, ACK] Seq=0 Ack=0 Win=0 Len=0 MSS=0

    Try these links:
    http://www.cisco.com/univercd/cc/td/doc/cisintwk/itg_v1/tr1925.htm#xtocid162254
    http://www.cisco.com/en/US/products/sw/secursw/ps2113/prod_technical_reference09186a00800d9dd5.html
    http://www.cisco.com/warp/public/63/nimda-ids.html

  • Event: NULL TCP PACKET

    Hello all,
    we are incrementally receiving a lot of MARS events that comes from Cisco IDS, all those events are “ NULL TCP PACKET”, and the destination is always the same, a smtp ironport machine trough the 25 port, from diferent public IPs.
    Does anybody have a similar scenario? What can we do?
    Thanks

    Hi,
    The signature version 364 and the IPS version is 6.1 (1) E2.
    It is suppoused that is a single TCP packet with none of the SYN, ACK,FIN or RST flags.
    It comes from different public IP's that comes from different ISP's.
    Regards
    Izaskun

  • Double TNS datagrams in one TCP packet

    I have the following Problem:
    During a database Connection over an IPSec - tunnel between a Fortigate and a Juniper firewall the connection stalls.
    This is exactly reproducible with on select or bulk insert statement. Neither OCI or thin changes the behavior. Without the tunnel(f.e. LAN or ISDN connect)
    there no problem an no duplicate TNS.
    I have logged the TCP traffic with wireshark on both sides and noticed that I have two tns datagrams in one TCP packet.
    I use different IPSec tunnels and haven only problems with this one. Do you have a hint whats going on?
    BTW: I change sdu and tdu sizes. This changes the point in time of the stall (double tns).
    Here is the Wireshark Log:
    519     1128.135566     192.168.197.33     10.4.100.73     TNS     Request, Data (6), Data
    520     1128.135912     192.168.197.33     10.4.100.73     TNS     Request, Data (6), Data
    521     1128.179202     10.4.100.73     192.168.197.33     TCP     [TCP Window Update] ncube-lm > 64542 [ACK] Seq=7203 Ack=2341 Win=65535 Len=0
    522     1128.202975     10.4.100.73     192.168.197.33     TCP     ncube-lm > 64542 [ACK] Seq=7203 Ack=3691 Win=64185 Len=0
    523     1128.213284     10.4.100.73     192.168.197.33     TNS     Response, Marker (12), Attention
    524     1128.213516     10.4.100.73     192.168.197.33     TNS     Response, Marker (12), Attention
    525     1128.213557     192.168.197.33     10.4.100.73     TCP     64542 > ncube-lm [ACK] Seq=4265 Ack=7225 Win=64201 Len=0
    526     1128.217649     192.168.197.33     10.4.100.73     TNS     Request, Marker (12), Attention
    527     1128.255460     10.4.100.73     192.168.197.33     TCP     [TCP Dup ACK 524#1] ncube-lm > 64542 [ACK] Seq=7225 Ack=3691 Win=65535 Len=0
    * 528     1128.501575     192.168.197.33     10.4.100.73     TNS     [TCP Retransmission] Request, Marker (12), Attention
    529     1128.588704     10.4.100.73     192.168.197.33     TCP     ncube-lm > 64542 [ACK] Seq=7225 Ack=4276 Win=64950 Len=0
    Here the connection stalls, but does not terminate. The data transmission is not finished.
    The * packet has the following header information:
    Frame 528: 639 bytes on wire (5112 bits), 639 bytes captured (5112 bits)
    Ethernet II, Src: FujitsuT_92:f0:b5 (00:19:99:92:f0:b5), Dst: Fortinet_25:ea:de (00:09:0f:25:ea:de)
    Internet Protocol, Src: 192.168.197.33 (192.168.197.33), Dst: 10.4.100.73 (10.4.100.73)
    Transmission Control Protocol, Src Port: 64542 (64542), Dst Port: ncube-lm (1521), Seq: 3691, Ack: 7225, Len: 585
    Transparent Network Substrate Protocol
    Packet Length: 574
    Packet Checksum: 0x0000
    Packet Type: Data (6)
    Reserved Byte: 00
    Header Checksum: 0x0000
    Data
    Transparent Network Substrate Protocol
    Packet Length: 11
    Packet Checksum: 0x0000
    Packet Type: Marker (12)
    Reserved Byte: 00
    Header Checksum: 0x0000
    Attention
    Marker Type: Data Marker - 1 Data Bytes (0x01)
    Marker Data Byte: 0x00
    Marker Data Byte: 0x02
    Any idea?

    Ben wrote:
    Convert dbl to U64 then use swap words. Swap Words is polymorphic and will adapt the the data type you prest to it.
    Ben
    Convert is a bad idea here.you want to typecast instead.
    Rolf Kalbermatter
    Rolf Kalbermatter
    CIT Engineering Netherlands
    a division of Test & Measurement Solutions

  • IS IT POSSIBLE TO SEND TCP PACKET WITH THE SOCKET?

    Hello everybody iam programing HIJACK attack with jbuilder8 that consiste to detecte a communication between the client and server (tcp session or tcp connexion) and read all informations from this tcp packet(like N�ACK,N� SEQ..) and finnaly send a tcp packet with false information. I have make this project with C under linux(red hat9) compiled with GCC and i have used raw socket like this:
    int creat_socket(char *interface)
    int fd;
    struct ifreq ifr;
    struct sockaddr_ll sll;
    if ((fd=socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL)))==-1)//creat socket {
         perror("socket");
         return -1;
    memset(&ifr, 0, sizeof(struct ifreq));//remplir ifr par des '0'
    strcpy(ifr.ifr_name, interface);//copier le nom de l'interface ds ifr_name
    if (ioctl(fd, SIOCGIFINDEX, &ifr)==-1)//Retrouve le num�ro d'interface et le place dans ifr_ifindex.
         perror("ioctl");
         return -1;
    memset(&sll, 0, sizeof(struct sockaddr_ll));//remplir sll par des '0'
    sll.sll_family=PF_PACKET;
    sll.sll_ifindex=ifr.ifr_ifindex;
    sll.sll_protocol=htons(ETH_P_ALL);
    if (bind(fd, (struct sockaddr *)&sll, sizeof(struct sockaddr_ll))==-1)//lie le socket a l'interface
         perror("bind");
         return -1;
    if (ioctl(fd, SIOCGIFFLAGS, &ifr)==-1)//Lire les attributs actifs du p�riph�rique
         perror("ioctl");
         return -1;
    ifr.ifr_flags|=IFF_PROMISC;//Interface en mode promiscuous
    if (ioctl(fd, SIOCSIFFLAGS, &ifr)==-1)////ecrire les attributs actifs du p�riph�rique
         perror("ioctl");
         return -1;
    return fd;
    PROBLEM : I want to know if it�s possible to make that in java because i had search and i have found just the client and server socket but i want a socket to send tcp Packet? Thank you.

    hello i had found the ROCKSAW (http://www.savarese.org/software/rocksaw.html ) and i had used in my program, but when the program arrived in:
    socket_send=new RawSocket();
    i had this error:
    java.lang.UnsupportedClassVersionError: org/savarese/rocksaw/net/RawSocket (Unsupported major.minor version 49.0)
         at java.lang.ClassLoader.defineClass0(Native Method)
         at java.lang.ClassLoader.defineClass(ClassLoader.java:502)
         at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
         at java.net.URLClassLoader.defineClass(URLClassLoader.java:250)
         at java.net.URLClassLoader.access$100(URLClassLoader.java:54)
         at java.net.URLClassLoader$1.run(URLClassLoader.java:193)
         at java.security.AccessController.doPrivileged(Native Method)
         at java.net.URLClassLoader.findClass(URLClassLoader.java:186)
         at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
         at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:265)
         at java.lang.ClassLoader.loadClass(ClassLoader.java:255)
         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315)
         at hijack.M_HIJACK.tcpsend(M_HIJACK.java:345)
         at hijack.M_HIJACK.injection_actionPerformed(M_HIJACK.java:611)
         at hijack.M_HIJACK_injection_actionAdapter.actionPerformed(M_HIJACK.java:861)
         at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1764)
         at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(AbstractButton.java:1817)
         at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:419)
         at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:257)
         at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:245)
         at java.awt.Component.processMouseEvent(Component.java:5093)
         at java.awt.Component.processEvent(Component.java:4890)
         at java.awt.Container.processEvent(Container.java:1566)
         at java.awt.Component.dispatchEventImpl(Component.java:3598)
         at java.awt.Container.dispatchEventImpl(Container.java:1623)
         at java.awt.Component.dispatchEvent(Component.java:3439)
         at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:3450)
         at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3165)
         at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3095)
         at java.awt.Container.dispatchEventImpl(Container.java:1609)
         at java.awt.Component.dispatchEvent(Component.java:3439)
         at java.awt.EventQueue.dispatchEvent(EventQueue.java:450)
         at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:197)
         at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
         at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:144)
         at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:136)
         at java.awt.EventDispatchThread.run(EventDispatchThread.java:99)
    i think that is a problem with a version of JDK (i have jdk1.4) so if you have an idea please help me

  • Firewall causing playstation 3 fragmented packets blocked!

    Just wanted to post this as info to other RV220w users that have a playstation 3.  By default a setting is on in the firewall that blocks fragmented packets..  With this setting on even if the ps3 is in the dmz some games wont work and if you test the ps3 connection it will tell you that either your router or service provider doesn't allow fragmented packets.  Its under Firewall > Attack Prevention > check box "block fragmented packets".
    the error from testing connection on  ps3 is
    The router in use may not support IP fragments, and the communication features of some games may be restricted.

    [email protected] wrote:
    > I am using Netware 6.5 sp1a and bm 3.8 sp1a.
    >
    > I recently deleted some unneeded packet filter exceptions using
    > iManager. When my server was restarted over the weekend the firewall is
    > not allowing packets in the exception list to pass through.
    > I get a message on the logger screen that states:
    > "nbm filewall failed to read configuration from ds"
    > What is actuall happening is all traffic is blocked as the exceptions do
    > not seem to be working.
    >
    > I have checked ds and all looks healthy.
    >
    > Any ideas. I have been forced to disable filters on the public interface
    > until I can fix the problem.
    >
    > Thanks,
    >
    Sorry but this is the wrong forum. You need to go to
    novell.support.bordermanager.packet-filtering. This forum is for the
    Novell Client Firewall that comes with BM 3.8
    Brad

  • My MBP has started to send out TCP packets larger than the MTU on the NIC - is there any place that this can be overriden?

    Got a very weird issue here and wondering if anyone has any other ideas. Basically over the wired NIC only, my Mac has started to send out large HTTP/HTTPS packets from the browser (> 1500 bytes) Captures show packet sizes from 2000 all the way to 4000 sometimes. This happens in Firefox and Chrome so doesn't appear to be application related.
    This causes fragmentation issues and traffic drops which basically causes most of my websites and  tools to crash and burn (and I get all sorts of SSL errors from applications, etc).
    It appears to be limited to just TCP packets as pings with the DF bit set will not send any larger than 1500 bytes.
    However if I switch to wireless, everything works fine and captures show the correct maximum packet size of 1500 for all packets leaving my client.
    The MTU on the  en0 interface is 1500 as per ifconfig and I made sure that it was set to 1500 in Network config panel (because there is an option for jumbo frames there which bumps up the MTU).
    A packet capture also shows that during the three way handshake the TCP MSS is successfully sent and negotiated as 1480, but then it appears to ignore that when sending packets later in the TCP stream.
    I've rebooted, upgraded to 10.7.4, checked the "sysctl" outputs and matched against a Mac not having the issue.
    This is the newest MBP 15 inch model.
    Any other ideas on things to check?

    Have you used any sort of "tuner" software? You are obviously an advanced user. Sometimes we hack things up and forget about it later. If you are sure you didn't do that, maybe poke around with IPv6 settings. Supposedly people are trying to enable that and it is going to be a disaster.

  • Pop Up blocker exceptions are not saved in the browser for use, the next time the PC reboots. How do you save these exceptions for long term use?

    Pop Up blocker exceptions are not saved in the browser for use, the next time the PC reboots. How do you save these exceptions for long term use?

    In case you are using "Clear history when Firefox closes":
    *do not clear the Site Preferences
    *Tools > Options > Privacy > Firefox will: "Use custom settings for history": [X] "Clear history when Firefox closes" > Settings
    *https://support.mozilla.org/kb/remove-browsing-search-and-download-history
    Note that clearing "Site Preferences" clears all exceptions for cookies, images, pop-up windows, software installation, passwords, and other website specific data.
    If you have software like Advanced SystemCare (Surfing Protection feature) that might reset some files to older versions to protect these files against changes then check the settings or uninstall this software.

  • My pop-up blocker exceptions are not saved. Is this because of my use of private browsing?

    Self-explanatory

    Private Browsing shouldn't have nay effect on exceptions and you should still be able to create new exceptions and keep existing exceptions.
    They are however removed if you use Clear Recent History to clear the "Site Preferences" or the file permissions.sqlite is removed by cleanup software.
    *https://support.mozilla.com/kb/Clear+Recent+History
    The file "permissions.sqlite" stores 'allow' and 'block' exceptions for cookies, images, pop-up windows, and extensions (software) installation.

  • Sending TCP packets to many IP addresses after downloading a program

    I constantly monitor UDP and TCP packets sent to IP addresses on my Windows 7 computer. After downloading a free online program to convert media video files, I soon noticed my computer constantly and rapidly sending out packets to more
    than 10 IP addresses (and quite a few were going to China, Russia and Germany). I tried a search on my hard drive for the file that contained those specific IP addresses and found nothing.
    Note: For Viewing Folders, I do not hide operating system files, and I show hidden files, folders and drives.
    Then I  tried searching my windows registry (via REGEDIT) for those IP addresses and found nothing.
    I assumed these IP addresses may have been hidden and included in a .dll file. I could not find an answer on the internet to determine where these hacking IP addresses originated from, so I deleted the program and rebooted.
    The problem still existed, so I had to restore to a previous backup date. The restore fixed the problem.  I am so confused. If I wasn't monitoring my connections I would never have known about this hacking flaw in Windows 7 security. I
    still don't know what type of file(s) were causing this problem. Or what causes my computer to send unsolicited packets to so many IP addresses (to domestic, foreign and hostile locations). 

    Message to members... DO NOT download the software in this area.
    Contains malicious code.
    Thank you FangZhou Chen for your response. I am not exactly sure which of these two programs (listed below) was the culprit for this problem, but I do know that both programs have issues with malicious code. Understand I have used both of these programs
    in the past, but stopped using them because of these issues. The Freeware #1 was my favorite and was user friendly, until the malicious code was added, and may be the real culprit.
    Malicious Freeware #1: Any Video Converter (program name: avc-free.exe)
    This program contains PUP.Optional.OpenCandy - While PUP.Optional.OpenCandy is not technically a virus, this PUP can be extremely annoying and quite difficult to get rid of. It comes loaded with adware, which as anyone who has been infected by adware can tell
    you, can drive you to the brink of insanity with its relentless adverts, plus it will very likely hijack your browser and install a strange and unwanted toolbar on your machine too. Not only do unwanted toolbars get in the way but they can direct you to websites
    that the creators want you to visit and can in general make using your computer a real user-unfriendly experience. PUP.Optional.OpenCandy is also a form of spyware which enables it to be installed deep within your PC’s operating system so that it is harder
    for you to find – and therefore delete.
    Link to site:              any-video-converter.com/products/for_video_free/             
    Link to download program:  any-video-converter.com/download-avc-free.php
    Malicious Freeware #2: SUPER © Media Converter Encoder
    This program is bundled with other software. I don't remember the malicious type or effects.
    Link to site:             erightsoft.com/SUPER.html
    Link to download program:  erightsoft.info/GetFile3.php?SUPERsetup.exe
    Hope this helps. Again thanks! God Bless.
    P.S. - Excellent tools in cleaning up maleware have been to use Malwarebytes, AdwCleaner and  HitmanPro (both recommended by the malwarebytes.org website).

  • Cisco 3750 --- Mark TCP packets from port 80 with DSCP ef

    Good afternoon,
    I am trying to mark outgoing traffic from a web server with value of DSCP ef
    When I am doing a traffic capture all TCP packets have tos 0x0
    If I marked UDP packets, or icmp packets, I can see it with in trafic capture, but not TCP traffic.
    This is my config,
    mls qos
    ip access-list extended MARK-HTTP-ACL
      permit tcp host 10.10.10.10 eq www any
    class-map match-any HTTP-CM
    match access-group name MARK-HTTP-ACL
    policy-map PRIORITY-PM
    class HTTP-CM
      set dscp ef
    interface GigabitEthernet1/0/11
    switchport access vlan 20
    switchport mode access
    spanning-tree portfast
    mls qos trust dscp
    service-policy input PRIORITY-PM
    Can anybody can help me to understand, why I cannot mark TCP packets?
    Thank you

    Yes.  You need to eliminate the things I've said to eliminate with the other side.  Ensure your configs are matching exactly.  They probably are, whatever, just make sure of it because it's easy.  You both need to run packet captures on your interfaces both in and out to even begin to have an idea of where to look.
    The more info you can have just one person responsible for the better.  What I mean by that is, it's typically a nice step for the 'bigger end' to have the 'smaller end's' config file to look at.
    If you are seeing packets come in your inside, leave your outside, and never make it to his inside, then take it a step at a time.
    If you're seeing them come in his interface and never come back out, you know where to look.
    Set your caps to a single host to single host if need be, and generate traffic accordingly.
    You need to narrow down where NOT to look so that you know where TO look.  I would say then, and only then, do you get the ISP involved.  Once you're sure the problem exists between his edge device and your edge device.
    I do exactly this for a living on a daily basis...day after day after day.  I'm responsible for over 200 IPSec s2s connections and thousands of SSL VPN sessions.  I always start the exact same way...from the very bottom.

  • Use Group Policy to add website to Popup Blocker Exception List

    I have downloaded the Firefox.adm Template and have added it to my local security settings for testing. I do not see how to add website(s) to the Popup Blocker Exception List. I have been able to do this for IE and Chrome (using the Chrome Group Policy Template) and need to do the same for Firefox.

    hello MorehouseSteve, firefox doesn't support any group policy settings per default - you might have to contact the developers or support resources of the plugin or extension you're using to get further help on this issue...

Maybe you are looking for

  • Print out array to JTextArea

    Hello! I having trouble to print out the array to a JTextArea. This is an asignment so please do not spoonfeed me with code. To test that I have added elements correctly in my array I sat it up to print out in console, wich works fine. Please give me

  • Dynamic Routing with VPN and multiple Peers

    I have several sites that connect to my primary host site (ASA5525-X) via LAN to LAN tunnels and currently all internal host routing is static. I need to implement a backup host site (ASA5520) for the remote sites to connect to. I know that I can add

  • 8530 White Screen AFTER Installing a new Screen

    Hi, my dog got hold of my 8530 and put a toothmark in the screen cover. The screen was also damaged meaning I could see white and grey stripes. I bought a new screen and replaced the old one. Now when I turn it on, I get the white screen and i cannot

  • When I open email it goes to a site called casual games beta instead of my email

    WHEN i OPEN MY EMAIL AND CLICK ON THE SENDER IT GOES TO A SITE CALLED CASUAL GAMES BETA POWERED BY YAHOO AND i CAN'T READ MY EMAILS

  • ACE - Load Balance SMB?

    Can the ACE load balance SMB? Server 1 DNS is msserver1 Server 2 DNS is msserver2 VIP DNS is msserver Can the ACE replace the server name (or IP address) in a tree connect query with the actual real server name that is chosen for the request?