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 hungOn 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 >
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 > > From that point it is hungI 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 printthe>> > byes of mac1 and mac2. In efi_create_binding() it does go through allof the>> > macs looking for the correct one and then finds a 100% match. In thiscase>> > 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 leadingnibble>> >> > (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 hintthat>> >> > 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 theMAC>> >> > 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 MACaddress>> >> > 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 > >
On Mon, Aug 31, 2015 at 06:08:19AM -0400, Gene Cumm via Syslinux 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 > > > > 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, 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.