Syslinux - Nov 2013 - syslinux.efi pxeboot across multiple subnets

I did change both instances of txdata->GatewayAddress, but I think
something may be wrong in my toolchain. If I extract syslinux.zip and
attempt to make from there (without modifying any files), the cached DHCP
packet isn't read on the same subnet.

I receive "Succeed to download NBP file." twice before anything from
syslinux is loaded, so I believe the duplicate request for syslinux.efi can
be put down to the UEFI or network adapter firmware.


On Fri, Nov 8, 2013 at 5:27 AM, Geert Stappers <stappers at stappers.nl>
wrote:
> Op 2013-11-08 om 01:31 schreef Celelibi:
> > 2013/11/7, Jason Matthews <jason.david.matthews at gmail.com>:
> > > Here are the pcaps:
> > >
> > > http://ge.tt/64G4yxx/v/0
>
> use
>
>   wget -O  pcaps.zip wget http://ge.tt/api/1/files/64G4yxx/0/blob?download
>
> to just fetch it
>
> > >
> > > syslinux6.02tftpserver.pcap is from the tftpserver with
syslinux.efi
> and
> > > ldlinux.e64 from syslinux-6.02.zip
> > > syslinux6.02frommirrorport.pcap is from the mirrored port with
> syslinux.efi
> > > and ldlinux.e64 from syslinux-6.02.zip
> > >
> > > syslinux6.02-modified-tftpserver.pcap is from tftpserver with
> syslinux.efi
> > > and ldlinux.e64 after modifying efi/udp.c
> > > syslinux6.02-modified-frommirrorport.pcap is from mirrored port
with
> > > syslinux.efi and ldlinux.e64 after modifying efi/udp.c
> > >
> >
> > Hum...
> > Some packets seems duplicated when captured from the server, but not
> > when captured from the mirror port. So let's assume that's ok.
> > I can't find anything in the capture of the non-modified version
that
> > would look suspicious.
>
> I only looked at syslinux6.02-modified-frommirrorport.pcap
>
>
> > Anyway, syslinux.efi is supposed to be downloaded by the UEFI firmware
> > itself. It succeed but keep restarting for no apparent reason. Maybe
> > an early termination? I don't know.
> >
> > However your modified version is interesting...
> > Try modifying the *other* txdata->GatewayAddress as well. :)
> > It seems like you modified sendto but not send. The TFTP request is
> > sent using "sendto" while the acknowledgement are sent using
"send".
> > Thus you need to patch both.
>
> That makes sense.
> My observation is also that the transmit works, but the recieve fails.
>
> At packet 90 starts TFTP of file sles113/syslinux.efi, which is succesfull.
>
> At packet 327 is the file sles113/syslinux.efi a second time transmitted.
> For reason unclear to me.
>
> At packet 564 starts 10.16.233.20 asking for sles113/ldlinux.e64.
> 10.168.195.178 answers, but client re-acts as if it didn't get that
answer.
>
> > I think you can open a bug report on the
> > bugzilla<http://bugzilla.syslinux.org/> for that exact problem
and
> > send your patch when you get it working. :)
>
> Yep, patches welcome.
>
>
> Groeten
> Geert Stappers
> Who only has netbooting with TFTP server and TFTP client on the same
> subnet.
> So not across a router.  But yes, it should work.
> --
> Leven en laten leven
> _______________________________________________
> 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.
>
>

On 11/08/2013 07:52 AM, Jason Matthews wrote:
>  I did change both instances of txdata->GatewayAddress, but I think
> something may be wrong in my toolchain. If I extract syslinux.zip and
> attempt to make from there (without modifying any files), the cached DHCP
> packet isn't read on the same subnet.
> 
> I receive "Succeed to download NBP file." twice before anything
from
> syslinux is loaded, so I believe the duplicate request for syslinux.efi can
> be put down to the UEFI or network adapter firmware.
OK, this looks like the "wandering source port" problem, where we
still
don't quite have the right algorithm for dealing with the fact that the
server will return a response from a different port but *we* need to
stay put on the *same* port.  TFTP is such a screwed-up protocol.

	-hpa

Thank you for posting the pcap files, by the way.  Analyzing them in
Wireshark is so much nicer than reading the text output of tcpdump.

	-hpa

Here is a completely untested patch if someone wants to try and take it
for a spin?

	-hpa

-------------- next part --------------
diff --git a/efi/udp.c b/efi/udp.c
index 59bb426..60a8fe9 100644
--- a/efi/udp.c
+++ b/efi/udp.c
@@ -41,8 +41,7 @@ int core_udp_open(struct pxe_pvt_inode *socket)
     udp = (EFI_UDP4 *)udp_reader->this;
 
     memset(&udata, 0, sizeof(udata));
-    udata.AcceptPromiscuous = TRUE;
-    udata.AcceptAnyPort = TRUE;
+    udata.AcceptBroadcast = TRUE;
 
     status = uefi_call_wrapper(udp->Configure, 2, udp, &udata);
     if (status != EFI_SUCCESS)
@@ -50,6 +49,18 @@ int core_udp_open(struct pxe_pvt_inode *socket)
 
     socket->net.efi.binding = b;
 
+    /*
+     * Save the random local port number that the UDPv4 Protocol
+     * Driver picked for us. The TFTP protocol uses the local port
+     * number as the TID.
+     */
+    status = uefi_call_wrapper(udp->GetModeData, 5, udp,
+			       &udata, NULL, NULL, NULL);
+    if (status != EFI_SUCCESS)
+	Print(L"Failed to get UDP mode data: %d\n", status);
+    else
+	socket->net.efi.localport = udata.StationPort;
+
     return 0;
 
 bail:
@@ -89,7 +100,6 @@ void core_udp_close(struct pxe_pvt_inode *socket)
 void core_udp_connect(struct pxe_pvt_inode *socket, uint32_t ip,
 		      uint16_t port)
 {
-    EFI_UDP4_CONFIG_DATA udata;
     EFI_STATUS status;
     EFI_UDP4 *udp;
 
@@ -113,20 +123,6 @@ void core_udp_connect(struct pxe_pvt_inode *socket,
uint32_t ip,
 	return;
     }
 
-    /*
-     * If this is the first time connecting, save the random local port
-     * number that the UDPv4 Protocol Driver picked for us. The TFTP
-     * protocol uses the local port number as the TID, and it needs to
-     * be consistent across connect()/disconnect() calls.
-     */
-    if (!socket->net.efi.localport) {
-	status = uefi_call_wrapper(udp->GetModeData, 5, udp,
-				   &udata, NULL, NULL, NULL);
-	if (status != EFI_SUCCESS)
-	    Print(L"Failed to get UDP mode data: %d\n", status);
-	else
-	    socket->net.efi.localport = udata.StationPort;
-    }
 }
 
 /**

Op 2013-11-08 om 10:48 schreef H. Peter Anvin:
> Thank you for posting the pcap files, by the way.  Analyzing them in
> Wireshark is so much nicer than reading the text output of tcpdump.
Fetch the new capture with

 wget -O pcap2.zip http://ge.tt/api/1/files/136167y/0/blob?downlad


The capture[1] shows two[2] TFTP transmissions of sles113/syslinux.efi,
but nothing after that. As if syslinux.efi was crashed.


Groeten
Geert Stappers

Notes
[1] With a snaplength of 96 bytes or something.
    Add -S0 to tcpdump to get the full network packets.
[2] A previous posting says that the repeated transmission
    is an artifact of the firmware.