search for: getmodedata

...branch firmware and I get a different (non-working) behavior. syslinux.efi is correctly downloaded and my tftp server receive requests for ldlinux.e64 and acknowledge options, but receive no response at all. Actually, what happen is 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...

...e_udp_open(struct pxe_pvt_inode *socket) socket->net.efi.binding = b; + /* + * Save the random local port number that the UDPv4 Protocol + * Driver picked for us. The TFTP protocol uses the local port + * number as the TID. + */ + status = uefi_call_wrapper(udp->GetModeData, 5, udp, + &udata, NULL, NULL, NULL); + if (status != EFI_SUCCESS) + Print(L"Failed to get UDP mode data: %d\n", status); + else + socket->net.efi.localport = udata.StationPort; + return 0; bail: @@ -89,7 +100,6 @@ void core_udp_close(struct pxe_pvt_inode *so...

I did change both instances of txdata->GatewayAddress, but I think something may be wrong in my toolchain. If I extract syslinux.zip and attempt to make from there (without modifying any files), the cached DHCP packet isn't read on the same subnet. I receive "Succeed to download NBP file." twice before anything from syslinux is loaded, so I believe the duplicate request for

...BS->SetTimer, 3, + udp_io->Timeout_Timer, + TimerRelative, + UDP_TIME_TO_GETMAP + ); + + if (EFI_ERROR (status)) + return FALSE; + + while (EFI_ERROR ( uefi_call_wrapper(BS->CheckEvent, 1, udp_io->Timeout_Timer) )) + { + udp->Poll(udp); + + if (!EFI_ERROR(udp->GetModeData(udp, NULL, &Ip4Mode, NULL, NULL)) && + Ip4Mode.IsConfigured) + { + udp->Configure(udp, NULL); + return (BOOLEAN) (udp->Configure(udp, udata) == EFI_SUCCESS); + } + } + + return FALSE; +} + + /** - * Try to configure this UDP socket + * Try to configure this UDP_I...

...nces are print-labeled page numbers not PDF page numbers; function context also provided) p1377 (EFI_UDP4_PROTOCOL.Configure()) "With different parameters in UdpConfigData, Configure() can be used to bind this instance to specified port." covers the manual case. p1376 (EFI_UDP4_PROTOCOL.GetModeData()) "StationPort" "The port number to which this EFI UDPv4 Protocol instance is bound. If a client of the EFI UDPv4 Protocol does not care about the port number, set StationPort to zero. The EFI UDPv4 Protocol driver will assign a random port number to transmitted UDP packets. Ignored...

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

...local + * port number that the UDPv4 Protocol Driver picked for us. The TFTP + * protocol uses the local port number as the TID, and it needs to + * be consistent across connect()/disconnect() calls. + */ + if (!socket->net.efi.localport) { + status = uefi_call_wrapper(udp->GetModeData, 5, udp, + &udata, NULL, NULL, NULL); + if (status != EFI_SUCCESS) + Print(L"Failed to get UDP mode data: %d\n", status); + else + socket->net.efi.localport = udata.StationPort; + } + close: uefi_call_wrapper(BS->CloseEvent, 1, token->Event); -- 1.8....

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

On Thu, Nov 28, 2013 at 9:47 PM, Gene Cumm <gene.cumm at gmail.com> wrote: > On Thu, Nov 28, 2013 at 9:34 PM, Celelibi <celelibi at gmail.com> wrote: >> Without an assigned source port, Transmit function assign a random new >> source port to the packet being sent. It thus have to be set before >> calling Transmit if the source port have already been decided.