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 RFC1149https://tools.ietf.org/html/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.
Dave Angelini said:
Has Dusty said he was sorry to Bill gates yet Might help
In decades past, checking/adjusting the maximum frame size (MTU) of the packets could fix things (too large of packet, and receiver would fail).https://en.wikipedia.org/wiki/IPv4#DataI don't remember enough to know if MTU could be a problem here... But given the possibility of a gaming computer doing anything it could to increase communications speed/efficiency, it could be a possible "hack" (large MTU, >1,500 bytes for example).-Bill
Dave Angelini said:
Just saying....Good Luck! I wish I could tell you what I am working on for Schneider. In the Fall maybe.
The driver thing was a bit of a long shot, as I suspect the issue is (mainly) higher up the protocol stack. It's been more years than I care to admit since I've gotten into this level of detail with TCP though. Will have to read through some RFCs etc as there've been lots of newer additions/tweaks/hacks.
Seems to me OS2 was widely used in bank machines, because it just worked (while MSDOS/Windoze needed a regular cold boot). Maybe some sort of *nix these days? My son gave me a t-shirt a few years back with a penguin (linux "Tux") holding a sword and a caption of "Kill Bill"
Maybe try disabling the Large Send Offloads. They're meant to let the machine spew forth packets faster by offloading cpu work (splitting buffers into packets) to the nic, but spewing too slow isn't our problem, and it's not hard to imagine something a bit broken in the process gumming things up. Worth a shot?
@Dusty Do you happen to have a wireless USB adapter? This could be used to bypass the Alienware adapters. That would be my next step. If you don't have one, Newegg has a good selection for less than 20 bucks. Rick
That's quite the wrinkle! A cpu bug that only apparently manifests on a specific http connection?