[syslinux] HP EFI binaries

Derrick derrick22 at gmail.com
Sun Aug 30 17:42:07 PDT 2015


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:
> > 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
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
>


More information about the Syslinux mailing list