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
    Scott

    Hi 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

  • FTP failure in CS 5.5

    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

  • CS6 FTP failure

    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....

  • WAAS FTP Failure

    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.

  • VPN 3000 problem

    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"
    Thanks

    I'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,
    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

  • 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

  • MHS-TS10 installing error

    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

  • IWeb - publishing a pdf form

    Howdy, How do I publish a pdf form on iWeb so that visitors can fill it and return it to me? thanx pierre