summaryrefslogtreecommitdiff
path: root/hurd/running/debian/dhcp.mdwn
blob: 8846769a5948201e3c8879cde58e6044a1aedc5b (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
[[!meta copyright="Copyright © 2011, 2012, 2013, 2014 Free Software Foundation,
Inc."]]

[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]

[[!tag open_issue_porting]]

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

  * [[!debbug 616290]]

  * [[Proper Hurdy DHCP support|hurd/translator/pfinet/dhcp]]

  * [[!message-id desc="dhclient aborting with a stack smashing error"
    "874ngfvwn4.fsf@kepler.schwinge.homeip.net"]]

    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