In order to use DHCP, you need to install the ifupdown and isc-dhcp-client packages, and manually create the following symbolic link:

# ln -s ../rcS.d/S10networking /etc/rc.boot/

During execution at boot time, the S10networking script will emit some error messages while trying to configure the loopback interface. These are not fatal.

Debian GNU/Hurd doesn't currently execute Debian standard /etc/rcS.d/* boot scripts, but has its own /libexec/rc script -- which integrates scripts from /etc/rc.boot/ instead.

Open Issues

  • Debian bug #616290

  • Proper Hurdy DHCP support

  • dhclient aborting with a stack smashing error

    IRC, freenode, #hurd, 2013-08-21:

    <teythoon> yay, I fixed the path of the dhcp leases file...
    <teythoon> ... and now dhclient dies of a buffer overflow
    <teythoon> fortunately the fix is rather simple, anyone who cares about
      the security of his box just has to stop using isc software
    <teythoon> the code is full of stuff like char foo[100]; /* surely
      that's enough */
    <pinotree> note that our version of isc-dchp (the one in ports) is
      older than the latest one available in unstable (which is still older
      than the latest upstream releases)
    <teythoon> so?
    <pinotree> dunno, might have been fixed or not
    <teythoon> ^^ yeah sure
    <gnu_srs> A lot of software has these limitations and PATH_MAX,
      MAXPATHLEN issues :(
    <pinotree> having a limitation is not a problem per-se
    <teythoon> no, only software written in c has these kind of problems
    <pinotree> the problem is not checking whether the limits are hit
    <teythoon> well, looking at the source of isc-dhcp my time is better
      spent making another dhcp client work on hurd
    <teythoon> also reading up on bug #616290 does make me want to avoid
      touching it ever
    <braunr> hehe
    <gnu_srs> teythoon: somebody was offering an alternative to the isc
      dhcpclient, but I think it was rejected by Samuel?
    <teythoon> why would he do that?
    <braunr> probably for compliance
    <gnu_srs> He probably thought they would release a new version soon, is
      4.3.0 out yet?
    <teythoon> well, as soon as my fixes for ifupdown go in, dhclient will
      start crashing
    <teythoon> no, there is no new version released
    <teythoon> no major one that is
    <teythoon> 4.2.5 is out
    <gnu_srs> can't you just increase the buffer size, where is the problem
      exactly?
    <teythoon> I have no idea
    <gnu_srs> The Hurd patches are not in 4.2.5, they were promised for
      4.3.0a1. 
    <gnu_srs> Still the buffer overflow problem might be present in 4.2.5
      if patched to build on Hurd.
    <braunr> there, darnassus now has a fully featured git/gitweb service
    <teythoon> :)
    <teythoon> btw, I managed to reproduce the crash reliably
    <teythoon> rm /var/lib/dhcp/*; dhclient -v /dev/eth0  ... *boom*
    <teythoon> ditch the -v, everything works, and now that there is a
      lease file, you can add the -v again and it works
    <braunr> ew :)
    <teythoon> and what has dhclient.c to say for its defense?
    <teythoon> log_info("%s", "");
    <teythoon> hm, not much :/
    

    IRC, freenode, #hurd, 2013-08-22:

    <teythoon> uh, the isc-dhcp situation is a huge pita, the source on
      -ports does not compile anymore :/
    

    IRC, freenode, #hurd, 2013-08-23:

    <gnu_srs> teythoon: Was it the slash in the network interface names
      that caused the buffer overflow in dhclient? 
    <teythoon> gnu_srs: no, previously no dhcp leases file was written and
      everything was fine
    <pinotree> teythoon: did you really develop your patch against that old
      version of ifupdown?
    <teythoon> gnu_srs: now it is written, and for some reason dhclient
      crashes *iff* -v is given *and* there is no previous lease file
    <teythoon> pinotree: no, I did not. that was only reportbug including
      information from my desktop machine without asking me
    <teythoon> but when I first looked at ifupdown it was still a 6000
      lines noweb file >,<
    <teythoon> that was fun
    <pinotree> which version is it against?
    <teythoon> hg tip
    

    IRC, freenode, #hurd, 2013-08-30:

    <tschwinge> teythoon: I understand correctly that you found that
      id:"874ngfvwn4.fsf@kepler.schwinge.homeip.net" in fact was really
      "just" a buffer overflow in the dhclient code?
    <teythoon> tschwinge: ah, most interesting, I didn't realize that you
      stumbled across this as well
    <teythoon> to be honest I don't know what's going on there, I only
      observed what I wrote in my report
    <teythoon> for me it started crashing once the lease file was actually
      a valid path (i.e. not to a non-existing directory b/c of the slashes
      in /dev/eth0)
    <teythoon> I tried to rebuild the package served on debian-ports, but
      that failed
    

    IRC, freenode, #hurd, 2014-01-03:

    <congzhang> dhcp 4.3 alpha released
    <congzhang> and PATH_MAX issue was fixed
    

    IRC, freenode, #hurd, 2014-01-21:

    <gnu_srs> teythoon: what about this?  *** stack smashing detected ***:
      dhclient terminated
    <teythoon> gnu_srs: well, dhclient dies
    <teythoon> i've seen this, it comes and goes
    <teythoon> not sure what happens, but i tend to blame it on our
      custom-built dhcp package
    <teythoon> from debian-ports, and it's outdated
    <teythoon> it's most likely not your fault
    <gnu_srs> i thought there was a new upstream by now
    <teythoon> and the network configuration can be done with passive
      translators as it was always done
    <teythoon> there was ?
    <gnu_srs> there is one recently released, haven't checked yet
    <gnu_srs> in experimental: 4.3.0a1-2, does still not build out of the
      box
    <teythoon> there was, but it does not seem to build on the hurd
    <teythoon>
      https://buildd.debian.org/status/logs.php?pkg=isc-dhcp&arch=hurd-i386
    <teythoon> the most recent version is from debian-ports
    

    IRC, freenode, #hurd, 2014-01-24:

    <braunr> stack smashing detected ***: dhclient terminated
    <braunr> how nice
    <tschwinge> braunr: dhclient:
      http://news.gmane.org/find-root.php?message_id=%3C874ngfvwn4.fsf%40kepler.schwinge.homeip.net%3E
    <tschwinge> braunr: And I thought, teythoon had found this to be a
      buffer overflow; something like char dev[10], and for us the path to
      the dev (/dev/eth0) was longer (but I may be misremebering).
    <braunr> tschwinge: sounds reasonable
    <tschwinge> braunr: By the way: I'm seeing this segfault all the time
      during boot, but when I again run it manually (root login), it works
      fine.
    <braunr> tschwinge: you mean the dhclient one µ?
    <tschwinge> Yes.
    <braunr> mhm
    <teythoon> braunr, tschwinge: i never found the cause of the dhclient
      issue
    <teythoon> i blame the (outdated) build on debian-ports
    

    IRC, freenode, #hurd, 2014-01-30:

    <youpi> err, still nobody found the dhclient bug?
    <gnu_srs> youpi: You found the dh-client bug, right?
    <youpi> gnu_srs: yes, the dhclient bug was in libc, as tschwinge
      guessed
    <youpi> I'll probably upload a fixed glibc on debian-ports
    
    
    <gnu_srs> youpi: dhclient starts OK with libc 2.17-98~0
    
    
    <youpi> btw, the experimental version of isc-dhcp has a newer
      occurrence of PATH_MAX
    <gnu_srs> :-(
    <youpi> (aside from not including the needed debian files for
      hurd-i386)
    
  • IPv6

    IRC, freenode, #hurd, 2014-02-23:

    <gg0> seems dhclient can't also set ipv6 translator
    <gg0> cheated by setting it manually, i had probably screwed it up
      somehow
    <gg0> exim was complaining 2014-02-23 22:26:41 IPv6 socket creation
      failed: Address family not supported by protocol