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 |