Confirmed firmware bug: MN-700 - Paging Neel M.

Hi all!

Just a followup posting on a topic that's been brought up
a few times - including once by myself. If an MN-700 is
sending and recieving data from a few hundred different
IPs consistantly for a few hours, a hard freeze will
occur. Tech support wasn't sure what was going on. They
ended up sending a replacement router which exhibits the
same issue. I'd just made another call and the problem
was sent to a senior tech. They couldn't quite seem to
figure out what was going on and suggested I return it.

Below, I've posted parts of an email sent to Neel and
(E-Mail Removed). In there, I've included a procedure
that'll *should* cause most MN-700s to freeze. It's been
tested with two separate MN-700s, across two or three
firmware versions. (Latest firmware included, FWIW.)


Original email, edited slightly:
After somewhere between 3-6 hours of medium - heavy
WAN traffic, the router will freeze up. Heavy LAN
traffic alone doesn't cause a freeze. When the router
is frozen, the lights are on and look happy enough.
(Modem light blinks, wireless is on and wired(s),
depending on what is connected, are on.) All LAN and
WAN traffic is refused from all computers, wired and
wireless. Just before a freeze, DHCP and DNS will
fail. At that point, for a moment, I am able to ping
WAN / net IP addresses, but am unable to resolve any
domain names. (I.e., I could ping 64.233.x.x, but
a ping for www.google.com fails.) At that point,
pinging the router itself still works. After perhaps a
minute or two after DHCP and DNS are lost, the router
will clam up and can't be pinged or accessed. (All
pings from that point on fail.)

If the wireless computer is rebooted when the router
is frozen, the card is able to connect to the router
with a fine enough signal and authenticate via WEP,
but is unable to obtain an IP. If the computer was on,
the wireless utility says that it is connected with
good signal strengh. Alas, an ipconfig /renew fails
with a timeout from the DHCP server. On wired
connections, a link light is shown, but any computers
that were on are unable to ping the base station. If a
wired computer is turned on after the base station has
failed, it is unable to grab an IP.

The only way to get everything going again is to power
cycle the router. Once the router is power cycled, all
network traffic works OK until the next freeze.

The router has been updated with the most recent
firmware - boot and runtime code 02.01.02.0590. (Edit:
Also tested on 02.00.08.0333) The
router logs don't seem to show anything out of the
ordinary.


Although I'm not the original poster (Edit: This was for
another post on ms.public.broadbandnet.hardware), there
were four
questions in your original reply - will just answer
them here as a batch, in case they might help.

1. Is this happening on wired or wireless connections?
Both.

2. What kind of apps are running on the network at the
time of the crash?
Generally, an AIM client, a bit of web browsing, and
an eMule client or two.


3. What wireless security is turned on (regardless of
the answer to #1)?
WEP, 128 bit.

4. What kind of WAN connection? If PPPoE, is idle
timeout on?
Cable modem.

Clients consist of one Win2K Pro box (wireless) and
two linux boxes (wired). Hardware version of router is
00.00.00.0004. On my side, I can replicate the
conditions which cause a router freeze consistantly.
To cause my router and (perhaps) some other MN-700s to
freeze:

Requirements: A cable/DSL+ net connection, an MN-700
(HW ver 4 - don't know if that matters), a Win2K/XP (for
eMule)
computer hooked up wirelessly to the MN-700 (Win9x and
ME sometimes have problems with a lot of concurrent
connections), and a hard drive with about 40-60 gigs
free - although the router probably will freeze before
it gets near that.

1. Grab a copy of eMule.
(http://sourceforge.net/project/showfiles.php?
group_id=71866
/ www.emuleplus.tk / www.emule-project.net)
2. Setup copy number one to have a TCP and UDP clientports
of your choice.
3. Using the base station management tool, forward
those ports to the eMule client computer.
3. Setup another copy of eMule (making sure, if the
specific version of eMule you are using has such a thing,
the checkbox to allow multiple eMules to run at once is
checked) using different TCP and UDP clientports of your
choice.
4. Using the base station management tool, forward
those ports to the eMule client computer.
5. Make sure max connections on each client are set to
500 or so.
6. Also, make sure that the upload bandwidth is capped
for each client, if that is desired - if the upload
speed is maxed out, downloads will have trouble... no
way to get ACKs back.
7. Connect to a server in each client, making sure it
does not report a low ID. (If you have a lowid, it
will either disconnect you or simply report, under the
log tab that: New clientid is xxxx, where XXXX is a
number under 1,000,000. If you have a number over
1,000,000, should be all set! If a low-id shows up,
*something* isn't letting one of the four ports
operate at it should - sometimes port forwarding needs
a double check or a software firewall needs to be
punched through.)
7. Click on Search on client one, type in Linux, (Big
files that are really legal - boo SCO!) set min file size
to 600 megs, then click on
Start. Using shift, select and start a download for
perhaps the first one hundred files. (I know it seems
like a lot. From what I've found a whole lot less will
cause the router to freeze, but would think this
should almost certainly cause such a thing.)
8. In eMule two, do the same, except only start to
download one of the large files.
9. Wait a few hours. (Probably less than 12.)

With any luck, the computer should still be working
fine, but the router should be frozen. Most likely,
this will also work on a wired connection, with only
one eMule client, and with only 30-75 files or so. The
above always will cause a router freeze for me,
though.

The only way to get the router back is to power cycle
it.

It would seem that there are also a bunch of other
scenarios which might cause the same data profile.
(Perhaps a web server which serves files under 10 megs to
a whole bunch of people... or something of that ilk.)

Any help Neel (or anyone else might be able to provide)
would be wonderful.

Thanks for reading this giant post!

Andy

Ummm... What makes you think that this is a "confirmed bug"?? It could just
as easily be an eMule issue. I downloaded approximately 30GB worth of stuff
last week from various sources - Bittorrent, Usenet, etc. - all the while
surfing the web, fetching mail and using AIM. On top of that, I have daily
backups that run from my 2003 server to my XP box - around 1GB is
transferred via LAN every morning at 8AM.

Having said all that, I have never had my MN-700 lock up. My WAN traffic
was uploading at an almost constant rate of 60kbps from Monday afternoon
until Friday morning, and for most of that time I was also downloading at
anywhere from 3-300kbps. For almost 5 straight days. Of course, this is
with a wired connection, so it could be an issue with the wireless part.



"Andy" <(E-Mail Removed)> wrote in message
news:0e4901c48bae$2a002740$(E-Mail Removed)...
> Hi all!

[huge post clipped]

Kindly Jim,

Thanks for the reply!

I'm pretty sure that it is a firmware bug for a few
reasons... the main one is that nothing on the PC side
(barring a failed firmware update - that might do it. )
should ever cause a router to flat out stop responding.
(When it does stop responding, all computers (wired and
wireless) are unable to ping it (if they have an IP) or
grab an IP address (if they haven't been assigned an IP).)
If there is any situation where traffic alone - even
malformed traffic - can cause a router to shut off all LAN
and WAN traffic, it would seem like that might indicate a
bug.

The reason I'd said it was confirmed was twofold: first,
it's been verified across two routers, with multiple
firmware version. Tech support, across about a week of
time and four hours on the phone, determined that it
wasn't a hardware issue or an issue with any of the
computers. Secondly, and most important, other people here
and elsewhere have been reporting the same issue. Even if
eMule is causing some strange traffic - even if the
traffic is wholly invalid - it would seem that it
shouldn't bring the router itself down.


(FWIW, I've run BT for a while, with a bunch of different
clients, and that doesn't bring the router down. On the
other hand, if BT is sending and recieving the same amount
of data as an eMule client, there *tend to be* (not
always, but usually) a much larger number of
source/destination IPs on the eMule side. BT clients, from
my experience - you may have had better luck, tend to have
trouble with more than ten or so concurrent downloads.
eMule tends to take longer to complete files, so it's
pretty common to have 50-100 files set to transfer
concurrently. Many times, this will lead to more
source/destination IPs for the router to deal with. If
there was an ability to download 50 torrents at once (such
bandwidth you'd need for fairness! ), making destination
IPs equal for BT and eMule... I don't know what would
happen. In the end, though, no transfer that I make
from any box on the network should bring the router down
for all boxes.)

Thanks again for the reply!

Andy

>-----Original Message-----
>Ummm... What makes you think that this is a "confirmed
bug"?? It could just
>as easily be an eMule issue. I downloaded approximately
30GB worth of stuff
>last week from various sources - Bittorrent, Usenet,
etc. - all the while
>surfing the web, fetching mail and using AIM. On top of
that, I have daily
>backups that run from my 2003 server to my XP box -
around 1GB is
>transferred via LAN every morning at 8AM.
>
>Having said all that, I have never had my MN-700 lock
up. My WAN traffic
>was uploading at an almost constant rate of 60kbps from
Monday afternoon
>until Friday morning, and for most of that time I was
also downloading at
>anywhere from 3-300kbps. For almost 5 straight days. Of
course, this is
>with a wired connection, so it could be an issue with the
wireless part.
>
>
>
>"Andy" <(E-Mail Removed)> wrote in
message
>news:0e4901c48bae$2a002740$(E-Mail Removed)...
>> Hi all!
>
>[huge post clipped]
>
>
>.
>

I have the same bug occuring on my MN-700.

I periodically need to give it a hard reboot.

I am running a P2P software program (edonkey), so the
scenario fits - hundreds of IP addresses going through
the wan connection.

...David
>-----Original Message-----
>Kindly Jim,
>
>Thanks for the reply!
>
>I'm pretty sure that it is a firmware bug for a few
>reasons... the main one is that nothing on the PC side
>(barring a failed firmware update - that might do it. )
>should ever cause a router to flat out stop responding.
>(When it does stop responding, all computers (wired and
>wireless) are unable to ping it (if they have an IP) or
>grab an IP address (if they haven't been assigned an
IP).)
>If there is any situation where traffic alone - even
>malformed traffic - can cause a router to shut off all
LAN
>and WAN traffic, it would seem like that might indicate
a
>bug.
>
>The reason I'd said it was confirmed was twofold: first,
>it's been verified across two routers, with multiple
>firmware version. Tech support, across about a week of
>time and four hours on the phone, determined that it
>wasn't a hardware issue or an issue with any of the
>computers. Secondly, and most important, other people
here
>and elsewhere have been reporting the same issue. Even
if
>eMule is causing some strange traffic - even if the
>traffic is wholly invalid - it would seem that it
>shouldn't bring the router itself down.
>
>
>(FWIW, I've run BT for a while, with a bunch of
different
>clients, and that doesn't bring the router down. On the
>other hand, if BT is sending and recieving the same
amount
>of data as an eMule client, there *tend to be* (not
>always, but usually) a much larger number of
>source/destination IPs on the eMule side. BT clients,
from
>my experience - you may have had better luck, tend to
have
>trouble with more than ten or so concurrent downloads.
>eMule tends to take longer to complete files, so it's
>pretty common to have 50-100 files set to transfer
>concurrently. Many times, this will lead to more
>source/destination IPs for the router to deal with. If
>there was an ability to download 50 torrents at once
(such
>bandwidth you'd need for fairness! ), making
destination
>IPs equal for BT and eMule... I don't know what would
>happen. In the end, though, no transfer that I make
>from any box on the network should bring the router down
>for all boxes.)
>
>Thanks again for the reply!
>
>Andy
>
>>-----Original Message-----
>>Ummm... What makes you think that this is a "confirmed
>bug"?? It could just
>>as easily be an eMule issue. I downloaded
approximately
>30GB worth of stuff
>>last week from various sources - Bittorrent, Usenet,
>etc. - all the while
>>surfing the web, fetching mail and using AIM. On top
of
>that, I have daily
>>backups that run from my 2003 server to my XP box -
>around 1GB is
>>transferred via LAN every morning at 8AM.
>>
>>Having said all that, I have never had my MN-700 lock
>up. My WAN traffic
>>was uploading at an almost constant rate of 60kbps from
>Monday afternoon
>>until Friday morning, and for most of that time I was
>also downloading at
>>anywhere from 3-300kbps. For almost 5 straight days.
Of
>course, this is
>>with a wired connection, so it could be an issue with
the
>wireless part.
>>
>>
>>
>>"Andy" <(E-Mail Removed)> wrote in
>message
>>news:0e4901c48bae$2a002740$(E-Mail Removed)...
>>> Hi all!
>>
>>[huge post clipped]
>>
>>
>>.
>>
>.
>

I should add to my prior post, that I was using a linksys
router until I swapped it out for the MN-700 and I had no
problems back then - so I know I don't have any issues on
the LAN/Wireless side.

The problem is in the router - there is a bug that causes
it to stop responding, and nothing short of a hard reset
of the router will fix it.

>-----Original Message-----
>Kindly Jim,
>
>Thanks for the reply!
>
>I'm pretty sure that it is a firmware bug for a few
>reasons... the main one is that nothing on the PC side
>(barring a failed firmware update - that might do it. )
>should ever cause a router to flat out stop responding.
>(When it does stop responding, all computers (wired and
>wireless) are unable to ping it (if they have an IP) or
>grab an IP address (if they haven't been assigned an
IP).)
>If there is any situation where traffic alone - even
>malformed traffic - can cause a router to shut off all
LAN
>and WAN traffic, it would seem like that might indicate
a
>bug.
>
>The reason I'd said it was confirmed was twofold: first,
>it's been verified across two routers, with multiple
>firmware version. Tech support, across about a week of
>time and four hours on the phone, determined that it
>wasn't a hardware issue or an issue with any of the
>computers. Secondly, and most important, other people
here
>and elsewhere have been reporting the same issue. Even
if
>eMule is causing some strange traffic - even if the
>traffic is wholly invalid - it would seem that it
>shouldn't bring the router itself down.
>
>
>(FWIW, I've run BT for a while, with a bunch of
different
>clients, and that doesn't bring the router down. On the
>other hand, if BT is sending and recieving the same
amount
>of data as an eMule client, there *tend to be* (not
>always, but usually) a much larger number of
>source/destination IPs on the eMule side. BT clients,
from
>my experience - you may have had better luck, tend to
have
>trouble with more than ten or so concurrent downloads.
>eMule tends to take longer to complete files, so it's
>pretty common to have 50-100 files set to transfer
>concurrently. Many times, this will lead to more
>source/destination IPs for the router to deal with. If
>there was an ability to download 50 torrents at once
(such
>bandwidth you'd need for fairness! ), making
destination
>IPs equal for BT and eMule... I don't know what would
>happen. In the end, though, no transfer that I make
>from any box on the network should bring the router down
>for all boxes.)
>
>Thanks again for the reply!
>
>Andy
>
>>-----Original Message-----
>>Ummm... What makes you think that this is a "confirmed
>bug"?? It could just
>>as easily be an eMule issue. I downloaded
approximately
>30GB worth of stuff
>>last week from various sources - Bittorrent, Usenet,
>etc. - all the while
>>surfing the web, fetching mail and using AIM. On top
of
>that, I have daily
>>backups that run from my 2003 server to my XP box -
>around 1GB is
>>transferred via LAN every morning at 8AM.
>>
>>Having said all that, I have never had my MN-700 lock
>up. My WAN traffic
>>was uploading at an almost constant rate of 60kbps from
>Monday afternoon
>>until Friday morning, and for most of that time I was
>also downloading at
>>anywhere from 3-300kbps. For almost 5 straight days.
Of
>course, this is
>>with a wired connection, so it could be an issue with
the
>wireless part.
>>
>>
>>
>>"Andy" <(E-Mail Removed)> wrote in
>message
>>news:0e4901c48bae$2a002740$(E-Mail Removed)...
>>> Hi all!
>>
>>[huge post clipped]
>>
>>
>>.
>>
>.
>

Any luck resolving this? I've noticed that when I don't
run edonkey, the router will stay up for days at a time,
but when I run p2p file sharing the router crashes on
average once a day before it needs a reset.

Is there a firmware fix or patch?


>-----Original Message-----
>Hi all!
>
>Just a followup posting on a topic that's been brought
up
>a few times - including once by myself. If an MN-700 is
>sending and recieving data from a few hundred different
>IPs consistantly for a few hours, a hard freeze will
>occur. Tech support wasn't sure what was going on. They
>ended up sending a replacement router which exhibits the
>same issue. I'd just made another call and the
problem
>was sent to a senior tech. They couldn't quite seem to
>figure out what was going on and suggested I return it.
>
>Below, I've posted parts of an email sent to Neel and
>(E-Mail Removed). In there, I've included a
procedure
>that'll *should* cause most MN-700s to freeze. It's been
>tested with two separate MN-700s, across two or three
>firmware versions. (Latest firmware included, FWIW.)
>
>
>Original email, edited slightly:
>After somewhere between 3-6 hours of medium - heavy
>WAN traffic, the router will freeze up. Heavy LAN
>traffic alone doesn't cause a freeze. When the router
>is frozen, the lights are on and look happy enough.
>(Modem light blinks, wireless is on and wired(s),
>depending on what is connected, are on.) All LAN and
>WAN traffic is refused from all computers, wired and
>wireless. Just before a freeze, DHCP and DNS will
>fail. At that point, for a moment, I am able to ping
>WAN / net IP addresses, but am unable to resolve any
>domain names. (I.e., I could ping 64.233.x.x, but
>a ping for www.google.com fails.) At that point,
>pinging the router itself still works. After perhaps a
>minute or two after DHCP and DNS are lost, the router
>will clam up and can't be pinged or accessed. (All
>pings from that point on fail.)
>
>If the wireless computer is rebooted when the router
>is frozen, the card is able to connect to the router
>with a fine enough signal and authenticate via WEP,
>but is unable to obtain an IP. If the computer was on,
>the wireless utility says that it is connected with
>good signal strengh. Alas, an ipconfig /renew fails
>with a timeout from the DHCP server. On wired
>connections, a link light is shown, but any computers
>that were on are unable to ping the base station. If a
>wired computer is turned on after the base station has
>failed, it is unable to grab an IP.
>
>The only way to get everything going again is to power
>cycle the router. Once the router is power cycled, all
>network traffic works OK until the next freeze.
>
>The router has been updated with the most recent
>firmware - boot and runtime code 02.01.02.0590. (Edit:
>Also tested on 02.00.08.0333) The
>router logs don't seem to show anything out of the
>ordinary.
>
>
>Although I'm not the original poster (Edit: This was for
>another post on ms.public.broadbandnet.hardware), there
>were four
>questions in your original reply - will just answer
>them here as a batch, in case they might help.
>
>1. Is this happening on wired or wireless connections?
>Both.
>
>2. What kind of apps are running on the network at the
>time of the crash?
>Generally, an AIM client, a bit of web browsing, and
>an eMule client or two.
>
>
>3. What wireless security is turned on (regardless of
>the answer to #1)?
>WEP, 128 bit.
>
>4. What kind of WAN connection? If PPPoE, is idle
>timeout on?
>Cable modem.
>
>Clients consist of one Win2K Pro box (wireless) and
>two linux boxes (wired). Hardware version of router is
>00.00.00.0004. On my side, I can replicate the
>conditions which cause a router freeze consistantly.
>To cause my router and (perhaps) some other MN-700s to
>freeze:
>
>Requirements: A cable/DSL+ net connection, an MN-700
>(HW ver 4 - don't know if that matters), a Win2K/XP (for
>eMule)
>computer hooked up wirelessly to the MN-700 (Win9x and
>ME sometimes have problems with a lot of concurrent
>connections), and a hard drive with about 40-60 gigs
>free - although the router probably will freeze before
>it gets near that.
>
>1. Grab a copy of eMule.
>(http://sourceforge.net/project/showfiles.php?
>group_id=71866
>/ www.emuleplus.tk / www.emule-project.net)
>2. Setup copy number one to have a TCP and UDP
clientports
>of your choice.
>3. Using the base station management tool, forward
>those ports to the eMule client computer.
>3. Setup another copy of eMule (making sure, if the
>specific version of eMule you are using has such a
thing,
>the checkbox to allow multiple eMules to run at once is
>checked) using different TCP and UDP clientports of your
>choice.
>4. Using the base station management tool, forward
>those ports to the eMule client computer.
>5. Make sure max connections on each client are set to
>500 or so.
>6. Also, make sure that the upload bandwidth is capped
>for each client, if that is desired - if the upload
>speed is maxed out, downloads will have trouble... no
>way to get ACKs back.
>7. Connect to a server in each client, making sure it
>does not report a low ID. (If you have a lowid, it
>will either disconnect you or simply report, under the
>log tab that: New clientid is xxxx, where XXXX is a
>number under 1,000,000. If you have a number over
>1,000,000, should be all set! If a low-id shows up,
>*something* isn't letting one of the four ports
>operate at it should - sometimes port forwarding needs
>a double check or a software firewall needs to be
>punched through.)
>7. Click on Search on client one, type in Linux, (Big
>files that are really legal - boo SCO!) set min file
size
>to 600 megs, then click on
>Start. Using shift, select and start a download for
>perhaps the first one hundred files. (I know it seems
>like a lot. From what I've found a whole lot less will
>cause the router to freeze, but would think this
>should almost certainly cause such a thing.)
>8. In eMule two, do the same, except only start to
>download one of the large files.
>9. Wait a few hours. (Probably less than 12.)
>
>With any luck, the computer should still be working
>fine, but the router should be frozen. Most likely,
>this will also work on a wired connection, with only
>one eMule client, and with only 30-75 files or so. The
>above always will cause a router freeze for me,
>though.
>
>The only way to get the router back is to power cycle
>it.
>
>It would seem that there are also a bunch of other
>scenarios which might cause the same data profile.
>(Perhaps a web server which serves files under 10 megs
to
>a whole bunch of people... or something of that ilk.)
>
>Any help Neel (or anyone else might be able to provide)
>would be wonderful.
>
>Thanks for reading this giant post!
>
>Andy
>
>
>.
>

What hardware version on your MN-700 do you have? This lockup problem
is prolific and if you aren't having any problems I would LOVE to know
what your settings and hardware versions are.


Jim Cofer wrote:
> Ummm... What makes you think that this is a "confirmed bug"?? It
could just
> as easily be an eMule issue. I downloaded approximately 30GB worth
of stuff
> last week from various sources - Bittorrent, Usenet, etc. - all the
while
> surfing the web, fetching mail and using AIM. On top of that, I have
daily
> backups that run from my 2003 server to my XP box - around 1GB is
> transferred via LAN every morning at 8AM.
>
> Having said all that, I have never had my MN-700 lock up. My WAN
traffic
> was uploading at an almost constant rate of 60kbps from Monday
afternoon
> until Friday morning, and for most of that time I was also
downloading at
> anywhere from 3-300kbps. For almost 5 straight days. Of course,
this is
> with a wired connection, so it could be an issue with the wireless
part.
>
>
>
> "Andy" <(E-Mail Removed)> wrote in message
> news:0e4901c48bae$2a002740$(E-Mail Removed)...
> > Hi all!
>
> [huge post clipped]

I wanted to resurface this as it seems to be the only detailed analysis
of this disconnect problem we're all having.

I think this router has a memory leak and after so many IPs access it,
it just gives up.


Andy wrote:
> Hi all!
>
> Just a followup posting on a topic that's been brought up
> a few times - including once by myself. If an MN-700 is
> sending and recieving data from a few hundred different
> IPs consistantly for a few hours, a hard freeze will
> occur. Tech support wasn't sure what was going on. They
> ended up sending a replacement router which exhibits the
> same issue. I'd just made another call and the problem
> was sent to a senior tech. They couldn't quite seem to
> figure out what was going on and suggested I return it.
>
> Below, I've posted parts of an email sent to Neel and
> (E-Mail Removed). In there, I've included a procedure
> that'll *should* cause most MN-700s to freeze. It's been
> tested with two separate MN-700s, across two or three
> firmware versions. (Latest firmware included, FWIW.)
>
>
> Original email, edited slightly:
> After somewhere between 3-6 hours of medium - heavy
> WAN traffic, the router will freeze up. Heavy LAN
> traffic alone doesn't cause a freeze. When the router
> is frozen, the lights are on and look happy enough.
> (Modem light blinks, wireless is on and wired(s),
> depending on what is connected, are on.) All LAN and
> WAN traffic is refused from all computers, wired and
> wireless. Just before a freeze, DHCP and DNS will
> fail. At that point, for a moment, I am able to ping
> WAN / net IP addresses, but am unable to resolve any
> domain names. (I.e., I could ping 64.233.x.x, but
> a ping for www.google.com fails.) At that point,
> pinging the router itself still works. After perhaps a
> minute or two after DHCP and DNS are lost, the router
> will clam up and can't be pinged or accessed. (All
> pings from that point on fail.)
>
> If the wireless computer is rebooted when the router
> is frozen, the card is able to connect to the router
> with a fine enough signal and authenticate via WEP,
> but is unable to obtain an IP. If the computer was on,
> the wireless utility says that it is connected with
> good signal strengh. Alas, an ipconfig /renew fails
> with a timeout from the DHCP server. On wired
> connections, a link light is shown, but any computers
> that were on are unable to ping the base station. If a
> wired computer is turned on after the base station has
> failed, it is unable to grab an IP.
>
> The only way to get everything going again is to power
> cycle the router. Once the router is power cycled, all
> network traffic works OK until the next freeze.
>
> The router has been updated with the most recent
> firmware - boot and runtime code 02.01.02.0590. (Edit:
> Also tested on 02.00.08.0333) The
> router logs don't seem to show anything out of the
> ordinary.
>
>
> Although I'm not the original poster (Edit: This was for
> another post on ms.public.broadbandnet.hardware), there
> were four
> questions in your original reply - will just answer
> them here as a batch, in case they might help.
>
> 1. Is this happening on wired or wireless connections?
> Both.
>
> 2. What kind of apps are running on the network at the
> time of the crash?
> Generally, an AIM client, a bit of web browsing, and
> an eMule client or two.
>
>
> 3. What wireless security is turned on (regardless of
> the answer to #1)?
> WEP, 128 bit.
>
> 4. What kind of WAN connection? If PPPoE, is idle
> timeout on?
> Cable modem.
>
> Clients consist of one Win2K Pro box (wireless) and
> two linux boxes (wired). Hardware version of router is
> 00.00.00.0004. On my side, I can replicate the
> conditions which cause a router freeze consistantly.
> To cause my router and (perhaps) some other MN-700s to
> freeze:
>
> Requirements: A cable/DSL+ net connection, an MN-700
> (HW ver 4 - don't know if that matters), a Win2K/XP (for
> eMule)
> computer hooked up wirelessly to the MN-700 (Win9x and
> ME sometimes have problems with a lot of concurrent
> connections), and a hard drive with about 40-60 gigs
> free - although the router probably will freeze before
> it gets near that.
>
> 1. Grab a copy of eMule.
> (http://sourceforge.net/project/showfiles.php?
> group_id=71866
> / www.emuleplus.tk / www.emule-project.net)
> 2. Setup copy number one to have a TCP and UDP clientports
> of your choice.
> 3. Using the base station management tool, forward
> those ports to the eMule client computer.
> 3. Setup another copy of eMule (making sure, if the
> specific version of eMule you are using has such a thing,
> the checkbox to allow multiple eMules to run at once is
> checked) using different TCP and UDP clientports of your
> choice.
> 4. Using the base station management tool, forward
> those ports to the eMule client computer.
> 5. Make sure max connections on each client are set to
> 500 or so.
> 6. Also, make sure that the upload bandwidth is capped
> for each client, if that is desired - if the upload
> speed is maxed out, downloads will have trouble... no
> way to get ACKs back.
> 7. Connect to a server in each client, making sure it
> does not report a low ID. (If you have a lowid, it
> will either disconnect you or simply report, under the
> log tab that: New clientid is xxxx, where XXXX is a
> number under 1,000,000. If you have a number over
> 1,000,000, should be all set! If a low-id shows up,
> *something* isn't letting one of the four ports
> operate at it should - sometimes port forwarding needs
> a double check or a software firewall needs to be
> punched through.)
> 7. Click on Search on client one, type in Linux, (Big
> files that are really legal - boo SCO!) set min file size
> to 600 megs, then click on
> Start. Using shift, select and start a download for
> perhaps the first one hundred files. (I know it seems
> like a lot. From what I've found a whole lot less will
> cause the router to freeze, but would think this
> should almost certainly cause such a thing.)
> 8. In eMule two, do the same, except only start to
> download one of the large files.
> 9. Wait a few hours. (Probably less than 12.)
>
> With any luck, the computer should still be working
> fine, but the router should be frozen. Most likely,
> this will also work on a wired connection, with only
> one eMule client, and with only 30-75 files or so. The
> above always will cause a router freeze for me,
> though.
>
> The only way to get the router back is to power cycle
> it.
>
> It would seem that there are also a bunch of other
> scenarios which might cause the same data profile.
> (Perhaps a web server which serves files under 10 megs to
> a whole bunch of people... or something of that ilk.)
>
> Any help Neel (or anyone else might be able to provide)
> would be wonderful.
>
> Thanks for reading this giant post!
>
> Andy

My MN700 has never gone down on me outside of a power failure or firmware
upgrade. I've had mine sine May/June 2004. Specs on the hardware are:

Runtime code version:
02.01.02.0590

Boot code version:
02.01.02.0590

Hardware version:
00.00.00.0004

I use static IP's, WEP and 802.11g. I have my PowerBook and sons XPsp2 box
(MN710) using wireless and my two other PCs on the switch. Never had a
hiccup of any sort. I am thinking about getting a Linksys so I can use a
range extender and wireless cameras for property surveillance.

On 01/15/2005 7:35 PM, in article
(E-Mail Removed). com, "Inteller"
<(E-Mail Removed)> wrote:

> What hardware version on your MN-700 do you have? This lockup problem
> is prolific and if you aren't having any problems I would LOVE to know
> what your settings and hardware versions are.
>
>
> Jim Cofer wrote:
>> Ummm... What makes you think that this is a "confirmed bug"?? It
> could just
>> as easily be an eMule issue. I downloaded approximately 30GB worth
> of stuff
>> last week from various sources - Bittorrent, Usenet, etc. - all the
> while
>> surfing the web, fetching mail and using AIM. On top of that, I have
> daily
>> backups that run from my 2003 server to my XP box - around 1GB is
>> transferred via LAN every morning at 8AM.
>>
>> Having said all that, I have never had my MN-700 lock up. My WAN
> traffic
>> was uploading at an almost constant rate of 60kbps from Monday
> afternoon
>> until Friday morning, and for most of that time I was also
> downloading at
>> anywhere from 3-300kbps. For almost 5 straight days. Of course,
> this is
>> with a wired connection, so it could be an issue with the wireless
> part.
>>
>>
>>
>> "Andy" <(E-Mail Removed)> wrote in message
>> news:0e4901c48bae$2a002740$(E-Mail Removed)...
>>> Hi all!
>>
>> [huge post clipped]
>

--

Do you have ICMP turned off?