unreliable DSL in Washinton DC
slownet
Enthusiast - Level 3

I live in a neighborhood that is not served by FiOS because it is in Washinton DC - one mile from the vice Presidents House.  Go figure.  So I have a DSL link and it crashes occasionally - sometimes it runs for a month but some periods it crashes frequently.  The most recent period of crashes began about a month ago.  I do have a fix - reboot the router - but that gets tedious.  The router is always up and available when the link is down so I feel quite comfortable that the problem is the link and not the router. I called support - telephone works OK even when DSL is down - and they gave me the usual spiel about checking my line.  It was working fine b/c I rebooted the router so they saw no problems.  Since 2 Aug I have been keeping track of the problem and one no day have I not had to reboot.  That is, 9 days I had to reboot at least once and on six of those days I had to reboot twice in one day.  I reboot whe I see it is down, mornings and evenings generally, but that probably is an artifact of my work schedule.  I considered writing a script to ping somewhere every 10 minutes to track when the link goes down to see if there is a pattern to when the local switch reboots their DSL interfaces and leaves me hanging.  I've also considered using the neighborhood chatlist to see if any other people are having problems with their Verizon DSL service.

Anyone else have any ideas for getting reliable Verizon DSL service in the nation's captal? 

0 Likes
Reply
1 Solution
slownet
Enthusiast - Level 3

You are right - thanks.  The line went down again this morning and I checked the transceiver stats before rebooting.  The downlink noise margin was 0.-3 (sic) when it usually is around 6.  After rebooting it was back to 6.

Thankyou for the help. 

View solution in original post

0 Likes
Reply
22 Replies
Telcoguru
Master - Level 1
Is the DSL light going out when you lose your internet connection? Please post your modem stats it would help to see if anything is wrong with the line.
0 Likes
Reply
dslr595148
Community Leader
Community Leader
If you have no idea on what "Telcoguru" meant, the brand and model of your router would help...
0 Likes
Reply
slownet
Enthusiast - Level 3
The light that reads "Internet" has changed to red from green.  All other lights remain green and active.
0 Likes
Reply
slownet
Enthusiast - Level 3

Whew, for a while there I thought I'd have a day without a lost connection.  The "internet" light doesn't turn red, it goes off when the link is lost.  The "DSL" light remains green as does "power" and "E1."  "Wireless" also remains green.  In other words, the only visible difference between connected and disconnected is that the "internet" light goes out.  As seen from my computer, the router also remains fully accessible with no signs that it has suffered an internal malfunction.

Next time it is down I'll go through the system logs to see if they add any useful data although I have little doubt that the problem lies between my Westell 5700 and the local c/o.  Looking at the logs now just tells me what happened after I rebooted.

Appreciate the assistance. 

0 Likes
Reply
Telcoguru
Master - Level 1
Please post your modem stats from this page. http://192.168.1.1/transtat.htm
0 Likes
Reply
slownet
Enthusiast - Level 3
This is the log for this morning's link loss.  I've removed some computer names used on my network and begun the log when errors begin to appear right before the crash.  I laos had to delete soem redundant messages to avoid exceeding the max message length on this forum.  I'll collect more stats next time it crashes.  I was fortunate to be at my computer as the link went down.  By now I'm not going to bother resetting the clock in the modem to summertime.  Thanks for the assist.
 
Time Severity Process Details
Aug 13 05:23:29 daemon.notice pppd[937]: Westell PPP Environment:device:nas1 linkname:config0 
iplocal:96.231.xx.xxipremote:10.1.78.1 ppplogname:root orig_uid:0 connect_time:303452220 xx.xx
161.12
Aug 13 05:23:29 daemon.warn pppd[937]: pppd[937] EXIT_PPPOE_TIMEOUT_PADO caused InternetFail 

light to be lit
Aug 13 05:23:29 daemon.notice pppd[937]: PPPD Exit Status changed 

EXIT_OK->EXIT_PPPOE_TIMEOUT_PADO during phase PHASE_SERIALCONN->PHASE_HOLDOFF
Aug 13 05:23:29 daemon.notice pppd[937]: Westell phase_hook PHASE=PHASE_HOLDOFF(11)
 05:23:29 daemon.notice pppd[937]: Westell Random Holdoff returning 454 seconds
 05:23:29 daemon.warn pppd[937]: Leaving destroy_pppoesessionfile
 05:23:29 daemon.err pppd[937]: Unlinking PPPoE session file:/WFIO/ppp-config0
 05:23:29 daemon.warn pppd[937]: Enter destroy_pppoesessionfile
 05:23:29 daemon.err pppd[937]: Unable to complete PPPoE Discovery
 05:23:29 daemon.warn pppd[937]: Timeout waiting for PADO packets
 05:23:29 daemon.warn pppd[937]: waitForPADO: timed out
 05:23:19 daemon.warn pppd[937]: waitForPADO: timed out
 05:23:14 daemon.warn pppd[937]: waitForPADO: timed out
 05:23:09 daemon.notice pppd[937]: Westell PPP Environment:device:nas1 linkname:config0 
iplocal:96.231.xx.xx ipremote:10.1.78.1 ppplogname:root orig_uid:0 connect_time:303452220 
bytes_sent:9263314 bytes_rcvd:176378351 usepeerdns:1 dns1:71.252.0.12 dns2:68.237.xxx.xx
Aug 13 05:23:09 daemon.notice pppd[937]: PPPD Exit Status changed EXIT_PEER_DEAD->EXIT_OK during 

phase PHASE_DORMANT->PHASE_SERIALCONN
Aug 13 05:23:09 daemon.notice pppd[937]: Westell phase_hook PHASE=PHASE_SERIALCONN(2)
Aug 13 05:23:09 daemon.notice pppd[937]: Wan link is up and PPPoE Terminator on DSL:nas1 is done 

working
Aug 13 05:23:09 daemon.notice pppd[937]: Westell PPP Environment:device:nas1 linkname:config0 

iplocal:96.231.xx.xx ipremote:10.1.78.1 ppplogname:root orig_uid:0 connect_time:303452220 

bytes_sent:9263314 bytes_rcvd:176378351 usepeerdns:1 dns1:71.252.0.12 dns2:68.237.xxx.xx
Aug 13 05:23:09 daemon.notice pppd[937]: Westell phase_hook PHASE=PHASE_DORMANT(3)
Aug 13 05:18:33 daemon.info dnsmasq[189]: DHCPACK(br0) 192.168.1.42 00:13:d3:51:08:76 
Aug 13 05:18:33 daemon.info dnsmasq[189]: DHCPINFORM(br0) 192.168.1.42 00:13:d3:51:08:76
Aug 13 05:18:04 daemon.err cwmpd[234]: ddnsWanIPCallback WAN State Down
Aug 13 05:18:01 daemon.notice pppd[937]: Westell PPP Environment:device:nas1 linkname:config0 
iplocal:96.231.xx.xx ipremote:10.1.78.1 ppplogname:root orig_uid:0 connect_time:303452220 
bytes_sent:9263314 bytes_rcvd:176378351 usepeerdns:1 dns1:71.252.0.12 dns2:68.237.xxx.xx
Aug 13 05:18:01 daemon.notice pppd[937]: Westell phase_hook PHASE=PHASE_HOLDOFF(11)
Aug 13 05:18:01 daemon.notice pppd[937]: Westell Random Holdoff returning 308 seconds
Aug 13 05:18:01 daemon.warn pppd[937]: Leaving destroy_pppoesessionfile
Aug 13 05:18:01 daemon.err pppd[937]: Unlinking PPPoE session file:/WFIO/ppp-config0
Aug 13 05:18:01 daemon.warn pppd[937]: Enter destroy_pppoesessionfile
Aug 13 05:18:01 daemon.notice pppd[937]: Westell PPP Environment:device:nas1 linkname:config0 

iplocal:96.231.xx.xx ipremote:10.1.78.1 ppplogname:root orig_uid:0 connect_time:303452220 

bytes_sent:9263314 bytes_rcvd:176378351 usepeerdns:1 dns1:71.252.0.12 dns2:68.237.xxx.xx
 05:18:01 daemon.info pppd[937]: Sent 9263314 bytes,received 176378351 bytes.
 05:18:01 daemon.info pppd[937]: Connect time 5057537.0 minutes.
 05:18:01 daemon.notice pppd[937]: Connection terminated.
 05:18:01 daemon.notice pppd[937]: Westell PPP Environment:device:nas1 ifname:ppp0 
linkname:config0 iplocal:96.231.87.49 ipremote:10.1.78.1 ppplogname:root orig_uid:0 
connect_time:303452220 bytes_sent:9263314 bytes_rcvd:176378351 usepeerdns:1 dns1:71.252.0.12 
dns2:68.237.xxx.xx
Aug 13 05:18:00 daemon.warn pppd[937]: pppd[937] EXIT_PEER_DEAD caused InternetFail light to be lit
Aug 13 05:18:00 daemon.notice pppd[937]: PPPD Exit Status changed EXIT_OK->EXIT_PEER_DEAD during 
phase PHASE_ESTABLISH->PHASE_DEAD
 05:18:00 daemon.notice pppd[937]: Westell phase_hook PHASE=PHASE_DEAD(0)
 05:17:58 daemon.notice net_mgr[237]: Routes transitioning to Down state on ppp0.
 05:17:58 daemon.notice net_mgr[237]: QoS on ppp0 transitioning to Down state.
3 05:17:55 daemon.notice ip-down[1129]: ppp0: 9263314 bytes sent,176378351 bytes received
 05:17:54 daemon.notice ip-down[1129]: ppp0: disconnected;connected for 303452220 seconds
 05:17:54 daemon.warn pppd[937]: Couldn t increase MRU to 1500
3 05:17:54 daemon.warn pppd[937]: Couldn t increase MTU to 1500
 05:17:54 daemon.notice pppd[937]: Westell PPP Environment:device:nas1 ifname:ppp0 

linkname:config0 iplocal:96.231.xx.xx ipremote:10.1.78.1 ppplogname:root orig_uid:0 

connect_time:303452220 bytes_sent:9263314 bytes_rcvd:176378351 usepeerdns:1 dns1:71.252.x.xx
dns2:68.237.xxx.xx
Aug 13 05:17:54 daemon.notice pppd[937]: Westell phase_hook PHASE=PHASE_ESTABLISH(4)
Aug 13 05:17:54 daemon.notice pppd[937]: Westell PPP Environment:device:nas1 ifname:ppp0 
linkname:config0 iplocal:96.231.87.49 ipremote:10.1.78.1 ppplogname:root orig_uid:0 
connect_time:303452220 bytes_sent:9263314 bytes_rcvd:176378351 usepeerdns:1 dns1:71.252.x.xx
dns2:68.237.xxx.xx
Aug 13 05:17:54 daemon.notice pppd[937]: Westell phase_hook PHASE=PHASE_NETWORK(7)
Aug 13 05:17:54 daemon.notice pppd[937]: Westell PPP Environment:device:nas1 ifname:ppp0 
linkname:config0 iplocal:96.231.87.49 ipremote:10.1.78.1 ppplogname:root orig_uid:0 
connect_time:303452220 bytes_sent:9263314 bytes_rcvd:176378351 usepeerdns:1 dns1:71.252.x.xx
dns2:68.237.xxx.xx
Aug 13 05:17:54 daemon.notice pppd[937]: Westell ip_down()
Aug 13 05:17:54 daemon.notice pppd[937]: Westell PPP Environment:device:nas1 ifname:ppp0
linkname:config0 iplocal:96.231.xx.xx ipremote:10.1.78.1 ppplogname:root orig_uid:0 usepeerdns:1 
dns1:71.252.0.12 dns2:68.237.xxx.xx
Aug 13 05:17:54 daemon.notice pppd[937]: Westell phase_hook PHASE=PHASE_TERMINATE(9)
Aug 13 05:17:54 daemon.notice pppd[937]: Serial link appears to be disconnected.
Aug 13 05:17:54 daemon.info pppd[937]: No response to 6 echo-requests
Aug 13 05:16:23 user.err syslog: WSTLIB_HTTP: error sending request
 
{edited IP's for privacy}
Message Edited by KaLin on 08-14-2009 03:42 PM
0 Likes
Reply
Telcoguru
Master - Level 1
The logs don't help me. I need to see the transceiver statistics.
0 Likes
Reply
dslr595148
Community Leader
Community Leader
Since I now know what modem you are talking about...

The correct path might be System Monitoring -> Advanced Status -> Transciever Stats.

^
0 Likes
Reply
slownet
Enthusiast - Level 3

I had hoped to include stats for the transceiver when the link was down but have not had a crash since the morning of the 13th.  These are the stats for the transceiver while it is working fine.

Transceiver Revision A2pB020b3.d19d

Vendor ID Code 4D54

Line Mode ADSL_G.dmt

Data Path INTERLEAVED

Transceiver Information Down Stream Path Up Stream Path

DSL Speed (Kbits/Sec) 2944                             832

Margin (dB)                         6.8                                     9.0

Line Attenuation (dB)         40.0                                     25.0

Transmit Power (dBm)        18.8                                     11.9 

This weekend I expect to run a test to compare the logs from a physical line failure to those from a logical line failure.  As far as I can read the logs above and the lights, my problem is a logical disconnection rather than a physical one since the DSL link remains up but the internet connection drops.  Similarly, the error logs only refer to logical problems rathe than physical problems.  Of course, that is where I started, seeing the problem as being high in the OSI stack and on Verizon's end rather than in my modem or DSL path, but I don't usually spend my days troubleshooting modems, so YMMV.

0 Likes
Reply
Telcoguru
Master - Level 1
Your stats look bad. I suspect that there is a line trouble somewhere. Try to test from your NID if you can. If not call DSL repair. Your download noise margin is too low causing disconnects.
0 Likes
Reply
slownet
Enthusiast - Level 3

You are right - thanks.  The line went down again this morning and I checked the transceiver stats before rebooting.  The downlink noise margin was 0.-3 (sic) when it usually is around 6.  After rebooting it was back to 6.

Thankyou for the help. 

0 Likes
Reply
slownet
Enthusiast - Level 3

So, I called Verizon when the link was down and after about 20 minutes of testing they declared that there was a problem between the c/o and my house.  "Yes" I said.  They started a trouble ticket and declared it closed, by phone call, about 12 hours later.  The following morning, the line was down again.  So, yesterday morning, I called to reopen the trouble ticket - that's hard becasue the phone staff are trained on the assumption that every call is a new problem.  We went through all the troubleshooting again during which they found that I had no problem because the line was working (here is the secret that they wouldn't hear: I fixed it by reboting the modem.)  Yesterday evening a very polite young man called to say that they had started a 24 hour test of the line and this morning - about 14 hours later - they called to say that the trouble ticket was closed and the problem fixed.  We'll see.  So far, I have not been able to convince them that the test for an intermittent problem is not a 24-hour test but a 7 day test.

From a technical perspective, the noise margins on the down link are slightly higher, I think, closer to 7.5 rather than 6 where I mostly saw it, but I am not checking it every 5 minutes so don't have a very good picture of what is normal.  We'll see.  The customer staff are all very nice, follow the scripts and the follow up is good, but the attention to the technical problem is not half as good.

0 Likes
Reply
FieldT
Enthusiast - Level 3
Did you try plugging in directly to the Nid and see if noise margin increased? Make sure to use the cord that came with modem to go from modem to jack/Nid, if not avail., use shortest cord you can. If noise margin is better you have bad wiring or bad connections in house. If it looks the same, trouble maybe outside in the lines. 80% of the time it is in the house, you need solid copper phone wire, not stranded wire like the stuff most phone cords are made of. Disconnect all unused lines in the house. Have you ever had a tech out to the house? If so did he do anything?
0 Likes
Reply
slownet
Enthusiast - Level 3

I'm typing with one hand and talking with Verizon in India as I type.  The line went down again this evening and this very nice tech ws trying to diagnose a problem in my computer.  Squelshed that idea, reset the line and now we are doing a line test - which won't show much since I rebooted the modem and fixed the problem.   She has permission to open a trouble ticket at the c/o which - I predict - will complete a 24-hour line test in half that time, declare it solved and call me with that good news.

Now I am supposedly getting 24 hr line tests for several days (until Tuesday) and then they will contact me.

The modem is plugged in using the rj-45 cable that came with it and it is about 10 feet from the outside box as well as the first device on the line.  The only way the modem could get closer to the outside box would be to park it on the lawn.  The connection from the outside box to my distribution panel was done by professionals five years ago.  I guess I'd believe in an internal problem if both up and down noise margins were bad, but my uplink is stable while the downlink margin is consistently lower (by 4-5 dB) and crashes every 12 hours or so.  The uplink margin shows no variation at all.  The fact that the crashes seem to coincide with sunrise/sunset makes me think that it is some device on a diurnal cycle between my house and the c/o or a device with a problem that crashes itself on a regular cycle.

Anyway, thanks for the ideas. I will double check the lines and makse sure that no spider is warming it's babies in the distribution box. 

0 Likes
Reply
ElizabethS
Moderator Emeritus
If you would like the "solved" designation removed from this thread, slownet, just PM me and I'll be glad to do that for you.
0 Likes
Reply
slownet
Enthusiast - Level 3

Thanks Elizabeth,

I think the problem is solved from an intellectual point of view - we know that the problem is a low noise margin on the down link.  Now the problem remains conveying that through customer service to the c/o techs who can do something about it.  Naturally, intermittent problems are the hardest to solve and the ones that the customer service can do least about.  None the less, their scripts require them to do certain things in a certain order and it is not possible to actually solve the problem on the timescale apparently imposed by Verizon.  Even the follow up calls, reporting the results of the 24 hour tests, seem to come before 24 hours have passed.

I am formulating a theory which runs along the lines that the customer's cost of complaining must at least equal the cost of Verizon's repair.  If there is a physical line problem between the c/o and my house, my efforts/costs to get that problem resolved must be at least as high as the cost of fixing the line because any repair to infrastructure takes away from profits.  It might make sense from a telco perspective but is not what I expect to be the responsibility of the telco in a commodity arena which esentially is monopolized by a few companies.  If they own all the copper, they need to maintain it at a reasonable level of service.  Similarly, ISPs can charge per MB when the serives is equivalent to power, gas and water.  As long as the ISPs provide "up to x download speeds" they shouldn't be able to charge by consumption.  Imagine if PEPCO promised up to 110V/50 Amps, or WASA up to 100 gallons of water a day.  Their service is as much as I can use in a normal residence, and ISPs should be the same.

Back to the point, can we change the title to  "unreliable DSL in Washington DC - problem identified but not fixed"?

0 Likes
Reply
Telcoguru
Master - Level 1
You may be too far from the C.O. for 3Mb service.  You need to be about 12,000ft or less otherwise downgrading to a lower tier will fix your problem.
0 Likes
Reply
slownet
Enthusiast - Level 3

You are right but the connection is generaly steady and then has periods, this is the longest one, when the service is unreliable.  It has gone for months with no hiccups and then suddenly there is a period when it can't remain alive.

Yesterday we had a huge rainstorm and that did not bring the service down although it did lower the noise margin - on the downlink only - which reduces the chances that the cause is environmental.  Yesterday I also started logging the exact time that the link went down, based on the logs.  So far I've had three crashes since yesterday afternoon, 16:42, 05:31 and 08:37.  Since the rains remain in the area and there are showers off and on, that may be a correlation though I still loose the link when it is completely dry.

We'll see.  With any kind of luck the five day monitoring cycle will give the c/o staff something to work with. 

0 Likes
Reply
FieldT
Enthusiast - Level 3

Does not sound like a CO problem at all, sounds like it's in the lines. Even if you are only 10' from nid anything else on line can still interfere with it. See if you can plug directly into the nid. Have the techs ever done a pair change? That is change the pair of wires you are on to the CO with a spare pair. If not I would have this done first. If that doesn't help have the tech call the MCO dept. And have them run a MLT test to see how the line looks. Ask them if the multi notch setting is turned off, if not ask them to turn it off and see if the capacity and the noise margin increases or decreases. If it is better or the same, leave it off, if it's worse have them turn it back on. Then have them temporally turn you down to 1.5m and see how the capacity and the noise margin look then. I have had many DSLs work better and faster at 1.5m then 3m

0 Likes
Reply
slownet
Enthusiast - Level 3

So, it has been one month, 30 disconnections, 9 "solved" trouble tickets and the problem persists.  

I've spoken to a significant number of very polite Indians who all have to say "don't worry - we will solve your problem."  {please keep your posts courteous}

Who does one call:  Better Business Bureau to complain about fraud?  The FCC to complain about false advertising and monopolistic behavior?

Welcome any ideas.

0 Likes
Reply