[syslinux] HP EFI binaries

[Gene Cumm]

On Mon, Aug 31, 2015 at 2:49 PM, Derrick M <derrick.martinez at gmail.com> wrote:
> Gene,
>
> Also, I wanted to point out there the code is freezing at in main.c. It's
> right at load_env32(NULL); at that point status has a numerical value of 6.

That's excellent to know.  Thanks.

> On Mon, Aug 31, 2015 at 3:08 AM, Gene Cumm <gene.cumm at gmail.com> wrote:
>>
>> On Aug 30, 2015 8:42 PM, "Derrick" <derrick22 at gmail.com> wrote:
>> >
>> > 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

Figured out I had a bug when thinking about that output.

https://sites.google.com/site/genecsyslinux/150831-efi.tgz?attredirects=0&d=1
will show the proper iterations over the handles.

-- 
-Gene

>> > From that point it is hung
>>
>> I find it hard to believe that it'd print that.  I think you did a
>> copy/paste and forgot to update and trimmed some data.
>>
>> Does your HP DL160 G9 have an iLO with remote KVM function?  If not and
>> you feel a screenshot from a real camera is too big for the list, feel free
>> to send it to me directly.
>>
>> --Gene
>>
>> > 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:
>> >> > Gene,
>> >> >
>> >> > Your binaries didn't work for me, however I put some code in to print
>> >> > the
>> >> > byes of mac1 and mac2. In efi_create_binding() it does go through all
>> >> > of the
>> >> > macs looking for the correct one and then finds a 100% match. In this
>> >> > case
>> >> > the mac is 8c-dc-d4-0d-a5-f0 so && memcmp(mac_1, mac_2,
>> >> > PXE_MAC_LENGTH) ==
>> >> > 0) { is correct
>> >>
>> >>
>> >> https://sites.google.com/site/genecsyslinux/150829-efi-1136.tgz?attredirects=0&d=1
>> >>
>> >> 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.
>> >>
>> >> > On Fri, Aug 28, 2015 at 3:46 AM, Gene Cumm <gene.cumm at gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> On Fri, Aug 28, 2015 at 6:34 AM, Patrick Masotta
>> >> >> <masottaus at yahoo.com>
>> >> >> wrote:
>> >> >> >>>>
>> >> >> >  More importantly: look at the actual captured text.  It does NOT
>> >> >> >  specify a valid MAC in its entirety and leaves off the leading
>> >> >> > nibble
>> >> >> >  (11 characters, not 12).  Handle 267 shows "065F36E00EE" not
>> >> >> > "0065F36E00EE".
>> >> >> >  <<<
>> >> >> >
>> >> >> > I saw that, they might even be making a mistake when implementing
>> >> >> > the Device Path protocol.
>> >> >> >
>> >> >> >  >>>
>> >> >> >  It is possible that this is a visual bug but it DOES give a hint
>> >> >> > that
>> >> >> >  there may be an issue in the MAC addresses.
>> >> >> > <<<
>> >> >> >
>> >> >> > It has to be more than visual; if not the code would've got a
>> >> >> > match.
>> >> >> >
>> >> >> > Probably they do not change the MAC but they make a mistake
>> >> >> > with the MAC Address Device Path. Anyway; it's a buggy EFI
>> >> >> > implementation that breaks the multi-nic approach.
>> >> >> >
>> >> >> >
>> >> >> >>>>
>> >> >> >   Derrick is already running the latest firmware on this machine.
>> >> >> > <<<
>> >> >> >
>> >> >> > sorry didn't know.
>> >> >> >
>> >> >> > Derrick ,
>> >> >> > you could try this as a ""hack"" for probably solving your
>> >> >> > problem:
>> >> >> > -        && memcmp(mac_1, mac_2, PXE_MAC_LENGTH) == 0) {
>> >> >> >
>> >> >> > +       && memcmp(mac_1 + 1, mac_2 + 1, 5) == 0) {
>> >> >> > **or alternatively**  (I do not remember now if the 6 bytes of the
>> >> >> > MAC
>> >> >> > go at front or back of the 32 bytes string
>> >> >> > +       && memcmp(mac_1 + PXE_MAC_LENGTH - 5, mac_2 +
>> >> >> > PXE_MAC_LENGTH -
>> >> >> > 5, 5) == 0) {
>> >> >> > at efi/main.c\efi_create_binding()
>> >> >> >
>> >> >> >
>> >> >> > this change will only look after the last 5 bytes of the HP MAC
>> >> >> > address
>> >> >> > for a match,
>> >> >> > considering they really are using a MAC length of PXE_MAC_LENGTH
>> >> >> > (32
>> >> >> > bytes) on the
>> >> >> > MAC representation of the MAC Address Device Path (who knows..)
>> >> >>
>> >> >> I sent Patrick and Derrick a copy of some binaries with a quick hack
>> >> >> to print the entire MAC on the first attempt to use a UDPv4Sb where
>> >> >> the PxeBc and UDPv4Sb don't live on the same handle.
>> >> >>
>> >> >> --
>> >> >> -Gene
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> -Gene