TCP segmentation offload (TSO) and vmxnet3/1000v - bug?

NOTE: My knowledge of ESX and the 1000v does not run deep so I do not have a thorough understanding of the relationship / integration between those two components. If anything I'm saying here is out-of-line I apologize in advance.
Yesterday a report came in that an IIS application on a staging server in our test environment was not working (in Internet Explorer it returned "Page cannot be displayed"). The IIS server sits behind an F5 load balancer. Both the F5 and the IIS server are VM guests on a VMware ESX host. Both the IIS server and the F5 had recently been moved to a new environment in which the version of 1000v changed and the vnic driver changed (from E1000 to vmxnet3) and this appeared to be the first time that anybody noticed an issue.
After some digging we noticed something peculiar. The problem only manifested when the IIS server and the F5 were on the same physical host. If they were not co-resident everything worked just fine. After reviewing packet captures we figured out that the "Page cannot be displayed" was not because the content wasn't making it from IIS server to client but rather because the content was gzip compressed and something happened in-transit between the IIS server and the client to corrupt the payload thereby making the gzip decompressible. As a matter of fact, at no time was IP connectivity ever an issue. We could RDP to the IIS server and SSH/HTTP into the F5 without any issues.
I started digging in a little deeper with Wireshark (details of which are included as an attached PDF). It turns out that a bug??? involving TCP segmentation offload (TSO) was causing the payload of the communication to become corrupted. What I'm still trying to figure out is who is responsible for the bug? Is it VMware or Cisco? I'm leaning towards Cisco and the 1000v and this is why.
Referring to the attached PDF, TEST #2 (hosts co-resident) and TEST #3 (hosts not co-resident) show packet captures taken from the IIS box, the 1000v and the F5. Figure 6 shows that the contents of the gzip'd payload can be deciphered by Wireshark as it leaves the IIS box. Figure 8 shows capture data from the 1000v's perspective (spanning rx/tx on the F5 veth port). It's still good at this point. However, figure 10 shows capture data taken on the F5. At some point in time between leaving the egress port on the 1000v and entering the F5 it cannot be decompressed (corrupt data). There is no mention that the TCP checksum failed. In my mind the only way that the data could be corrupt without a TCP checksum failure is if the corruption occurred during the segmentation of the packet. However, if it was due to the guest OS-level vnic driver then why did it still look good to the 1000v egress towards the F5?
The most curious aspect of this whole thing is the behavior I described earlier related to onbox vs. offbox. This problem only occurs when the traffic is switched in memory. Refer to figure's 11 - 16 for capture data that shows the very same test when the F5 and IIS are not co-resident. Is the 1000v (or vnic) savy enough to skip TSO in software and allow the physical NIC to do TSO if it knows that the traffic is going to have to leave the host and go onto the physical wire? That's the only way I can make sense of this difference in behavior.
In any case, here are all of the guest OS-level settings related to offload of any type (along with the defaults) and the one we had to change (in bold) to get this to work with the vmxnet3 NIC:
IPv4 Checksum Offload: Rx & Tx Enabled
IPv4 TSO Offload: From Enabled to Disabled
Large Send Offload V2 (IPv4): Enabled
Offload IP Options: Enabled
Offload TCP Options: Enabled
TCP Checksum Offload (IPv4): Rx & Tx Enabled
UPD Checksum Offload (IPv4): Rx & Tx Enabled

Hi sdavids5670
Did you ever find a proper fix to your issue? was updating the N1Kv a solution?
I have exactly the same symptoms with a N1Kv [4.2(1)SV2(1.1a)], F5 (ASM), vmxnet3 guests, however I'm failing all RDP (win2k8r2) and SSH large packets (redhat); the rest of my traffic appears fine. This only occurs when the F5 resides on the same VEM or VMware host as you have seen. My packet captures are similar.
My work around is two fold. Firstly create rules to isolate the F5 onto hosts where guests are not utilising it and secondly, disable TCP offloading (I use IPv4 only). Neither of these are solutions.
I have not tried a non-F5 trunk (ie, perhaps a CSR1000v) to replicate this without the F5.
I suspected that the onbox / offbox issue was something specific about the logic of the VEM installed on the host (that's how I justified it to myself) rather than VEM->VEM traffic. It appears that only vEth -> vEth traffic on the same VEM is the issue. Also, I can only replicate this when one of the vEth ports is a trunk. I have yet to be able to replicate this if both are access port-groups (vEths).
I have yet to log a TAC as I wanted to perform testing to exclude the F5.
Thought that I would just ask....
Cheers
David

Similar Messages

TCP Segmentation Offload and Jumbo Frames.

I have VmWare-OpenSolaris and VMXNET3 network card.
Can i enable subj?
#:> ifconfig vmxnet3s mtu 5000
ifconfig: setifmtu: SIOCSLIFMTU: vmxnet3s0: Invalid argument

Hi sdavids5670
Did you ever find a proper fix to your issue? was updating the N1Kv a solution?
I have exactly the same symptoms with a N1Kv [4.2(1)SV2(1.1a)], F5 (ASM), vmxnet3 guests, however I'm failing all RDP (win2k8r2) and SSH large packets (redhat); the rest of my traffic appears fine. This only occurs when the F5 resides on the same VEM or VMware host as you have seen. My packet captures are similar.
My work around is two fold. Firstly create rules to isolate the F5 onto hosts where guests are not utilising it and secondly, disable TCP offloading (I use IPv4 only). Neither of these are solutions.
I have not tried a non-F5 trunk (ie, perhaps a CSR1000v) to replicate this without the F5.
I suspected that the onbox / offbox issue was something specific about the logic of the VEM installed on the host (that's how I justified it to myself) rather than VEM->VEM traffic. It appears that only vEth -> vEth traffic on the same VEM is the issue. Also, I can only replicate this when one of the vEth ports is a trunk. I have yet to be able to replicate this if both are access port-groups (vEths).
I have yet to log a TAC as I wanted to perform testing to exclude the F5.
Thought that I would just ask....
Cheers
David

TCP Segment Overwrite - IDSM2 with IPS5.1(1d)

Hi,
I have an IDSM2 running IPS5.1(1d)S220 upgraded recently from 4.x. My network has windows desktops (spanned on multiple subnets) whose default gateway is a Cisco 6500 FWSM module.
Since I upgraded to IPS 5.x, I am seeing lots and lots of TCP Hijack and TCP Segment Overwrite alarms. The source addresses of these alarms are my windows PCs, destination addresses are Windows 2003 servers..Sometimes, the destination address is 0.0.0.0 and ports are empty.
It is difficult to ignore so many alarms unless there is a technical explanation to see if the placement of FWSM is causing IPS to treat this as a threat.
Can someone help me to get out of this issue?

I found this on a previously written thread. I cannot find the thread anymore. All credit is given to the message owner. i hope the reply helps.
mlhall of - CISCO SYSTEMS wrote:
Oct 6, 2003, 11:06am PST
I have several packet traces from several customers that see this alert. There appears to be a bug in the microsoft TCP stack when connections go stale. What happens is that the last successful segment's last byte is resent with a value of 0xff. This is after the other endhost has ACK'ed the sequence from the last segments.
So for example.
a->b seq=100 data="ABCDEFG"
b->a ack=107 no data
a->b seq=106 data="(0xff)"
The last packet in the example is overwriting the G in the first packet with an 0xff. This causes the IDS to fire. We are working on detecting this stack bug in a new version.

Java NIO - TCP segment size abnormally low

Hi !
After noticing a weird behaviour on our Linux production server for code that works perfectly on my Windows dev box, I used tcpdump to sniff the packets that are actually sent to our clients.
The code I use to write the data is as simple as :
// using NIO - buffer is at most 135 bytes long
channel.write(buffer);
if (buffer.hasRemaining()) {
// this never happens
}When the buffer is 135 bytes long, this systematically results in two TCP segments being sent : one containing 127 bytes of data, the other one containing 8 bytes of data.
Our client is an embedded system which is poorly implemented and handles TCP packets as whole application messages, which means that the remaining 8 bytes end up being ignored and the operation fails.
I googled it a bit, but couldn't find any info about the possible culprit (buffer sizes and default max tcp segment sizes are of course way larger that 127 bytes !)
Any ideas ?
Thanks !

NB the fragmentation could also be happening in any intermediate router.
All I can suggest is that you set the TCP send buffer size to some multiple of the desired segment size, or maybe just set it very large, like 64k-1, so that you can reduce its effect on segmentation.

Signature 1330-X: TCP segment out of order - what does it mean?

Hi,
on a customer's site, on one of their IPS, I get a lot of sig 1330 alerts, mainly those two:
1330-12: TCP segment is out of order. If the signature status is set to disabled, the packet will be passed to all engines that are not stream based.
This signature will not produce an alert in promiscuous mode regardless of the signature status.
1330-17: TCP segment out of state order. If a packet in a stream causes this signature to produce an alert, processing will cease for that stream. This signature will not produce an alert in promiscuous mode regardless of the signature status
I'm not sure how to interpret these alerts correctly and/or how to troubleshoot further. Does anyone have an idea?
Thanks a lot,
Florian

Is your sensor monitoring more than one network segment?
If so then these alarms are common when a TCP connection crosses both networks and gets seen twice by the sensor.
This can confuse the sensor's tracking of the connection.
A common scenario is to have the sensor monitor both the Inside network or a firewall as well as the DMZ. When an internal user connects to the company's web server the traffic gets seen by the sensor both on the Inside network and in the DMZ. The sensor tries to put the packets from both networks together in order to try and monitor it as a single connection. Because the packets get modified by the firewall it often results in inconsitency between traffic on the 2 sides and causes the sensor to be confused about the connection.
The good news is that if this is your problem, then there are 2 easy workarounds.
1) If your sensor supports virtual sensors, then create a second virtual sensor. Assign one network to default vs0, and assign the other network to the new virtual sensor. This way each virtual sensor sees traffic on just one of the networks and won't become confused.
2) If your sensor does not support additional virtual sensors, or you've used up all 4 virtual sensors, then there is a configuration option within the virtual sensor configuration itself:
Inline TCP Session Tracking Mode
By default it is set to Virtual Sensor which is why it tries to put together packets from both networks to try and look at is a single connection and gets confused.
BUT it can also be set to Interface and Vlan. This configuration allows the virtual sensor to treat the traffic on each network independantly. The connection on the first network will be monitored independant of the connection on the second network. This will prevent the virtual sensor from getting confused.
The above is just my guess at what is going on in your network based on what we've seen on other networks. If this doesn't address the reason for the signature triggerings, then please respond back with more information about your network.
It is possible that these could be a hacker trying to avoid detection by the sensor, but more likely something in your deployment is confusing the sensor.

TCP segment of a reassembled PDU - nsludt2.cap (0/1)

Hi,
I've been having some issues lately with long DNS lookups. I ran
PacketScan on the DNS server (10.10.10.20), and saw many occurences of
"TCP segment of a reassembled PDU". This mainly occurred during
communication between the DNS server and other servers on our network.
Could this segmentation issue be the cause of processing delays on DNS
querys? Is this something I should be concerned about? Does it
indicate MTU mismatches between servers? All servers are NW6 SP4.
Please see the attached CAP file.
Thanks,
Jeff Palmer

1) The messages "TCP segment of a reassembled PDU" are not problems. They
are just indicators that the main traffic of that connection occured
earlier. In fact, looking at the actual packets shows that these are
simply TCP keepalive packets. E.g. there are some open connections to your
server and the other end that has the connection open sends keepalive
packets from time to time.
2) Your DNS traffic is perfectly "normal". All requests are properly
replied to. The delays you get are entirely due to the external server
216.68.4.10 (ns1.zoomtown.com) which is slow in responding to you. It
takes 0.8 seconds for the first query your DNS does to it, and 1.7 seconds
for the followup Akamai DNS query. Overall, this leads to a delay of about
2.5 seconds for answering your workstation's query.
If you want to speed up your DNS you should investigate why the queries to
216.68.4.10 take so long and maybe you should consider forwarding your DNS
requests to a different faster server.
Marcel Cox (using XanaNews 1.18.1.6)

ID 1300 TCP Segment Overwrite

I keep seeing the Sig ID 1300 TCP Segment Overwrite between two hosts. This is normal traffic and I have no reason to suspect the machines as having to been compromised or misused. I was wondering if anyone has had the experience of seeing this signature fire for normal traffic. Can this be a programming error caused by our in house programmers writing custom applications?

Personally, I error on the side of suspicion. I would recommend investigating this further. This signature is somewhat suspicious in that segmentation overwriting is something hackers use to try to bypass IPS. Is the destination address always the same, if you are always getting the error from the same source to the same destination that could be a bad sign.?
I would suspect that it's not a program error because, most programmers will just send their data to a socket and the underlying network code will set up windowing and segmentation. In this case most socket code is pretty tried and true.
Is this data coming from a VPN segment? It could be an MTU issue. Could be a network device behaving badly between your source and destination, if this is happening it should be true for more then just one host.
Dont forget you can use your reporting tool and turn on verbose reporting when ever the alert is generated or to assist in forensics you can turn on reporting of all packets between a specific host or destination.

TCP segment Overwrite

Recently, I've been seeing a ton of messages on the IPS Event Viewer stating that TCP Segment Overwrites have been detected. The events are from either the IPS-A to our DMZ or vice versa. It just started whenever we added some servers to the network. Does anybody have any suggestions? We traced the packets, it's not hacker related. It seems like maybe a server or app. may be causing the issue. The problem is isolating it. I would appreciate any feedback you could provide. Thanks!

TCP normalization
Through intentional or natural TCP session segmentation, some classes of attacks can be hidden. To make sure policy enforcement can occur with no false positives and false negatives, the state of the two TCP endpoints must be tracked and only the data that is actually processed by the real host endpoints should be passed on. Overlaps in a TCP stream can occur, but are extremely rare except for TCP segment retransmits. Overwrites in the TCP session should not occur. If overwrites do occur, someone is intentionally trying to elude the security policy or the TCP stack implementation is broken. Maintaining full information about the state of both endpoints is not possible unless the sensor acts as a TCP proxy. Instead of the sensor acting as a TCP proxy, the segments will be ordered properly and the normalizer will look for any abnormal packets associated with evasion and attacks.
http://www.cisco.com/en/US/products/hw/vpndevc/ps4077/products_configuration_guide_chapter09186a00804cf52e.html

TCP Hijack/TCP Segment Overwrite false positives?

Hello all,
I was just curious if anyone else has had many false positives with 3 signatures in particular: TCP Hijack (3250.0 - High), TCP Hijack Simplex Mode (3251.0 - High), and TCP Segment Overwrite (1300.0 - High). The reason I think they are false positives is because they occur everyday, and I've also seem them caused by internal network traffic that crosses an IPS sensor (that is, making the potentially dangerous assumption that the internal devices can be trusted). We usually see between a dozen and 3 dozen a day depending on the signature, and we have 8 IPS total deployed internally and on the perimeters.
Has anyone else had similar experiences? If so, do you have any suggestions on how to decrease the number of false positives for these alerts?
Thanks,
Ryan

I get TCP Hijack and TCP Segment Overwrite all the time. I opened a TAC case about it because it was getting out of hand, and the engineer said that TCP Hijack would be very very hard to execute and if it is getting fired a lot odds are it is a false positive.
This was his response:
5769 - Malformed HTTP Request
This signature basically just looks for traffic destined to one of your web ports (defined by the WEBPORTS variable) and containing a valid HTTP request (i.e., GET, POST, HEAD, PUT, DELETE, TRACE, CONNECT) but followed by malformed (i.e., not proper http protocol syntax) URI information. This type of malformed HTTP request can be used for a variety of exploits. Microsoft has malformed HTTP request vulnerabilities, another attack known as "http request smuggling" can be launched using malformed HTTP requests at a Squid web proxy, which may cause the web proxy and an upstream HTTP agent to disagree on the boundary between HTTP requests on a persistent connection. These are a couple of examples.
If you open this signature in IDM and go to "Edit", you can see the regex it looks for within the http payload. Basically, it looks for a valid HTTP request followed by the hex code regex [\x20][\x21-\x7e]+[\x20]?[\x0d\x0a]. A properly formed HTTP request should not contain this hex code.
It's possible that normal traffic could cause this, but unlikely. If you have further concerns about this signature firing, please capture the trigger packet context either by changing the signature action to 'produce verbose alert' or 'log attacker packet' for analysis. If you need assistance in analyzing these alerts, please contact TAC and open a case on this issue.
3250 or 3251 - TCP Hijack and TCP Hijack Simplex Mode
This signature detects attempts to insert packets into a TCP stream by an attacker in an effort to take over this session. However, if you're using inline ips mode, TCP Hijack attacks are impossible. Also, this type of attack is very rare and not easy to do, and is often a false positive. Types of things that can be used by network sniffers to detect that a TCP hijack may be happening is looking for repeated ARP updates, frames sent between client and server with different MAC addresses, or tcp ack storms.
For these two hijack signatures, per MySDN information:
"This signature fires upon detecting out of order ack packets. The most common network event that may trigger this signature is an idle telnet session. The TCP Hijack attack is a low-probability, high level-of-effort event."
Thus, very likely to be false positives and unlikely to be a legitimate attack given the difficulties involved in doing this. However, it's worth checking out the source / destination of the attacks. Again though, if you are running inline mode, these attacks are impossible and you can ignore these signatures.
About the TCP Segment Overwrite, mine is always fired for port 20 traffic from some sort of web cache server. Is that the same for you?

MiFi4510L sporatically hangs on Web sites w/ IE Win6&7 (THIS URL!); TCP Segment Lost

I had to use Dial-Up just to get this far!!!
Sometimes it works fine; other times it hangs FOREVER (TCP Segment Lost)! Must manually STOP..
I've let it hang for over 10 minutes; nothing ever happens after the last trace entry. No re-xmits.
The last time it hung, I collected dumps&traces, then Stop & Refresh in IE and it worked fine.
During the hang, I successfully TELNET'ed to the DNS (same IPAddr), so it's NOT apparently a connection issue.
Certainly YOUR OWN URL should NOT be having constant problems!
I powered off&on your device. Still occasionally hangs.
WHAT IS GOING ON? The only solution seems to be to use Dial-Up!!! I have NEVER had this problem in all the many years
using Dial-Up.
Here are NETMON traces from a recent hang
669 {DNS:131, UDP:130, IPv4:4} 4:01:19 PM 8/4/2011 127    DNS 0x1    192.168.1.2 8.8.8.8 DNS:QueryId = 0xCAB, QUERY (Standard query), Query for www.goes.noaa.gov of type Host Addr on class Internet
670 {DNS:131, UDP:130, IPv4:4} 4:01:19 PM 8/4/2011 247    DNS 0x2    8.8.8.8 192.168.1.2 DNS:QueryId = 0xCAB, QUERY (Standard query), Response - Success, 129.15.96.23, 140.90.33.23 ...
671 {TCP:132, IPv4:26} 4:01:19 PM 8/4/2011 116 iexplore.exe 0x12d4  TCP 0x1 Half Connected Disregarded  192.168.1.2 129.15.96.23 TCP:Flags=......S., SrcPort=49248, DstPort=HTTP(80), PayloadLen=0, Seq=3442312612, Ack=0, Win=8192 ( Negotiating scale factor 0x2 ) = 8192
672 {TCP:132, IPv4:26} 4:01:19 PM 8/4/2011 116 iexplore.exe 0x12d4  TCP 0x2 Connected Good  129.15.96.23 192.168.1.2 TCP:Flags=...A..S., SrcPort=HTTP(80), DstPort=49248, PayloadLen=0, Seq=3625396553, Ack=3442312613, Win=5840 ( Negotiated scale factor 0x9 ) = 2990080
673 {TCP:132, IPv4:26} 4:01:19 PM 8/4/2011 104 iexplore.exe 0x12d4  TCP 0x1 Connected Disregarded  192.168.1.2 129.15.96.23 TCP:Flags=...A...., SrcPort=49248, DstPort=HTTP(80), PayloadLen=0, Seq=3442312613, Ack=3625396554, Win=4380 (scale factor 0x2) = 17520
674 {HTTP:133, TCP:132, IPv4:26} 4:01:19 PM 8/4/2011 497 iexplore.exe 0x12d4 Request, GET /GIFS/ECIR.JPG HTTP 0x1 Connected Disregarded  192.168.1.2 129.15.96.23 HTTP:Request, GET /GIFS/ECIR.JPG
675 {TCP:132, IPv4:26} 4:01:19 PM 8/4/2011 104 iexplore.exe 0x12d4  TCP 0x2 Connected Good  129.15.96.23 192.168.1.2 TCP:Flags=...A...., SrcPort=HTTP(80), DstPort=49248, PayloadLen=0, Seq=3625396554, Ack=3442313006, Win=14 (scale factor 0x9) = 7168
676 {HTTP:133, TCP:132, IPv4:26} 4:01:19 PM 8/4/2011 1286 iexplore.exe 0x12d4 HTTP Payload, URL: /GIFS/ECIR.JPG IPHTTPS 0x2 Connected Good 0x1 129.15.96.23 192.168.1.2 IPHTTPS
Frame: Number = 676, Captured Frame Length = 1286, MediaType = WiFi
- WiFi: [Unencrypted Data] F.....P, (I) RSSI = -49 dBm, Rate = 67.5 Mbps
- MetaData: RSSI = -49 dBm, Rate = 67.5 Mbps
     Version: 2 (0x2)
     Length: 32 (0x20)
   - OpMode: Extensible Station Mode
      StationMode:           (...............................0) Not Station Mode
      APMode:                (..............................0.) Not AP Mode
      ExtensibleStationMode: (.............................1..) Extensible Station Mode
      Unused:                (.0000000000000000000000000000...)
      MonitorMode:           (0...............................) Not Monitor Mode
     Flags: 0 (0x0)
     PhyType: 802.11g
     Channel: 1, Center Frequency: 2412 MHz
     lRSSI: -49 dBm
     Rate: 67.5 Mbps
     TimeStamp: 08/04/2011, 22:01:19.606165 UTC
- FrameControl: Version 0,Data, Data, F.....P(0x4208)
     Version:        (..............00) 0
     Type:           (............10..) Data
     SubType:        (........0000....) Data
     DS:             (......10........) DS to STA via AP
     MoreFrag:       (.....0..........) No
     Retry:          (....0...........) No
     PowerMgt:       (...0............) Active Mode
     MoreData:       (..0.............) No
     ProtectedFrame: (.1..............) Yes
     Order:          (0...............) Unordered
    Duration: 48 (0x30)
    DA: 1C659D CA2550
    BSSID: Novatel Wireless, Inc. 04C0AF
    SA: Novatel Wireless, Inc. 04C0AF
- SequenceControl: Sequence Number = 889
     FragmentNumber: (............0000) 0
     SequenceNumber: (001101111001....) 889
- LLC: Unnumbered(U) Frame, Command Frame, SSAP = SNAP(Sub-Network Access Protocol), DSAP = SNAP(Sub-Network Access Protocol)
- DSAP: SNAP(Sub-Network Access Protocol), Individual DSAP
     Address: (1010101.) SNAP(Sub-Network Access Protocol)
     IG:      (.......0) Individual Address
- SSAP: SNAP(Sub-Network Access Protocol), Command
     Address: (1010101.) SNAP(Sub-Network Access Protocol)
     CR:      (.......0) Command Frame
- Unnumbered: UI - Unnumbered Information
     MMM: (000.....) 0
     PF:   (...0....) Poll Bit - No Response Solicited
     MM:   (....00..)
     Type: (......11) Unnumbered(U) Frame
- Snap: EtherType = Internet IP (IPv4), OrgCode = XEROX CORPORATION
    OrganizationCode: XEROX CORPORATION, 0(0x0000)
    EtherType: Internet IP (IPv4), 2048(0x0800)
- Ipv4: src=129.15.96.23, Dest = 192.168.1.2, Next Protocol = TCP, Packet ID = 44701, Total IP Length = 1222
- Versions: IPv4, Internet Protocol; Header Length = 20
     Version:      (0100....) IPv4, Internet Protocol
     HeaderLength: (....0101) 20 bytes (0x5)
- DifferentiatedServicesField: DSCP: 0, ECN: 0
     DSCP: (000000..) Differentiated services codepoint 0
     ECT: (......0.) ECN-Capable Transport not set
     CE:   (.......0) ECN-CE not set
    TotalLength: 1222 (0x4C6)
    Identification: 44701 (0xAE9D)
- FragmentFlags: 16384 (0x4000)
     Reserved: (0...............)
     DF:       (.1..............) Do not fragment
     MF:       (..0.............) This is the last fragment
     Offset:   (...0000000000000) 0
    TimeToLive: 46 (0x2E)
    NextProtocol: TCP, 6(0x6)
    Checksum: 63171 (0xF6C3)
    SourceAddress: 129.15.96.23
    DestinationAddress: 192.168.1.2
- Tcp: [Segment Lost]Flags=...AP..., SrcPort=HTTP(80), DstPort=49248, PayloadLen=1182, Seq=3625399474 - 3625400656, Ack=3442313006, Win=14 (scale factor 0x9) = 7168
ALL HANGS GET "SEGMENT LOST"
    SrcPort: HTTP(80)
    DstPort: 49248
    SequenceNumber: 3625399474 (0xD81734B2)
    AcknowledgementNumber: 3442313006 (0xCD2D872E)
- DataOffset: 80 (0x50)
     DataOffset: (0101....) 20 bytes
     Reserved:   (....000.)
     NS:         (.......0) Nonce Sum not significant
- Flags: ...AP...
     CWR:    (0.......) CWR not significant
     ECE:    (.0......) ECN-Echo not significant
     Urgent: (..0.....) Not Urgent Data
     Ack:    (...1....) Acknowledgement field significant
     Push:   (....1...) Push Function
     Reset: (.....0..) No Reset
     Syn:    (......0.) Not Synchronize sequence numbers
     Fin:    (.......0) Not End of data
    Window: 14 (scale factor 0x9) = 7168
    Checksum: 0xF6BE, Good
    UrgentPointer: 0 (0x0)
    TCPPayload: SourcePort = 80, DestinationPort = 49248
- Http: HTTP Payload, URL: /GIFS/ECIR.JPG
    payload: HttpContentType = NetmonNull
IPHTTPS:
677 {TCP:132, IPv4:26} 4:01:19 PM 8/4/2011 116 iexplore.exe 0x12d4  TCP 0x1 Connected Disregarded  192.168.1.2 129.15.96.23 TCP:Flags=...A...., SrcPort=49248, DstPort=HTTP(80), PayloadLen=0, Seq=3442313006, Ack=3625396554, Win=4380 (scale factor 0x2) = 17520
Comments?

11103 {TCP:736, IPv4:735} 7:02:15 AM 8/24/2011 104 iexplore.exe  0x598 TCP 0x2 Connected Good  129.15.96.23 192.168.1.2 Flags=...A...., SrcPort=HTTP(80), DstPort=49472, PayloadLen=0, Seq=3370795655, Ack=3806480488, Win=14 (scale factor 0x9) = 7168 TCP:Flags=...A...., SrcPort=HTTP(80), DstPort=49472, PayloadLen=0, Seq=3370795655, Ack=3806480488, Win=14 (scale factor 0x9) = 7168
Frame: Number = 11103, Captured Frame Length = 104, MediaType = WiFi
- WiFi: [Unencrypted Data] F.....P, (I) RSSI = -51 dBm, Rate = 67.5 Mbps
- MetaData: RSSI = -51 dBm, Rate = 67.5 Mbps
     Version: 2 (0x2)
     Length: 32 (0x20)
   - OpMode: Extensible Station Mode
      StationMode:           (...............................0) Not Station Mode
      APMode:                (..............................0.) Not AP Mode
      ExtensibleStationMode: (.............................1..) Extensible Station Mode
      Unused:                (.0000000000000000000000000000...)
      MonitorMode:           (0...............................) Not Monitor Mode
     Flags: 0 (0x0)
     PhyType: 802.11g
     Channel: 2, Center Frequency: 2417 MHz
     lRSSI: -51 dBm
     Rate: 67.5 Mbps
     TimeStamp: 08/24/2011, 13:02:15.623759 UTC
- FrameControl: Version 0,Data, Data, F.....P(0x4208)
     Version:        (..............00) 0
     Type:           (............10..) Data
     SubType:        (........0000....) Data
     DS:             (......10........) DS to STA via AP
     MoreFrag:       (.....0..........) No
     Retry:          (....0...........) No
     PowerMgt:       (...0............) Active Mode
     MoreData:       (..0.............) No
     ProtectedFrame: (.1..............) Yes
     Order:          (0...............) Unordered
    Duration: 48 (0x30)
    DA: 1C659D CA2550
    BSSID: Novatel Wireless, Inc. 04C0AF
    SA: Novatel Wireless, Inc. 04C0AF
- SequenceControl: Sequence Number = 2338
     FragmentNumber: (............0000) 0
     SequenceNumber: (100100100010....) 2338
- LLC: Unnumbered(U) Frame, Command Frame, SSAP = SNAP(Sub-Network Access Protocol), DSAP = SNAP(Sub-Network Access Protocol)
- DSAP: SNAP(Sub-Network Access Protocol), Individual DSAP
     Address: (1010101.) SNAP(Sub-Network Access Protocol)
     IG:      (.......0) Individual Address
- SSAP: SNAP(Sub-Network Access Protocol), Command
     Address: (1010101.) SNAP(Sub-Network Access Protocol)
     CR:      (.......0) Command Frame
- Unnumbered: UI - Unnumbered Information
     MMM: (000.....) 0
     PF:   (...0....) Poll Bit - No Response Solicited
     MM:   (....00..)
     Type: (......11) Unnumbered(U) Frame
- Snap: EtherType = Internet IP (IPv4), OrgCode = XEROX CORPORATION
    OrganizationCode: XEROX CORPORATION, 0(0x0000)
    EtherType: Internet IP (IPv4), 2048(0x0800)
- Ipv4: src=129.15.96.23, Dest = 192.168.1.2, Next Protocol = TCP, Packet ID = 62246, Total IP Length = 40
- Versions: IPv4, Internet Protocol; Header Length = 20
     Version:      (0100....) IPv4, Internet Protocol
     HeaderLength: (....0101) 20 bytes (0x5)
- DifferentiatedServicesField: DSCP: 0, ECN: 0
     DSCP: (000000..) Differentiated services codepoint 0
     ECT: (......0.) ECN-Capable Transport not set
     CE:   (.......0) ECN-CE not set
    TotalLength: 40 (0x28)
    Identification: 62246 (0xF326)
- FragmentFlags: 16384 (0x4000)
     Reserved: (0...............)
     DF:       (.1..............) Do not fragment
     MF:       (..0.............) This is the last fragment
     Offset:   (...0000000000000) 0
    TimeToLive: 46 (0x2E)
    NextProtocol: TCP, 6(0x6)
    Checksum: 46808 (0xB6D8)
    SourceAddress: 129.15.96.23
    DestinationAddress: 192.168.1.2
- Tcp: Flags=...A...., SrcPort=HTTP(80), DstPort=49472, PayloadLen=0, Seq=3370795655, Ack=3806480488, Win=14 (scale factor 0x9) = 7168
    SrcPort: HTTP(80)
    DstPort: 49472
    SequenceNumber: 3370795655 (0xC8EA4287)
    AcknowledgementNumber: 3806480488 (0xE2E24868)
- DataOffset: 80 (0x50)
     DataOffset: (0101....) 20 bytes
     Reserved:   (....000.)
     NS:         (.......0) Nonce Sum not significant
- Flags: ...A....
     CWR:    (0.......) CWR not significant
     ECE:    (.0......) ECN-Echo not significant
     Urgent: (..0.....) Not Urgent Data
     Ack:    (...1....) Acknowledgement field significant
     Push:   (....0...) No Push Function
     Reset: (.....0..) No Reset
     Syn:    (......0.) Not Synchronize sequence numbers
     Fin:    (.......0) Not End of data
    Window: 14 (scale factor 0x9) = 7168
    Checksum: 0x14A8, Good
    UrgentPointer: 0 (0x0)
11104 {HTTP:737, TCP:736, IPv4:735} 7:02:15 AM 8/24/2011 1286 iexplore.exe HTTP Payload, URL: /GIFS/ECIR.JPG 0x598 HTTP 0x2 Connected Good 0x1 129.15.96.23 192.168.1.2 [Segment Lost]Flags=...AP..., SrcPort=HTTP(80), DstPort=49472, PayloadLen=1182, Seq=3370798575 - 3370799757, Ack=3806480488, Win=14 (scale factor 0x9) = 7168 HTTP:HTTP Payload, URL: /GIFS/ECIR.JPG
Frame: Number = 11104, Captured Frame Length = 1286, MediaType = WiFi
- WiFi: [Unencrypted Data] F.....P, (I) RSSI = -51 dBm, Rate = 67.5 Mbps
- MetaData: RSSI = -51 dBm, Rate = 67.5 Mbps
     Version: 2 (0x2)
     Length: 32 (0x20)
   - OpMode: Extensible Station Mode
      StationMode:           (...............................0) Not Station Mode
      APMode:                (..............................0.) Not AP Mode
      ExtensibleStationMode: (.............................1..) Extensible Station Mode
      Unused:                (.0000000000000000000000000000...)
      MonitorMode:           (0...............................) Not Monitor Mode
     Flags: 0 (0x0)
     PhyType: 802.11g
     Channel: 2, Center Frequency: 2417 MHz
     lRSSI: -51 dBm
     Rate: 67.5 Mbps
     TimeStamp: 08/24/2011, 13:02:15.626528 UTC
- FrameControl: Version 0,Data, Data, F.....P(0x4208)
     Version:        (..............00) 0
     Type:           (............10..) Data
     SubType:        (........0000....) Data
     DS:             (......10........) DS to STA via AP
     MoreFrag:       (.....0..........) No
     Retry:          (....0...........) No
     PowerMgt:       (...0............) Active Mode
     MoreData:       (..0.............) No
     ProtectedFrame: (.1..............) Yes
     Order:          (0...............) Unordered
    Duration: 48 (0x30)
    DA: 1C659D CA2550
    BSSID: Novatel Wireless, Inc. 04C0AF
    SA: Novatel Wireless, Inc. 04C0AF
- SequenceControl: Sequence Number = 2339
     FragmentNumber: (............0000) 0
     SequenceNumber: (100100100011....) 2339
- LLC: Unnumbered(U) Frame, Command Frame, SSAP = SNAP(Sub-Network Access Protocol), DSAP = SNAP(Sub-Network Access Protocol)
- DSAP: SNAP(Sub-Network Access Protocol), Individual DSAP
     Address: (1010101.) SNAP(Sub-Network Access Protocol)
     IG:      (.......0) Individual Address
- SSAP: SNAP(Sub-Network Access Protocol), Command
     Address: (1010101.) SNAP(Sub-Network Access Protocol)
     CR:      (.......0) Command Frame
- Unnumbered: UI - Unnumbered Information
     MMM: (000.....) 0
     PF:   (...0....) Poll Bit - No Response Solicited
     MM:   (....00..)
     Type: (......11) Unnumbered(U) Frame
- Snap: EtherType = Internet IP (IPv4), OrgCode = XEROX CORPORATION
    OrganizationCode: XEROX CORPORATION, 0(0x0000)
    EtherType: Internet IP (IPv4), 2048(0x0800)
- Ipv4: src=129.15.96.23, Dest = 192.168.1.2, Next Protocol = TCP, Packet ID = 62249, Total IP Length = 1222
- Versions: IPv4, Internet Protocol; Header Length = 20
     Version:      (0100....) IPv4, Internet Protocol
     HeaderLength: (....0101) 20 bytes (0x5)
- DifferentiatedServicesField: DSCP: 0, ECN: 0
     DSCP: (000000..) Differentiated services codepoint 0
     ECT: (......0.) ECN-Capable Transport not set
     CE:   (.......0) ECN-CE not set
    TotalLength: 1222 (0x4C6)
    Identification: 62249 (0xF329)
- FragmentFlags: 16384 (0x4000)
     Reserved: (0...............)
     DF:       (.1..............) Do not fragment
     MF:       (..0.............) This is the last fragment
     Offset:   (...0000000000000) 0
    TimeToLive: 46 (0x2E)
    NextProtocol: TCP, 6(0x6)
    Checksum: 45623 (0xB237)
    SourceAddress: 129.15.96.23
    DestinationAddress: 192.168.1.2
- Tcp: [Segment Lost]Flags=...AP..., SrcPort=HTTP(80), DstPort=49472, PayloadLen=1182, Seq=3370798575 - 3370799757, Ack=3806480488, Win=14 (scale factor 0x9) = 7168
    SrcPort: HTTP(80)
    DstPort: 49472
    SequenceNumber: 3370798575 (0xC8EA4DEF)
    AcknowledgementNumber: 3806480488 (0xE2E24868)
- DataOffset: 80 (0x50)
     DataOffset: (0101....) 20 bytes
     Reserved:   (....000.)
     NS:         (.......0) Nonce Sum not significant
- Flags: ...AP...
     CWR:    (0.......) CWR not significant
     ECE:    (.0......) ECN-Echo not significant
     Urgent: (..0.....) Not Urgent Data
     Ack:    (...1....) Acknowledgement field significant
     Push:   (....1...) Push Function
     Reset: (.....0..) No Reset
     Syn:    (......0.) Not Synchronize sequence numbers
     Fin:    (.......0) Not End of data
    Window: 14 (scale factor 0x9) = 7168
    Checksum: 0xD681, Good
    UrgentPointer: 0 (0x0)
    TCPPayload: SourcePort = 80, DestinationPort = 49472
- Http: HTTP Payload, URL: /GIFS/ECIR.JPG
- payload: HttpContentType = NetmonNull
     HTTPPayloadLine: 4ïücvÖ#8íÒª×wªx!fÕ.î Ô-`µ’whð˜URÇT1Ç ªsxXLdß«Ç(Ü’¤YVú‘ÈèGZ

%FW-4-TCP_OoO_SEG: Dropping TCP Segment

Any idea what this means? Why are these packets being dropped?
Mar 2 13:46:11.315: %FW-4-TCP_OoO_SEG: Dropping TCP Segment: seq:1826858942 1492 bytes is out-of-order; expected seq:1826829902. Reason: TCP reassembly queue overflow - session 10.2.31.31:50052 to 31.13.69.42:80
Mar 2 13:52:13.439: %FW-4-TCP_OoO_SEG: Dropping TCP Segment: seq:1264022358 1492 bytes is out-of-order; expected seq:1263984606. Reason: TCP reassembly queue overflow - session 10.2.31.31:50228 to 184.84.239.17:80
Mar 2 14:08:46.261: %FW-4-TCP_OoO_SEG: Dropping TCP Segment: seq:3591782745 1492 bytes is out-of-order; expected seq:3591717405. Reason: TCP reassembly queue overflow - session 10.2.31.13:58412 to 207.46.206.46:80
Mar 2 14:08:47.825: %FW-4-TCP_OoO_SEG: Dropping TCP Segment: seq:3591726117 1492 bytes is out-of-order; expected seq:3591720309. Reason: TCP reassembly queue overflow - session 10.2.31.13:58412 to 207.46.206.46:80

Ronni,
It looks like you are running some firewall inspection features on your router. What's happening is your out-of-order queue is getting full and dropping packets.
One thing you can try is increasing the queue size:
ip inspect tcp reassembly queue length
I would suggest starting with a size of about 80 to see if it has any effect on the logs. If you are still seeing an issue, could you provide a 'show ip inspect statistics' and any relevant configuration?
Thanks!
Joey

ITunes 10.4 and Windows 7 bug thread

I thought I would start an entire thread devoted to iTunes 10.4 and Windows 7 bugs since there are MANY people reporting various issues and may not know about all of them. Hopefully this will combine a list of all bugs for reference and help others. So far, most of this effects Windows 7 64 bit, but some are reporting issues under 32 bit too.
I have spoken with both Apple Care and a higher level tech at iTunes support. The iTunes support tech said they were "looking into all reported bugs and are aware of issues with version 10.4, especially under Windows 7. They encourage others to report their bugs to iTunes support so they can work on this and find all the issues.
KNOWN BUGS:
Album Art copy/paste broken - A bug that causes copy/pase from clipboard where album art is not displayed in the info tab as before. Some have reported success by dragging the image file over to it vs copy/paste method but it is still very much spotty and a known bug.
iTunes store not working - Some have been effected with the iTunes store not working properly for them. Personally I don't have a problem but this has been for some.
"Purchases" link not working in iTunes - When you click on "Purchases" link on the right column, all your purchases are missing and do not show up. This includes, music, movies, apps, etc. This is also a known bug and one that I have personally. Works fine in iTunes 10.3 for Windows 7 64bit and also works fine under both Snow Leopard and Lion OS.
Sync issues - Some have reported syncing issues since upgrading to 10.4 iTunes on Windows 7. This is a bit spotty as well as I have no trouble but there are others that have reported issues.
Solutions:
For now, the only way to fix this is to use iTunes 10.4 under Snow Leopard or Lion OS. Also, you can uninstall (not repair) 10.4 and install 10.3 again which should work.

You are correct and I wish that I had known this before spending 4 days and a lot of trouble going over this with both Apple Care and iTunes support. They had me jumping through hoops and didn't know anything until it was finally escalated. Only then did I get a vague response like I mentioned in the first post. It's troubling to me how a simple response from anyone there could've just said we know about this and they are bugs in 10.4 causing this.
There are other issues too as you point out with the syncing and crashing. Anyway, hopefully others will find information here more useful than calling Apple for help. Not much we can do now except roll back to 10.3 for those that kept it and hope also they can updated Apple Application Support component.

Time and date reset bug

hu guys, recently ive been experiencing a time and date reset bug, sometimes when i open up my computer it says something like your date is set to (i forgot the exact date but the year is 2001) so i change it back to the correct time and date, im not sure how i got the bug, can anyone help me fix this problem, its beginning to be annoying. thanks in advance!!

Sherwin,
Those symptoms indicate that you need to get your backup (PRAM) battery replaced.If your computer does not retain parameter RAM (PRAM) settings when it is turned off, this generally indicates that the battery needs to be changed.;~)

Region and dialog return bug in JDEVELOPER 11.1.1.1.0

SomeOne know hot to fix this bug...??
http://adfbugs.blogspot.com/2009/08/region-and-dialog-return-bug.html
ADF_FACES-60058: Attempt to re-register component with different model.
Cause: An IllegalStateException occurred.
Action: Contact Oracle Support Services.
Level: 2
Type: INCIDENT_ERROR
Impact: Logging
I have trying and trying and trying to solve this but didnt get a fix....

John Stegeman wrote:
The comments in that blog seem to indicate it was fixed in 11.1.1.2 - so two choices for you:
1). upgrade
2). File a support request and ask them to backport the fix.
Since there is a bug filed with support, you can just contact them to see what the current status is.
Johnas i heard from August 1, 2011 Oracle has stopped supporting 11.1.1.1.0 ......only 11.1.1.2 or later is supported (or may be they told us this to FORCEFULLY upgrade :P)
so upgrade would be better choice.
Zeeshan

[svn:osmf:] 12425: Extending unit tests, and fixing a bug.

Revision: 12425
Revision: 12425
Author:   [email protected]
Date:     2009-12-03 04:22:59 -0800 (Thu, 03 Dec 2009)
Log Message:
Extending unit tests, and fixing a bug.
Modified Paths:
    osmf/trunk/framework/MediaFramework/org/osmf/metadata/CompositeMetadata.as
    osmf/trunk/framework/MediaFrameworkFlexTest/org/osmf/metadata/TestCompositeMetadata.as

TCP segmentation offload (TSO) and vmxnet3/1000v - bug?

Similar Messages

Maybe you are looking for