FTP Failure: Lots of TCP Retransmission & Duplicate ACK
Hi Friends,
I am having some serious problem with FTP transfer between 2 sites. When ever trying to send files more than 10 15 Mb its failing or less files receiving.
I put a sniffer into one of access switch between and capture some data. I can see a lot of retransmissions and DUP ACK happening.
Capture File :- https://www.cloudshark.org/captures/03975d64a70e
Can some expert on packet capture help me understand this :-
1. Everything was fine till Line-69 i.e the ACK send from receiver(10.21.1.58) to server(10.29.1.199).
2. On Line-70 Server send a packet with SEQ-42901.
3. Next the receiver replies it with ACK-44201.
4. The server notice that the previous SEQ-42901 is not ACK, so it mentioned it as lost frame.
5. On the exact next trasmit the server directly move to a SEQ-78145 WHY ???...
6. Next there are 12 DUP-ACK on ACK-44201 from client to server and then there is a FAST Retransmision from server for that segment.
7. And further a lot of similar problems through out the capture,which is the cause of failure.
Can someone help me understanding the cause of this.
Hello,
Did you find a solution to your problem ?
I am facing a similar situation and I cannot find the root cause.
Thank you
Similar Messages
-
ACE duplicate ack and tcp out-of-order errors
Hi,
I have just performed a capture using a NAM in my 6500 on the port attached to my ACE appliance.
What i have noticed in the capture is a lot of duplicate ack errors and tcp out-of-sync errors.
The reason we found this was becuase the link utilisation per session seems higher than we expected, hence are the errors adding to this and is there any way to remedy them?
Thanks
ScottHi Scott,
I'm not sure why you would see duplicate packets, although when you use SPAN, I know you can see them when you configure it to capture both directions on a VLAN. This is because you see each packet as it enters and leaves the VLAN. I don't know if that would apply to a NAM.
One thing you could do is use the ACE 4710's built-in capture utility to see if you see the same symptoms from an alternative source. This is covered in the Capturing Packet Information section of the configuration guides.
Hope this helps,
Sean -
[solved] problems with timeouts and tcp retransmission
I've recently upgraded my archlinux and am having real problems with the network.
I have checked the configuation and all seems ok.
Everything like DNS/Gateways/IPs all seem to be setup (not changed anything from when it was working before)
I read about setting the MTU manually
ifconfig eth0 mtu 1492
I tried this but it doesn't seem to make any difference
Looking at the packetflow on wireshark it seems that there are a huge amount of TCP Dup ACK and TCP Retransmission when trying to POST
If I boot into windows everything is fine so unfortunately it seems that it might be something with linux
Everything in linux seemed to be working ok before I upgraded
Last edited by equilibrium (2009-12-05 15:13:14)seems that I am still unable to post from my arch system
$ dmesg | grep sky2
sky2 driver version 1.23
sky2 0000:02:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
sky2 0000:02:00.0: setting latency timer to 64
sky2 0000:02:00.0: Yukon-2 EC chip revision 2
sky2 0000:02:00.0: irq 29 for MSI/MSI-X
sky2 eth0: addr xx:xx:xx:xx:xx:xx
sky2 eth0: enabling interface
sky2 eth0: Link is up at 100 Mbps, full duplex, flow control both
$ ifconfig
eth0 Link encap:Ethernet HWaddr 00:17:31:F4:ED:A2
inet addr:192.168.1.20 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1170 errors:0 dropped:0 overruns:0 frame:0
TX packets:1362 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1101154 (1.0 Mb) TX bytes:197742 (193.1 Kb)
Interrupt:19
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:4595 errors:0 dropped:0 overruns:0 frame:0
TX packets:4595 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:541498 (528.8 Kb) TX bytes:541498 (528.8 Kb)
/etc/rc.conf
eth0="eth0 192.168.1.20 netmask 255.255.255.0 broadcast 192.168.1.255"
INTERFACES=(eth0)
gateway="default gw 192.168.1.1"
ROUTES=(gateway) -
Failure modes in TCP WRITE?
I need help diagnosing an issue where TCP communications breaks down between my host (Windows) and a PXI (LabVIEW RT 2010).
The bottom-line questions are these:
1...Are there circumstances in which TCP WRITE, given a string of say, 10 characters, will write more than zero and fewer than 10 characters to the connection? If so, what are those circumstances?
2...Is it risky to use a timeout value of 1 mSec? Further thought seems to say that I won't get a 1000 uSec timeout if we're using a 1-mSec timebase, but I don't know if that's true in the PXI.
Background:
On the PXI, I'm running a 100-Hz PID loop, controlling an engine. I measure the speed and torque, and control the speed and throttle. Along the way, I'm measuring 200 channels of misc stuff (analog, CAN, TCP instruments) at 10 Hz and sending gobs of info to the host (200 chans * 8 = 1600 bytes every 0.1 sec)
The host sends commands, the PXI responds.
The message protocol is a fixed-header, variable payload type: a message is a fixed 3-byte header, consisting of a U8 OpCode, and a U16 PAYLOAD SIZE field. I flatten some structure to a string, measure its size, and prepend the header and send it as one TCP WRITE. I receive in two TCP READs: one for the header, then I unflatten the header, read the PAYLOAD SIZE and then another read for that many more bytes.
The payload can thus be zero bytes: a TCP READ with a byte count of zero is legal and will succeed without error.
A test starts with establishing a connection, some configuration stuff, and then sampling starts. The 10-Hz data stream is shown on the host screen at 2-Hz as numeric indicators, or maybe selected channels in a chart.
At some point the user starts RECORDING, and the 10-Hz data goes into a queue for later writing to a file. This is while the engine is being driven thru a prescribed cycle of speed/torque target points.
The recording lasts for 20 or in some cases 40 minutes (24000 samples) and then recording stops, but sampling doesn't. Data is still coming in and charted. The user can then do some special operations, related to calibration checks and leak checks, and those results are remembered. Finally, they hit the DONE button, and the whole mess gets written to a file.
All of this has worked fine for several years, but as the system is growing (more devices, more channels, more code), a problem has cropped up: the two ends are occasionally getting out of synch.
The test itself, and all the configuration stuff before, is working perfectly. The measurement immediately after the test is good. At some point after that, it goes south. The log shows the PXI sending results for operations that were not requested. The data in those results is garbage; 1.92648920e-299 and such numbers, resulting from interpreting random stuff as a DBL.
After I write the file, the connection is broken, the next test re-establishes it, and all is well again.
In chasing all this, I've triple-checked that all my SENDs are MEASURING the size of the payload before sending it. Two possibilities have come up:
1... There is a message with a payload over 64k. If my sender were presented with a string of length 65537, it would convert that to a U16 of value 1, and the receiver would expect 1 byte. The receiver would then expect another header, but this data comes instead, and we're off the rails.
I don't believe that's happening. Most of the messages are fewer than 20 bytes payload, the data block is 1600 or so, I see no evidence for such a thing to happen.
2... The PXI is failing, under certain circumstances, to send the whole message given to TCP WRITE. If it sent out a header promising 20 more bytes, but only delivered 10, then the receiver would see the header and expect 20 more. 10 would come immediately, but whatever the NEXT message was, it's header would be construed as part of the payload of the first message, and we're off the rails.
Unfortunately, I am not checking the error return from TCP write, since it never failed in my testing here (I know, twenty lashes for me).
It also occurs to me that I am giving it a 1-mSec timeout value, since I'm in a 100-Hz loop. Perhaps I should have separated the TCP stuff into a separate thread. In any case, maybe I don't get a full 1000 uSec, due to clock resolution issues.
That means that TCP WRITE cannot get the data written before the TIMEOUT expires, but it has written part of it.
I suspect, but the logs don't prove, that the point of failure is when they hit the DONE button. The general CPU usage on the PXI is 2-5% but at that point there are 12-15 DAQ domain managers to be shutting down, so the instantaneous CPU load is high. If that happens to coincide with a message going out, well, maybe the problem crops up. It doesn't happen every time.
So I repeat the two questions:
1...Are there circumstances in which TCP WRITE, given a string of say, 10 characters, will write more than zero and fewer than 10 characters to the connection? If so, what are those circumstances?
2...Is it risky to use a timeout value of 1 mSec? Further thought seems to say that I won't get a 1000 uSec timeout if we're using a 1-mSec timebase, but I don't know if that's true in the PXI.
Thanks,
Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com
Blog for (mostly LabVIEW) programmers: Tips And Tricks
Solved!
Go to Solution.There are a couple of issues at play here, and both are working together to cause your issue(s).
1) LV RT will suspend the TCP thread when your CPU utilization goes up to 100%. When this happens, your connection to the outside world simply goes away and your communications can get pretty screwed up. (More here)
Unless you create some form of very robust resend and timeout strategy your only other solution would be to find a way to keep your CPU from maxing out. This may be through the use of some scheduler to limit how many processes are running at a particular time or other code optimization. Any way you look at it, 100% CPU = Loss of TCP comms.
2) The standard method of TCP communication shown in all examples I have seen to date uses a similar method to transfer data where a header is sent with the data payload size to follow.
<packet 1 payload size (2 bytes)><packet 1 payload..........><packet 2 payload size (2 bytes)><packet 2 payload.......................>
On the Rx side, the header is read, the payload size extracted then a TCP read is set with the desired size. Under normal circumstances this works very well and is a particularly efficent method of transferring data. When you suspend the TCP thread during a Rx operation, this header can get corrupted and pass the TCP Read a bad payload size due to a timeout on the previous read. As an example the header read expects 20 bytes but due to the TCP thread suspension only gets 10 before the timeout. The TCP Read returns only those 10 bytes, leaving the other 10 bytes in the Rx buffer for the next read operation. The subsequent TCP Read now gets the first 2 bytes from the remaining data payload (10 bytes) still in the buffer. This gives you a further bad payload read size and the process continues OR if you happen to get a huge number back, when you try to allocate a gigantic TCP receive buffer, you get an out of memory error.
The issue now is that your communications are out of sync. The Rx end is not interpeting the correct bytes as the header thus this timeout or bad data payload behavior can continue for quite a long time. I have found that occasionally (although very rare) the system will fall back into sync however it really is a crap shoot at this point.
I more robust way of dealing with the communication issue is to change your TCP read to terminate on a CRLF as opposed to the number of bytes or timeout (The TCP Read has an enum selctor for switching the mode. In this instance, whenever a CRLF is seen, the TCP Read will immediately terminate and return data. If the payload is corrupted, then it will fail to be parsed correctly or would encounter a checksum failure and be discarded or a resend request issued. In either case, the communications link will automatically fall back into sync between the Tx and Rx side. The one other thing that you must do is to encode your data to ensure that no CRLF characters exist in the payload. Base64 encode/decode works well. You do give up some bandwith due to the B64 strings being longer, however the fact that the comm link is now self syncing is normally a worthwhile sacrifice.
When running on any other platform other than RT, the <header><payload> method of transmitting data works fine as TCP guarantees transmission of the data, however on RT platforms due to the suspension of the TCP thread on high CPU excursions this method fails miserably. -
Adobe products (Dreamweaver CS 3 and CS4) and FTP failures in Snow Leopard
Hi all, this is a bit of a cross post, sorry, but I wanted to be a bit more precise about the nature of a problem many folks are voicing. That is, Dreamweaver and Adobe products are trouble it seems, particularly around the FTP function (there are other issues too). Yet it does not affect machines universally.
For instance, initially after the Snow Leopard update CS3 (Dreamwearver) worked fine, the for me poof the FTP client in Dreamweaver failed with the ubiquitous Permissions error.
On line forums suggest:
1) recreating all Dreamweaver accounts with ==> various reports of success.
2) Using a direct IP address to the server in question....==> also mixed results.
3) Reinstall CSx--==> not a fix.
So for those of us tearing hair out over the problem, Adobe itself has been no help, anyone find a patch or have an untried idea?
thanks.See if this helps:
http://forums.adobe.com/thread/439283
Ken Ford -
I have been updating one of my sites on and off all day. Suddenly I started getting error messages that the server was not responding.
The remote files were all visible in my remote screen, but it had become impossible to ftp any files. When I checked the site info, I found that the FTP address, Username, password and root directory fields were all blank.
This applies to about 8 sites. It did not happen all at once, as sometimes the files transferred successfully.
Has this happened to anyone else?I've never seen that happen, but it sounds like something is corrupting the site defintions. Here's what I would do...
1. From the Files tab menu, choose Site > Recreate Site Cache, then check if the ftp info is actually gone, if it is...
2. Run any and all anti-virus/anti-malware software you have and kill any bugs you find.
3. Go through the process of clearing the DW cache file and config folder: http://forums.adobe.com/thread/494811
4. Build new Site Defintions in DW from existing content and delete the old ones.
5. If it still happens after that, a full un-install and reinstall of DW -
I am experiencing multiple problems with CS6 FTP. I am using Mac OS X (Lion) and I have applied the DW CS6 12.0.1 updater. Still cannot put and have the permissions on the file be anything other than 0. I have to change the permissions on the file manually to 644. I cannot overwrite a file on the remote server after editing. I have to delete the old file, upload the edited file and then manually change the permissions. This occurs with all file types - html, pdf, JPEG and Gif. Sometimes, if I completely close Dreamweaver and start with another site, the first file I put will be ok, but everything after that one is a problem. I have several sites on mainehost.com and bluehost.com. Mainehost.com uses Pure-FTPd [privsep] [TLS]. Bluehost uses Pure-FTPd [privsep] [TLS]. Also experiencing same problems with an Intranet server using WS_FTP Server 7.5(53268144). This problem occurs whether I put from the edit window after saving or from the Files window. I have no confidence in CS6 and have gone back to CS5.5. Please take this problem seriously!
However, people here don't like me saying Windows hasn't got such probelms.
This is complete nonsense.
Never seen anybody posting FTP problems on their windows system though I expect these to flood in now that I have mentioned it.
DW's FTP has gotten its share of gripes both from Windows and Mac users. I can't say that I've seen a serious platform imbalance over time, although there has definitely been a spate of complaints from Mac users in CS6. I use DW routinely on PCs and occasionally on Macs and can say that since DW2, I've not felt the need to switch to a 3rd-party FTP program, nor have I experienced any of the current problems on Macs with CS6, so as far as I can see there are still too many variables involved to lay those problems on DW. I have a strong suspicion, though, that Mountain Lion is involved.... -
Attempting to FTP a Wireshark capture file>
381796-4216-R#copy disk ftp 166.38.50.249 C:\ Columbus_WAAS.pcap JimsTest1_000$
Enter username for remote ftp server: 2ndlvl
Enter password for remote ftp server:
Initiating FTP upload...
Sending: USER 2ndlvl
3Com 3CDaemon FTP Server Version 2.0
User name ok, need password
Sending: PASS ********
User logged in
Sending: TYPE I
Type set to I.
Sending: PASV
Entering passive mode (166,38,50,249,14,92)
Sending: CWD C:\
C:\ : No such file or directory.
ftp changing to remote directory failed.
The FTP upload failed. Please try again.
Sent 0 bytes
=====================================================================
Destination FTP server gives a "Session closed by peer".
Any assistance is much appreciated!Hi James,
Seems like issue in FTP command, see below
copy disk ftp 166.38.50.249 C:\ Columbus_WAAS.pcap JimsTest1_000$
here is how it should be
copy disk ftp 166.38.50.249 (FTP_Folder_on_FTP_Server) (Filename on remote FTP server) (Local filename)
So if FTP server folder is the root of FTP server then simply define "/" See below example
copy disk ftp 172.16.1.20 / UcliEvt.log UcliEvt.log
Enter username for remote ftp server:
Hope this helps. -
I have 2 CVPN 3000 at my institution. They have both software version 4.7.2.L-k9. Thay also have WebVPN running.
Lately something strange has been happening. One VPN loses connection (ping keepalives stop working) and no one can connect. When this happens I change the dns A record of the vpn service to the 2nd CVPN and, after a while, that 2nd CVPN stops responding. Can this be an attack? What can I search for in the logfile? The logfile cannot handle more than 15, 20 minutes.
Thanks in advance.I have captured some traffic directed to the SSL port. There alots of TCP retransmission packets (ack dup).
Disabling SSL service I have the CVPN running for a day now.. it seems the problems have stopped. Of course nw I don?t have WebVPN service.
Any suggestions? Has anyone experienced such a problem?
Tx -
ACE Normalization for SMTP Traffic
Hi,
I was facing issue with the ACE normalization and that was stopping my SMTP traffic. When i disabled it globally my SMTP traffic is working fine. But due to the audit i cannot disabled it for all the traffic. I want to disabled the normalization only for the SMTP por 25 traffic.
I am trying to create the L4 policy as mention below but unable to set the partameter require for to disable the normalization.
class-map match-any SMTP_CLASS
match port tcp eq 25
parameter-map type connection TCP_SMTP_MAP
no random-sequence-number
exceed-mss allow
policy-map multi-match TCP_SMTP_POLICY
What else i need to reacll in parameter-map in order to disable the normalization for SMTP traffic.
Pleae help.Hi,
I have attached the capture when normalization was enabled (not working) and capture when normalization was disabled.
Please review and let me know how to achive this by fine tunning the parameters.
We are seeing lot of tcp retransmission error etc.
I have done some research and normalization deals with the following below mentoin parameters.
exceed-mss-----Configure behavior if a packet exceeds MSS
random-seq-num-disable----Disable TCP sequence number randomization
reserved-bits-----Configure Reserved bits in TCP header
syn-data-----Configure behavior for a SYN packet containing data
tcp-options-----Configure TCP header options
urgent-flag-----Allow/Clear Urgent flag -
Slow SMB transfer on Windows 2012R2
Hi,
i have ESXi host with windows 2012R2 and Windows 2008R2 which has 1Gbit network. I am trying to copy a folder from win 2008R2 which is 57MB and has 4084 files. When this folder from win 2008r2 to win 2008r2 i am getting about 10MB/s, but when i copy that
same folder to win2012r2 i am getting transfer speed of 3-4MB/s
I tried following:
Set-SmbServerConfiguration -EnableSMB2Protocol $false
See:
http://support.microsoft.com/kb/2696547/en-us
Note: This is just for testing and you can enable it after testing.
If it is SMB related, try to disable the TCP Chimney Offload, Receive Side Scaling and Network Direct Memory Access features.
Information about the TCP Chimney Offload, Receive Side Scaling, and Network Direct Memory Access features in Windows Server 2008
http://support.microsoft.com/kb/951037
Here are the steps to disable RSS, TCP Chimney Offload and NetDMA:
netsh int tcp set global rss=disabled
netsh int tcp set global chimney=disabled
In HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters, double-click the EnableTCPA registry entry.
Note: If this registry entry does not exist, right-click Parameters, point to New, click DWORD Value, type EnableTCPA, and then press ENTER.
To disable NetDMA, type 0 in the Value data box, and then click OK.
I also tried to disable SMB signing (http://mctexpert.blogspot.com/2011/02/disable-smb-signing.html) but no help.
VMs have same configuration (vCPU and memory) What i noticed on 2012r2 is that explorer takes about 23% of CPU while doing copy while on 2008r2 cpu usage is 11%.
I came to a point where i don't know where to look for a problem anyone maybe had same issues? Btw it is NOT vmware problem :).Hi,
Please try to copy a large file. If the speed is normal, it means that is should not be a SMB issue.
Also, please try to perform a network capture on the server. Check if there are a lot of TCP retransmission in the capture data.
If there is no retransmission, the speed of transmission should be limited by performance of the disk.
To download network monitor, please refer to the link below,
https://www.microsoft.com/en-us/download/details.aspx?id=4865
Best Regards.
Steven Lee
TechNet Community Support -
ACE Dup ACK and TCP Out-of-order
Hi,
I have a pair of FT ACE 4710 offloading https traffic to a couple of webservers. We are seeing very high network utilisation when I capture the client facing port of the active ACE. There appears to alot of duplicate ACKs and TCP out-of-order packets (as shown by wireshark). Does anyone know if this is a problem with the ACE or "normal"
ThanksI've seen some similar behaviour with the ACE Module and Apache webservers. To mitigate this I've configured the following which seems to work.
On the ACE Module
parameter-map type http ALL-HEADERS
persistence-rebalance
parameter-map type connection TCP-OPTIONS
set tcp syn-retry 5
tcp-options timestamp allow
policy-map multi-match test-policy
class http-vip
loadbalance vip inservice
loadbalance policy http-test-pm
loadbalance vip icmp-reply active
appl-parameter http advanced-options ALL-HEADERS
connection advanced-options TCP-OPTIONS
On Apache here are the two test results with keepalive on and off
httpd.conf
KeepAlive Off
MaxKeepAliveRequests 1024
KeepAliveTimeout 30
MK-ACE01/001# show serverfarm MK-FARM-sf
serverfarm : MK-FARM-sf, type: HOST
total rservers : 8
----------connections-----------
real weight state current total failures
---+---------------------+------+------------+----------+----------+---------
rserver: MK-HOST10
10.10.1.10:0 8 OPERATIONAL 321 510863 16442
rserver: MK-HOST11
10.10.1.11:0 8 OPERATIONAL 304 512718 16276
rserver: MK-HOST12
10.10.1.12:0 8 OPERATIONAL 286 524207 17257
rserver: MK-HOST13
10.10.1.13:0 8 OPERATIONAL 291 516987 16626
rserver: MK-HOST14
10.10.1.14:0 8 OPERATIONAL 291 513016 16594
rserver: MK-HOST15
10.10.1.15:0 8 OPERATIONAL 311 510177 16434
rserver: MK-HOST16
10.10.1.16:0 8 OPERATIONAL 345 516340 16708
rserver: MK-HOST17
10.10.1.17:0 8 OPERATIONAL 282 513046 16418
httpd.conf
KeepAlive On
MaxKeepAliveRequests 1024
KeepAliveTimeout 30
MK-ACE01/001# show serverfarm MK-FARM-sf
serverfarm : MK-FARM-sf, type: HOST
total rservers : 8
----------connections-----------
real weight state current total failures
---+---------------------+------+------------+----------+----------+---------
rserver: MK-HOST10
10.10.1.10:0 8 OPERATIONAL 0 553 0
rserver: MK-HOST11
10.10.1.11:0 8 OPERATIONAL 0 551 0
rserver: MK-HOST12
10.10.1.12:0 8 OPERATIONAL 0 552 0
rserver: MK-HOST13
10.10.1.13:0 8 OPERATIONAL 0 555 0
rserver: MK-HOST14
10.10.1.14:0 8 OPERATIONAL 0 554 0
rserver: MK-HOST15
10.10.1.15:0 8 OPERATIONAL 0 551 0
rserver: MK-HOST16
10.10.1.16:0 8 OPERATIONAL 0 550 0
rserver: MK-HOST17
10.10.1.17:0 8 OPERATIONAL 0 550 0
This seems to of reduced the large number or re-transmits and dup-acks. -
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 -
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,
NavrasInteresting - 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 -
Getting huge number tcp-retransmissions 7& TCP Dup ACK packets.
Hi,
I was working with a issue, in which we were observing that the citrix application page is freezing intermittently for 5-10secs and again working without any discosnnections.
On troubleshooting I did nt observe any abnormal latency or packet loss on the GRE tunnel from source vlan till server destiantions.
The citrix traffic flows via a GRE tunnel to remote location then via plain internet flows to a internet facing citrix server behind a firewall.
On analyzing the traffic using Ethereal I have observed huge number of duplicate ACK packets and TCP retransmissions, hence i derived it has some thing to do with packet fragmentations.Hence I modified that TCP MSS size to 1400 from 1412.
Hence I modified the GRE tunnel configs as below
Router#sh run int tu 691
interface Tunnel691
description XXXX
ip address X.X.X.41 255.255.255.252
ip mtu 1500
ip tcp adjust-mss 1400
tunnel source Loopback69
tunnel destination X.X.X.X
end
Still there is intermittent issue.Can you pls help me to find out where excatly the issue can lie.We had a similar issue and issued the following commands and everything is working well.
ip mtu 1476
ip tcp adjust-mss 1436
Maybe you are looking for
-
when installing Bloggie software, get always message that "Bloggie software has error". Using XP. Help!
-
PO created but SC still in SOCO
Hi, We are working on SRM 4.0 Extended Classic Scenario. Once the PO is created in SRM, the Shopping cart should get removed from the SOCO of the Purchaser, but the SC are still in the SOCO. We have applied some notes and the issue is now resolved,
-
How Can I make the toggle navigation OFF a default for an user
HI, working with ISS6 Windows 2003 and Xir2 (SP3) I am trying to make one specific user (Or all users) to have hidden (grapped) by default the navigation panel in Infoview, but this setting seems to pick the default (Display=true) not from the user's
-
Flash player for IE does not install
from my ie browser, flash player downloads and installs successfully on Win7. however chrome browser opens and the successful confirmation page shows up. i go back to ie browser and it still says no flash player. i did the install 10 times and all
-
Howdy, How do I publish a pdf form on iWeb so that visitors can fill it and return it to me? thanx pierre