Re: [gentoo-user] Strange behaviour of dhcpcd
On Friday, October 31, 2014 03:46:50 PM Marc Joliet wrote: Am Fri, 31 Oct 2014 12:16:04 +0100 schrieb J. Roeleveld jo...@antarean.org: On Friday, October 31, 2014 11:47:50 AM Marc Joliet wrote: I didn't explicitly mention this, but the problem is that the router and modem are in my brothers room (four room shared students apartment, plus bathroom and kitchen). Now, I'm not about to drag a cable out of my room, across the hall, and into my brother's room, never mind that neither of us could close our doors anymore without unplugging the cable and dragging it back. I had a similar issue a long time ago. With a little remodeling of the door, you can make room for the wire to pass and the door can then still close. Just make sure you do it without the owner of the building seeing it. (Bottom of the door on side of hinge is a common location) So the alternative would have been to teach my desktop WLAN, which would've been slower unless I could find something for PCI(e) or USB3 that works with Linux, *without* me having to check out some git repository and manually compile things in the hope that it works. The first USB3 WLAN adapter I found would've lead to that, so I made a snap decision in favour of powerline. It also didn't hurt that I was curious about it and wanted to try it out :) . PowerLine is ok for this kind of use. I just have too many items on the wires here that can cause interference. (I actually had to (unexpectedly) to do that with my wireless keyboard. Now there's app-misc/solaar, thankfully, although why Logitech couldn't just stick with infrared...) (If you accept the reduction in line-speed) How long ago was this? I read that all modern devices incorporate various filters to mitigate disturbances coming from other devices and, thus, that they perform much better (or at least more robustly) than previous generations (they also *cause* less disturbances). Either way, I can saturate our 16 MiB/s internet connection with enough parallel downloads (or with a fast enough server, such as with speedtest.net), and LAN performance is satisfactory. I suspect one limiting factor is that the powerline adapters only have Fast Ethernet connections (of course, so does the router, so it doesn't matter). My internet connection is 180Mbit down, 18Mbit up. Without Gigabit network (including the WAN-port), I can't get use this. [...] I once connected a fresh install directly to the modem. Only took 20 seconds to get owned. (This was about 9 years ago and Bind was running) Ouch. I was, to be honest, expecting it to be owned. (Just not this quick). It was done on purpose to see how long it would take. I pulled the network cable when the root-kit was being installed. Was interesting to see. I bet :) ! The rootkit also was installed using make -j. Suddenly slow server is a bit of a give-away. -- Joost
Re: [gentoo-user] Strange behaviour of dhcpcd
On Tuesday, October 28, 2014 07:31:56 PM Marc Joliet wrote: Am Tue, 28 Oct 2014 16:28:37 + schrieb Mick michaelkintz...@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. Sounds similar to what I've been using for the past 10+ years. 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? Not sure about half-bridge mode. But most cable-modems work in bridge-mode. (If they have more then 1 ethernet-port, they act as routers) 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. Uh-oh... If you have multiple machines that can ask for a DHCP-lease, you might keep getting a different result each time it tries to refresh. 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
Re: [gentoo-user] Strange behaviour of dhcpcd
On Friday 31 Oct 2014 06:52:54 J. Roeleveld wrote: On Tuesday, October 28, 2014 07:31:56 PM Marc Joliet wrote: Am Tue, 28 Oct 2014 16:28:37 + (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? Not sure about half-bridge mode. But most cable-modems work in bridge-mode. (If they have more then 1 ethernet-port, they act as routers) Yes, it seems to be a fully bridged modem. A PC or router behind it will be accessible from the Internet using your public IP address provided by the ISP. In a fully bridged mode the modem only manages encapsulation of your LAN hosts ethernet packets (using DOCSIS frames in the case of cable, or ATM frames in the case of ADSL). PPPoE or any other authentication method is undertaken by the PC or by the router behind it. There's no NAT'ing or routing performed by the modem - it is just a transparent bridge. In a typical half bridged mode the modem performs encapsulation of your packets AND authentication with the ISP's radius server. It also passes the public IP address over to the host in the LAN, but it doesn't just bridge - it routes it. The half bridged modem acts as an arp proxy. Some implementations advertise more addresses on the LAN side than the public ISP's address and offer the host a different IP address to the ISP's (usually public IP + 1 with 255.255.255.0 instead of 255.255.255.255). MSWindows machines work fine with this, but Linux won't work without setting a static route to the ISP's gateway and complains that the gateway is not on public-IP/32. Cisco routers barf at this problem too. 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. Uh-oh... If you have multiple machines that can ask for a DHCP-lease, you might keep getting a different result each time it tries to refresh. 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* That's a common flaw. These modems are designed with the idea that people only have 1 computer. Or at the very least put a router between the modem and whatever else they have. Please note, there is NO firewall on these modems and your machine is fully exposed to the internet. Unless you have your machine secured and all unused services disabled, you might as well assume your machine compromised. Yes, the way these modems work you may need to reboot the modem so that it flushes its arp cache if you start reconnecting machines to it. I once connected a fresh install directly to the modem. Only took 20 seconds to get owned. (This was about 9 years ago and Bind was running) - 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. Then assume not. Most, if not all, ISPs charge extra for this. (If they even offer it) You would typically have two IP addresses with a half bridged modem, but only one of these would be usable by the PC/router in your LAN. Personally I find all this a bothersome faff and only buy and set up modems in fully bridged mode, so that they get out of the way and let me route things using a router. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Strange behaviour of dhcpcd
Am Fri, 31 Oct 2014 07:52:54 +0100 schrieb J. Roeleveld jo...@antarean.org: On Tuesday, October 28, 2014 07:31:56 PM Marc Joliet wrote: [...] 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. Uh-oh... If you have multiple machines that can ask for a DHCP-lease, you might keep getting a different result each time it tries to refresh. How so? You mean if the modem is directly connected to the powerline adapter? I would be surprised if this were a problem in general, since AFAIU they're ultimately just bridges as far as the network is concerned, not to mention that they explicitly target home networks with multiple devices. But in the end, it doesn't matter, since it's just for my desktop (which doesn't have WLAN built-in); all other clients connect via WLAN. FWIW, I chose poewrline because it seemed like a better (and driverless!) alternative to getting a WLAN USB-stick (or PCI(e) card), and so far I'm quite happy with it. 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* That's a common flaw. These modems are designed with the idea that people only have 1 computer. Or at the very least put a router between the modem and whatever else they have. Please note, there is NO firewall on these modems and your machine is fully exposed to the internet. Unless you have your machine secured and all unused services disabled, you might as well assume your machine compromised. Yes, I wasn't explicitly aware of this, but it makes sense, since AFAIU the modem's job boils down to carrying the signal over the cable network and (on a higher level) dialing in to the ISP and forwarding packets. I would not really expect a firewall there. I once connected a fresh install directly to the modem. Only took 20 seconds to get owned. (This was about 9 years ago and Bind was running) Ouch. I just hope the Fritz!Box firewall is configured correctly, especially since there doesn't appear to be a UI for it. Well, OK, there is, but it's not very informative in that it doesn't tell me what rules (other than manually entered ones) are currently in effect; all it explicitly says is that it blocks NetBIOS packets. The only other thing that's bothered me about the router is the factory default (directly after flashing the firmware) of activating WPA2 *and* WPA (why?!). I turned off WPA as soon as I noticed. Out of curiosity, I looked through the exported configuration file (looks like JSON), and found entries that look like firewall rules, but don't really know how they apply. It's less the rules themselves, though, than the context, i.e., the rules are under pppoefw and dslifaces, even though the router uses neither PPPoE nor DSL (perhaps a sign that AVM's software grows just as organically as everybody else's ;-) ). The one thing I'm most curious about is what lowinput, highoutput, etc. mean, as Google only found me other people asking the same question. Anyway, it *looks* like it blocks everything from the internet by default (except for output-related and input-related, which I interpret to mean responses to outgoing packets and... whatever input-related means), and the manual seems to agree by implying that the firewall is for explicitly opening ports. Also, I used the Heise Netzwerk Check and it reports no problems, so I'm mostly relieved. - 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. Then assume not. Most, if not all, ISPs charge extra for this. (If they even offer it) That's what I thought :) . Anyway, I think that I'll contact the dhcpcd maintainer (Roy Marples) directly and ask for his opinion. -- Marc Joliet -- People who think they know everything really annoy those of us who know we don't - Bjarne Stroustrup signature.asc Description: PGP signature
Re: [gentoo-user] Strange behaviour of dhcpcd
On Fri, Oct 31, 2014 at 6:47 AM, Marc Joliet mar...@gmx.de wrote: Am Fri, 31 Oct 2014 07:52:54 +0100 schrieb J. Roeleveld jo...@antarean.org: On Tuesday, October 28, 2014 07:31:56 PM Marc Joliet wrote: - 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. Then assume not. Most, if not all, ISPs charge extra for this. (If they even offer it) That's what I thought :) . Generally speaking you can't just attach a modem to your LAN and have it act as a DHCP server. Your ISP probably will assign you dynamic IPs, but they will not as a matter of policy assign you more than one unless you pay for them. IPv4 address space is in short supply these days. I'm using FIOS and in my case the modem is in a box in the basement and the ISP provides a router with the service. Whatever you plug into the modem will obtain a DHCP lease for one routable IP. If you do plug more than one device into the modem then the first device to get the IP is the only one that will get an IP - the modem won't hand out another unless it gets a DHCPRelease from the MAC that was issued the original lease or until that lease expires, or until you call up the ISP on the phone and get them to release it manually. Another design would be to issue a new IP anytime a device asks for one, but to silently cancel the lease of the last IP that was issued and drop packets using it. For a single device being plugged in that won't have any impact, and if for some reason you buy a new router and plug it in you don't have to worry about your old router still having a lease. This is less standards-compliant, but perhaps more clueless-friendly. In general, though, you really shouldn't be plugging your ISP's modem into anything but a router for general use. In fact, I have the router provided by my ISP configured as a bridge and running into another router (FIOS uses MoCA over coax in the standard install and I'm too lazy to run CatV and beg Verizon to reconfigure the modem to use the RJ45 connection instead). Note that if you use an ISP-provided router there is a good chance that they can essentially VPN into your LAN. The last time I called up Verizon over a cablecard issue they helpfully turned on DHCP on my router so that it started competing with my DHCP server, and then I was wondering why PXE was randomly failing. Now all they can do is disable bridge mode, which will break my external connection and be a fairly obvious point to troubleshoot. -- Rich
Re: [gentoo-user] Strange behaviour of dhcpcd
On Friday, October 31, 2014 11:47:50 AM Marc Joliet wrote: Am Fri, 31 Oct 2014 07:52:54 +0100 schrieb J. Roeleveld jo...@antarean.org: On Tuesday, October 28, 2014 07:31:56 PM Marc Joliet wrote: [...] 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. Uh-oh... If you have multiple machines that can ask for a DHCP-lease, you might keep getting a different result each time it tries to refresh. How so? You mean if the modem is directly connected to the powerline adapter? I would be surprised if this were a problem in general, since AFAIU they're ultimately just bridges as far as the network is concerned, not to mention that they explicitly target home networks with multiple devices. Actually, a HUB is a better comparison. All the powerline adapters all connect to the same network. Some you can set to a network-ID (think vlan) to limit this. The one time I played with one, I ended up seeing my neighbours NAS. But in the end, it doesn't matter, since it's just for my desktop (which doesn't have WLAN built-in); all other clients connect via WLAN. FWIW, I chose poewrline because it seemed like a better (and driverless!) alternative to getting a WLAN USB-stick (or PCI(e) card), and so far I'm quite happy with it. If you can ensure that only 2 devices communicate, it's a valid replacement for a dedicated network cable. (If you accept the reduction in line-speed) 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* That's a common flaw. These modems are designed with the idea that people only have 1 computer. Or at the very least put a router between the modem and whatever else they have. Please note, there is NO firewall on these modems and your machine is fully exposed to the internet. Unless you have your machine secured and all unused services disabled, you might as well assume your machine compromised. Yes, I wasn't explicitly aware of this, but it makes sense, since AFAIU the modem's job boils down to carrying the signal over the cable network and (on a higher level) dialing in to the ISP and forwarding packets. I would not really expect a firewall there. There isn't, usually. I once connected a fresh install directly to the modem. Only took 20 seconds to get owned. (This was about 9 years ago and Bind was running) Ouch. I was, to be honest, expecting it to be owned. (Just not this quick). It was done on purpose to see how long it would take. I pulled the network cable when the root-kit was being installed. Was interesting to see. I just hope the Fritz!Box firewall is configured correctly, especially since there doesn't appear to be a UI for it. Well, OK, there is, but it's not very informative in that it doesn't tell me what rules (other than manually entered ones) are currently in effect; all it explicitly says is that it blocks NetBIOS packets. The only other thing that's bothered me about the router is the factory default (directly after flashing the firmware) of activating WPA2 *and* WPA (why?!). I turned off WPA as soon as I noticed. It will have NAT enabled, which blocks most incoming packets. As long as the router isn't owned, you should be ok. Out of curiosity, I looked through the exported configuration file (looks like JSON), and found entries that look like firewall rules, but don't really know how they apply. It's less the rules themselves, though, than the context, i.e., the rules are under pppoefw and dslifaces, even though the router uses neither PPPoE nor DSL (perhaps a sign that AVM's software grows just as organically as everybody else's ;-) ). The one thing I'm most curious about is what lowinput, highoutput, etc. mean, as Google only found me other people asking the same question. Not familiar with those routers. Maybe someone with more knowledge can have a look at the config and shed some light. I would do a find/replace on the username and password you use to ensure that is masked before sending it to someone to investigate. Anyway, it *looks* like it blocks everything from the internet by default (except for output-related and input-related, which I interpret to mean responses to outgoing packets and... whatever input-related means), and the manual seems to agree by implying that the firewall is
Re: [gentoo-user] Strange behaviour of dhcpcd
Am Fri, 31 Oct 2014 12:16:04 +0100 schrieb J. Roeleveld jo...@antarean.org: On Friday, October 31, 2014 11:47:50 AM Marc Joliet wrote: Am Fri, 31 Oct 2014 07:52:54 +0100 schrieb J. Roeleveld jo...@antarean.org: On Tuesday, October 28, 2014 07:31:56 PM Marc Joliet wrote: [...] 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. Uh-oh... If you have multiple machines that can ask for a DHCP-lease, you might keep getting a different result each time it tries to refresh. How so? You mean if the modem is directly connected to the powerline adapter? I would be surprised if this were a problem in general, since AFAIU they're ultimately just bridges as far as the network is concerned, not to mention that they explicitly target home networks with multiple devices. Actually, a HUB is a better comparison. All the powerline adapters all connect to the same network. Some you can set to a network-ID (think vlan) to limit this. Also, AFAICS, all newer ones support encryption (AES128 in my case), where you pair the devices, for which you need physical access to press the necessary buttons. This can be used to similar effect IIUC. No clue on cross-vendor compatibility, though. However, encryption was mainly targeted at solving the next problem: The one time I played with one, I ended up seeing my neighbours NAS. Yeah, that problem gets mentioned a lot. You can access every other (compatible) powerline adapter on the same electric network. Adapters on different phases could have trouble communicating, I believe, and cross-talk between cables can lead to data leaking into another network (but my knowledge on things electric is reaching its end). In my case, our apartment has an electric meter that isolates our apartment from the others, so we're fine (plus, the adapters use encryption as mentioned above) But in the end, it doesn't matter, since it's just for my desktop (which doesn't have WLAN built-in); all other clients connect via WLAN. FWIW, I chose poewrline because it seemed like a better (and driverless!) alternative to getting a WLAN USB-stick (or PCI(e) card), and so far I'm quite happy with it. If you can ensure that only 2 devices communicate, it's a valid replacement for a dedicated network cable. I didn't explicitly mention this, but the problem is that the router and modem are in my brothers room (four room shared students apartment, plus bathroom and kitchen). Now, I'm not about to drag a cable out of my room, across the hall, and into my brother's room, never mind that neither of us could close our doors anymore without unplugging the cable and dragging it back. So the alternative would have been to teach my desktop WLAN, which would've been slower unless I could find something for PCI(e) or USB3 that works with Linux, *without* me having to check out some git repository and manually compile things in the hope that it works. The first USB3 WLAN adapter I found would've lead to that, so I made a snap decision in favour of powerline. It also didn't hurt that I was curious about it and wanted to try it out :) . (I actually had to (unexpectedly) to do that with my wireless keyboard. Now there's app-misc/solaar, thankfully, although why Logitech couldn't just stick with infrared...) (If you accept the reduction in line-speed) How long ago was this? I read that all modern devices incorporate various filters to mitigate disturbances coming from other devices and, thus, that they perform much better (or at least more robustly) than previous generations (they also *cause* less disturbances). Either way, I can saturate our 16 MiB/s internet connection with enough parallel downloads (or with a fast enough server, such as with speedtest.net), and LAN performance is satisfactory. I suspect one limiting factor is that the powerline adapters only have Fast Ethernet connections (of course, so does the router, so it doesn't matter). [...] I once connected a fresh install directly to the modem. Only took 20 seconds to get owned. (This was about 9 years ago and Bind was running) Ouch. I was, to be honest, expecting it to be owned. (Just not this quick). It was done on purpose to see how long it would take. I pulled the network cable when the root-kit was being installed. Was interesting to see. I bet :) ! I just hope the Fritz!Box firewall is configured correctly, especially since there doesn't appear to be a UI for it. Well, OK, there is, but it's not very informative in that it doesn't tell me what rules (other than manually entered ones) are currently in effect; all it explicitly says is that it blocks NetBIOS packets. The only other thing that's bothered me about the router is
Re: [gentoo-user] Strange behaviour of dhcpcd
Am Fri, 31 Oct 2014 07:09:08 -0400 schrieb Rich Freeman ri...@gentoo.org: On Fri, Oct 31, 2014 at 6:47 AM, Marc Joliet mar...@gmx.de wrote: Am Fri, 31 Oct 2014 07:52:54 +0100 schrieb J. Roeleveld jo...@antarean.org: On Tuesday, October 28, 2014 07:31:56 PM Marc Joliet wrote: - 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. Then assume not. Most, if not all, ISPs charge extra for this. (If they even offer it) That's what I thought :) . Generally speaking you can't just attach a modem to your LAN and have it act as a DHCP server. Your ISP probably will assign you dynamic IPs, but they will not as a matter of policy assign you more than one unless you pay for them. IPv4 address space is in short supply these days. I'm using FIOS and in my case the modem is in a box in the basement and the ISP provides a router with the service. Whatever you plug into the modem will obtain a DHCP lease for one routable IP. If you do plug more than one device into the modem then the first device to get the IP is the only one that will get an IP - the modem won't hand out another unless it gets a DHCPRelease from the MAC that was issued the original lease or until that lease expires, or until you call up the ISP on the phone and get them to release it manually. Another design would be to issue a new IP anytime a device asks for one, but to silently cancel the lease of the last IP that was issued and drop packets using it. For a single device being plugged in that won't have any impact, and if for some reason you buy a new router and plug it in you don't have to worry about your old router still having a lease. This is less standards-compliant, but perhaps more clueless-friendly. In general, though, you really shouldn't be plugging your ISP's modem into anything but a router for general use. In fact, I have the router provided by my ISP configured as a bridge and running into another router (FIOS uses MoCA over coax in the standard install and I'm too lazy to run CatV and beg Verizon to reconfigure the modem to use the RJ45 connection instead). Note that if you use an ISP-provided router there is a good chance that they can essentially VPN into your LAN. The last time I called up Verizon over a cablecard issue they helpfully turned on DHCP on my router so that it started competing with my DHCP server, and then I was wondering why PXE was randomly failing. Now all they can do is disable bridge mode, which will break my external connection and be a fairly obvious point to troubleshoot. Right, thanks for the explanation :) . Thankfully, our ISP only gave us the modem (though they also offer modems with WLAN for 5€ a monthg :-/ ). The router we bought off eBay ourselves :) . -- Marc Joliet -- People who think they know everything really annoy those of us who know we don't - Bjarne Stroustrup signature.asc Description: PGP signature
Re: [gentoo-user] Strange behaviour of dhcpcd
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. 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. 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 have not found a solution to this annoying behaviour, however wirelessly the IP address allocation is established immediately without delays. Go figure ... -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Strange behaviour of dhcpcd
Am Tue, 28 Oct 2014 16:28:37 + schrieb Mick michaelkintz...@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.
[gentoo-user] Strange behaviour of dhcpcd
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, -- Marc Joliet -- People who think they know everything really annoy those of us who know we don't - Bjarne Stroustrup signature.asc Description: PGP signature
