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 -
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,000Hello 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
ThanksHi,
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=0Try 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 -
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?
ThanksHi,
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 -
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?
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. -
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 youYes. 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
-
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
-
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?