TCP / HTTP overhead

I appologize if this is not the correct place to post this question.. I am trying to understand the overhead with tcp and HTTP response that I see in the packet capture (wireshark)  which I am attaching to this thread.
My understanding is:
I can calculate the TCP data portion by subtracting the ip/tcp headers from the total length field in IP header. My confusion is when looking at the tcp data payload and then seeing the overhead that is specified in the HTTP response header/message body.  I see there is 1448 bytes that is the tcp data portion of the packet.
However, the HTTP response header is 347 bytes and the Content-Length of the entity message body is 3867 bytes. I am trying to wrap my head around how to determine the correct overhead for this specific packet. Normally this is very simple but its the HTTP rsponse header thats throwing me off.
Can anyone break this down and help me to understand how I can have 1448 for TCP data but greater values for the HTTP portion?

So as I am thinking on this, after the first post..... The remaining  would be the initial segment ( not really fragment ) of the response  message..I think   I was overcomplicating this when it is very simple...
Thanks for clarification.

Similar Messages

  • Do streaming video plugins have to use TCP/HTTP transport ?

    Can browser plugins open UDP sockets ? all the video plugins I know of are TCP/HTTP based, but I don't know if that is a requirement of operating through a browser.

    milnuts wrote:
    Ok, I reconfigured my system.  Current setup is now
    Cable Modem -> Time Capsule -> Switch (connected to both the blu ray, Xbox 360, and PC).
    I just tried to connect with both the Xbox and the blu ray player, no luck.  
    Yes, that is disappointing.. can you briefly borrow the router from your neighbour and test it again.. I would really like to see what happens when you put the netgear back and pull full ipconfig /all from the computer. Or another router of any kind.. if your modem is also a router completely remove the TC and see what happens.
    The Xbox360 won't even recognize the PC at all.  I thought for sure this would work as the Time Capsule is completely out of the picture, or so I would have thought.
    What can change when you swap router??
    Windows can change.. here is one I missed in the previous suggestions.. windows can jump from home location to work or public without telling you, simply because you changed router. Jump into windows PC and make sure the location is set to home.. turn off the firewall even. Turn off ipv6 as the TC is ipv6 capable and that could mess things up.
    Even turn on the guest account with full permissions.. and see if any of those things helps.
    How do I set the IP for the blu-ray and PC to something other than the default?  I tried to do that through the AirPort Utility in the Time Capsule.  Network->DHCP Reservations->+  That lets me put in the MAC address for the device I want to reserve, but it only allows me to change the last bit of the address.  So it grays out the 10.0.1 and only allows me to change the last number.
    No, you cannot do it via dhcp.. you set manual IP address.. in other words, open the PC networking.. go to TCP/IP properties and change from auto to manual and set IP as I indicated. You do it directly on the PC and directly on the bluray and xbox.. not via dhcp.

  • TCP & HTTP

    http is lies on the tcp....but TCP is Stateful and HTTP is stateless......
    how it is possible....... please send me the details........

    Basically, HTTP "standard" does not define any state mechanics. Instead, various people, businesses, and organizations added things into their software to provide for state management.
    There are two sides to this debate: Server-Side State Management (S3M), and Client-Side State Management (CS2M).
    Cookies are one way to provide for state-management, but there are privacy and security concerns.
    Stateful HTTP, designed through various server-side mechanics, are basically data stores on a server that holds information from CGI forms and some custom per-box settings.
    This is great, because things can be done easily with a homogenious system. Oops, too bad the net is NOT homogenious.
    We have Opera, Netscape, Firefox, IE, etc. for client-side software, while IIS, Apache, Tomcat, etc. for server-side software.
    All different companies - and thus - no uniform support of technologies. Certainly, an Apache web server is not going to out-of-the-box support IWA (Integrated Windows Authentication).
    There is a problem with ad-hoc state management within the current cycle of software.

  • How to calculate the byte tranfer to the http server

    Hi,
    I'm developing a multiplayer game on mobile phone.
    At the end of the connexion, I need to know how many bytes were sent and received from the http server.
    Here is the part code for the connexion to the server :
    HttpConnection connection = (HttpConnection)Connector.open(request);
    connection.setRequestMethod(HttpConnection.GET);
    InputStream is = connection.openInputStream();
    long length = connection.getLength();
    byte[] datach = new byte[1];
    int ch = 0;
    while(is.read(datach) != -1)
         ch = datach[0];
         b.append((char)ch);
    String s = b.toString();The size of each data I have to send or receive is less than 50 bytes.
    All I do for now is adding the request size and the server response size.
    For each request, I have to count the header size and the data size. But I don't know how to find the header size of my request.
    And for each response from the server, I count the header size and the data size with connection.getLength().
    I don't know whether it's the right method.
    Does anyone know a better method to calculate exactly the bytes sent and received?

    TCP/IP "overhead" is basically 20%.

  • How do I create a digital signature on a TCP or a UDP flow?

    I am trying to convert samples of a voice signal, which is intercepted from the microphone, into fixed length digital signature bytes (using Hash, or) and attach these fixed length bytes to a communication session between two terminals (UDP or TCP "HTTP"). The other receving end should be able to identify the person at the sending side.
    Any thoughts how I could do this?
    Any help is most appreciated.
    Sam

    Sam,
    If you have the Sound and Vibration toolkit it may make some things easier for you regarding the voice-recording aspect, but if you aren't recording and playing back the actual sounds, just using this for detection and digital signatures, you shouldn't need to worry about this.
    1. For this you are going to be doing some form of Analog Input.  Then you will be storing this data to a file.  There are examples for both of these aspects in the NI Example Finder from within LabVIEW.
    2. If you are going to be doing the FFT, there is a VI under the Mathematics Palette that performs this operation.  Again you can use the same example for saving data to the file.
    3. You would need to figure out what needs to be done to create a digital signature for this.  There may be something in the Sound and Vibration toolkit for this, but I do not know.
    4. For the UDP or TCP transfers, there are several examples for doing this and they cover how to create the connection and transfer / receive data.  These too are in the NI Example Finder
    5. This goes back to number 4, this would indeed be a separate program, but everything else would just be one project and one program.  
    6. This would depend on how the ID was created in step 3, again whether you do the algorithm on yourself or not.  For comparing to the table, you would use a Search Array and some comparison functions, all depending on how you stored the data initially.
    7. Graphs are all available on your Front Panel of your VIs and you would just wire up the data that you'd like and have it displayed on the graph.
    There will not be an example for everything that you are wanting to do.  The examples are meant to help you get started.  Have you used LabVIEW before?  I would recommend doing the 3 Hour LabVIEW Introduction Course to help you get started.  This will cover some of the basic concepts that you will need to know in order to create your application.
    Unfortunately I cannot write the code for you, only guide and direct you.  LabVIEW is a programming language and does require the user to lay out and create their own program.  You will not be able to just find three or four pre-built code-snippets and connect them together to get your appliction working the way you want it.  You will need to develop the applications yourself.
    Regards,
    Jared Boothe
    Staff Hardware Engineer
    National Instruments

  • 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

  • ACE - Balance HTTP and sticky only SSL/TLS

    Hi there,
    I have a situation that I am trying to solve. We have lot of services trough ACE, but now I have to modify one of them, PROXY servers. 
    I have six (6) servers working with Sticky, but with a MASK 255.255.255.0, which produce an unbalanced situation some times, and that affect some servers on depending of how many users connected to that server. We have between 40K and 50K conns in that serverfarm, but in Sticky terms we have arround 700 /24 subnets.
    I want to modify the configuration, specificaly the MASK to 255.255.255.255, which is going to increase a lot Sticky resources. But thinking in optimize Sticky resources, I want to know if there is a way to select only e-commerce, Home Banking or other kind of SSL/TSL traffic (always using port 80 trough proxy servers), so I could use Sticky only  for connections that need it, and leave other HTTP traffic without this feature.
    I´m sorry, may be I'm doing a silly question, but don´t have the experience to make this configuration, and I will apreciate your help.
    Here is the actual configuration:
    probe tcp HTTP
      description Keepalive web servers
      interval 20
      passdetect interval 30
    rserver host Server1
      ip address 10.1.1.1
      inservice
    rserver host Server2
      ip address 10.1.1.2
      inservice
    rserver host Server3
      ip address 10.1.1.3
      inservice
    rserver host Server4
      ip address 10.1.1.4
      inservice
    rserver host Server5
      ip address 10.1.1.5
      inservice
    rserver host Server6
      ip address 10.1.1.6
      inservice
    serverfarm host PRX
      failaction purge
      predictor leastconns
      probe HTTP
      rserver Server1
        inservice
      rserver Server2
         inservice
      rserver Server3
        inservice
      rserver Server4
        inservice
      rserver Server5
        inservice
      rserver Server6
        inservice
    sticky ip-netmask 255.255.255.0 address source sticky-PRX
      timeout 60
      serverfarm PRX
    class-map match-any VIP-PRX
      2 match virtual-address 10.10.10.101 tcp eq www
    policy-map type loadbalance first-match POLICY-L7-PRX
      class class-default
        sticky-serverfarm sticky-PRX
    policy-map multi-match PRX-Balance
      class VIP-PRX
        loadbalance vip inservice
        loadbalance policy POLICY-L7-PRX
        loadbalance vip icmp-reply
    interface vlan 100
      ip address 10.10.10.11 255.255.255.0
      alias 10.10.10.10 255.255.255.0
      peer ip address 10.10.10.12 255.255.255.0
      no normalization
      access-group output SOLO-SLB
      service-policy input PRX-Balance
    Thanks
    Alexis

    You might want to check out this new product called ITD.
    Simple and faster solution:
    ITD provides :
    ASIC based multi-terabit/s L3/L4 load-balancing at line-rate
    No service module or external L3/L4 load-balancer needed. Every N7k port can be used as load-balancer.
    Redirect line-rate traffic to any devices, for example web cache engines, Web Accelerator Engines (WAE), video-caches, etc.
    Capability to create clusters of devices, for example, Firewalls, Intrusion Prevention System (IPS), or Web Application Firewall (WAF), Hadoop cluster
    IP-stickiness
    Resilient (like resilient ECMP)
    VIP based L4 load-balancing
    NAT (available for EFT/PoC). Allows non-DSR deployments.
    Weighted load-balancing
    Load-balances to large number of devices/servers
    ACL along with redirection and load balancing simultaneously.
    Bi-directional flow-coherency. Traffic from A-->B and B-->A goes to same node.
    Order of magnitude OPEX savings : reduction in configuration, and ease of deployment
    Order of magnitude CAPEX savings : Wiring, Power, Rackspace and Cost savings
    The servers/appliances don’t have to be directly connected to N7k
    Monitoring the health of servers/appliances.
    N + M redundancy.
    Automatic failure handling of servers/appliances.
    VRF support, vPC support, VDC support
    Supported on both Nexus 7000 and Nexus 7700 series.
    Supports both IPv4 and IPv6
    N5k / N6k support : coming soon
    Blog
    At a glance
    ITD config guide
    Email Query or feedback:[email protected]

  • HTTP request abnormal terminaison

    Hi there,
    I have a network problem. I have a http client (java on a Solaris 9 box) that send a http request to a IIS 6.0 server (win 2003). Here is the exchange (captured with ethereal):
    |Time     | Client            | server        |
    |0.000    |         TCP       |               |35437 > http [SYN] Seq=0 Ack=0 Win=49640 Len=0 MSS=1460
    |         |(35437)  ------------------>  (80) |
    |0.081    |         TCP       |               |http > 35437 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1380
    |         |(35437)  <------------------  (80) |
    |0.081    |         TCP       |               |35437 > http [ACK] Seq=1 Ack=1 Win=49680 Len=0
    |         |(35437)  ------------------>  (80) |
    |0.082    |         HTTP      |               |POST /SmartCards/credibility.aspx HTTP/1.1
    |         |(35437)  ------------------>  (80) |
    |0.266    |         TCP       |               |http > 35437 [ACK] Seq=1 Ack=238 Win=65298 Len=0
    |         |(35437)  <------------------  (80) |
    |4.591    |         TCP       |               |35437 > http [FIN, ACK] Seq=238 Ack=1 Win=49680 Len=0
    |         |(35437)  ------------------>  (80) |
    |4.710    |         TCP       |               |http > 35437 [ACK] Seq=1 Ack=239 Win=65298 Len=0
    |         |(35437)  <------------------  (80) |
    |17.008   |         HTTP      |               |HTTP/1.1 200 OK (text/plain)
    |         |(35437)  <------------------  (80) |
    |17.008   |         TCP       |               |35437 > http [RST] Seq=239 Ack=2264099094 Win=49680 Len=0
    |         |(35437)  ------------------>  (80) |
    |17.008   |         TCP       |               |http > 35437 [FIN, ACK] Seq=227 Ack=239 Win=65298 Len=0
    |         |(35437)  <------------------  (80) |
    |17.008   |         TCP       |               |35437 > http [RST] Seq=239 Ack=2264099094 Win=0 Len=0
    |         |(35437)  ------------------>  (80) |My question is : Why the client send a FIN after 4 seconds of no response of the server ? Did I reach the tcp timeout (my tcp_time_wait_interval=60000)
    Anyone have an idea on what is going wrong here ?
    I would really appreciate some help here.
    Matt

    Please post a screenshot that shows what you mean. Be careful not to include any private information.
    Start a reply to this message. Click the camera icon in the toolbar of the editing window and select the image file to upload it. You can also include text in the reply.

  • Using the CSM to setup a HTTPS session on non-standard ports?

    Hi Guys,
    One of our clients wants to setup an SSL connection on a non-standard SSL port i.e. 4444 to begin with. Here the sever handles the SSL encryption / deccryption) instead of the SSL module.
    I've found the following config to work well:
    serverfarm FARM-MOBS-4444
    nat server
    no nat client
    predictor leastconns
    failaction purge
    real 130.194.12.81 4444
    inservice
    real 130.194.12.84 4444
    inservice
    probe MOBS-4444
    sticky 108 netmask 255.255.255.255 timeout 60
    vserver VMOBS-PROD-4444
    virtual 130.194.11.51 tcp https
    serverfarm FARM-MOBS-4444
    sticky 60 group 108
    persistent rebalance
    inservice
    With the above setup the CSM redirects the SSL connections (recieved on 443) to port 4444 on the sever and maintains this for the duration of the session.
    While the above setup works, is it possible to configure the VIP to use a HTTPS port other than 443 (which is default)? This would then allow for separate HTTPS paths to be setup on non-standard ports. I ask this since the client also wants to setup a HTTPS path on port 4443 as well.
    Any ideas would be useful.
    thanks
    Sheldon

    Hi Martin,
    Do you mean using the SSL module to perform the encryption / decryption? If so i've tried this and it does work without an issue.
    I was just wondering if it were possible to have a VIP setup where the HTTPS port is not 443 but say 4443, where the encryption / decryption is done by the real servers themselves.
    thanks
    Sheldon

  • Syslog over TCP?

    Hi all,
    Does anyone know if the MARS can accept syslog over TCP? The issue is that I want the ASA to stop making new connections in case the connection is lost to the MARS.
    Thanks in advance!
    Regards,
    Jesper

    The configuration on MARS is in the bottom of the table located at:
    http://www.cisco.com/en/US/docs/security/security_management/cs-mars/6.0/device/configuration/guide/chAsa8x.html#wp1053993
    And yes, SECURE is the key word needed, but only works if you specify TCP.
    http://www.cisco.com/en/US/docs/security/asa/asa80/command/reference/l2.html#wp1751719

  • OPEN TCP-Ports

    I've detected 4 open network-protzs on my Oracle 8.05 EE
    without configured MTS oder listener.
    Why ??
    Older releases (7.3.4 on other platforms) don't have this
    "problem".
    Any hints are wellcome
    So long
    Christian
    null

    There is the standard set of ports that are open for mgmt by ssh, telnet, and SNMP v2 or v3. Additionally, there is port 80 open so you can point web browser to it and get the FM code. The list is as follows.
    Common to all applications
    * SSH 22 (TCP)
    * TELNET 23 (TCP)
    * HTTP 80 (TCP)
    * SYSLOG 514 (UDP)
    Fabric Manager Server and Performance Manager
    * SNMP_TRAP 2162 (UDP)
    * SNMP picks a random free local port (UDP) - (can be changed in server.properties)
    * Java RMI 9099, 9199 to 9299 (TCP)
    Fabric Manager Client
    * Java RMI 9099, 9199 to 9299 (TCP)
    * SNMP picks a random free local port. (UDP) or 9189 (TCP) if SNMP proxy is enabled (can be changed in server.properties)
    Device Manager
    * SNMP_TRAP 1163 to 1170 (UDP) (picks one available in this range)
    * SNMP picks a random free local port (UDP) or 9189 (TCP) if SNMP Proxy is enabled (can be changed in server.properties)
    You can shut off telnet in lieu of ssh in the configuration. Also, it is possible to use access-lists on the mgmt ports to limit IP addresses/ports/etc. Also, don't forget that the IPS ports will be listening for FCIP and ISCSI if enabled.

  • Open TCP Ports on 9216i

    We are auditing open TCP ports on our network equipment and discovered a number of open TCP ports on our 9216i. Is there any way to tell what the open ports are used for and shut them down if unnecessary? The show tcp command is not available. show tech did not reveal anything.

    There is the standard set of ports that are open for mgmt by ssh, telnet, and SNMP v2 or v3. Additionally, there is port 80 open so you can point web browser to it and get the FM code. The list is as follows.
    Common to all applications
    * SSH 22 (TCP)
    * TELNET 23 (TCP)
    * HTTP 80 (TCP)
    * SYSLOG 514 (UDP)
    Fabric Manager Server and Performance Manager
    * SNMP_TRAP 2162 (UDP)
    * SNMP picks a random free local port (UDP) - (can be changed in server.properties)
    * Java RMI 9099, 9199 to 9299 (TCP)
    Fabric Manager Client
    * Java RMI 9099, 9199 to 9299 (TCP)
    * SNMP picks a random free local port. (UDP) or 9189 (TCP) if SNMP proxy is enabled (can be changed in server.properties)
    Device Manager
    * SNMP_TRAP 1163 to 1170 (UDP) (picks one available in this range)
    * SNMP picks a random free local port (UDP) or 9189 (TCP) if SNMP Proxy is enabled (can be changed in server.properties)
    You can shut off telnet in lieu of ssh in the configuration. Also, it is possible to use access-lists on the mgmt ports to limit IP addresses/ports/etc. Also, don't forget that the IPS ports will be listening for FCIP and ISCSI if enabled.

  • Which TCP/UDP ports need to be opened on a firewall for adobe reader and flashplayer?

    Which TCP/UDP ports need to be opened on a firewall for adobe reader and flashplaer to operate properly? This would include updating, linking, and any subset of features.

    The Acrobat Family uses TCP HTTP/HTTPS for all traffic. The following processes and ports may be active on a Windows client machine:
    AdobeARM.exe - automatic updates - port 443
    AcroRd32.exe - brand messages - port 443
    AcroRd32.exe - links in documents - anything specified in the URL
    Acrobat.exe - brand messages - port 443
    Acrobat.exe - links in documents - anything specified in the URL
    AdobeCollabSync.exe - Tracker review data - port 443
    The same ports are used by the  program components on OS X.
    There are no inbound listening ports for any elements of the Acrobat Family. Automatic updates are not pushed and there are no server processes within the software.

  • AP PHY data rates

    Hello,
    AP 1600 has PHY data rates up to 300 Mbps, and 2600 up to 450 Mbps.
    With 1600 AP, if I have a client connected at 300 Mbps on the radio 5 GHz (MCS index 15, 40 Mhz) and another client connected at 130 Mbps on the radio 2.4 GHz at 130 Mbps (MCS index 15, 20 Mhz); how will the AP handle the traffic ?
    Will the AP force one of the client to lower data rates, or will it drop some paquets ?
    I'm a little bit confuse about the behavior in high density environment,
    Thanks a lot,
    Regards

    Gerald,
    Wi-fi is half duplex medium and data rate does not equal throughput
    Here is a good guide on the issue:
    http://www.speedguide.net/faq_in_q.php?qid=374
    As wi-fi performance is determined by the client, AP and external factors such as interference, wi-fi overhead, distance, loss, etc. figure throughput somewhere @ 50 - 60% of data rate at best. On top of that, there will be tcp/ip overhead too.
    It will always drop to the lowest common denominator.  So if the switchport is only 100 mbps, that is your bottleneck for traffic that goes over it.
    Use some tools like iperf or jperf to do some client-server testing between laptops to see what the actual throughput is.
    If you are using MacBooks, there is a great app in the Mac App Store called WiFiPerf
    Eric

  • SG 300-28 Switch - Jumbo Frames Problem.

    I just got the SG 300-28 28 port switch tonight and got it up and running however, i've encountered a problem regarding jumbo frames. In the documentation and product brochures, it states the SG 300 switches supports jumbo frames up to 10k. When I first setup the switch and enabled jumbo frames, i was getting very slow speeds in my network transfers (800kb/s !!!). All the workstations are running Intel PCIE nic cards with jumbo frames enabled at 9014 bytes. After some troubleshooting, i lowered the frame size to 4088 bytes and everything returned to normal with fast speeds.
    I had a suspicion that it might be the switch that is causing the network slowdown with 9k frames; I went ahead and enabled the 9k jumbo frame settings on my NICs again and started to ping other workstations on the network using the "don't fragment" flag. It turns out, the largest packet that i can send out is 8972 bytes. This is a little far from 10k frames that is stated in the documentation and brochures. Please correct me if i'm wrong, but it seems that i've stumbled into a bug in switch.
    Time for a firmware update?

    Hi Dickson C,
    Interesting query.. TCP, UDP and ICMP packet overhead are fairly negligible according to the information below i would think about 94 bytes for ethernet plus tcp overhead.
    The switch would internally label the ethernet frame to identify what VLAN the frame is in (even Vlan 1), so an extra 4 bytes would be used within the switch for that.
    Ethernet frame format:
    6 byte dest MAC  addr
    6 byte src MAC  addr
    [4 byte optional 802.1q VLAN Tag]
    2 byte length/type
    46-9014 byte data (payload)
    4 byte CRC
    Ethernet overhead bytes:
    12 byte intergap + 8 preamble + 14 header + 4 trailer = 18 bytes/packet w/o 802.1q
    12 byte intergap + 8 preamble + 18 header + 4 trailer = 22 bytes/packet with 802.1q
    TCP encapsulated in Ethernet:
    Assuming no header compression (e.g. not PPP)
    Add 20 IPv4 header or 40 IPv6 header (no options)
    Add 20 TCP header
    Add 12 bytes optional TCP timestamps
    TCP overhead can be 52 bytes
    Ethernet + TCP overhead around 52+22 bytes = 74 bytes
    Your Intel ethernet NIC supports around 9500-byte, so the datasheets from intel suggest for a jumbo frame , but you have it enabled at 9014 bytes.
    So your  NIC enabled at 9014 bytes - 74 bytes for Ethernet and TCP packet overhead= approximately 8940 bytes of data.
    You say you are getting packet data throughput around 8972 bytes.
    Check my maths, I have made a few assumptions.  What you reckon, worth a call to the Small Business Support center to double check, please open a case  and report back with the results. I really may be way off in some of my assumptions.
    regards Dave
    http://www.cisco.com/en/US/support/tsd_cisco_small_business_support_center_contacts.html

Maybe you are looking for