similar to: syslinux6 EFI fail to boot via pxe

> > Have you tried 5.10 in your environment on a BIOS machine to see whether > that works and which port numbers it uses? > > -- > Matt Fleming, Intel Open Source Technology Center > Hi Matt, I think I've found the problem. In /core/fs/pxe/tftp.c in function tftp_open: First you do a core_udp_connect to port 69 (TFTP) at line 264. -> source port = x After that

On Tue, 25 Jun, at 01:51:52PM, Michael Szerencsits wrote: > Hi Matt, > > I think I've found the problem. Thanks for doing this analysis. > In /core/fs/pxe/tftp.c in function tftp_open: > First you do a core_udp_connect to port 69 (TFTP) at line 264. -> source port = x > After that you sent the filerequest at line 265 > You receive the fileinfo and also the used port

> Isn't the server complaining because port 7012 is unreachable? Not the > other way around? It really doesn't matter to the server what the value > of the source port is from the client. > > Looking at your network packet dump from a previous email, > > Source Destination Protocal SPort DPort Description > 10.0.0.100 10.0.0.1 tftp 1479

On Mon, 24 Jun, at 11:17:29AM, Michael Szerencsits wrote: > Hello, > > I tried to boot the new syslinux.efi (32bit) from the released > syslinux 6 via PXE. In a wireshark trace I can see that the > syslinux.efi was loaded successfully via TFTP. Then the client try to > load ldlinux.e32. I see the request and also the acknoledgement in the > trace. After that the client try

Hi Guys, i have a problem with PXE/UEFI Boot. Legacy PXE Boot is working fine. I use Dnsmasq with integrated tftp. As Mentioned above, legacy pxe boot is working fine, tcpdump shows: --- start tcpdump legacy pxe boot --- 13:44:16.589197 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from f8:ca:b8:06:7d:ed (oui Unknown), length 548 13:44:20.543910 IP 0.0.0.0.bootpc >

Signed-off-by: Julien Viard de Galbert <jviarddegalbert at online.net> --- efi/udp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/efi/udp.c b/efi/udp.c index 1088f47..b0f13ad 100644 --- a/efi/udp.c +++ b/efi/udp.c @@ -163,7 +163,7 @@ void core_udp_connect(struct pxe_pvt_inode *socket, uint32_t ip, } else { udata.UseDefaultAddress = FALSE;

from: Jeff Sloan <jeff_sloan at selinc.com> Based on commit: 9314e330 Setting UseDefaultAddress to TRUE uses invalid StationAddress and SubnetMask values. This is in a network with a local TFTP/MTFTP server. If the server is local, on the same subnet, UseDefaultAddress is set to false and the client ip and subnetmask are loaded, otherwise set UseDefaultAddress to TRUE. This is added to

The variable 'ok' is never used and generates a warning. Remove it. Also ntfssect.c is designed to be compiled in non Unicode mode when using MSVC compilers, so remove all ambiguity about it (LPCTSTR -> LPCSTR, use of 'A' API calls) so that it doesn't break when compiled in Unicode mode, which is what Rufus uses with MSVC. -------------- next part --------------

> Have you tried 5.10 in your environment on a BIOS machine to see whether > that works and which port numbers it uses? > > -- > Matt Fleming, Intel Open Source Technology Center Hi Matt, I have now tested the gpxelinux.0 from syslinux-6.00. This work. The ldlinux.c32 download is from the same port as it was requested from the client. My problem is with EFI boot, not BIOS.

On Tue, 25 Jun, at 03:14:00PM, Michael Szerencsits wrote: > Hi Matt, > > the server is listening on the port. I reviewed the RFC for TFTP and > it say that the server would response with an error if the source TID > is not correct: Aha, yes, you're right. I'll take a look at fixing this. -- Matt Fleming, Intel Open Source Technology Center

> On Tue, 25 Jun, at 09:43:02PM, Matt Fleming wrote: > > Aha, yes, you're right. I'll take a look at fixing this. > > Michael, could you try out Syslinux 6.01-pre2 and see if things are now > working for you? > > -- > Matt Fleming, Intel Open Source Technology Center > Hi Matt, yes, now the TFTP download work. I'm able to successfully boot into a

On Wed, 26 Jun, at 03:15:51PM, Michael Szerencsits wrote: > Sure, > > here it is OK, staring at this packet dump, I see that your firmware isn't setting a default value for the IP TTL field, but seeing as the UEFI spec doesn't require this, that's a Syslinux bug. Interestingly, the firmware on my test machine does fill out the TTL field with a value of 64. -- Matt Fleming,

On Thu, 27 Jun, at 02:08:34PM, Michael Szerencsits wrote: > > > Oh, also, if possible please test 6.01-pre4, just to make sure it's not > > the TCP packets that are now causing problems on your Sony machine. > > > > -- > > Matt Fleming, Intel Open Source Technology Center > > > > I tested the pre4 on both systems. Same problems as before. >

> > I can't see any HTTP traffic in either of these dumps. Which machine did > you capture these logs on? Are you sure that the HTTP packets are > reaching your server? > > -- > Matt Fleming, Intel Open Source Technology Center > The boot-efi5.cap is from the booting lenovo system. I ran the trace again, but the file is 100MB

On Thu, 27 Jun, at 03:25:57PM, Michael Szerencsits wrote: > The boot-efi5.cap is from the booting lenovo system. I ran the trace again, but the file is 100MB Oh, I just remembered, the DNS resolving code isn't fully functional for EFI. If you replace hostnames with IP addresses, do you see any different behaviour? Of course, it's possible you're not getting that far. Can you get

On Thu, 27 Jun, at 04:18:04PM, Michael Szerencsits wrote: > Change hostname to IP address, but same problem. > Copy the default config to uuid of the system, same problem > PROMPT 1 -> I see boot: but cannot do anything. If I press a key nothing happen OK, now that's just weird. You don't see any response whatsoever from tapping at the keys? If you set a TIMEOUT, can you run

On Thu, 27 Jun, at 08:16:35PM, Michael Szerencsits wrote: > Am 27. Juni 2013 17:44:58 schrieb Matt Fleming <matt at console-pimps.org>: > >OK, now that's just weird. You don't see any response whatsoever from > >tapping at the keys? > > That's correct. Nothing happen. Bad :-/ > >If you set a TIMEOUT, can you run a DEFAULT even though you cannot

> Gesendet: Donnerstag, 27. Juni 2013 um 17:44 Uhr > OK, now that's just weird. You don't see any response whatsoever from > tapping at the keys? > > If you set a TIMEOUT, can you run a DEFAULT even though you cannot type? > That's one way to figure out whether the machine is dead at that point > or not. A useful DEFAULT might be reboot.c32, that way even if the

On Mon, 01 Jul, at 04:30:19PM, Michael Szerencsits wrote: > I tried to test the 6.01-pre5 version, but after loading from > ldlinux.e64 nothing happen in the trace. If I test the efi32 in > VMWare it comes up with a 'Firmware error' and close the VMWare. > > It seems that syslinux.efi from pre5 is broken > > I now would perfrom the tests with pre4 Does reverting to

On Thu, 04 Jul, at 08:17:19AM, Michael Szerencsits wrote: > > > Could you try out 6.01-pre6 and see if your machine actually gets to > > the point of config file failure (I still need to debug that)? > > > Yes, 6.01-pre6 works. syslinux.efi and ldlinux.e64 was loaded > successfully, but when trying to load the config file it stuck. See > wireshark trace Thanks