Do you by any chance have an old-school dumb hub?
What I'm thinking is to get a non-working client, the combox, and a working client all on the same collision domain (switched router port). The working client box would do the wireshark sniffing, and should see packets between the non-working client and the combox with no router/switch in between. Running the sniffer on a box separate from send/receive boxes mostly eliminates issues (for diagnostic purposes) around off-loading, in which things like checksums may be added where the sniffer doesn't operate on a send/receive box. Running the sniffer on a third party box helps eliminate that as it should just see traffic on the segment, not anything internal to the boxes being tested.
If so, put all 3 devices on the hub connected to one (likely switched) port on the router. The router should leave traffic between boxes on the hub on that port, and likely not mess with it.
It isn't actually as much of a stretch as you might think. From what I've observed, much of the internet only works because of a principle similar to the "swiss cheese" approach to transportation safety.
In transportation safety, every "slice" has holes (features/tweaks/bugs), but stack enough slices, the holes all get filled, and the system works. If you remove or change a slice, unexpected holes can appear.
Applying this to your processor theory; these processors have been out for some time, and neither internal or real-world testing turned up a big hole. There have to be enough of these processors used with enough comboxes, that if the hole opened with that change alone, it would be evident by now. That impies there's a tertiary (or more) slice opening the hole.
In other words, there could (for example) be a change (eg. ordering through multiple cpu cores) in threading that occurs only rarely in some code under certain circumstances, but in which some TCP implementations, in certain circumstances, rely on an obsolete/newer RFC, which the combox can't deal with.
Dave Angelini said:
We beta tested in 2011 and shortly after. The latest firmware will have all the issues that are addressed. I did not see anything about swiss cheese If you can sum this up in a couple short paragraphs which include what support has said and a case number I will send it up to Engineering in Barnaby. No guarantee as everyone is out on vacation this time of year. You can e-mail me if you wantFor my clients I have a guru who I pay to take care of the few problems over the years. I would much rather go to the Dentist than go deeper into this than a quick-start manual. Much nicer outside for me!
If it was simply an issue with recent cpus and the combox, I suspect Dave is right, and the issue would have been addressed in a firmware update.
That it hasn't suggests there's a third (or more) factor causing the issue for you, but occurring together rarely enough that it hasn't been recognized more widely as an issue. The third factor could be as simple as a local source of electrical noise, or some really complex series of factors.
If Schneider engineering could duplicate the issue, that would certainly help.
Hopefully whatever it is will turn up if/when Schneider tries to duplicate, and it isn't something in your specific environment (which might not turn up trying to duplicate elsewhere).
Some context to my thinking...
The issue occurs with both wireless and wired, suggesting it's likely not a hardware issue per se.
With the same adapter in different machines, one of which works, it might be worth checking to see if the driver versions are identical. I doubt this is the issue, but worth checking on the remote chance the alienware uses some sort of tweaked version.
Having tried two different routers, it's unlikely the router is mangling flow control in packets, but if they have any sort of QOS setting, it should be disabled for now.
The devices are communicating, albeit with errors, so not likely a routing issue (bad subnetting, etc.). The ARP response suggests proper MAC address to IP address.
You've run Win10pro okay on a non-alienware machine successfully, which suggests either it's not an OS level issue, or the alienware boxes are doing (or not doing) something different at that level.
The "rules" around networking generally, and TCP in particular (the layer at which the issue appears to be), are done with RFCs (Request For Comments). The thing is, because of the history of internet development, these "rules" really aren't. They become "rules" only if and to the extent they get adopted in the real world. There's RFC1149
"A Standard for the Transmission of IP Datagrams On Avian Carrier". This one wasn't widely adopted, being a suggested method for using carrier pigeons
The RFCs use terms like "Must", "Should", and "May" in describing various parts of a protocol. Companies can and do implement the protocol with minor differences, which often leads to good things, but sometimes to incompatibilities.
I'll look into the combox sequence thing a bit more, but on it's face it's not surprising. The combox will have much less memory and processor resources than a full-on computer (eg. the small win=4096 in the SYN, ACK response). If ram buffers fill, for example, it can't take more until the queue gets processed. The TCP protocol has means to deal with this, but it's apparently not working properly in this case. When it goes wrong, the problem can compound exponentially. A well known denial of service attack exploits this.
So that you see the sequence message on both computers isn't surprising. The issue is likely in how the alienware is responding. Using a human example, say I say "Hi there" to you just as a loud truck goes by. You could respond with "Can you repeat that", and the conversation goes from there. If instead, your reply was "Parlez vous francais?", and I don't speak french, we have a problem. I might repeat the Hi louder, and you might shout louder and more often, to the point one of us gives up and walks away. That's sort of what I think may be happening here.
I believe the CWR in the AW(AlienWare) SYN packet suggests it doesn't see network congestion, and ECN offers a way of handling dropped packets that the combox may not support. Not necessarily the problem, but it could be if AW insists on using it.
netsh int tcp set global ecncapability=disabled
I have nothing to add but this is one of the most interesting threads I have followed. And to think I was looking at Alienware machines. Wonder if there are any Alienware users on this forum that are running the Combox? Keep us informed and sure hope you find a solution.
Thanks, good that you found the issue. Your persistence paid off and will probably help others.
This is a good article that explains what I experienced on 5 of my computers when having problems communicating with the combox:https://community.rackspace.com/products/f/public-cloud-forum/4848/disabling-ecn-explicit-congestion-notification-on-windows-servers-having-network-issuesThis says that ECN has been set to "enabled" since Windows Server 2012. I'm not sure why only a handful of my computers had this switch enabled in the OS, but it would have been difficult for Schneider to detect this during their firmware testing--especially if there were only a couple people testing it, and ECN was disabled on their system's OS while testing.On the second computer (the KabyLake Alienware laptop), I didn't reset everything to default like I did on the first one. This time, I only disabled ECN by using the command:netsh int tcp set global ecncapability=disabledThis worked as well.I'll send this on to Schneider and close my case numbers.