Gentoo Archives: gentoo-user

From: Marc Joliet <marcec@×××.de>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Strange behaviour of dhcpcd
Date: Tue, 28 Oct 2014 18:33:18
Message-Id: 20141028193156.7b55437b@marcec.fritz.box
In Reply to: Re: [gentoo-user] Strange behaviour of dhcpcd by Mick
1 Am Tue, 28 Oct 2014 16:28:37 +0000
2 schrieb Mick <michaelkintzios@×××××.com>:
3
4 > On Monday 27 Oct 2014 23:44:58 Marc Joliet wrote:
5 > > Hi list
6 > >
7 > > First off: this is a "fixed" issue, in that I don't see the behaviour
8 > > anymore, so time is not of the essence ;) . I'm only looking for an
9 > > explanation, or for comments from other people who experienced this.
10 > >
11 > > So the issue was some really strange behaviour on the part of dhcpcd. I
12 > > completed a move a few weeks ago and got an internet connection last
13 > > Wednesday (using a local cable company, that is, using a cable modem
14 > > connected to via ethernet). I reconfigured my system to use regular DHCP
15 > > (a relief after the PPPoE mess in the dorm), but dhcpcd could not apply
16 > > the default route; it *obtained* one, but failed with "if_addroute:
17 > > Invalid argument". I tried it manually, to no effect: "ip route"
18 > > complained about invalid arguments, and I think plain "route" said "file
19 > > exists", but I'm not sure anymore (either way, the error messages were
20 > > less than clear). The funny thing is, I *could* set the default route,
21 > > just not to the one advertised via DHCP, but to the x.y.z.2+ instead of
22 > > x.y.z.1, which even gave me access to the internet part of the time.
23 > >
24 > > Now the funny thing is what fixed it:
25 > >
26 > > *commenting out the entirety of /etc/dhcpcd.conf*
27 > >
28 > > Then dhcpcd ran with default settings and could apply the default route.
29 > > Even more bizarre is the fact that it kept working after uncommenting it
30 > > again (and I track it with git, so I'm 100% sure I got it back to its
31 > > original state). This leads me to believe that there was some (corrupted?)
32 > > persistent state somewhere that got overwritten by starting dhcpcd after I
33 > > commented out the file, but I have no clue where.
34 > >
35 > > Has anyone seen this sort of behaviour before, or anything similar to it?
36 > > I searched for the error messages I was seeing, but couldn't find
37 > > anything. I was using gentoo-sources-3.15.9 (now I'm at 3.16.6) and
38 > > dhcpcd 6.4.3 at the time, but also had the issue with dhcpcd 6.4.7, to
39 > > which I could upgrade by using the aforementioned x.y.z.2 gateway. Perhaps
40 > > it was a bug in the kernel? But that's just guessing.
41 > >
42 > > Regards,
43 >
44 > Since dhcpcd doesn't misbehave any more it would be difficult to check what
45 > was the cause of this problem. You didn't say if the cable modem is
46 > functioning as a router or as in a full or half bridge mode and if there is a
47 > router between your PC and the modem that distributes IP addresses. You also
48 > didn't say if the ISP has allocated an IP block or just a single IP address.
49
50 First off: thanks for the response. Note that I have no clue about modems
51 (other than that the modulate and demodulate signals), let alone cable modems
52 and the wide variety of hardware out there. I also have no clue about the
53 protocols involved (save for a tiny bit of IP and TCP/UDP). Just so you know
54 what to expect.
55
56 Anyway, in answer to your queries:
57
58 - I do not know for sure how the modem is configured, and whether it hands
59 out the addresses itself or whether these come from the other end of the
60 cable connection. But from what I can observe it does *not* function as a
61 router; it has *one* Ethernet connection, and that's it. I did not test it
62 in a bridged network, to see if it hands out addresses to multiple clients.
63 Our ISP refers to it as a "LAN modem".
64
65 OK, I looked up more information: It's a Thomson THG571, and the manual (I
66 found a copy here:
67 http://www.kabelfernsehen.ch/dokumente/quicknet/HandbuchTHG570.pdf) refers
68 to "Transparent bridging for IP traffic", and AFAICT makes no mention of
69 routing. It does explicitly say that it gets an IP address from the ISP, so
70 I suspect that it acts as a bridge for all IP clients (like the "IP Client
71 Mode" in Fritz!Box routers). So it sounds to me that the DHCP packets likely
72 come from a server beyond the router. Is this the half bridge mode you
73 alluded to?
74
75 Oh, and there are two powerline/dLAN adapters in between (the modem is in the
76 room next door), but direct connections between my computer and my brother's
77 always worked, and they've been reliable in general, so I assume that they're
78 irrelevant here.
79
80 Furthermore, I found out the hard way that you *sometimes* need to reboot the
81 modem when connect a different client for the new client to get a response
82 from the DHCP server (I discovered this after wasting half a day trying to
83 get our router to work, it would log timeouts during DHCPDISCOVER). I didn't
84 think it was the modem because when we first got it, I could switch cables
85 around between my computer and my brother's and they would get their IP
86 addresses without trouble. *sigh*
87
88 - At the time there was no router, just the modem. We now have a Fritz!Box
89 3270 with the most recent firmware, but we got it after I "solved" this
90 problem.
91
92 - I don't know whether we have an IP block or not; I suspect not. At the very
93 least, we didn't make special arrangements to try and get one.
94
95 > I have had problems with dhcpcd over the years and in particular with it using
96 > DUID, which my router does not like at all. Also, for some reason it first
97 > checks for IPv6, then times out, and eventually it looks for IPv4 which takes
98 > like forever, each time I connect to my wired network.
99
100 I don't know if this helps, but dhcpcd has a "-4" (aka "--ipv4only") option.
101
102 > In waiting for an IPv4
103 > address it may set up APIPA and then sometime later will eventually look for
104 > and obtain an IPv4 address from the router.
105
106 I expect that you've already tried this, but I wonder if a combination of a
107 longer timeout and "--noipv4ll" would help.
108
109 > I have not found a solution to this annoying behaviour, however wirelessly the
110 > IP address allocation is established immediately without delays. Go figure
111 > ...
112
113 See above.
114
115 --
116 Marc Joliet
117 --
118 "People who think they know everything really annoy those of us who know we
119 don't" - Bjarne Stroustrup

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies

Subject Author
Re: [gentoo-user] Strange behaviour of dhcpcd "J. Roeleveld" <joost@××××××××.org>