Hi, I've been looking at the pxelinux code and I was wondering a couple of things: 1) Why does pxelinux create UDP packets from scratch instead of use the Intel PXE TFTP OPEN/CLOSE/READ calls? I'm assuming this is to support TFTP options like tsize right? Did earlier versions of pxelinux use the TFTP calls directly? 2) How big of an image can pxelinux download (minus memory constraints)? My understanding is that tftp packet numbers are from 0-65535 yielding a maximum size of 32MB. Yet, from the revision history, it seems pxelinux can handle bigger images? (I don't see any wrap around handling though I maybe not looking hard enough in seachdir() - from the looks of it, the only way I can see pxelinux downloading a bigger image is if the tftp_blksize is negotiated greater than 512, right?) 3) Why does pxelinux require tsize? Does it make a difference what size the file is as long as the last packet returns < 512? Sorry if these topics have been covered before (I did attempt to search through the archives for answers - I got bits and pieces). Thanks! -aps -- "Linux is OBSOLETE." -Andrew Tanembaum
Alexander Sack wrote:> Hi, > > I've been looking at the pxelinux code and I was wondering a couple of > things: > > 1) Why does pxelinux create UDP packets from scratch instead of use the > Intel PXE TFTP OPEN/CLOSE/READ calls? I'm assuming this is to support > TFTP options like tsize right? Did earlier versions of pxelinux use the > TFTP calls directly? >Because they're largely useless. They have too many limitations -- only one transaction at one time, must go into contiguous memory, and they will write to the screen and read from the keyboard (there are ways you're *supposed* to be able to override that, but they frequently don't work.)> 2) How big of an image can pxelinux download (minus memory constraints)? > My understanding is that tftp packet numbers are from 0-65535 yielding a > maximum size of 32MB. Yet, from the revision history, it seems pxelinux > can handle bigger images? (I don't see any wrap around handling though > I maybe not looking hard enough in seachdir() - from the looks of it, > the only way I can see pxelinux downloading a bigger image is if the > tftp_blksize is negotiated greater than 512, right?)Nope. After FFFF follows 0000.> 3) Why does pxelinux require tsize? Does it make a difference what > size the file is as long as the last packet returns < 512?PXELINUX wants to know the size of the file before it downloads it. -hpa
Hi, Alexander Sack <aps at holmeister.net> schrieb am 20.06.03 18:57:30:> I've been looking at the pxelinux code and I was wondering a couple of > things:> 2) How big of an image can pxelinux download (minus memory constraints)? > My understanding is that tftp packet numbers are from 0-65535 yielding a > maximum size of 32MB. Yet, from the revision history, it seems pxelinux > can handle bigger images? (I don't see any wrap around handling though > I maybe not looking hard enough in seachdir() - from the looks of it, > the only way I can see pxelinux downloading a bigger image is if the > tftp_blksize is negotiated greater than 512, right?)One thing to add: tftp is UDP, so the server sends exactly one packet, the client acks this packet, then the server sends the next and so on. TCP is quite different, but it's also much more complicated to implement.> 3) Why does pxelinux require tsize? Does it make a difference what > size the file is as long as the last packet returns < 512?Just a hint: The linux kernel and initrd aren't just put one after the other into the memory. The linux kernel spreads in various places (real memory <1M, above 1M), and the initrd even gets put somewhere else. So for keeping it simple syslinux needs to know how much to transfer before actually doing it. The overhead on the network side is two packets (OACK, ACK 0), and it's much less overhead on the client. Just keep in mind that pxelinux still needs all network services from the pxe rom, and can't do it on itself. There are quite much tftp servers that support tsize, and it sholdn't hurt the server since this should be running a real operating system instead of a rom-based network stack. Regards, Josef ____________________________________________________________________________ Jetzt bei WEB.DE FreeMail anmelden = 1qm Regenwald schuetzen! Helfen Sie mit! Nutzen Sie den Serien-Testsieger. http://user.web.de/Regenwald
Hi, Alexander Sack <aps at holmeister.net> schrieb am 23.06.03 16:36:04:> > Alexander Sack <aps at holmeister.net> schrieb am 20.06.03 18:57:30: > > > I've been looking at the pxelinux code and I was wondering a couple of > > > things: > > > > > 2) How big of an image can pxelinux download (minus memory constraints)? > > > My understanding is that tftp packet numbers are from 0-65535 yielding a > > > maximum size of 32MB. Yet, from the revision history, it seems pxelinux > > > can handle bigger images? (I don't see any wrap around handling though > > > I maybe not looking hard enough in seachdir() - from the looks of it, > > > the only way I can see pxelinux downloading a bigger image is if the > > > tftp_blksize is negotiated greater than 512, right?) > > > > One thing to add: tftp is UDP, so the server sends exactly one packet, > > the client acks this packet, then the server sends the next and so on. > > TCP is quite different, but it's also much more complicated to implement. > > Thanks. Yea, I've read the RFC (the lock step!), I was just wondering > if I could send a RRQ, read the packet, and then drop the connection > using the PXE stuff by creating some form of error packet. I'm on the > wrong path anyway at this point for my purposes...This is how some PXE roms do it: send RRQ pxelinux.bin tsize rcv OACK 12345 send ERR The error packet always terminates the connection, and it's allowed to send it even if the packet was correct. Some PXE roms even leave the first connection open, letting the tftp server repeat until they timeout. Not nice ... BTW: The rom just got the tsize from the first transfer, it should continue: send RRQ pxelinux.bin rcv DATA 1 send ACK 1 (and so on ...) Regards, Josef ______________________________________________________________________________ UNICEF bittet um Spenden fur die Kinder im Irak! Hier online an UNICEF spenden: https://spenden.web.de/unicef/special/?mc=021101