Re: Buffalo router disupts internet connection on lease renewal

Peabody <waybackNO784SPAM44@yahoo.com> 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 jeffl@comix.santa-cruz.ca.us
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

On Fri, 09 Mar 2007 17:32:28 -0600, Peabody
<waybackNO784SPAM44@yahoo.com> 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 jeffl@comix.santa-cruz.ca.us
# http://802.11junk.com jeffl@cruzio.com
# http://www.LearnByDestroying.com AE6KS

On Sat, 10 Mar 2007 00:14:10 GMT, in alt.internet.wireless , Jeff
Liebermann <jeffl@comix.santa-cruz.ca.us> wrote:

>On Fri, 09 Mar 2007 17:32:28 -0600, Peabody
><waybackNO784SPAM44@yahoo.com> 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

Peabody <waybackNO784SPAM44@yahoo.com> 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 jeffl@comix.santa-cruz.ca.us
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
<waybackNO784SPAM44@yahoo.com> 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