From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id A09601388E5 for ; Tue, 28 Oct 2014 18:33:18 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BBCA1E0A7D; Tue, 28 Oct 2014 18:32:07 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id E91B7E0A6E for ; Tue, 28 Oct 2014 18:32:05 +0000 (UTC) Received: from marcec.fritz.box ([93.181.44.4]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MJjUO-1Xi5dH3uHU-0017mb for ; Tue, 28 Oct 2014 19:32:04 +0100 Date: Tue, 28 Oct 2014 19:31:56 +0100 From: Marc Joliet To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Strange behaviour of dhcpcd Message-ID: <20141028193156.7b55437b@marcec.fritz.box> In-Reply-To: <201410281628.46275.michaelkintzios@gmail.com> References: <20141028004458.16d1bbbc@marcec.fritz.box> <201410281628.46275.michaelkintzios@gmail.com> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.24; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/1Nvd4FeO8gYl7yTR1wymHmQ"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:o92Cvz4eRHVKo//vi8JU/Zca+oZvsyu0diexcOhNnqmTZhPwXZR m3jLdHtTSIGA1QrAcSqG2PKjFfwbaS2YOC/ibIM0mYiZvJPXDqTH2TuGH50378nd4Denx45 ODomBx0zbYcP4dL90FnFeoyD/HCvPNHfUAcxJIRInZJHYi+S0QkUr4sW+5HvsLsKXxnVub0 DhDno57bg+wuZ6+SFp3tA== X-UI-Out-Filterresults: notjunk:1; X-Archives-Salt: f79bb56d-9b5f-4c19-8b25-9b64174142f5 X-Archives-Hash: 93d30a6aafba2ce888997d8c6c79cde1 --Sig_/1Nvd4FeO8gYl7yTR1wymHmQ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Tue, 28 Oct 2014 16:28:37 +0000 schrieb Mick : > On Monday 27 Oct 2014 23:44:58 Marc Joliet wrote: > > Hi list > >=20 > > 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. > >=20 > > 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. > >=20 > > Now the funny thing is what fixed it: > >=20 > > *commenting out the entirety of /etc/dhcpcd.conf* > >=20 > > Then dhcpcd ran with default settings and could apply the default rou= te. > > 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 (corrupte= d?) > > persistent state somewhere that got overwritten by starting dhcpcd afte= r I > > commented out the file, but I have no clue where. > >=20 > > Has anyone seen this sort of behaviour before, or anything similar to i= t?=20 > > 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. Perh= aps > > it was a bug in the kernel? But that's just guessing. > >=20 > > Regards, >=20 > Since dhcpcd doesn't misbehave any more it would be difficult to check wh= at=20 > was the cause of this problem. You didn't say if the cable modem is=20 > functioning as a router or as in a full or half bridge mode and if there = is a=20 > router between your PC and the modem that distributes IP addresses. You = also=20 > didn't say if the ISP has allocated an IP block or just a single IP addre= ss. 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 mode= ms 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 kn= ow 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 client= s. 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 li= kely 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 brothe= r's always worked, and they've been reliable in general, so I assume that the= y'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 di= dn'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 v= ery 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=20 > DUID, which my router does not like at all. Also, for some reason it fir= st=20 > checks for IPv6, then times out, and eventually it looks for IPv4 which t= akes=20 > 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=20 > address it may set up APIPA and then sometime later will eventually look = for=20 > 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 wirelessl= y the=20 > IP address allocation is established immediately without delays. Go figu= re=20 > ... See above. --=20 Marc Joliet -- "People who think they know everything really annoy those of us who know we don't" - Bjarne Stroustrup --Sig_/1Nvd4FeO8gYl7yTR1wymHmQ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUT+EhAAoJEL/Q5oYsiHj06p8P/1KAJlw5TW/3Lsa/93sNIvdT Tql0nPk77JlxowHLdQvFuqwn2pgND2r6aqK5JlIqUvziF0W+tvdE5oY6Ah9q/RhT OiFrBM1rmFAhW7hFF3UPlavStlx6vHY1aOCr7dBWihlkPG8PvmhcXPeHOo5IcETS +yKTWfVegznBT9TChixjac4YpHsTynjXMJpjNtd12/uTxmB6FmI+QepoQebjE5Wc C87PkOOcg/UNbGTV10SdKw/adTXcmrCR+S0bLLL/UlgVAaosdnIAx5m+qtr3xAXK ZKc32ZEg8BgUFVPPVD55pjVhbxtzSIUa7EPc9Th2xYkuU7LxhjI3mwp6Ja5dBT5o loU7US+Iori5X4EBHQvEcxSbinuVjvHqH3L2BOMXlz3heQCw52VApRuue0F4UiSe xVdtU0RKqJWVYSl8boL1KjO3I2Hgn6B29Q6oR/FtvhTHHl1wwRPb4zZVuLSDrzwq Ct/u8CyOtHoZiJ6pcysIalkQ8oxuUjen19LaavOaCww4Rr5Wu39iZDM5BGSdc4r7 T1ui2gBKqU5u+3WDMVqSNQbn/VgVvmrBk374kIUACxOxyCmlkUb+zliU8y10MZtO ZEh2aQOfdjFUars/qTlpW2I6/AWqNGPSlCjZec24Y5rj0jv3V7bbXEG9E8VTawB4 F74S74p88AKRJU2X+Hfb =02gH -----END PGP SIGNATURE----- --Sig_/1Nvd4FeO8gYl7yTR1wymHmQ--