search for: 0065f36e00ee

...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 0065F36E00EE 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". > UDPv4ServiceBinding handle 23E -> MAC 5065F36E00EE >...

Sorry guys; I got a bit lost about Gene's request on this thread; usually a handle dump like # dh > handles.txt it's all we need to see the relationship between the NBP's device handle and the Service Binding handles. Did you get handles.txt? is it available for download somewhere? >>> Gene, after modifying some of Patrick's code I have been able to get the

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

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

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

...e: >> >>>> >> > 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 &gt...

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 =

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

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

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

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.

...;> >> >> >> > nibble >> >> >> >> >> >> > (11 characters, not 12). Handle 267 shows "065F36E00EE" >> >> >> >> >> >> > not >> >> >> >> >> >> > "0065F36E00EE". >> >> >> >> >> >> > <<< >> >> >> >> >> >> > >> >> >> >> >> >> > I saw that, they might even be making a mistake when >> >> >> >> >> &gt...