Re: [ipxe-devel] [ipxe/ipxe] successful wpa handshake (memcmp polarity) (#103)
I haven't contributed to iPXE in many years, so I don't have write access to the Github repo, but this PR looks good to me. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/ipxe/ipxe/pull/103#issuecomment-574368989___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo/ipxe-devel
Re: [ipxe-devel] [ipxe/ipxe] successful wpa handshake (memcmp polarity) (#103)
I wrote the original WPA code in 2009, and definitely successfully booted with it at that time. It looks like the incorrect-polarity memcmp() was only introduced in 2014: https://github.com/ipxe/ipxe/commit/8ee39f7432e63c2382ab3e7d24e234310f4532c9 -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/ipxe/ipxe/pull/103#issuecomment-574368260___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo/ipxe-devel
Re: [ipxe-devel] Pre-embedding a kernel within ipxe.pxe?
On Sat, Dec 22, 2012 at 11:19 PM, Matthew Helton mwhel...@gmail.com wrote:
The stray thought occured to me that instead of scripting
whitelists/blacklists by system model, or relying on external detection
methods (Syslinux or HDT) for NICs, could be ipxe.pxe be altered to carry an
alternate kernel within itself?
The concept would be that as part of the ipxe.pxe binary; it already has
undionly.kpxe embedded within it.
That way, if we do a simple check to see if the native iPXE can detect a
NIC, and if it fails we have a way to back out of it.
Example:
isset ${net0/mac:hexhyp} goto next || boot undionly.kpxe
Am I insane?
Sure, you can embed undionly.kpxe in ipxe.pxe in the same way you'd
embed a script - but ipxe.pxe already includes all drivers including
the UNDI driver. While I haven't tested it, I believe you should be
able to build ipxe.kpxe and have it automatically use a native driver
if one is available, an UNDI driver if not.
Josh
Matt
--
There is never time enough to do it right, but there always seems to be
enough time to do it again.
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
Re: [ipxe-devel] debug able modules
On Thu, Oct 18, 2012 at 2:28 PM, Kalpesh Patel kalpesh.pa...@glgroup.com wrote: Hi, Is there a comprehensive list of modules that can be built with debug turned on? In particular, I am looking for additional non-hardware modules that can be included: Hi Kalpesh, Every source file in the iPXE tree is a legitimate target for the DEBUG option. You enable debug statements in whatever.c by including DEBUG=whatever. Not all files have debug statements in them, so in some cases this will be a no-op. Hope this helps, Josh # cd ipxe/src # make DEBUG=http,scsi,iscsi,dns.tftp,aoe,bzimage,dhcp,… Thanks. This e-mail message, and any attachments, is intended only for the use of the individual or entity identified in the alias address of this message and may contain information that is confidential, privileged and subject to legal restrictions and penalties regarding its unauthorized disclosure and use. Any unauthorized review, copying, disclosure, use or distribution is strictly prohibited. If you have received this e-mail message in error, please notify the sender immediately by reply e-mail and delete this message, and any attachments, from your system. Thank you. ___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel ___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
Re: [ipxe-devel] vmxnet3 port
On Thu, Jan 5, 2012 at 12:22 AM, Pete Holland phollan...@gmail.com wrote: So I'm working on a port of the vmxnet3 driver to ipxe (mainly because the default pxe client in ESX is not suitable for my needs). One problem I've run into is that the vmxnet3 driver seems to require far more memory (by default somewhere between 1-2 MB) from the heap than ipxe normally has (128K) for setting up all of its DMA structures. I am currently hacking malloc.c to up the heap size but I'm wondering if there is a 'correct' way of doing this in terms of ipxe development (since, if I'm successful, I'd like to contribute the port to the project). [Disclaimer: it's been a while since I've worked significantly on iPXE, although I used to be a pretty active developer.] This is definitely an issue that's come up before, e.g. with Infiniband drivers that require several megabytes of memory to store their firmware. There are technical reasons why iPXE's heap is as small as it is, so increasing its size dramatically is, unfortunately, likely to make your patch unsuitable for general inclusion. I'm not familiar with vmxnet specifically, but oftentimes the size of the DMA ring can be dramatically reduced from what would be typical in an OS network driver. iPXE won't need more than about 16 TX or RX descriptors at once, whereas I've seen Linux drivers allocate 512 or more of each. This might allow you to make the DMA allocations within the confines of iPXE's heap. That said, there are definitely some drivers that have a rather large minimum ring size, and for which this method won't work. If you do need lots of memory for your driver, you can use the umalloc()/ufree() allocator instead of malloc()/free(). This allocates memory external to iPXE's heap; the same facility is used to store images that have been fetched but not yet executed. You get a user pointer (typedefed integer type) instead of a real pointer, to allow iPXE to run on architectures that don't allow this external memory to be directly addressed (e.g. segmented 16-bit x86). There are functions such as copy_from_user() and user_to_phys() that allow you to work with these user pointers in a way that doesn't sacrifice portability. The second problem is that I am at the point where I have set up the BARs correctly (as I can read/write the MAC address, link state is readable, and resetting the device seems to jigger some logs into vmware.log indicating that it is successfully doing the reset), however 'activating' the device fails (with no indication in vmware.log or hostd.log as to why). At this point, I'm about to go hat-in-hand to the vmware dev responsible for the Linux vmxnet3 driver for some insight, but I figured I'd ask if anyone else here has tried this before, heard of anyone trying this, or otherwise has a thought on the matter. Unfortunately, much hardware (real and virtual) is quite finicky about the exact manner in which it's initialized. Being unfamiliar with the specifics of vmxnet, I can only suggest triple-checking you're doing everything necessary in exactly the right way, and wish you the best of luck. Hope this helps, Josh Cheers, Pete ___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo/ipxe-devel ___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo/ipxe-devel
[ipxe-devel] One ROM, multiple PCI IDs
On Sat, Jul 31, 2010 at 3:08 AM, Stefan Hajnoczi stefanha at gmail.com wrote: Josh: I have CCed you explicitly because I think you had ideas on this some time ago. The question of multiple PCI IDs for a single gPXE ROM came up recently on IRC. ?It can be useful to have a single gPXE ROM file that works on multiple PCI devices that have different IDs. I reviewed the PnP, BBS, and PCI 3.0 Firmware specifications to check whether it is possible or not. ?The constraints end up making general-purpose multiple PCI ID ROMs infeasible. ?I think it is not worth pursuing this unless these ROMs can be widely used. Have we gotten a lot of requests for this feature? I'm under the impression that most cases of I want to make a single ROM and flash it on every machine in my cluster involve fairly homogeneous setups. The approaches I found are: 1. PCI 3.0 device ID list. ?The PCI 3.0 Data Structure includes a Device List pointer allowing a ROM to advertise support for additional *device* IDs. ?Two limitations here: only additional device IDs may be used, not vendor IDs, and the BIOS needs to have PCI 3.0 Firmware support. This could work well in the fairly homogeneous case I mentioned. We could extend the build system such that make bin/8086.rom would make a ROM with support for all the e1000 variants (though that particular case would also pull in e1000e and e1000igb and generally be infeasibly large). 2. Using multiple ROM headers. ?This means providing multiple expansion ROM headers within the ROM so the BIOS can pick an applicable one. ?However, each header must start on a 512-byte boundary and I don't see a reasonable way to share the compressed gPXE image between multiple ROM headers. ?There will not be enough space to accommodate multiple (duplicate) images, and the alternative is a more complex loader that tries to fetch gPXE as a second stage payload from the PCI expansion ROM (which is known to be tricky). Using the .mrom facility that Michael contributed, this would be feasible for small sets of ROMs from a size perspective. Thoughts? I actually haven't thought about this use case that much. I think both possibilities are tractable, but like you suggest, probably not worth the effort unless someone would use them extensively. A much simpler alternative that would cover many of the same use cases would be to restore the functionality that used to be in modrom.pl of rebranding the ROM device:vendor IDs post-build. -- Josh
