Re: PXE-Problem

["lukas.simma@inexess.com" <lukas.simma@inexess.com>]

*Hallo,

hmm... die Meldung mit der *blksize ist interessant und dass nur ein UDP 
block versendet wird.  Dies erinnert mich an mein eigenes Problem mit 
dem 3C905 PXE Stack. Die hatte ein Intel PXE drin mit  einem Bug mit der 
blksize option des tftp servers. Ein Update des Bootagent hat bei mir 
das Problem gelöst. Eventuell hilft Dir das. Prüfe obs ein Boot Agent 
Update gibt für die Netzwerkkarte gibt.

Unfortunately, the Intel LANDesk Service Agent II prior to version 0.99h 
(PXE PDK V2.4) seems to have a rather serious bug: it requests the TFTP 
"blksize" option, but will be mortally confused if this option is 
actually accepted by the server....

http://www.gctglobal.com/Download/PXE_Server_FIX/pxe_server_fix.html

Grüße,
Lukas



Jan-Benedict Glaw schrieb:
> On Thu, 2006-11-23 16:01:26 +0100, Stefan Padberg <epost@stefan-padberg.de> wrote:
>   
> > Jan-Benedict Glaw schrieb:
> >     
> > > On Wed, 2006-11-22 09:47:11 +0100, Stefan Padberg <epost@stefan-padberg.de> wrote:
> > >       
> > > > Ich habe neue Rechner bekommen: IBM Netvista. Will die als ThinClients 
> > > > ins Netz integrieren. Booten automatisch über PXE.
> > > >
> > > > Fehlermeldung: 'File not found"
> > > >
> > > > Der 'pxelinux.0' ist an Ort und Stelle auf dem Tjener, wird auch von den 
> > > > TCs als der gesuchte identifiziert, also funktioniert die Kommunikation 
> > > > mit dem DHCP-Server.
> > > >
> > > > Wie kann ich den tftpd dazu überreden, den file rauszurücken?
> > > >         
> > > Erstmal gucken, ob da überhaupt passend angefragt wird:
> > >
> > > 	tcpdump
> > >       
> > hier ist der Dump:
> >
> > -----> Zitat ----->
> > tjener:~# tcpdump -i eth1 -n host 192.168.0.9
> > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> > listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
> > 15:52:26.254335 arp who-has 192.168.0.254 tell 192.168.0.9
> > 15:52:26.254350 arp reply 192.168.0.254 is-at 00:0d:88:6f:f5:94
> > 15:52:26.254437 IP 192.168.0.9.2070 > 192.168.0.254.69:  41 RRQ "/tftpboot/lts/pxelinux.0" octet tsize 0
> > 15:52:26.261281 IP 192.168.0.254.34055 > 192.168.0.9.2070: UDP, length: 19
> > 15:52:26.263269 IP 192.168.0.9.2071 > 192.168.0.254.69:  46 RRQ "/tftpboot/lts/pxelinux.0" octet blksize 1456
> > 15:52:26.270848 IP 192.168.0.254.34055 > 192.168.0.9.2071: UDP, length: 19
> > -----> Ende <-----
> >     
>
> ...wenn jetzt noch volle hexdumps da wären, könnte man die
> Antwort-Pakete mal genauer unter die Lupe nehmen.  Wir können anhand
> dessen jedenfalls schonmal abschätzen, daß der erste Teil, die Anfrage
> der DHCP-Konfiguration, funktioniert hat.
>
> Von hier aus würde ich mal den tftpd strace'n, oder den inetd, falls
> der von da aus gestartet wird.  Vielleicht schickt der auch was zum
> Syslog; es kann also nicht schaden, auch nochmal in die Logs zu
> gucken.
>
>   
> > Was will der Tjener denn da sagen? Das sieht doch komisch aus, oder?
> >     
>
> Der tftpd schickt eine Antwort auf die Anfrage, die dem Client nicht
> gefällt. Daraufhin versucht's der nocheinmal.
>
> MfG, JBG
>
>