search for: core_udp_send

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 =

...t;hpa at zytor.com> wrote: >>>> Here is a completely untested patch if someone wants to try and take it >>>> for a spin? core_udp_open() should bind to the local IP address and obtain a local UDP port allocation. core_udp_close() should release the UDP port allocation. core_udp_sendto() knows the remote IP address and remote UDP port and must calculate the GatewayAddress. core_udp_connect() is passed the remote IP address and UDP port, calculates the GatewayAddress and stores all three for core_udp_send(). core_udp_send() should only copy the local/remote IP address/UDP port...

...On a newly cloned repo: git checkout -b genec-efi-fixes-2-for-mfleming origin/efi-fixes-2-for-mfleming >> core_udp_open() should bind to the local IP address and obtain a local >> UDP port allocation. core_udp_close() should release the UDP port >> allocation. >> >> core_udp_sendto() knows the remote IP address and remote UDP port and >> must calculate the GatewayAddress. core_udp_connect() is passed the >> remote IP address and UDP port, calculates the GatewayAddress and >> stores all three for core_udp_send(). core_udp_send() should only >> copy...

...s in util/geniso). The version is listed as 4.07. I was under the impression 6.00 was the first version that supported efi. > core_udp_open() should bind to the local IP address and obtain a local > UDP port allocation. core_udp_close() should release the UDP port > allocation. > > core_udp_sendto() knows the remote IP address and remote UDP port and > must calculate the GatewayAddress. core_udp_connect() is passed the > remote IP address and UDP port, calculates the GatewayAddress and > stores all three for core_udp_send(). core_udp_send() should only > copy the local/remote...

>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

...out -b genec-efi-fixes-2-for-mfleming > origin/efi-fixes-2-for-mfleming > > >> core_udp_open() should bind to the local IP address and obtain a local > >> UDP port allocation. core_udp_close() should release the UDP port > >> allocation. > >> > >> core_udp_sendto() knows the remote IP address and remote UDP port and > >> must calculate the GatewayAddress. core_udp_connect() is passed the > >> remote IP address and UDP port, calculates the GatewayAddress and > >> stores all three for core_udp_send(). core_udp_send() should only...

...t;>>> Here is a completely untested patch if someone wants to try and take it >>>>> for a spin? > > core_udp_open() should bind to the local IP address and obtain a local > UDP port allocation. core_udp_close() should release the UDP port > allocation. > > core_udp_sendto() knows the remote IP address and remote UDP port and > must calculate the GatewayAddress. core_udp_connect() is passed the > remote IP address and UDP port, calculates the GatewayAddress and > stores all three for core_udp_send(). core_udp_send() should only > copy the local/remote...

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 no guarantee > what's in it (unless there's som...

...s that before any packet is actually sent (and Transmit is called), GetModeData return a StationPort = 0. Leading to received packets being discarded by the firmware because of the non-matching port and the absence of AcceptAnyPort flag. Local port, thus, can't be saved before the first call to core_udp_send or core_udp_sendto. Two possible solutions I see: 1) Handle the local port "by hand" instead of relying on the EFI implementation to chose it. 2) Save the StationPort as soon as it is known similarly to what is currently done. 2013/11/9, H. Peter Anvin <hpa at zytor.com>: > On...

...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's in it (unless there's som...

On Fri, Nov 8, 2013 at 5:08 PM, Jason Matthews <jason.david.matthews at gmail.com> wrote: > I attempted the patch, but had to add a declaration to get it to compile. I > also added the gateway like before. Here's a link to the modified diff I > used and the pcaps from tftpserver and mirrored port from boot to reset. > > http://ge.tt/136167y/v/0 > > I'm also not

..._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; - struct efi_binding *b; EFI_STATUS status; - EFI_UDP4 *udp; - size_t size; - int rv = -1; - jiffies_t start; - -...

...er 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's in it (unless...

...stall. > > 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's in it (unless there's some stack trickery jus...

...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 plus there's no guarantee >> what's in it (unless...

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

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

From: Sylvain Gault <sylvain.gault at gmail.com> Despite having native network capabilities, UEFI 2.4 (the most widely deployed at the moment) has no native DNS resolver. I propose here an implementation more or less inspired by the one found in core/legacynet/dnsresolv.c. Since it's non-trivial, I'd like to ask for a deep review of this code. I tried to make it as strong as