search for: pxenv_udp_read

Displaying 9 results from an estimated 9 matches for "pxenv_udp_read".

2005 Mar 09
0
Re: [Fwd: Re: etherboot 5.3.14 and pxelinux keyboard problem]
...GPL) http://etherboot.org > Drivers: 3C90X Images: NBI ELF PXE Exports: PXE > Protocols: DHCP TFTP > Relocating _text from: [00010420,00022880) to [5feedba0,5ff00000) > Boot from (N)etwork or (Q)uit? > > <snip> > [PXENV_UDP_WRITE 40708->10.0.0.100:69 (41)] > [PXENV_UDP_READ 10.0.0.100:33016->10.0.0.101:40708 (12)] > [PXENV_UDP_WRITE 40708->10.0.0.100:33016 (4)] > [PXENV_UDP_READ 10.0.0.100:33016->10.0.0.101:40708 (260)] > [PXENV_UDP_WRITE 40708->10.0.0.100:33016 (4)] > Unknown keyword in config file. > boot: > [PXENV_UDP_READ 0001 err] &g...
2005 Mar 08
2
[Fwd: Re: etherboot 5.3.14 and pxelinux keyboard problem]
....3.14. > > That would not be a PXELINUX bug, but an Etherboot bug. The PXE READ > UDP call is defined as non-blocking, but several implementors have > screwed that one up (including VMWare.) Unfortunately not answering > ARPs has bad effects, too. Etherboot's implementation of PXENV_UDP_READ is and has always been non-blocking. I don't see this problem when I try pxelinux from syslinux-3.08-pre5 and current Etherboot CVS. The relevant routine, pxenv_udp_read() in Etherboot's core/pxe_export.c, hasn't changed since July last year. You can debug this by defining -DTRACE_PX...
2005 Mar 06
2
etherboot 5.3.14 and pxelinux keyboard problem
Hello PXE folk, I mentioned in another thread that I had problems finding an etherboot that actually works with a 486 and Realtek 8019/NE2000 card. Etherboot worked up until v 5.3.5-mc1 with the ne driver but then stopped working between 5.3.7 to 5.3.13 (anoying since 5.3.7 started supporting PXELINUX. But then I downloaded 5.3.14 and it seems to work again with the ne driver (finally
2005 Apr 21
1
pxelinux 3.08-pre8 hangs at boot prompt under vmware GSX
...oed promptly. C+A+D still resets promptly. I don't know if the problem exists with real hardware, but I do know that syslinux-2.07 was ok on vmware (but that didn't have the arp code, of course). Is this most likely a bug in the vmware BIOS, or is there some timeout we can specify on the PXENV_UDP_READ call? Thanks, Richard
2003 Apr 11
1
PXELINUX on top of Etherboot?
Question for people... Has anyone actually tried running PXELINUX on top of Etherboot? There is something in Etherboot 5.1.7 called FREEBSD_PXEEMU, which seems to be a PXE stack subset, in particular it seems to support the following calls: PXENV_GET_CACHED_INFO PXENV_UDP_OPEN PXENV_UDP_WRITE PXENV_UDP_READ PXENV_UDP_CLOSE PXENV_UNLOAD_STACK PXENV_UNDI_SHUTDOWN This happens to be pretty close to the subset used by PXELINUX, with two exceptions: PXELINUX will also invoke PXENV_STOP_UNDI (for version >= 2.00) or PXENV_UNDI_CLEANUP (for version < 2.00). I'd be really curious to see how thi...
2002 Feb 04
2
nilo -> tftp-hpa interaction
...cting the nics (loops forever); I think this has to do with the new becker pci-scan.o stuff that oskit does not know and I somehow forced it to "know". Did anyone used nilo succesfully with tftp-hpa? Thanks ====== nilo trace <= dump.c:496 dump_arp_table() return <= pxe_udp.c:182 pxenv_udp_read() return => tftp.c: tftp_decode_packet() enter => dump.c: dump_tftp_packet() enter 00:02:57: ERROR: tftp structure is NULL 02:40:09: Unknown TFTP packet type 0x53ff <= tftp.c:243 tftp_decode_packet() return 12:22:24: Packet numbers too far out of sync. <= pxe_tftp.c:172 pxenv_...
2013 Mar 28
1
Makefile race condition with parallel make
When attempting to build syslinux in parallel (make -j5), I encountered the following error at the end: rm -f liblpxelinux.a ar cq liblpxelinux.a rawcon.o ./fs/pxe/dhcp_option.o ./fs/pxe/pxe.o ./fs/pxe/tftp.o ./fs/pxe/urlparse.o ./lwip/src/netif/ethernetif.o ./lwip/src/netif/etharp.o ./lwip/src/netif/slipif.o ./lwip/src/netif/ppp/md5.o ./lwip/src/netif/ppp/randm.o ./lwip/src/netif/ppp/chpms.o
2012 Jul 16
5
[PATCH 0/5] Deleting __intcall() from Syslinux
From: Matt Fleming <matt.fleming at intel.com> Since we can't use __intcall() for EFI, and since we can now have the ELF module code resolve all our symbols at runtime, we should delete as many references to __intcall() as possible and just access the symbols directly. The most interesting patch is the support for weak symbols. We need to be able to reference derivative-specific
2012 Aug 14
1
[GIT PULL] elflink fixes
...0dacb 100644 --- a/com32/libupload/upload_tftp.c +++ b/com32/libupload/upload_tftp.c @@ -53,7 +53,6 @@ const char *tftp_string_error_message[]={ static int send_ack_packet(struct tftp_state *tftp, const void *pkt, size_t len) { - com32sys_t ireg, oreg; t_PXENV_UDP_WRITE *uw; t_PXENV_UDP_READ *ur; clock_t start; @@ -67,9 +66,6 @@ static int send_ack_packet(struct tftp_state *tftp, uw = lmalloc(sizeof *uw + len); ur = lmalloc(sizeof *ur + RCV_BUF); - memset(&ireg, 0, sizeof ireg); - ireg.eax.w[0] = 0x0009; - for (timeout = timeouts ; *timeout ; timeout++)...