similar to: HP EFI binaries

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:

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

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 =

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

>>> Jeff, Patrick: Could you try my code from my github repo branch efi-multinic?? It's derived from Patrick's code and I finally see good responses with a VMware VM's e1000e NIC (never saw ANYTHING good from it until now). git://github.com/geneC/syslinux.git https://github.com/geneC/syslinux.git -- -Gene <<< Hi there I think in the case of a particular

Patrick Yes it looks like EFI_SUCCESS is true. There is a line if status == EFI_SUCCESS and status is 0 so it continues On Aug 29, 2015, at 01:00, Patrick Masotta via Syslinux <syslinux at zytor.com> wrote: > Gene, > Your binaries didn't work for me, > <<< > I had problems with them too (I didn't see anything) > > however I put some code in to print

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.

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 &&

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

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. Looks like it's merely a visual display bug. > On Mon, Aug 31, 2015 at 3:11 PM, Gene Cumm <gene.cumm

On Tue, Sep 1, 2015 at 11:36 PM, Derrick M <derrick.martinez at gmail.com> wrote: > Gene > > I have tried to sleep 75 seconds right before the spawn_load() call just to > wait if it wasn't ready yet to send. Also according to tcpdump there are no > RRQ packets to the tftp server from syslinux. (only the initial > syslinux.efi) Where are you doing the capture? I find

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

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

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

On Wed, Jul 22, 2015 at 5:13 AM, Patrick Masotta <masottaus at yahoo.com> wrote: >>>> > Jeff, Patrick: Could you try my code from my github repo branch > efi-multinic? It's derived from Patrick's code and I finally see good > responses with a VMware VM's e1000e NIC (never saw ANYTHING good from > it until now). > >

hello list i got the following pb: # xm create -f mac1/mac1.xen Using config file "mac1/mac1.xen". Error: Error creating domain: vbd: Segment not found: uname=file:/xen/mac1/swapfs but: # dmesg | grep loop loop: loaded (max 32 devices) # ls -l /xen/mac1/swapfs -rw-r--r-- 1 root root 268435457 2005-04-12 11:25 /xen/mac1/swapfs # xm list Name Id Mem(MB) CPU State

Hi all. I would need to use a single physical interface on a Linux box to manage two different IP addresses (belonging to two separate logical subnets) with two different MAC address. (I need to emulate te presence of two separate physical interfaceses for a PC on the same LAN, at layer 2 and layer 3). Is it possible to use the linux ethernet bridging code and two tap interfaces for this

Hello. At a customer's site I had: _ Windows 2008 DC; _ Samba 4.8 fileserver on FreeBSD 11.3/amd64 on UFS; _ several Windows and Mac clients. Recently, having to move to Samba 4.10, I decided to bring up a new fileserver in a jail (and let the base 4.8 one die after transferring all shares). I have no problems with Windows clients, but several strange things are happening with Macs.

Ubuntu Samba server running Version 3.4.0 Most windows and OS X clients connect with no issues. Permissions are working correctly on shares and umask settings are working on Window 7, OS X, and XP. The annoying mystery here is that these little bugs are annoying users and taking up precious time... Most recently, Mac1 (OS X 10.6.5 smb Version 3.0.28a-apple) is able to change a directory's

The variable 'ok' is never used and generates a warning. Remove it. Also ntfssect.c is designed to be compiled in non Unicode mode when using MSVC compilers, so remove all ambiguity about it (LPCTSTR -> LPCSTR, use of 'A' API calls) so that it doesn't break when compiled in Unicode mode, which is what Rufus uses with MSVC. -------------- next part --------------