search for: udp4_cb

On Sun, Nov 24, 2013 at 6:29 AM, Gene Cumm <gene.cumm at gmail.com> wrote: > On Wed, Nov 13, 2013 at 4:26 PM, Jason Matthews > <jason.david.matthews at gmail.com> wrote: >>>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...

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

...10:52 PM, Gene Cumm <gene.cumm at gmail.com> wrote: > On Sun, Nov 24, 2013 at 6:29 AM, Gene Cumm <gene.cumm at gmail.com> wrote: >> On Wed, Nov 13, 2013 at 4:26 PM, Jason Matthews >> <jason.david.matthews at gmail.com> wrote: >>>>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; } >>> &gt...

...rc_port) Changed 'ip' and 'port' in 'src_ip' and 'src_port'. However: 'src_ip' and 'src_port' are not in } + * @param:ip, the source ip address } + * @param:port, the source port number, host-byte order <snip/> > -static EFIAPI void udp4_cb(EFI_EVENT event, void *context) > +VOID > +EFIAPI > +UdpIoOnDgramSent ( > + IN EFI_EVENT event, > + IN VOID* context > + ) Such coding style change did me really stop removing this unified patch. Groeten Geert Stappers -- Leven en laten leven ------------- volgend deel ---...

...EFI_UDP4 *)socket->net.efi.binding->this; - - /* Reset */ - status = uefi_call_wrapper(udp->Configure, 2, udp, NULL); - if (status != EFI_SUCCESS) - Print(L"Failed to reset UDP: %d\n", status); + + return; + } -static int volatile cb_status = -1; -static EFIAPI void udp4_cb(EFI_EVENT event, void *context) -{ - (void)event; - - EFI_UDP4_COMPLETION_TOKEN *token = context; - if (token->Status == EFI_SUCCESS) - cb_status = 0; - else - cb_status = 1; +/** + * + * Send callback function + * + */ +VOID +EFIAPI +UdpIoOnDgramSent ( + IN EFI_EVENT event, +...

On Mon, Nov 11, 2013 at 4:53 PM, Jason Matthews <jason.david.matthews at gmail.com> wrote: > On Sun, Nov 10, 2013 at 12:23 PM, Gene Cumm <gene.cumm at gmail.com> wrote: > >> 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 >>

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

On Wed, Nov 13, 2013 at 4:26 PM, Jason Matthews <jason.david.matthews at gmail.com> wrote: >>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...

...ination of synchronous timers (TimerPeriodic) with callback function to calculate "jiffies" which is used to determine the increasing receive timeout (based on a table). The reception of every block also creates an event triggered by EFI_EVENT_NOTIFY which calls a callback function (udp4_cb()) just to change a status (cb_status). Next we keep polling the cb_status variable while calling EFI_UDP4_PROTOCOL.Poll()to speed things up. So far I have been focusing my analysis on the EFI/UDP side of things because Wireshark traffic captures shown a pretty constant heavy delay (under VMw...

I tried the efi-fixes-2-for-mfleming, but it doesn't look like it's getting much further. It looks like it's now storing the local port but is still bailing out after the jiffies loop. Here are the pcaps from that: http://ge.tt/4O5N9Az/v/0 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; } and set the jiffies loop to set cb_status to 1 on timeo...

On Wed, Sep 23, 2015 at 4:24 PM, Patrick Masotta <masottaus at yahoo.com> wrote: >>>> > > > BTW if you take a minute and read the first report > > https://communities.vmware.com/message/2536774 > > You'll realize that VMWare TFTP "surprisingly" does not present slow TFTP transfers > > when they are driven by MS