Odd behavior running under Parallels

[Richard]

More detail and some progress, for the record...

The base server running TFTP, HTTP, etc. is actually CentOS6.3, while the ISO is being built using CentOS6.4. The iPXE I'm using are all 1.0.0+ builds. I rebuilt the whole environment under VMware Fusion 5.0.3 and ran into some similarities and some improvements. (Edit: Re-tested with CentOS 6.4 on the server, and TCP behaves the same.)

On the similarities front, booting the demo ipxe.iso and manually issuing the commands had the same result when using HTTP as the source. However, upon switching back to TFTP, I was able to get a successful boot! Painfully slow loading time, but it worked!

Now, I haven't a clue why TFTP isn't playing nice under Parallels. But I do have some clues about HTTP in both environments - CentOS 6's TCP stack appears to be misbehaving.

If I can believe what tcpdump is telling me, during an HTTP transfer the CentOS6 server is sending super jumbo frames... like 15kB! Not only is this bigger than every jumbo frame implementation I've seen (9216 bytes is usually the cap), but the server is also ignoring the 1460-byte MSS requested by the iPXE client. iPXE seems to hold its own for a while, accepting these goliath frames up to a point before falling over. Specifically, iPXE sends back an ACK for part of a jumbo frame (not normally how it's done), then goes unresponsive.

I've been doing Sniffer traces for many years, so I'm pretty confident in what I see in Wireshark (after tcpdump'ing to file). But I'm not a heavy tcpdump user, so I don't know if I can completely trust what tcpdump is reporting, or if it could possibly be merging packets - that seems unlikely, because everything seems consistent in the packet layouts. Normally, these goliath packets wouldn't even be possible in the real world, but inside a virtual network in Parallels or VMware I could see it being possible. (I did try changing the NIC MTU, and while it reports as being changed this doesn't change the large frame behavior.)

So...
* With TFTP under Parallels 8.0.18494, there seems there's some sort of issue with iPXE; I'd suspect it's client-side interaction with the virtual NIC, since the same TFTP server works fine under Fusion.
* With HTTP and CentOS 6, the OS is sending huge packets when it shouldn't. This is eventually choking the iPXE client, and happens under both Parallels 8.0.18494 and VMware Fusion 5.0.3. While it's exposed a weakness in iPXE, this is a CentOS/RHEL defect in my eyes; it's probably just never been discovered in the real world because a physical network wouldn't forward these giant packets (and TCP Path MTU discovery would cause them to retry at a smaller packet size).

Does this sound like anything that's been reported before? I'm not getting any hits on searches.

Thanks,
Richard