Buffalo router disupts internet connection on lease renewal

On Thu, 08 Mar 2007 07:51:19 -0600, Peabody wrote in :

Why? DHCP works well, and helps to avoid problems.

It's not. How do you know the connection is dropping? What _exactly_ does that mean? Is it the cable modem losing the connection? The router? One computer? Both computers?

Do you have the latest router firmware? Have you tried running DD-WRT firmware in the router?

Try that now. The number of computers shouldn't matter.

Yes.

Possibly.

Have you checked the router's log to see if anything odd is happening during renewal? (The entries will have DHCPC in the Type column.) You might also check the modem's log, which shold be available at

192.68.100.1.

I'm using a WHR-HP-G54 with stock (Ver.1.38) Buffalo firmware connected to a Time Warner SB 5100 modem. My WAN DHCP renewals occur essentially instantaneously, even though the Motorola lists a discrepancy ("Field invalid in response") during the process. Could it be Cox's DHCP server that's causing the delay?

Peabody hath wroth:

That's what happens if Cox decides that your router needs to have a new IP address. When the Buffalo requests a lease renewal, but Cox returns a NACK, then the DHCP client in the Buffalo will restart DHCP negotiation and get a new IP address. It's the change in IP address that's causing the connection loss. You're not really losing t he internet connection. However, any session you have running at the time will be dropped and interrupted.

Only if Cox fails to appreciate users that setup servers and change IP addresses to discourage the practice. At one time, SBC would always issue a NACK for a long term (greater than half lease time) DHCP renewal along with issuing fairly short (2 hr???) lease times. The result was that I couldn't maintain a VPN connection for more than an hour. They stopped doing that after a few months of complaints. At this time, I think it's a 24hr lease, but they still issue NACK's on long renewals. Kinda sounds like Cox is doing the same thing, but with the longer lease time.

The router is not in control of the DHCP address pool. It's the Cox server that decides the lease time, renewal response, policy, etc. All your Buffalo DHCP client can do is politely ask for a renewal and live with whatever Cox has in place.

I'm making a big assumption as to what's happening. The only way I know to test this is to sniff the DHCP related traffic between the modem and router for a few days using WireShark/Ethereal. Use an ethernet hub (not a switch) to do the sniffing. Leave a laptop running (disable sleep, standy, hibernate, power save, green) with Wireshark running to capture only DHCP related traffic. Let it run a few days and see what happens.

I understand, but that's not it. It keeps the same IP. Always the same IP.

I think there may be something wrong with the way the router is requesting the renewal. Without the router, this didn't happen. Here's the router's log showing what happens when I manually requested a renewal through the browser interface (sorry, but it's in reverse order, with the oldest entry at the bottom):

07:21:41 DHCPS max_leases value (256) not sane, setting to 64 instead 07:21:41 DHCPS udhcpd (v0.9.9-pre) started 07:21:41 DHCPS Received a SIGTERM 07:21:37 DHCPC add resolve 07:21:37 DHCPC Info : LEASETIME(86400) , RENEWALTIME(43200) , REBINDTIME(75600) 07:21:37 DHCPC Info : DHCPSNAME = 07:21:37 DHCPC Info : DHCPSHADDR = 00:50:57:01:47:ED 07:21:37 DHCPC Info : DHCPCHADDR = 00:20:EA:12:5C:03 07:21:37 DHCPC Info : DHCPSIADDR = 172.19.57.19 07:21:37 DHCPC Info : DHCPGIADDR = 10.6.96.1 07:21:37 DHCPC Info : DHCPSID = 172.19.57.19 07:21:37 DHCPC Info : DNS[3] = 68.2.16.30 07:21:37 DHCPC Info : DNS[2] = 68.12.16.30 07:21:37 DHCPC Info : DNS[1] = 68.12.16.25 07:21:37 DHCPC Info : Domain Name = tu.ok.cox.net 07:21:37 DHCPC Info : Default Gateway = 70.185.216.1 07:21:37 DHCPC Info : Subnet Mask = 255.255.248.0 07:21:37 DHCPC Info : IP Address = 70.185.218.200 07:21:37 DHCPC DHCP_ACK received from (172.19.57.19) 07:21:37 DHCPC broadcasting DHCP_REQUEST for 70.185.218.200 07:21:37 DHCPC DHCP_OFFER received from (172.19.57.19) 07:21:37 DHCPC broadcasting second DHCP_DISCOVER 07:21:36 DHCPC Request: broadcasting DHCP_DISCOVER 07:21:36 DHCPC OpenDhcpSocket: can't set initial netmask: Invalid argument 07:21:36 DHCPC del resolve 07:21:36 DHCPC dhcpStop: ioctl SIOCSIFNETMASK: Invalid argument 07:21:36 DHCPC fail to try rebinding 07:21:35 CONFIGURE WAN DHCPCD RENEW

It looks like something is going wrong, so it starts over. But it still ends up with the same IP it had immediately before. This is what happens every time. In case anyone else wants to try it, I got this by clicking on System Info, and then Update. In this case, the whole thing is done in about six seconds, but my impression is that the automatic half-point renewal lasts longer than that.

The only thing that I'm doing that may be different from normal is to spoof the router's MAC. I just like to get a different IP from time to time, and changing the MAC does that. But that doesn't happen often, and isn't the cause of these problems unless for some reason the router tries to use the hardware MAC when it renews instead of the one I've assigned. Which it shouldn't.

So, tonight at 7:21, I'm going to be connected to a Java-based chat room which will tell me "You have been disconnected" and log me back in when the connection has been re-established. And I'll also try to watch for icons, popups, and flashing lights. And of course, the log, which I will post.

I would suspect Cox, but this all works fine when the router isn't in the path.

Film at 11.

So much for that theory.

Argh. That's all wrong. However, I can't tell for sure where the error is buried. In order from top down:

(Client requests a DHCP renewal)

(Client tries to reopen old connection to DHCP server)

(Tries to set netmask for interface and fails)

(clears DNS servers (resolver)? What on earth for?)

(Fails again setting netmask as it tries to contact DHCP server)

(Client starts over with a new DHCP session)

Agreed.

That shouldn't make any difference as long as you don't duplicate the MAC address of the ISP's router or any machine connected to the router. It might also get confused if you duplicate the MAC of another connected Cox customer.

Yeah, but what are your chances of picking a MAC address that's already in use on the system? Be careful (or more random).

Can I assume firmware version 1.40?

I don't have an answer, but there sure seems like there is something wrong in the Buffalo DHCP client.

Agreed - randomly changing your MAC is a /really/ bad idea. MACs are hardware unique, and the chances are you're picking one that belongs to someone else's hardware. Fairly unlikely it'll be someone else on your cable network but you never know.

I use a non-random range of 16 sequential numbers beginning with the MAC of my old DSL modem from the SBC days. I just assumed that no DSL modem MAC would ever be used by a cable modem, either on Cox or anywhere else. The only chance I have of running into a conflict is if someone else is doing the same thing I am, and we just happen to use the same numbers, and only if we are on the same local DHCP server. I feel pretty safe with that.

Yes.

Well, guess what. At 19:21 last night, the router renewed it's lease, and did it seamlessly, without dropping the connection. Moreover, a manual renewal, done after that, also worked perfectly, with none of the errors or failures shown in the previous log. Hard to figure. In reverse order again:

2007/03/09 19:21:37 DHCPC Info : Subnet Mask = 255.255.248.0

2007/03/09 19:21:37 DHCPC Info : IP Address = 70.185.218.200

2007/03/09 19:21:37 DHCPC DHCP_ACK received from (172.19.57.19)

2007/03/09 19:21:37 DHCPC Renew : sending DHCP_REQUEST for 70.185.218.200 to 172.19.57.19

Peabody hath wroth:

Using MAC addresses from guaranteed incompatible hardware (or obsolete junk) is fairly safe. I use the MAC addresses from my collection of ancient ISA ethernet cards.

However, before I realized what I was doing, I would just increment the router MAC address by one, not thinking that the ISP might be issuing identical hardware with sequential MAC addresses. Judging by the results I sometimes obtained, I'm fairly sure I hit upon an address in use. Similarly, one of my friends decided to start with the MAC address of the ISP's router, ignoring that it was a multiport device and probably also had sequential MAC addresses. It's all part of "Learn By Destroying(tm)".

Agreed. However, it's worth the effort changing it to see if there's an effect. The probability of a conflict is exteremely low and easy to test.

Sigh. Welcome to the irreproduceable results department. I've lost count of how many bug reports I've submitted that magically fixed themselves for no obvious reason. Since you didn't do anything on your end, my best guess is that it's something on the Cox DHCP server end.

Looks normal. I have yet another guess(tm). DHCP renewals are unicast and directed at the IP of the DHCP server that originally assigned the IP address. If Cox has a pool of such DHCP servers, your DHCP client might be looking for a server that is offline or dropped out of the pool. If the client can't find the original DHCP server, it is suppose to stop and try again later (at an increasing polling frequency). It appears that the Buffalo DHCP client is being more aggressive. If it can't find the original DHCP server, it doesn't stop and try again later. It restarts the negotiation looking for a different DHCP server with a DHCP_DISCOVER broadcast. That's not the way I understand it's suppose to work. If you don't mind, I'll preserve my sanity by not reading the various DHCP related RFC's.

Remember that the MAC addy is related to the manufacturer of the network interface, not the router or type of router. Buffalo also make DSL modems, probably using the same hardware apart from swapping an ethernet WAN port for a phone line Wan port.