search for: mac_1

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

...| eth0 (no IP) ________|________ | | | br0 | | (no IP) | |_________________| tap0 | | tap1 192.168.40.1/24 | | 192.168.30.1/24 MAC_0 | | MAC_1 __|________|__ | | | PC | | | |______________| I would need this picture to be equivalent to this one: LAN__________________________________ eth0 | | eth1 192.168.40.1...

...39;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...

...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_LEN...

...> 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 t...

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 =

...;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 UD...

...gt; 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...

On Mon, Aug 31, 2015 at 07:59:06PM -0400, Gene Cumm via Syslinux wrote: > On Mon, Aug 31, 2015 at 6:42 PM, Derrick M <derrick.martinez at gmail.com> wrote: > > Thanks Gene! > > > > this one is much better > > EXCELLENT! That's what I wanted to see. It iterates through 3 > handles, printing the entire MAC buffer and the handle's memory > address.

...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) {...

...t;> >> >> > 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 >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> &gt...

From: Sylvain Gault <sylvain.gault at gmail.com> I don't know if I should merge those trivial warning fix into one commit. I can reformat it as requested. Those are a few warning fixes for the efi part. The code involved has mainly been introduced in recent commits. Sylvain Gault (3): efi: fix warnings about argument types efi: fix pointer-type mismatch assigment warning efi: fix

...ith them too (I didn't see anything) >>> 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 <<< mmmhh that means there's a match considering the 32 bytes of the MAC (PXE_MAC_LENGTH) then you don need the previous hack considering only the last 5 bytes of the MAC; and what happens after the match? do you get EFI_SUCCESS when trying t...

...t;status != EFI_SUCCESS" to avoid de-referencing an undefined pointer (sbp->CreateChild) in the next code line. ... for (i = 0; i < nr_handles; i++) { DevicePath = DevicePathFromHandle(handles[i]); if (efi_get_MAC(DevicePath, &mac_2, PXE_MAC_LENGTH) && memcmp(mac_1, mac_2, PXE_MAC_LENGTH) == 0) { sb_handle = handles[i]; status = uefi_call_wrapper(BS->OpenProtocol, 6, sb_handle, bguid, (void **)&sbp, image_handle, sb_handle, EFI_OPEN_PROTOCOL_GET_PROTOCOL); if (status == EFI_SUCCESS) { mnpsb_handle = sb_handle; break;...

...undefined pointer (sbp->CreateChild) in the next code line. > > ... > for (i = 0; i < nr_handles; i++) { > DevicePath = DevicePathFromHandle(handles[i]); > if (efi_get_MAC(DevicePath, &mac_2, PXE_MAC_LENGTH) > && memcmp(mac_1, mac_2, PXE_MAC_LENGTH) == 0) { > sb_handle = handles[i]; > status = uefi_call_wrapper(BS->OpenProtocol, 6, sb_handle, > bguid, (void **)&sbp, > image_handle, sb_handl...

...them too (I didn't see anything) > > 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 > <<< > > mmmhh that means there's a match considering the 32 bytes of the MAC (PXE_MAC_LENGTH) > then you don need the previous hack considering only the last 5 bytes of the MAC; > and what happens after the match? do you get...

On Wed, Jul 8, 2015 at 7:34 PM, Gene Cumm <gene.cumm at gmail.com> wrote: > What about the observed symptoms? Have you performed an inline packet Jeff, there's specific code that creates specific responses that if you had mentioned what you saw, I'd expect we could have seen something sooner. -- -Gene