Understanding xDSL connection related problems

The DSL Parameters part of this article is valid and can be considered with any brand of internet router and modem (Dlink, 3com, Alcatel, Usrobotics, Parks), by accessing the configuration interface available by the manufacturer eg: ou

The Authentication and Logs part is valid for any modem that use PPPoe and/or PPPoa configured on Routed mode only, considering that the authentication and logs for the modems on Bridge mode are made by the hardware or software dialer.

The DSL parameters are responsible for the quality of a xDSL connection. If these parameters are not under certain levels, almost always the connection will suffer performance losses, caused by unexpected errors and packet retransmission, and the final effect on the user is the evident connection slow down.

Another often fact is when these parameters are the main reason for link instability, because the connection keeps on dropping and reestablishing. A physical explanation may be found after checking the cabling system. Bad connections, old wires, UV damaged on weather exposed cables, rusted connectors and others.

The carriers and xDSL operator technician may simply say that your line is Qualified or NOT Qualified when noise or instability is affecting the line signal.

Let’s explain the most important parameters.

SNR Margin: (Signal Noise Relation) – It’s the difference measured in dB between the signal and the noise.
Means that if the difference between the signal and the noise is too small, then it’s impossible for the hardware the determine what is signal and what is noise. The communication is not established or will suffer.

The signal noise relation also is used to indicate the dynamic range of the equipment, the intensity difference that can occur on the hardware, since the most weak signal (when the signal is close to the noise) to the highest signal without any distortion.
This parameter is always better as it raises.

Another important parameter is the LINE ATTEN, which means the existing line attenuation, also known as the transmition loss. It’s always better when it’s as little as possible.


CRC: “Cyclic Redundancy Checking" (CRC) in general terms is a math function to verify if data was transmited with success. When CRC occur, a new transmition may be requested to that package.
When the hardware is showing a lot of CRC errors, there may be an evidency of noise on the transmition media.

Finally, the router shows pre-configured DSLAM channel from the operator / carrier.

Fig1: Screen Wan/Dsl/DSL PARAMETERS

  fig 1
IF there is everything fine with the line, there is no reason for the ADSL not to align.

Here is na attached piece of modem LOG running on routed mode:

System UP: O hardware is turned on
DSL Interface UP: Hardware recognized the line with success
ATM Vc Up: On ATM based xDSL, the hardware needs a Virtual path and a Virtual channel, they are ok.
Sending Config Req: The hardware has sent a auth request.
Config packet received: The hardware has received the requested information
Authentication Successfull: The hardware has received the auth and IP needed to finish the process and it’s ready to use.

*Another possible result is auth failed, (Check your username and password combination)

Fig2: Screen Admin/Alarm

  fig 2
The Routers can have another screen format, but the parameters have almost the same name.
Fig 3: Status/ADSL

  fig 3
Fig4: Status/LOG

Similar to the last auth process description, but in this case we can see the PADI and PADT packets, which are respectively:
PPPoE Active Discovery Initiation (PADI) – The PPPOE sends a Discovery packet.
PPPoE Active Discovery Offer (PADO)  - The PPPOE Server or DSLAM must respond with the PADI with a PADO if it’s able to handle to a connection to the requester.

PPPoE Active Discovery Request (PADR) – After a PADO is received, the client responds with a PADR to the PPPOE server or DSLAM.

PPPoE Active Discovery Session-confirmation (PADS) – After receiving the PADR, a PADS is sent back to the client.

PPPoE Active Discovery Terminate (PADT) – It’s the session disconnect packet

  fig 4

Comments (2)

Keith AlabasterEnterprise Architect
Top Expert 2008



Congratulations! Your article has been published.

Page Editor

Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.