Buffalo router disupts internet connection on lease renewal

I have a Buffalo WHR-HP-G54 router. On the LAN side I have two
computers, one Ethernet and one wireless. The WAN side goes to a
Motorola SB5120 cablemodem and then to Cox Cable.

On the LAN side I have DHCP disabled, and both computers have
specific IPs assigned. On the WAN side the router obtains a
24-hour dynamic IP lease from Cox.

Half way through the lease, the router apparently renews it, but in
doing so drops the internet connection for a while. I just wondered
if that's necessary. I'm pretty sure that never happened when I had
one computer connected directly to the cablemodem, and Windows
handled the DHCP. Couldn't the router just Renew instead of
starting over?

Or, do I have something set wrong?

On Thu, 08 Mar 2007 07:51:19 -0600, Peabody
<(E-Mail Removed)> wrote in
<qxUHh.14979$(E-Mail Removed)>:

>I have a Buffalo WHR-HP-G54 router. On the LAN side I have two
>computers, one Ethernet and one wireless. The WAN side goes to a
>Motorola SB5120 cablemodem and then to Cox Cable.
>
>On the LAN side I have DHCP disabled, and both computers have
>specific IPs assigned.

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

>On the WAN side the router obtains a
>24-hour dynamic IP lease from Cox.
>
>Half way through the lease, the router apparently renews it, but in
>doing so drops the internet connection for a while. I just wondered
>if that's necessary.

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?

>I'm pretty sure that never happened when I had
>one computer connected directly to the cablemodem, and Windows
>handled the DHCP.

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

>Couldn't the router just Renew instead of
>starting over?

Yes.

>Or, do I have something set wrong?

Possibly.

--
Best regards, FAQ for Wireless Internet: <http://Wireless.wikia.com>
John Navas FAQ for Wi-Fi: <http://wireless.wikia.com/wiki/Wi-Fi>
Wi-Fi How To: <http://wireless.wikia.com/wiki/Wi-Fi_HowTo>
Fixes to Wi-Fi Problems: <http://wireless.wikia.com/wiki/Wi-Fi_Fixes>

Peabody <(E-Mail Removed)> wrote:

> I have a Buffalo WHR-HP-G54 router. On the LAN side I have two
> computers, one Ethernet and one wireless. The WAN side goes to a
> Motorola SB5120 cablemodem and then to Cox Cable.
>
> On the LAN side I have DHCP disabled, and both computers have
> specific IPs assigned. On the WAN side the router obtains a
> 24-hour dynamic IP lease from Cox.
>
> Half way through the lease, the router apparently renews it, but in
> doing so drops the internet connection for a while. I just wondered
> if that's necessary. I'm pretty sure that never happened when I had
> one computer connected directly to the cablemodem, and Windows
> handled the DHCP. Couldn't the router just Renew instead of
> starting over?
>
> Or, do I have something set wrong?

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 <(E-Mail Removed)> hath wroth:

>I have a Buffalo WHR-HP-G54 router. On the LAN side I have two
>computers, one Ethernet and one wireless. The WAN side goes to a
>Motorola SB5120 cablemodem and then to Cox Cable.
>
>On the LAN side I have DHCP disabled, and both computers have
>specific IPs assigned. On the WAN side the router obtains a
>24-hour dynamic IP lease from Cox.
>
>Half way through the lease, the router apparently renews it, but in
>doing so drops the internet connection for a while.

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.

>I just wondered
>if that's necessary.

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.

>I'm pretty sure that never happened when I had
>one computer connected directly to the cablemodem, and Windows
>handled the DHCP. Couldn't the router just Renew instead of
>starting over?

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.

>Or, do I have something set wrong?

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.

--
Jeff Liebermann (E-Mail Removed)
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

Jeff Liebermann says...

>> Half way through the lease, the router apparently
>> renews it, but in doing so drops the internet
>> connection for a while.

> 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.

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

>> I'm pretty sure that never happened when I had one
>> computer connected directly to the cablemodem, and
>> Windows handled the DHCP. Couldn't the router just
>> Renew instead of starting over?

> 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 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.

On Fri, 09 Mar 2007 17:32:28 -0600, Peabody
<(E-Mail Removed)> wrote:

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

So much for that theory.

>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):

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

>07:21:35 CONFIGURE WAN DHCPCD RENEW
(Client requests a DHCP renewal)
>07:21:36 DHCPC fail to try rebinding
(Client tries to reopen old connection to DHCP server)
>07:21:36 DHCPC dhcpStop: ioctl SIOCSIFNETMASK: Invalid argument
(Tries to set netmask for interface and fails)
>07:21:36 DHCPC del resolve
> Invalid argument
(clears DNS servers (resolver)? What on earth for?)
>07:21:36 DHCPC OpenDhcpSocket: can't set initial netmask:
(Fails again setting netmask as it tries to contact DHCP server)
>07:21:36 DHCPC Request: broadcasting DHCP_DISCOVER
(Client starts over with a new DHCP session)

>It looks like something is going wrong, so it starts over.

Agreed.

>The only thing that I'm doing that may be different from
>normal is to spoof the router's MAC.

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.

>I just like to get a
>different IP from time to time, and changing the MAC does
>that.

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.

--
# Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
# 831-336-2558 (E-Mail Removed)
# http://802.11junk.com (E-Mail Removed)
# http://www.LearnByDestroying.com AE6KS

On Sat, 10 Mar 2007 00:14:10 GMT, in alt.internet.wireless , Jeff
Liebermann <(E-Mail Removed)> wrote:

>On Fri, 09 Mar 2007 17:32:28 -0600, Peabody
><(E-Mail Removed)> wrote:
>
>
>>I just like to get a
>>different IP from time to time, and changing the MAC does
>>that.
>
>Yeah, but what are your chances of picking a MAC address that's
>already in use on the system? Be careful (or more random).

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.
--
Mark McIntyre

Jeff Liebermann says...

>> The only thing that I'm doing that may be different
>> from normal is to spoof the router's MAC.

> 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.

>> I just like to get a different IP from time to time,
>> and changing the MAC does that.

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

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.

> Can I assume firmware version 1.40?

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 <(E-Mail Removed)> hath wroth:

>I use a non-random range of 16 sequential numbers beginning
>with the MAC of my old DSL modem from the SBC days.

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)".

>I feel pretty safe with that.

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.

> > Can I assume firmware version 1.40?
>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.

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.

>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
>

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.

--
Jeff Liebermann (E-Mail Removed)
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

On Sat, 10 Mar 2007 08:01:48 -0600, in alt.internet.wireless , Peabody
<(E-Mail Removed)> wrote:

>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.

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.

--
Mark McIntyre