Re: [gentoo-user] Strange behaviour of dhcpcd

[Marc Joliet <marcec@gmx.de>]

[-- Attachment #1: Type: text/plain, Size: 6173 bytes --]

Am Tue, 28 Oct 2014 16:28:37 +0000
schrieb Mick <michaelkintzios@gmail.com>:

> On Monday 27 Oct 2014 23:44:58 Marc Joliet wrote:
> > Hi list
> > 
> > First off: this is a "fixed" issue, in that I don't see the behaviour
> > anymore, so time is not of the essence ;) . I'm only looking for an
> > explanation, or for comments from other people who experienced this.
> > 
> > So the issue was some really strange behaviour on the part of dhcpcd.  I
> > completed a move a few weeks ago and got an internet connection last
> > Wednesday (using a local cable company, that is, using a cable modem
> > connected to via ethernet). I reconfigured my system to use regular DHCP
> > (a relief after the PPPoE mess in the dorm), but dhcpcd could not apply
> > the default route; it *obtained* one, but failed with "if_addroute:
> > Invalid argument". I tried it manually, to no effect: "ip route"
> > complained about invalid arguments, and I think plain "route" said "file
> > exists", but I'm not sure anymore (either way, the error messages were
> > less than clear).  The funny thing is, I *could* set the default route,
> > just not to the one advertised via DHCP, but to the x.y.z.2+ instead of
> > x.y.z.1, which even gave me access to the internet part of the time.
> > 
> > Now the funny thing is what fixed it:
> > 
> >   *commenting out the entirety of /etc/dhcpcd.conf*
> > 
> > Then dhcpcd ran with   default settings and could apply the default route.
> > Even more bizarre is the fact that it kept working after uncommenting it
> > again (and I track it with git, so I'm 100% sure I got it back to its
> > original state). This leads me to believe that there was some (corrupted?)
> > persistent state somewhere that got overwritten by starting dhcpcd after I
> > commented out the file, but I have no clue where.
> > 
> > Has anyone seen this sort of behaviour before, or anything similar to it? 
> > I searched for the error messages I was seeing, but couldn't find
> > anything.  I was using gentoo-sources-3.15.9 (now I'm at 3.16.6) and
> > dhcpcd 6.4.3 at the time, but also had the issue with dhcpcd 6.4.7, to
> > which I could upgrade by using the aforementioned x.y.z.2 gateway. Perhaps
> > it was a bug in the kernel? But that's just guessing.
> > 
> > Regards,
> 
> Since dhcpcd doesn't misbehave any more it would be difficult to check what 
> was the cause of this problem.  You didn't say if the cable modem is 
> functioning as a router or as in a full or half bridge mode and if there is a 
> router between your PC and the modem that distributes IP addresses.  You also 
> didn't say if the ISP has allocated an IP block or just a single IP address.

First off: thanks for the response.  Note that I have no clue about modems
(other than that the modulate and demodulate signals), let alone cable modems
and the wide variety of hardware out there. I also have no clue about the
protocols involved (save for a tiny bit of IP and TCP/UDP).  Just so you know
what to expect.

Anyway, in answer to your queries:

- I do not know for sure how the modem is configured, and whether it hands
  out the addresses itself or whether these come from the other end of the
  cable connection.  But from what I can observe it does *not* function as a
  router; it has *one* Ethernet connection, and that's it.  I did not test it
  in a bridged network, to see if it hands out addresses to multiple clients.
  Our ISP refers to it as a "LAN modem".

  OK, I looked up more information:  It's a Thomson THG571, and the manual (I
  found a copy here:
  http://www.kabelfernsehen.ch/dokumente/quicknet/HandbuchTHG570.pdf) refers
  to "Transparent bridging for IP traffic", and AFAICT makes no mention of
  routing.  It does explicitly say that it gets an IP address from the ISP, so
  I suspect that it acts as a bridge for all IP clients (like the "IP Client
  Mode" in Fritz!Box routers).  So it sounds to me that the DHCP packets likely
  come from a server beyond the router. Is this the half bridge mode you
  alluded to?

  Oh, and there are two powerline/dLAN adapters in between (the modem is in the
  room next door), but direct connections between my computer and my brother's
  always worked, and they've been reliable in general, so I assume that they're
  irrelevant here.

  Furthermore, I found out the hard way that you *sometimes* need to reboot the
  modem when connect a different client for the new client to get a response
  from the DHCP server (I discovered this after wasting half a day trying to
  get our router to work, it would log timeouts during DHCPDISCOVER).  I didn't
  think it was the modem because when we first got it, I could switch cables
  around between my computer and my brother's and they would get their IP
  addresses without trouble.  *sigh*

- At the time there was no router, just the modem.  We now have a Fritz!Box
  3270 with the most recent firmware, but we got it after I "solved" this
  problem.

- I don't know whether we have an IP block or not; I suspect not.  At the very
  least, we didn't make special arrangements to try and get one.

> I have had problems with dhcpcd over the years and in particular with it using 
> DUID, which my router does not like at all.  Also, for some reason it first 
> checks for IPv6, then times out, and eventually it looks for IPv4 which takes 
> like forever, each time I connect to my wired network.

I don't know if this helps, but dhcpcd has a "-4" (aka "--ipv4only") option.

> In waiting for an IPv4 
> address it may set up APIPA and then sometime later will eventually look for 
> and obtain an IPv4 address from the router.

I expect that you've already tried this, but I wonder if a combination of a
longer timeout and "--noipv4ll" would help.

> I have not found a solution to this annoying behaviour, however wirelessly the 
> IP address allocation is established immediately without delays.  Go figure 
> ...

See above.

-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]