search for: core_udp_recv

>I played around with the udp4_cb function and it looked like it was coming back with token->Status == 512, which (if I read the spec right) isn't a valid value. I'm not sure what is coming through on that. I changed the if to if (token->Event) { cb_status = 0; } Looks like the same thing with tcp.c. After I changed that callback, everything went through and I go into the OS

...and I go into the OS install. >> >> But, if I go back to 1 subnet after those changes, it errors out with >> Invalid Parameter when attempting to send the first packet. >> >> (Sorry for the top posting.) > > I just started examining this and find it odd that the core_udp_recv() > doesn't zalloc() its token while core_udp_send()/core_udp_sendto() do. > All three are a part of commit fe283b78 by Matt Fleming. Should this > be made into a zalloc() rather than pushing it into the stack? It'd > seem like it could run some stack issues plus there's...

On 11/24/2013 03:29 AM, Gene Cumm wrote: >> >> (Sorry for the top posting.) > > I just started examining this and find it odd that the core_udp_recv() > doesn't zalloc() its token while core_udp_send()/core_udp_sendto() do. > All three are a part of commit fe283b78 by Matt Fleming. Should this > be made into a zalloc() rather than pushing it into the stack? It'd > seem like it could run some stack issues plus there's...

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;

...l. >>> >>> But, if I go back to 1 subnet after those changes, it errors out with >>> Invalid Parameter when attempting to send the first packet. >>> >>> (Sorry for the top posting.) >> >> I just started examining this and find it odd that the core_udp_recv() >> doesn't zalloc() its token while core_udp_send()/core_udp_sendto() do. >> All three are a part of commit fe283b78 by Matt Fleming. Should this >> be made into a zalloc() rather than pushing it into the stack? It'd >> seem like it could run some stack issues p...

...ARP and then nothing hits the wire from the client. The internal failing scenario is core_udp_sendto in syslinux calls Udp4Configure BIOS command, (I will grab the packet.) BIOS returns an EFI_UNSUPPORTED (EFIERR (3)) error but tftp_open still tries to transmit a packet and waits for a reply (core_udp_recv). The loop timeout values are long enough that the watchdog eventually times out and reboots the client. In tftp.c (tftp_open) starting at line 240: sendreq: timeout = *timeout_ptr++; if (!timeout) return; /* No file available... */ oldtime = jiffies(); core_udp_send...

...t; > > > I made a few tests, it worked correctly with a normal dns > > server. Didn't test malformed packets. > > > > Here are the two main missing features of this patch. > > - No caching implemented. > > - No timeout management. The efi implementation of core_udp_recv > > wait 15ms before giving up. > > > > I'd also like to ask if it wouldn't be better to just write an > > efi driver for lwip and just inherit all the network protocols > > implemented there, instead of trying to use the buggy native UEFI > > implement...

...> everything went through and I go into the OS install. > > But, if I go back to 1 subnet after those changes, it errors out with > Invalid Parameter when attempting to send the first packet. > > (Sorry for the top posting.) I just started examining this and find it odd that the core_udp_recv() doesn't zalloc() its token while core_udp_send()/core_udp_sendto() do. All three are a part of commit fe283b78 by Matt Fleming. Should this be made into a zalloc() rather than pushing it into the stack? It'd seem like it could run some stack issues plus there's no guarantee what...

On Tue, Nov 26, 2013 at 2:02 PM, H. Peter Anvin <hpa at zytor.com> wrote: > On 11/24/2013 03:29 AM, Gene Cumm wrote: >>> >>> (Sorry for the top posting.) >> >> I just started examining this and find it odd that the core_udp_recv() >> doesn't zalloc() its token while core_udp_send()/core_udp_sendto() do. >> All three are a part of commit fe283b78 by Matt Fleming. Should this >> be made into a zalloc() rather than pushing it into the stack? It'd >> seem like it could run some stack issues p...

...A and NM but special-cases both null to allow for proxy. BIOS tries to find the GUID to configure but fails and returns EFI_UNSUPPORTED error, EFIERR(3). Then core_udp_sendto attempts to send the packet even though it was never configured. It does not check for problems, instead relying on the core_udp_recv to timeout. It retries based on the timeout table but before completing all of the retries, the watchdog timer triggers a reset. So the net is that no udp packets hit the wire once syslinux starts executing. I was able to circumvent this by setting UseDefaultAddress to FALSE and populating SA a...

...robably the native UEFI firmware in action. Also, this step never fails. The next file will always at least start to load, even when the slave decides to crash before (or after?) the next file finnishes downloading. Even ldlinux can fail to load. On bigger files, there is an increasing chance that core_udp_recv in efi/udp.c hits the 15ms (or is it 15 undefined jiffies?) timeout and returns -1 to its caller in core/fs/pxe/tfpt.c:tftp_get_packet(). This function then goes to ack_again, causing atfptd to resend the packet that just timed out. Then on the next call the original(!) packet is received anyway a...

...ion of buffer to store data - * @param:buf_len, size of buffer - - * @out: src_ip, ip address of the data source - * @out: src_port, port number of the data source, host-byte order + * @param:socket, the open socket + * @param:data, data buffer to send + * @param:len, size of data bufer */ -int core_udp_recv(struct pxe_pvt_inode *socket, void *buf, uint16_t *buf_len, - uint32_t *src_ip, uint16_t *src_port) + +void core_udp_send(struct pxe_pvt_inode *socket, const void *data, size_t len) { - EFI_UDP4_COMPLETION_TOKEN token; - EFI_UDP4_FRAGMENT_DATA *frag; - EFI_UDP4_RECEIVE_DATA *rxdata; -...

...omething. I would take any comment, even on the coding style. :) I made a few tests, it worked correctly with a normal dns server. Didn't test malformed packets. Here are the two main missing features of this patch. - No caching implemented. - No timeout management. The efi implementation of core_udp_recv wait 15ms before giving up. I'd also like to ask if it wouldn't be better to just write an efi driver for lwip and just inherit all the network protocols implemented there, instead of trying to use the buggy native UEFI implementations. Depending on this, I may or may not spend time on t...

...firmware in action. > Also, this step never fails. The next file will always at least start to > load, even when the slave decides to crash before (or after?) the next > file finnishes downloading. Even ldlinux can fail to load. > > On bigger files, there is an increasing chance that core_udp_recv in > efi/udp.c hits the 15ms (or is it 15 undefined jiffies?) timeout and > returns -1 to its caller in core/fs/pxe/tfpt.c:tftp_get_packet(). > > This function then goes to ack_again, causing atfptd to resend the packet > that just timed out. Then on the next call the original(!) pac...

On Sat, Nov 9, 2013 at 9:22 AM, Jason Matthews <jason.david.matthews at gmail.com> wrote: > The setup I was using was in a chassis. Slot 8 of the chassis is the client > machine. It goes through Switch 1 (a Brocade switch) to the top of rack > (BNT). The mirror is in the chassis switch. Slot 3 of the same chassis is > connected to the mirror port in Switch 1. > > client =

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

...le (cb_status == -1) { /* 15ms receive timeout... */ if (jiffies() - start >= 30) { if (jiffies() - start >= 60) printf("Failed to cancel UDP\n"); uefi_call_wrapper(udp->Cancel, 2, udp, &token); printf("core_udp_recv: timed out\n"); } uefi_call_wrapper(udp->Poll, 1, udp); } Just to rule out some stupid missed interrupt or so, I gave it an extra CPU. > I presume you disabled VMware's isc-dhcp on vmnet1? Yes. I should have mentioned that. Found out the hard way.. . ;-) &gt...

...store the values for reuse. > > It looks like it's going into core_udp_open, giving station port to > socket->net.efi.localport. core_udp_sendto sets the remote port. From > there, I'm never getting into core_udp_send or core_udp_connect. After > core_udp_sendto, I go into core_udp_recv, hit the jiffies() loop, time out > and bail to repeat the same process until reset. > > Thanks for pointing out the UEFI_Spec_2_3_1.pdf. It help me get a little > more grasp on what's happening. I set it to use the Default Address. If you > set UseDefaultAddress to true and comm...

...worked correctly with a normal dns >>> > server. Didn't test malformed packets. >>> > >>> > Here are the two main missing features of this patch. >>> > - No caching implemented. >>> > - No timeout management. The efi implementation of core_udp_recv >>> > wait 15ms before giving up. >>> > >>> > I'd also like to ask if it wouldn't be better to just write an >>> > efi driver for lwip and just inherit all the network protocols >>> > implemented there, instead of trying to use t...

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 --------------