On Mon, Aug 8, 2016 at 3:15 PM, Jim Dennis <j...@blockstream.io> wrote:
> > David, > > Thanks for the fast response. I have, since writing that, confirmed that > I > can boot at least one of these systems (Lenovo ThinkPad T410) using > pixiecore (running on my Mac laptop) when both systems are connected > to my home router (which, of course, provides DHCP). > > So that works. I'd like to suggest that you make this point more clear in > the README.md file (I can provide a pull request if you like). > A pull request would be most welcome, but failing that I'll get that done later this week. Thanks for the suggestion! > Another > possibility might be for you to add an option to pixiecore, perhaps built > on an compile time option to link to https://github.com/krolaw/dhcp4 ... > Richard Warburton's DHCP library (client and server support) written > in Go(lang). > Yeah, I'm thinking about various options. I'm still worried about using a Go dhcp4 package, because those don't have all the compatibility tweaks that battle-tested implementations like ISC dhcpd and dnsmasq have. My slight preference at this point would be to have a way to delegate to a local dnsmasq that Pixiecore runs as needed. Either way, it's clear this needs to happen. > > The other option I'm considering is Astralboot: > https://github.com/zignig/astralboot which seems to include the DHCP > server ... but which requires IPFS for the file distribution services. > Yeah, Astralboot is implementing a full DHCP server. This has several advantages, the biggest being that the network boot process is simplified when a single server provides network and boot configuration (fewer buggy clients). That's great if it's what you need, of course. My design goal with Pixiecore was to have something that I can drop into an existing network to add netbooting capabilities, without having to change any other network services (basically, I wanted a quick way to do one-off netboot installs on some machines on my LAN :) ). So in a sense Astralboot and Pixiecore are at odds on the fundamental problem they want to solve. I'll test those and write up my recommendations for my boss. > I'd be interested in your analysis once you're done, if you can/feel like sharing it. I think I already have all the "lessons learned" for Pixiecore from your messages so far, but I'm generally interested in the space, so it's useful to have additional inputs :). - Dave > > > On Mon, Aug 8, 2016 at 11:43 AM, David Anderson <d...@natulte.net> wrote: > >> On Sun, Aug 7, 2016 at 5:11 PM, <j...@blockstream.io> wrote: >> >>> >>> David, >>> >>> I'm confused by one part of this ... >>> >>> On Monday, September 14, 2015 at 8:18:23 PM UTC-7, David Anderson wrote: >>> >>> ... >>> >>> Of note is that Pixiecore does *not* require replacing or changing your >>>> existing DHCP server. Instead, Pixiecore uses a feature of the PXE spec >>>> (very poorly named "ProxyDHCP" - it's not a proxy, and it's barely DHCP) to >>>> complement the normal DHCP network configuration with PXE configurations >>>> for eligible clients, without directly interacting with the network's main >>>> DHCP server. Your non-PXE clients and your regular DHCPd are completely >>>> unaware of Pixiecore and don't need any reconfiguration. >>>> >>>> >>> ... if I'm reading correctly then it sounds like you're saying that >>> 'pixiecore' is NOT a DHCP server. That it's able to piggyback on DHCP >>> traffic (on a segment, within a given ethernet broadcast/collision >>> domain) to provide additional configuration data (using this "ProxyDHCP" >>> feature/spec.) which a PXE client can use for just the TFTP fetch >>> (bootloader -> kernel + initrd/initramfs chains)? >>> >>> If that's the case then, I guess it's necessary to have a separate DHCP >>> server on the network already? >>> >> >> That's correct. ProxyDHCP allows a third-party server to provide _just_ >> network booting information, while the network's primary DHCP server >> provides network configuration. The idea being that you can run Pixiecore >> on an existing DHCP-managed network without changing any other >> configurations. >> >> While at this point I probably know enough of DHCP to implement full DHCP >> support as well... I'm a bit resistant to doing so, because really good >> DHCP support is a huge can of worms in terms of supporting buggy >> implementations, and I'd much rather point people to dnsmasq if they need a >> quick and dirty DHCP server :). >> >> >>> (I've tried setting up multiple PXE clients on cross-over cables to my >>> MacOS X (10.11.5) running 'pixiecore' >>> (fc0d895c19e7c6a31f9d3b8ad5c8967d7285ef87 >>> from Feb 28, 2016) and the "tinycorelinux" configuration as described in >>> the github >>> pages. When running it I get messages like: >>> >>> [ProxyDHCP] Couldn't find an IP address to use to reply to >>> f0:de:f1:3b:b9:65: interface en5 has no usable unicast addresses >>> >>> [ProxyDHCP] Offering to boot f0:de:f1:3b:b9:65 (via 172.17.17.1) >>> >>> [ProxyDHCP] Responding to f0:de:f1:3b:b9:65: write udp4 0.0.0.0:67-> >>> 255.255.255.255:68: sendmsg: network is unreachable >>> >>> >>> ... after having statically configure the en5 (thunderbolt connect >>> ethernet cable to the other systems (I've tried four different systems, at >>> least two of which I've PXE booted into Linux using the traditional >>> ISC/Linux tools and configuration in the past). I've done this with and >>> without ethernet cross-over cabling (many ethernet adapters know support >>> auto-MDI crossing) and I've done with direct and through an old, simple, >>> Netgear switch ... but always with no DHCP server on that segment! >>> >> >> The initial error you're getting is that Pixiecore can't find a usable >> source IP address on en5. It needs that address to transmit the ProxyDHCP >> response. Do you have any IPs configured on en5? >> >> >>> I'll try again with a DHCP server to see if that works. But you might >>> make it clear in the docs if 'pixiecore' REQUIRES a separate DHCP server, >>> or perhaps add an option to detect and optionally provide DHCP services. >>> >> >> Are you connecting your machine directly to a system that you need to >> boot? If that's the case, you'll run into a separate issue if you try to >> run both Pixiecore and a DHCP server on the same machine, which is that >> they both want to bind to the DHCP server port, and so one of them will >> fail. I have a working solution for that on linux using some raw socket >> trickery, but since I have no macs, I don't have an answer for your setup >> yet :(. >> >> The closest thing to an answer I have is to make sure you connect both >> the machine running Pixiecore and the system you're trying to boot to an >> ethernet broadcast domain that already has DHCP services provided by some >> other machine. I'm very much aware that this isn't great, and I'll now go >> off and think about how to improve that. >> >> - Dave >> >> >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "golang-nuts" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to golang-nuts+unsubscr...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
