[syslinux] gpxelinux.0 and slow HTTP performance on VMware ESX VM

[Eric W. Biederman]

Gene Cumm <gene.cumm at gmail.com> writes:

> On Thu, Jun 30, 2011 at 16:08, Eric W. Biederman <ebiederm at xmission.com> wrote:
>> syslinux at schlomo.schapiro.org writes:
>>
>>> Hi,
>>>
>>> Am 29.06.2011 22:05, schrieb H. Peter Anvin:
>>>> On 06/29/2011 11:57 AM, Schlomo Schapiro wrote:
>>>>>
>>>>> The core problem is that HTTP transfers by gpxelinux.0 are very slow. Sadly this
>>>>> problem seems to be somehow related to our VMware ESX environment and I am not
>>>>> able to pin the problem down.
>>>>>
>>>>
>>>> The requirement for gpxelinux.0 to support HTTP transfers is going to be
>>>> dropped in Syslinux 4.10, which is now on the release track.  Could you
>>>> test out pxelinux.0 (*not* gpxelinux.0) from Syslinux 4.10-pre15 and see
>>>> if you have any problems?
>>>>
>>>> Other than that, it would be good to get a package trace
>>>> (tcpdump/wireshark).
>>>
>>> I tried your suggestion today (and I think it is a very good thing to
>>> have native HTTP support in pxelinux).
>>>
>>> Unfortunately it does not work. I put together some debug infos and
>>> traces at http://files.schapiro.org/schlomo/syslinux/index.html
>>>
>>> Things to notice:
>>> * syslinux 4.10 did apparently not try to load vesamenu.c32 but
>>> immediately tried vesamenu.c32.0 and other variations. The access log
>>> shows that very nice. First you find there a successful boot with a user
>>> agent of gPXE from gpelinux.0 4.04. After that the failed boot requests
>>> from a user agent of Syslinux/4.10

Ok.  I took a second look at this and the packet trace and the access
log are inconsistent.

My blind guess is that it you don't see it trying vesamenu.c32 because
a packet was dropped somewhere.  The code in core/ui.inc always tries
the specified name first and then it tries different extensions.
So the mystery is why you don't see it trying vesamenu.c32.

>> It is odd, because at least the pcap shows that 4.10-pre15 completed
>> the http transfer of /boot/pxelinx.cfg/default and went on to try and=
>> transfer the next file.  In trying to establish the next tcp connect
>> pxelinux decided to RST the connection instead of just acking it.
>
> Looks like the same "christmas tree" I've been seeing.
>
> Is it possible that the closing of the first connection leaves things
> inconsistent to open the next?  Is it possible the error I see after
> an aborted TFTP transfer is related?

I'm going to guess that we have two separate problems.

Eric