Re: Buffalo router disupts internet connection on lease renewal
- From: Jeff Liebermann <jeffl@xxxxxxxxxxxxxxxxxxxxxx>
- Date: Sat, 10 Mar 2007 08:53:41 -0800
Peabody <waybackNO784SPAM44@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxx
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558
.
- References:
- Re: Buffalo router disupts internet connection on lease renewal
- From: Jeff Liebermann
- Re: Buffalo router disupts internet connection on lease renewal
- From: Jeff Liebermann
- Re: Buffalo router disupts internet connection on lease renewal
- Prev by Date: Re: cisco 350 devices not assoicating
- Next by Date: Re: BUFFALO WLI-U2-KG54-AI USB adaptor stopped being 'recognized'
- Previous by thread: Re: Buffalo router disupts internet connection on lease renewal
- Next by thread: Re: Buffalo router disupts internet connection on lease renewal
- Index(es):
Relevant Pages
|
