dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
3038
hogwild6
join:2004-03-14
Canada

hogwild6

Member

Line drops / Error accesing P660R-61 web configuration

Hi everyone:

We have a Prestige 660R-61 which has been working fine for years. Firmware is 3.40(QG.7) Oct. 08/2005

Recently, we started to have our DSL connection drop more and more often, so I looked into it.
The ISP can't find any problems with the signal, and our local Telco did a line test and found
strong signal with very little noise. I checked the house, and there are no phones without filters,
and everything else has not changed (it worked fine for almost 2 years.)

I went through the firmware changelog for the 660R-61 (US) and couldn't find anything about
dropped DSL links that stood out. I can't find any pattern to the drops. Does anyone know
anything about this?

My second question:
While trying to fix the first problem, I reset the modem to factory defaults. Afterwards,
I could not get access via web configurator. I can login via Telnet, but when I try via
web browser, I get:
"Protected ojbect. This object on the Prestige 660R-61 is protected"
 

It doesn't matter which port I use, or which browser. I've tried clearing the browser cache.
I see a few have posted about this issue on net, but in most cases, I don't see any
real solutions. In any case, I tried the solutions posted on other sites with no success.

If anyone can help, I need to do this as soon as possible.

Thanks in advance for any help

HogWild
hogwild6

hogwild6

Member

Okay, one of the two problems has been fixed. I did a factory reset using the hardware switch this time, and I got the GUI web interface back.

The second problem may still be there. I'm wondering if this model is susceptible to problems with open NAT sessions. We do use BitTorrent here sometimes, and I wonder if perhaps there are not enough NAT sessions available for that. Anyone know if that will cause a disconnect in this modem?

HogWild
JPedroT
Premium Member
join:2005-02-18

JPedroT to hogwild6

Premium Member

to hogwild6
try the following commands to see how many sessions your device has used.

sys tos historicalHigh
sys tos historicalCHigh

If they do not work, try

ip nat hash mpoa00
hogwild6
join:2004-03-14
Canada

1 edit

hogwild6

Member

Thanks dslpartner.

The other commands don't appear to be available, or the syntax isn't right.

The last command worked, but showed no results other than the column headings.

Would this likely be because I rebooted the modem yesterday, and haven't used a P2P sharing client since?

HogWild
JPedroT
Premium Member
join:2005-02-18

JPedroT

Premium Member

The first set of commands is probably not available on your device.

The second should give you a list of all your nat sessions, so if you are not online, well then it will be empty.

Also what does the log say after a disconnect

sys log disp
hogwild6
join:2004-03-14
Canada

hogwild6

Member

D'Oh! I'm so rusty when it comes to networking stuff that I forgot
to check the log BEFORE I set modem to factory defaults.

I haven't had any disconnects since last night. I'll try to
load up the system with P2P traffic, and check the logs, even if
the modem doesn't drop the connection.

That should be enough for now, yes?

HogWild
hogwild6

1 edit

hogwild6

Member

Okay. Just got off the phone with local ISP. I asked them to do a bandwidth test, and check our profile speed. They got the same that I did. Roughly 700K downstream and 512K upstream.

Moreover, the noise margin is 2 upstream and 4 downstream.
Isn't 10 or 11 optimal for minimal loss of sync.?

We are paying for 5MB down, (I can't remember what upstream speed). The minimum profile is supposed to be 3008 down and 512 up. The speeds went bad after we initially called Bell. So maybe Bell messed up something.

Bell is supposed to come to our location tomorrow evening. I will press them to get us a line profile with the minimum speed.

Shplad
Expand your moderator at work
JPedroT
Premium Member
join:2005-02-18

JPedroT to hogwild6

Premium Member

to hogwild6

Re: Line drops / Error accesing P660R-61 web configuration

wan adsl lineperf near
wan adsl lineperf far

If my memory is correct, then again there is a host of sub commands you can play with under wan adsl.

If your noisemargins are as low as 2-4 then its a bad link, for lines with no noise on them, we usually have 6 as the minimum noise level.
hogwild6
join:2004-03-14
Canada

1 edit

hogwild6

Member

Here we go again.

1. We had a Bell/Sympatico tech. here earlier in the week. He blamed the problem on our alarm system wiring. Said it was shorted, causing both DSL drops and bandwidth problems.

2. I had the alarm tech. in, who of course blamed it on the Bell/Sympatico tech.

I contacted my ISP again. Four times. After some confusing communications between all three, a Bell/Sympatico tech. showed up late this afternoon. He said the problem was fixed by connecting us to a neighbourhood Stinger, which is under one kilometre away. Supposedly we were originally connected to a CO 3.3 km away.

I looked at my modem's stats, and it read 4032K downstream. I didn't notice that upstream was only 512K, and that noise stats were poor, so after being rushed, I signed off on the Sympatico work order.

20 minutes after the Sympatico tech. left, the DSL signal dropped again. We are back up again now, but who knows what's really going on.

Here are the stats from the modem's command-line interface.

Copyright (c) 1994 - 2004 ZyXEL Communications Corp.
Zyxel P660R-61> wan adsl perfdata
near-end FEC error fast:   0
near-end FEC error interleaved:   0
near-end CRC error fast:   0
near-end CRC error interleaved:   0
near-end HEC error fast:   0
near-end HEC error interleaved:   0
far-end FEC error fast:   0
far-end FEC error interleaved:  68
far-end CRC error fast:   0
far-end CRC error interleaved:   4
far-end HEC error fast:   0
far-end HEC error interleaved: 136
Zyxel P660R-61>
 
================================================
 
Zyxel P660R-61> wan adsl linedata near
noise margin downstream: 31 db
output power upstream: 12 db
attenuation downstream: 16 db
carrier load: number of bits per symbol(tone)
tone   0- 31: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
tone  32- 63: 00 00 00 00 00 04 55 66 66 77 77 77 77 77 77 77
tone  64- 95: 07 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77
tone  96-127: 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77 77
tone 128-159: 77 76 66 65 40 45 65 56 66 55 22 55 66 66 66 66
tone 160-191: 66 66 66 66 66 66 56 66 66 66 56 66 66 66 65 45
tone 192-223: 55 55 55 53 45 55 55 55 55 55 55 55 55 55 55 55
tone 224-255: 55 55 55 55 44 03 44 44 43 20 02 23 33 32 22 00
tone 256-287: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
tone 288-319: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
tone 320-351: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
tone 352-383: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
tone 384-415: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
tone 416-447: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
tone 448-479: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
tone 480-511: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 
======================================
 
noise margin upstream: 6 db
output power downstream: 9 db
attenuation upstream: 12 db
carrier load: number of bits per symbol(tone)
tone   0- 31: 00 00 00 03 45 56 77 88 77 78 88 88 77 66 65 55
tone  32- 63: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
tone  64- 95: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
tone  96-127: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
tone 128-159: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
tone 160-191: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
tone 192-223: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
tone 224-255: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
tone 256-287: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
tone 288-319: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
tone 320-351: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
tone 352-383: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
tone 384-415: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
tone 416-447: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
tone 448-479: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
tone 480-511: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 
 

These don't look like good numbers to me for a system that's supposedly connected to a link just half a kilometre away.

I wonder whether the original problems could have been caused by both a bad line AND some faulty (or intermittent?) wiring.

I've been asked by my ISP to monitor the connection for 24 hours, and get back to them.

Any attempts to speak with Sympatico by phone directly results in being told they can't help. Anyone know of a way around that?

HogWild
OGalati
join:2005-08-19
1682

OGalati

Member

It's at least suspicious that consistent limit of 7 bit per tone with your good SNR Margin.
That limit, to achieve the 4Mbps, are forcing the sync to use higher tones to the end of the spectrum with lower SNR.
You'd try
wan adsl driver dnmaxbits 15
to check if there is a manual limit that can be removed.
hogwild6
join:2004-03-14
Canada

hogwild6

Member

Thanks for that.

I wish I could understand all of that.

How would I (or would I be able to) reverse that command to put things back to the way they were, if it were to not work?

HogWild
OGalati
join:2005-08-19
1682

OGalati

Member

Yes, if you are limited to 7 bits per bin you could go back to actual state with
wan adsl driver dnmaxbits 7
If you are not actually limited in this way, then that other command (15 bits) will have not effect, because 15 is the maximum and standard stated for ADSL, and the modem will allocate the maximum allowable by real SNR.
In the last and worst case: push the reset button.
hogwild6
join:2004-03-14
Canada

1 edit

hogwild6 to OGalati

Member

to OGalati
OGalati:

Thanks very much for that info.

I tried using the wan adsl driver dnmaxbits 15 command. I issued the command,
and nothing happened the first one or two times. The second time, it seemed to
reset the line, and then we'd get DSL connectivity, but seemingly,
no IP connectivity. I can't say I understand that.

Then, after I set dnmaxbits back to 7, I was able to get the connection back to sync.
up to where it was earlier:
3032 down
512k up,
Same noise and tone figures as above.

Should I now try it with values between 7 and 15 to see whether that will improve
my line stats?

BTW, the connection has at least been stable in terms of not dropping and keeping the same
line stats for 3 days now.

Oh, can anyone point me to a primer on understanding some of the text in the modem's error log
and some ATM terminology? I barely understand any of it, and it would obviously help for me
to learn more.

HogWild
said by OGalati:

It's at least suspicious that consistent limit of 7 bit per tone with your good SNR Margin.
That limit, to achieve the 4Mbps, are forcing the sync to use higher tones to the end of the spectrum with lower SNR.
You'd try
wan adsl driver dnmaxbits 15
to check if there is a manual limit that can be removed.
OGalati
join:2005-08-19
1682

OGalati

Member

said by hogwild6:

I tried using the wan adsl driver dnmaxbits 15 command. I issued the command,
and nothing happened the first one or two times. The second time, it seemed to
reset the line, and then we'd get DSL connectivity, but seemingly,
no IP connectivity. I can't say I understand that.

Then, after I set dnmaxbits back to 7, I was able to get the connection back to sync.
up to where it was earlier
I can't figure out how DSL bits allocation can be related to IP Layer.
I guess you reset the DSL link without appropriately closing the PPPoE session, thus, the PPPoE server must close your session by timeout, that could take several minutes to do. In that lapse you went back to 7 bits per tone. You might to close the PPPoE connection before use ADSL commands or reset the DSL link. If you are in bridge mode, disconnect from PPPoE dialer. If you are in router mode, go to menu 11 and deactivate the active node.
Should I now try it with values between 7 and 15 to see whether that will improve
my line stats?
Yes, you'd play a bit with it.

Best regards.
OG
hogwild6
join:2004-03-14
Canada

hogwild6

Member

I'll try those things. Thanks again.

Any way I might be able to persuade the local Bell carrier
to do something about the noise/low upstream issue? I'm guessing they'll just tell me I've got the bandwidth I need, and so I should shut up and be happy, right?

Hogwild
OGalati
join:2005-08-19
1682

OGalati

Member

They must provide you the bandwidth you purchased. They could say you that you must forget about the SNR issue if they provide you a decent stability. In the mid-time, you must be sure your instability is not because of a misconfiguration in the modem provided by them.
hogwild6
join:2004-03-14
Canada

hogwild6

Member

Okay, well, after a few more days, we're getting NO DSL at all from our ISP through Bell's line.

I've tested the problem at the demarc point again, and also tried with other cables, and two more DSL modems.
The problem clearly lies with Bell. I can't tell if the error message is generic, or is accurate, but it suggests
that there is an ATM link layer connection, but no packets going through because PPPoE server did not respond to
authentication requests.

We have now been 4 days in a row with no connection at all, and 5 days in total this week. I'm losing my patience with
Bell's games. We have two trouble tickets in with our 3rd party ISP, but no response yet from Bell.

Welcome to Canada, where it can feel like a third world country.

HogWild
hogwild6

hogwild6

Member

Well, we have had no DSL since Thursday afternoon. Apparently, Bell's great "repair" included making sure there was no connectivity at all.

I had about 5 more phone calls to our 3rd party isp, and another 4-5 hours of them stalling by questioning the modem config. Two diff modems (a Speedstream 4200 as well) now clearly indicate from their logs that PPPoE authentication requests are not being answered. Of course, this could be for several reasons.

Bell phoned me on Mon. to tell me they admitted it was a line problem, and they were sending a tech. out to the house on Mon. That, of course, never happened. I was told the same thing by the ISP on Tues. Big surprise, no one showed up. It seems Bell's monopoly is well established.

After I spoke with another supervisor at our ISP, Bell came out to the house (for the 3rd time) today. The tech. claims to have tested the line, and reset the node. He changed our profile to 5 meg up 512k down, and when I asked him if this would increase the chances of disconnects, he insisted it wouldn't. He said that Bell could not possibly provide better than 6dB upstream noise margin due to the fact that the CO was 4.3 KM away. I thought the only important link in terms of distance was the one to the Stinger, no?

Bell tech. left here saying there was nothing else he could do. I fear that we will have no sync again in days or even hours.

I thought about getting another modem such as a 2wire or Paradyne, to see if that could squeeze better noise margins out of the line.

Is it likely Bell can't fix the problem due to distance, or is it more likely that the problem is a load coil or tap or something they just dont' WANT to fix?

Thanks again all.

HogWild