On Thu, Jun 6, 2013 at 5:01 PM, H. Peter Anvin <hpa at zytor.com> wrote:> Very odd! > > This shows a TFTP connection being correctly established and then > disconnected, with all the negotiation involved. I'm wondering if it is > iPXE that is playing games with us here...Packets 301-306, 309-312 show two successful attempts to read linux-install/pxelinux.cfg/C0A80058 with the same UDP source port (49153). Packets 307,308,313-316 show two unsuccessful attempts to read linux-install/pxelinux.cfg/vesamenu.c32 reusing the same UDP source port (49153) with an ICMP reply stating the port is closed. Packets 317-357 show a successful single attempt to read linux-install/pxelinux.cfg/vesamenu.c32 reusing the same UDP source port (49153). Packets 358,360-412,415-625 show a success on libcom32.c32 while 359,413,414 show an unsuccessful attempt. Something is certainly tripping up as I don't see these duplicate attempts in my testing and in my mind iPXE is in the lead. -- -Gene
I have to say I wonder how much of this is iPXE and much is syslinux... Gene Cumm <gene.cumm at gmail.com> wrote:>On Thu, Jun 6, 2013 at 5:01 PM, H. Peter Anvin <hpa at zytor.com> wrote: >> Very odd! >> >> This shows a TFTP connection being correctly established and then >> disconnected, with all the negotiation involved. I'm wondering if it >is >> iPXE that is playing games with us here... > >Packets 301-306, 309-312 show two successful attempts to read >linux-install/pxelinux.cfg/C0A80058 with the same UDP source port >(49153). > >Packets 307,308,313-316 show two unsuccessful attempts to read >linux-install/pxelinux.cfg/vesamenu.c32 reusing the same UDP source >port (49153) with an ICMP reply stating the port is closed. > >Packets 317-357 show a successful single attempt to read >linux-install/pxelinux.cfg/vesamenu.c32 reusing the same UDP source >port (49153). > >Packets 358,360-412,415-625 show a success on libcom32.c32 while >359,413,414 show an unsuccessful attempt. > >Something is certainly tripping up as I don't see these duplicate >attempts in my testing and in my mind iPXE is in the lead. > >-- >-Gene-- Sent from my mobile phone. Please excuse brevity and lack of formatting.
On Sat, Jun 8, 2013 at 1:17 PM, H. Peter Anvin <hpa at zytor.com> wrote:> I have to say I wonder how much of this is iPXE and much is syslinux... > > Gene Cumm <gene.cumm at gmail.com> wrote: > >>On Thu, Jun 6, 2013 at 5:01 PM, H. Peter Anvin <hpa at zytor.com> wrote: >>> Very odd! >>> >>> This shows a TFTP connection being correctly established and then >>> disconnected, with all the negotiation involved. I'm wondering if it >>is >>> iPXE that is playing games with us here... >> >>Packets 301-306, 309-312 show two successful attempts to read >>linux-install/pxelinux.cfg/C0A80058 with the same UDP source port >>(49153). >> >>Packets 307,308,313-316 show two unsuccessful attempts to read >>linux-install/pxelinux.cfg/vesamenu.c32 reusing the same UDP source >>port (49153) with an ICMP reply stating the port is closed. >> >>Packets 317-357 show a successful single attempt to read >>linux-install/pxelinux.cfg/vesamenu.c32 reusing the same UDP source >>port (49153). >> >>Packets 358,360-412,415-625 show a success on libcom32.c32 while >>359,413,414 show an unsuccessful attempt. >> >>Something is certainly tripping up as I don't see these duplicate >>attempts in my testing and in my mind iPXE is in the lead. >> >>-- >>-GeneCorrection: an iPXE _interaction_ as it could be that we need to instruct iPXE's PXE to be quiet while lwIP is using the UNDI and/or unload. Silencing iPXE's PXE would be preferable in case we chainload to another NBP (in which case we'd unquiet it). -- -Gene