similar to: A few questions for the braintrust

OK there are problems. From https://sourceforge.net/p/edk2/mailman/message/31604654/ ""In current EDKII implementation, all the network servicebinding protocols for a NIC device are installed together on the NIC's device handle, so you can get all of them when you have chosen a special NIC handle."" Unfortunately there are PCs with UEFI implementations not following the

Hello, Does anyone know of a "slick" way to get R to convert a string which is all upper case to a string where the first letter in each word is upper case and all others are lower case? I suspect the solution is to begin by parsing the string, convert the appropriate letters to upper and lower case using "toupper" and "tolower", and then to paste the pieces back

>>> Lovely, the ServiceBindings are on a handle that resembles the NIC while the Pxebc is IP-type specific.? Looks like we should try to do a ServiceBinding based on Pxebc but fall back to MAC-based searching, saving all 3 handles, the image handle, Pxebc handle, and ServiceBinding handle.? Presumably the UDP and TCP handles _should_ be the same... -- -Gene <<< OK now it

On 09/26/2015 10:36 AM, Patrick Masotta via Syslinux wrote: > > About PXEbc Peter has recently said: >> The problem with the pxebc is that it only supports one concurrent TFTP >> connection, and Syslinux expects to be able to keep multiple files open >> at the same time. >> http://www.syslinux.org/archives/2015-August/024025.html > > I wonder why should

>> Doesn't work. Apparently the Dell UEFI PXE firmware doesn't know HTTP. > > There's a lot of variation. Do you have a shell option > in your boot selections? None of Dell OptiPlex 990 (firmware A19), 9010 (firmware A22), nor 9020 (firmware A16) seem have a built-in EFI shell option, but in all three cases I had success running the external EFI shell from

>>> I'm just debating what's the best algorithm here.? It would seem if the LoadeImage's DeviceHandle provides UDPv4Sb, use it as it's guaranteed to be the same interface.? Otherwise, we need a MNPSb (EFI_MANAGED_NETWORK_SERVICE_BINDING) that provides UDPv4Sb across the same interface.? Presumably it should also provide TCPv4Sb (rather than being on a separate

We can, and do, suspend a TFTP transfer simply by delaying the ACK packet as necessary. On September 29, 2015 7:45:27 PM PDT, Patrick Masotta <masottaus at yahoo.com> wrote: >>>> >On 09/26/2015 10:36 AM, Patrick Masotta via Syslinux wrote: >> >> About PXEbc Peter has recently said: >>> The problem with the pxebc is that it only supports one concurrent

>>> > 1) There's not "any" SB protocol present (Elitebook 8460p/2560p) The only solution for these is to use our own stack (likely full TCP/IP like lwIP) and connect to the Net GUID (EFI_SIMPLE_NETWORK_PROTOCOL).? Does the handle for Pxebc contain a Net?? >>> It does contain a Net but there are 2 issues with SNP: 1) The interface is different than

>>> > Considering any editing/buffering benefits are only marginal (AFAIK) there are not benefits with the current approach.On the other hand the list of potential problems includes: > 1) We cannot use the ubiquitous EFI PXEbc protocol forcing us to rely on the (not always present) EFI Binding Services. > Best,Patrick Speaking utterly ignorantly here... could this switch help

>>>>>I do not understand.Are we parsing a configuration file and potentially >>starting new TFTP transfers while downloading it? How can we do this on >>a single thread?We cannot stop/resume a TFTP transfer then I cannot >>imagine how to detect an INCLUDE during TFTP transfer N to launch TFTP >>transfer N+1 if TFTP transfer N is not finished yet, all in a

On Fri, Aug 14, 2015 at 11:42 AM, Patrick Masotta via Syslinux <syslinux at zytor.com> wrote: >>>>> > website (meaning, HP could test their firmware to be compatible with > Syslinux and with non-Windows OSes). If the HP firmware could be made > (more) compliant with UEFI specs, or if it could be improved and still > be compliant with UEFI specs, wouldn't

On Wed, Nov 29, 2017 at 6:30 AM, Gene Cumm <gene.cumm at gmail.com> wrote: > On Tue, Nov 28, 2017 at 2:38 PM, Joakim Tjernlund > <Joakim.Tjernlund at infinera.com> wrote: >> On Mon, 2017-11-27 at 18:18 -0500, Gene Cumm wrote: > >>> On Mon, Nov 27, 2017 at 6:07 PM, Joakim Tjernlund >>> <Joakim.Tjernlund at infinera.com> wrote: >>> > On

>>> Jeff, Patrick: Could you try my code from my github repo branch efi-multinic?? It's derived from Patrick's code and I finally see good responses with a VMware VM's e1000e NIC (never saw ANYTHING good from it until now). git://github.com/geneC/syslinux.git https://github.com/geneC/syslinux.git -- -Gene <<<< I've seen your code. Your

>>> > It does contain a Net but there are 2 issues with SNP: > 1) The interface is different than UDPv4/TCPv4 protocols; this imply lot of code. Not as much as you may think.? We already have lwIP implemented into lpxelinux.0.? It's more a matter of using more glue. > 2) SNP has its non-blocking transmit issues ; see "Flaws in the design" at >

Gene thanks, here is the output My IP is 10.2.49.10 Img @ 71d89718 = 8cdcd40ca5f0 Udp @ 71d89718 = 8cdcd40ca5f0 Udp @ 71d89718 = 8cdcd40ca5f0 Udp @ 71d89718 = 8cdcd40ca5f0 >From that point it is hung On Sun, Aug 30, 2015 at 4:10 AM, Gene Cumm via Syslinux <syslinux at zytor.com> wrote: > On Fri, Aug 28, 2015 at 3:13 PM, Derrick M <derrick.martinez at gmail.com> > wrote:

On Wed, 2017-12-13 at 10:34 -0500, Gene Cumm wrote: > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. > > > On Wed, Dec 13, 2017 at 7:03 AM, Joakim Tjernlund > <Joakim.Tjernlund at infinera.com> wrote: > > On Mon, 2017-12-11 at 08:59 +0100, Joakim

On Fri, Jun 26, 2015 at 10:15 AM, <jeff_sloan at selinc.com> wrote: > Will do, Gene. I'll let you (and the mailing list) know. Jeff, what's your status? -- -Gene > From: Gene Cumm <gene.cumm at gmail.com> > To: jeff_sloan at selinc.com, > Cc: For discussion of Syslinux and tftp-hpa <syslinux at zytor.com>, > masotta <masottaus

On Wed, Jul 8, 2015 at 4:10 PM, <jeff_sloan at selinc.com> wrote: > Gene, > > I am very sorry. I did try the patch you suggested and had the same issue. > Then, I grabbed the latest patch on Patrick's git repo. That's the commit > that I listed. It was posted two days ago. > > I just noticed this on Patrick's repo: This branch is 6 commits ahead, 2 >

>>> Pseudo code:? Using the most recently used handle (the one holding Pxebc by default), attempt to create a service binding.? If unsuccessful, hunt for a handle that provides the target service binding and matches the MAC address. Best case, it's 1 binding attempt.? Worst case it's about N+1. -- -Gene <<< I see; on fail you fall back getting all handles

On 30/08/15 12:10, Gene Cumm via Syslinux wrote: > Those should produce debug text listing the original PxeBc handle and > its full MAC then proceed to list the UDPv4Sb handles and their MACs. > I'm still trying to figure out if there's a way to get the handle > numbers that the shells use. I looked into this for iPXE. From memory, it wasn't easily possible: the shell