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.
