On Fri, Aug 28, 2015 at 4:22 AM, Patrick Masotta <masottaus at yahoo.com> wrote:> Thanks Derrik; I got your efi-dh.txt > > I've found this: > > 252: SimpleNetwork PXEBaseCode LoadFile DevicePath(0000:0000:0000:0000:0000:0000)) > 267: SimpleNetwork PXEBaseCode LoadFile DevicePath(065F36E00EE,0x1)/IPv4(0.0.0.0)) > 27C: SimpleNetwork PXEBaseCode LoadFile DevicePath(0000:0000:0000:0000:0000:0000)) > 291: SimpleNetwork PXEBaseCode LoadFile DevicePath(065F36E00EF,0x1)/IPv4(0.0.0.0)) > 2A6: SimpleNetwork PXEBaseCode LoadFile DevicePath(0000:0000:0000:0000:0000:0000)) > 2BB: SimpleNetwork PXEBaseCode LoadFile DevicePath(CDCD40CA5F0,0x0)/IPv4(0.0.0.0)) > 2D0: SimpleNetwork PXEBaseCode LoadFile DevicePath(0000:0000:0000:0000:0000:0000)) > 2E5: SimpleNetwork PXEBaseCode LoadFile DevicePath(CDCD40CA5F4,0x0)/IPv4(0.0.0.0)) > > 23E: MTFTPv4ServiceBinding DHCPv4ServiceBinding UDPv4ServiceBinding UnknownDevice TCPv4ServiceBinding IPv4ServiceBinding ARPServiceBinding UnknownDevice EfiMtftp6ServiceBindingProtocolGuid IPv4Config EfiDhcp6ServiceBindingProtocolGuid EfiUdp6ServiceBindingProtocolGuid UnknownDevice EfiTcp6ServiceBindingProtocolGuid EfiIp6ConfigProtocolGuid EfiIp6ServiceBindingProtocolGuid ManagedNetworkServiceBinding EfiVlanConfigProtocolGuid SimpleNetwork HIIConfigAccess AdapterInfo(AdapterInfo) > EfiFirmwareManagementProtocolGuid UnknownDevice UnknownDevice NetworkInterfaceIdentifier31 UnknownDevice DevicePath(0x0,0x0)/MAC(5065F36E00EE,0x1)) > UnknownDevice > > 268: MTFTPv4ServiceBinding DHCPv4ServiceBinding UDPv4ServiceBinding UnknownDevice TCPv4ServiceBinding IPv4ServiceBinding ARPServiceBinding UnknownDevice EfiMtftp6ServiceBindingProtocolGuid IPv4Config EfiDhcp6ServiceBindingProtocolGuid EfiUdp6ServiceBindingProtocolGuid UnknownDevice EfiTcp6ServiceBindingProtocolGuid EfiIp6ConfigProtocolGuid EfiIp6ServiceBindingProtocolGuid ManagedNetworkServiceBinding EfiVlanConfigProtocolGuid SimpleNetwork HIIConfigAccess AdapterInfo(AdapterInfo) > UnknownDevice UnknownDevice NetworkInterfaceIdentifier31 UnknownDevice DevicePath(0x0,0x1)/MAC(5065F36E00EF,0x1)) > UnknownDevice > > 292: MTFTPv4ServiceBinding DHCPv4ServiceBinding UDPv4ServiceBinding UnknownDevice TCPv4ServiceBinding IPv4ServiceBinding ARPServiceBinding UnknownDevice EfiMtftp6ServiceBindingProtocolGuid IPv4Config EfiDhcp6ServiceBindingProtocolGuid EfiUdp6ServiceBindingProtocolGuid UnknownDevice EfiTcp6ServiceBindingProtocolGuid EfiIp6ConfigProtocolGuid EfiIp6ServiceBindingProtocolGuid ManagedNetworkServiceBinding EfiVlanConfigProtocolGuid SimpleNetwork HIIConfigAccess EfiFirmwareManagementProtocolGuid AdapterInfo(AdapterInfo) > EfiDriverHealthProtocolGuid UnknownDevice UnknownDevice DevicePath(0x0,0x0)/MAC(8CDCD40CA5F0,0x0)) > NetworkInterfaceIdentifier NetworkInterfaceIdentifier31 > > 2BC: MTFTPv4ServiceBinding DHCPv4ServiceBinding UDPv4ServiceBinding UnknownDevice TCPv4ServiceBinding IPv4ServiceBinding ARPServiceBinding UnknownDevice EfiMtftp6ServiceBindingProtocolGuid IPv4Config EfiDhcp6ServiceBindingProtocolGuid EfiUdp6ServiceBindingProtocolGuid UnknownDevice EfiTcp6ServiceBindingProtocolGuid EfiIp6ConfigProtocolGuid EfiIp6ServiceBindingProtocolGuid ManagedNetworkServiceBinding EfiVlanConfigProtocolGuid SimpleNetwork HIIConfigAccess EfiFirmwareManagementProtocolGuid AdapterInfo(AdapterInfo) > EfiDriverHealthProtocolGuid UnknownDevice UnknownDevice DevicePath(0x0,0x1)/MAC(8CDCD40CA5F4,0x0)) > NetworkInterfaceIdentifier NetworkInterfaceIdentifier31 > > > Then we have: > > 1) Handles 267,291,2BB,2E5 > correspond to the IPv4 PXEBaseCode protocols (one handle per NIC in your system). > one of these handles is used every time you boot syslinux.efi as NBP. > > 2) Handles 252,27C,2A6,2D0 > idem before but for IPv6 (ignore them) > > 3) Handles 23E,268,292,2BC > correspond (among other things) to the Service Binding protocols we are looking for (UDPv4ServiceBinding) > (one handle per NIC in your system) > > > The goal: > We must bind the UDPv4ServiceBinding handle that has a matching MAC with the PXEBaseCode used for > booting syslinux.efi > > > The problem: > It is supposed there's always a possible MAC match between PXEBaseCode and UDPv4ServiceBinding protocols, > but this does not happen in what I consider your faulty FW. > i.e. > if we consider > PXEBaseCode handle 267 -> MAC 0065F36E00EEMore 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".> UDPv4ServiceBinding handle 23E -> MAC 5065F36E00EE > > You can see the MACs are "almost" identical but there's not match! > While 5065F36E00EE is a valid HP MAC, 0065F36E00EE is not. > something identical happens with the rest of handle pairs. > > My code relies on a full MAC match in order to decide which UDPv4ServiceBinding to use. > Of course in your case you'll get an error; there's never a suitable UDPv4ServiceBinding available. > I do not know why on earth HP uses different MACs for the same hardware, they are even changing > their MAC vendor signature!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.> I can only think you are running a test version of the FW where the different MAC signatures > are probably used at the DHCP/PXE server side to know what protocol is the client using for transfers > (just a shot in the dark guess). > > Conclusion: > I think you should update your firmware. IMHO it does not make sense to mod Syslinux code in order to > catch this issue.Derrick is already running the latest firmware on this machine. -- -Gene
>>>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..) Best, Patrick
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
On Fri, Aug 28, 2015 at 03:34:12AM -0700, Patrick Masotta via Syslinux wrote: Derrick 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() >Thanks Patrick. && memcmp(mac_1 + PXE_MAC_LENGTH - 5, mac_2 + PXE_MAC_LENGTH - 5, 5) == 0) { was the code that was able to make a match the mac. It is getting further, now the messages are core_udp_sendto: stalling on configure with no mapping
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 correcthttps://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
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 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 handle numbers conceptually exist only within that invocation of the shell, and don't represent any property of the underlying handle. If it helps, http://git.ipxe.org/ipxe.git/blob/HEAD:/src/interface/efi/efi_debug.c shows the code that iPXE uses to dump out meaningful labels for arbitrary handles. This generates names such as: PciRoot(0x0)/Pci(0x3,0x0)/MAC(525400123456,0x1) ConIn wdsmgfw and when no descriptive naming scheme can be found, falls back to dumping the raw handle and a list of installed protocols, such as UNKNOWN<0x3f0df318,SimpleTextIn,SimpleTextInEx> Michael