Description of problem:
We are running ipxe in OpenStack instances, using a small disk image containing ipxe.lkrn, similar to the approach described here:
https://kimizhang.wordpress.com/2013/08/26/create-pxe-boot-image-for-openstack/

The instances are attached to Neutron virtual networks, which internally inside OpenStack are using some Ethernet encapsulation which means the network MTU visible to the OpenStack instances is less than the standard Ethernet 1500 bytes. The DHCP server provided by Neutron is correctly configured to serve up the smaller MTU in DHCP option 26 (in our case it is using 1400). There is a bit more background about OpenStack MTU issues here:
https://specs.openstack.org/openstack/neutron-specs/specs/kilo/mtu-selection-and-advertisement.html

ipxe ignores DHCP option 26 and assumes that an IPv4-on-Ethernet network interface supports the full 1500-byte MTU.

Actually in its sending path when calculating TCP transmit window, ipxe already assumes a very conservative MTU of 1280. The problem is it advertises its TCP MSS assuming the full 1500 MTU. As a result, if ipxe makes a TCP connection to a nearby host on a segment with 1500 MTU but no fragmenting router in between, the TCP MSS will be too large and packets sent by the other end will get dropped.

The end result is that the TCP connection will appear to stall with no data received, if the sender is transmitting large packets (for example fetching a kernel image over HTTP). Note that some very small HTTP responses will be unaffected, as will any TCP connections which pass over WAN links or anything else which happens to have a small enough MTU.

Version-Release number of selected component (if applicable):
ipxe-bootimgs-20160127-5.git6366fa7a.el7

How reproducible:
reliably, in this particular OpenStack instance

Steps to Reproduce:
1. Create and upload a disk image containing ipxe to Glance, using the technique described in the article above, or by using beaker-create-ipxe-image.
(We hit this problem while working on Beaker's OpenStack integration which uses ipxe disk images.)
2. Boot the image on an OpenStack instance in a Neutron virtual network with MTU less than 1500.
3. Use imgfetch or a similar command, to pull down a large kernel image from an HTTP server on a LAN segment with MTU 1500.

Actual results:
The imgfetch download stalls at 0% after receiving HTTP headers. Observe that the TCP MSS advertised by ipxe is 1460, which is larger than it can actually receive.

Expected results:
HTTP transfer should complete. TCP MSS should be based on the MTU supplied by DHCP option 26.

Additional info:
I wrote a patch for ipxe to obey DHCP option 26 and posted it upstream:
http://lists.ipxe.org/pipermail/ipxe-devel/2016-November/005261.html