Syslinux - Jun 2009 - tftp open timeout but with no server side errors

Background,

Client - realtek rtl8111c
tftpd version is 5.0
options on use -l -v

Client:

PXE-EX32 TFTP Open Timeout

Server:

Jun 12 10:48:38 damar in.tftpd[30132]: RRQ from 192.168.1.107 filename
gpxelinux.0
Jun 12 10:48:48 damar in.tftpd[30133]: RRQ from 192.168.1.107 filename
gpxelinux.0
Jun 12 10:49:24 damar in.tftpd[30134]: RRQ from 192.168.1.107 filename
gpxelinux.0
Jun 12 10:50:36 damar in.tftpd[30135]: RRQ from 192.168.1.107 filename
gpxelinux.0
etc.

The client has a valid ip and the server can communicate , tftpd-hpa
tries to send it the file multiple times
but it appears that it does not receive it. In order to get more
information I tried atftpd which has more detailed logging
and it reports continuous timeouts.

I was wondering if anyone has experienced this problem before or has
any suggestions. I'd like to note
this machine is identical to 40 other machines , to which about half boot.

Christopher Deneen wrote:
> Background,
> 
> Client - realtek rtl8111c
> tftpd version is 5.0
> options on use -l -v
> 
> Client:
> 
> PXE-EX32 TFTP Open Timeout
> 
> Server:
> 
> Jun 12 10:48:38 damar in.tftpd[30132]: RRQ from 192.168.1.107 filename
> gpxelinux.0
> Jun 12 10:48:48 damar in.tftpd[30133]: RRQ from 192.168.1.107 filename
> gpxelinux.0
> Jun 12 10:49:24 damar in.tftpd[30134]: RRQ from 192.168.1.107 filename
> gpxelinux.0
> Jun 12 10:50:36 damar in.tftpd[30135]: RRQ from 192.168.1.107 filename
> gpxelinux.0
> etc.
> 
> The client has a valid ip and the server can communicate , tftpd-hpa
> tries to send it the file multiple times
> but it appears that it does not receive it. In order to get more
> information I tried atftpd which has more detailed logging
> and it reports continuous timeouts.
> 
> I was wondering if anyone has experienced this problem before or has
> any suggestions. I'd like to note
> this machine is identical to 40 other machines , to which about half boot.
> 
Getting a packet trace via tcpdump or wireshark would be useful, but
this sounds like a case of something I call "dead receiver syndrome",
which means the IP stack sends, but does not receive, packets.  In your
case it seems to happen for the initial TFTP download, which is fairly
unusual; it is more common for it to happen after the initial TFTP
download as PXELINUX starts up.

Look for the specific PXE stack versions on your machine and see if
there is an updated one.  Since this is happening while still in ROM,
it's unlikely that anything other updating the BIOS to a different
version of the vendor stack or to another stack like gPXE is going to
help.  There is obviously nothing the software can do -- it's not
running yet.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

In this particular instance, perhaps a packet capture could help to
diagnose the issue.  If I understand you correctly, it is the NIC
vendor's PXE stack which is timing out before you are able to download
gpxelinux.0.  Some packet capturing tools you can use are: tcpdump,
Wireshark.  - Shao

-----Original Message-----
From: syslinux-bounces at zytor.com [mailto:syslinux-bounces at zytor.com] On
Behalf Of Christopher Deneen
Sent: Friday, June 12, 2009 11:17
To: syslinux at zytor.com
Subject: [syslinux] tftp open timeout but with no server side errors

Background,

Client - realtek rtl8111c
tftpd version is 5.0
options on use -l -v

Client:

PXE-EX32 TFTP Open Timeout

Server:

Jun 12 10:48:38 damar in.tftpd[30132]: RRQ from 192.168.1.107 filename
gpxelinux.0
Jun 12 10:48:48 damar in.tftpd[30133]: RRQ from 192.168.1.107 filename
gpxelinux.0
Jun 12 10:49:24 damar in.tftpd[30134]: RRQ from 192.168.1.107 filename
gpxelinux.0
Jun 12 10:50:36 damar in.tftpd[30135]: RRQ from 192.168.1.107 filename
gpxelinux.0
etc.

The client has a valid ip and the server can communicate , tftpd-hpa
tries to send it the file multiple times
but it appears that it does not receive it. In order to get more
information I tried atftpd which has more detailed logging
and it reports continuous timeouts.

I was wondering if anyone has experienced this problem before or has
any suggestions. I'd like to note
this machine is identical to 40 other machines , to which about half
boot.

_______________________________________________
Syslinux mailing list
Submissions to Syslinux at zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Op 20090612 om 11:17 schreef Christopher Deneen:
> Background,
> 
> Client - realtek rtl8111c
> tftpd version is 5.0
> options on use -l -v
> 
~ Client screen message:
> 
> PXE-EX32 TFTP Open Timeout
> 
~ Server log:
> 
> Jun 12 10:48:38 damar in.tftpd[30132]: RRQ from 192.168.1.107 filename
gpxelinux.0
> Jun 12 10:48:48 damar in.tftpd[30133]: RRQ from 192.168.1.107 filename
gpxelinux.0
> Jun 12 10:49:24 damar in.tftpd[30134]: RRQ from 192.168.1.107 filename
gpxelinux.0
> Jun 12 10:50:36 damar in.tftpd[30135]: RRQ from 192.168.1.107 filename
gpxelinux.0
> etc.
> 
> The client has a valid ip and the server can communicate , tftpd-hpa
> tries to send it the file multiple times
> but it appears that it does not receive it. In order to get more
> information I tried atftpd which has more detailed logging
> and it reports continuous timeouts.
> 
> I was wondering if anyone has experienced this problem before or has
> any suggestions. I'd like to note
> this machine is identical to 40 other machines , to which about half boot.
My gutt feeling says there is something wrong with the network switches.

The booting half of the forty identical machines is connected to a "good
switch port",
the non-booting half to an "bad switch port".

The  "bad switch ports" could be all in the same (bad) switch.
Good and bad could be in the same physical switch, where access ports
have different settings for negotition of speed and/or duplex mode.


Cheers
Geert Stappers

Perhaps you need to clear your ARP cache/static ARP entries or perhaps your
scope doesn't quite line up with the IP reservations?  - Shao

----- Original Message -----
From: syslinux-bounces at zytor.com <syslinux-bounces at zytor.com>
To: For discussion of Syslinux and tftp-hpa <syslinux at zytor.com>
Sent: Fri Jun 12 13:24:28 2009
Subject: Re: [syslinux] tftp open timeout but with no server side errors

Here is an interesting update.

My dhpd is static per mac

here is the example of the machine that doesn't work
  host cluster0107 {
        hardware ethernet  00:1F:C6:BA:05:42;
        fixed-address 192.168.1.107;

here is one that works

 host cluster0139 {
        hardware ethernet  00:1F:C6:BA:07:46;
        fixed-address 192.168.1.139;

If i switch them, the machine that didn't work, works.
It boots fully with no problems and the other machine doesn't
bear in mind all 40 of these machines are identical hardware and bios version.



On Fri, Jun 12, 2009 at 1:13 PM, Geert Stappers<stappers at stappers.nl>
wrote:
> Op 20090612 om 11:17 schreef Christopher Deneen:
>> Background,
>>
>> Client - realtek rtl8111c
>> tftpd version is 5.0
>> options on use -l -v
>>
> ~ Client screen message:
>>
>> PXE-EX32 TFTP Open Timeout
>>
> ~ Server log:
>>
>> Jun 12 10:48:38 damar in.tftpd[30132]: RRQ from 192.168.1.107 filename
gpxelinux.0
>> Jun 12 10:48:48 damar in.tftpd[30133]: RRQ from 192.168.1.107 filename
gpxelinux.0
>> Jun 12 10:49:24 damar in.tftpd[30134]: RRQ from 192.168.1.107 filename
gpxelinux.0
>> Jun 12 10:50:36 damar in.tftpd[30135]: RRQ from 192.168.1.107 filename
gpxelinux.0
>> etc.
>>
>> The client has a valid ip and the server can communicate , tftpd-hpa
>> tries to send it the file multiple times
>> but it appears that it does not receive it. In order to get more
>> information I tried atftpd which has more detailed logging
>> and it reports continuous timeouts.
>>
>> I was wondering if anyone has experienced this problem before or has
>> any suggestions. I'd like to note
>> this machine is identical to 40 other machines , to which about half
boot.
>
> My gutt feeling says there is something wrong with the network switches.
>
> The booting half of the forty identical machines is connected to a
"good switch port",
> the non-booting half to an "bad switch port".
>
> The ?"bad switch ports" could be all in the same (bad) switch.
> Good and bad could be in the same physical switch, where access ports
> have different settings for negotition of speed and/or duplex mode.
>
>
> Cheers
> Geert Stappers
>
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
> Please do not send private replies to mailing list traffic.
>
>
_______________________________________________
Syslinux mailing list
Submissions to Syslinux at zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.