Showing results for 
Search instead for 
Did you mean: 

Need help configuring 1841 Router with a WIC-ADSL1 Module

Hello folks...

I am new to using this forum so please bare with me...

I only know a little about programming a CISCO router but I know the config I setup is not working...

Here is what I want to do...

  • The ISP provides us with IP Addresses via DHCP. Our public address is NOT static so the interface on the DSL Module needs to be provisioned to get a DHCP address with a CLASS C License.
  • The IP address of the Router should be subnet=
  • The LAN Clients need receive their IP address via DHCP EXCEPT for a range of 100 addresses. The lan Clients only need about 40 DHCP addresses.
  • ONE of the Lan Clients ( needs to have ports 25, 1723, and others forwarded to it.

Below is the config I am trying to use but I can't even ping the router from the LAN. What am I doing wrong?

Can anyone tell me how to fix this and can you send examples or even rewrite my config for me? I would be grateful!

Please advise...

Dale Allen


hi dale,

got the opportunity to look again on your config, you seem to have used both authentication protocol - CHAP and PAP. looking at your thomson ST  modem logs, it uses PAP. kindly make the necessary changes in using only PAP  (verify this info with your ISP).

interface Dialer1

ip address negotiated

ip nat outside

encapsulation ppp

dialer pool 1

ppp chap hostname CP1004NTT6Q

ppp chap password 0 CP1004NTT6Q

ppp pap sent-username CP1004NTT6Q password 0 CP1004NTT6Q


should look like this

ppp authentication pap callin

ppp pap sent-username password

Peter Paluch
Hall of Fame Cisco Employee

Hi John,

To my best knowledge, this change would not accomplish anything. The particular kind of PPP authentication is not enforced by a node willing to authenticate itself, rather, it is requested by the neighboring node that wants to authenticate its peer.

Dale's configuration is currently simply prepared to answer to both CHAP and PAP authentication requests, but it does not enforce any. If the remote end requires PAP during the LCP phase, Dale's router will use PAP. If the remote end negotiates CHAP during the LCP, the Dale's router will run CHAP. It is as simple as that.

The ppp authentication pap callin command is actually quite dangerous in this situation. What it means is that "I will want the other end to authenticate to myself but only if it is calling me, not if I am calling it". Note the problems related to this command:

  • We are requested the remote end to authenticate to us, in other words, we want the ISP to authenticate itself. That is a totally opposite direction of authentication than that which should take place.
  • We do not know any username nor password that the ISP should use to prove its identity to us. The username/password combination that is configured on the interface is our credential, not ISP's. If the ISP was indeed to authenticate to us, we would have to record its credentials using the username password global configuration command.
  • The callin parameter tells Dale's router to authenticate the ISP only if it calls us. Note that this direction of PPP connection creation never occurs on DSL lines. It is valid for dialed lines and callback scenarios, but never in a stable provider environment.

What is interesting is that precisely this kind of configuration seems to persist all around. I see it all the time configured on client devices and I wonder where does it come from. To me, it appears to be patently wrong. I guess I have seen it somewhere in some Cisco configuration example that got it wrong in the first place, and it is simply being propagated further and further.

Please correct if I am wrong here!

Best regards,


hi peter,

the 2 lines which i provided are required for PAP to work. the optional "callin" keyword is up to OP to add if one or the other works for his connection.

this kind of set up is very common with our 1841s with the same ADSL WIC module. it's also common with PPPoE and PPPoA setup.

Peter Paluch
Hall of Fame Cisco Employee

Hi John,

Hmmm... I am sorry but I still do not agree with your reasoning.

the 2 lines which i provided are required for PAP to work.

This depends on the direction of the authentication. I maintain that these two lines are not required if Dale's router should authenticate to the ISP and not vice versa. The ppp authentication pap command will request that the other party authenticates to us. It does not influence whether we agree on a particular type of authentication requested from the other party. If we wanted to refuse a particular authentication type we would use the ppp pap refuse or ppp chap refuse commands, but it is always the other party that requires authentication from us.

Quoting from the IOS Security Command Reference for 12.4T at

When you enable Password Authentication Protocol  (PAP), Challenge Handshake Authentication Protocol (CHAP), or Extensible  Authentication Protocol (EAP) authentication (or all three methods),  the local router requires the remote device to prove its identity before  allowing data traffic to flow.

In other words, using the plain ppp authentication pap on Dale's router would cause Dale's router to send PPP PAP Request to the ISP, and Dale's router would expect a PAP Response from ISP, then compare the received username and password to the local username database. Is this what we want - to authenticate the ISP to us? Surely not! The authentication should go the other way around!

Let me also quote the Linux manpage about pppd that puts it quite nicely:

The  PPP  protocol, being symmetrical, allows both peers to require the

other to authenticate itself.  In that case, two separate and  indepen‐

dent  authentication exchanges will occur.  The two exchanges could use

different authentication protocols, and in principle,  different  names

could be used in the two exchanges.

So, if I request authentication from the other party, it has absolutely no effect whether I will have to authenticate myself to the other party as well, and what kind of authentication that will be.

The configuration as used and suggested by you works because, just by a happy coincidence, a DSL connection is not treated as incoming PPP call, and thus the command ppp authentication pap callin actually has no effect - as if you never entered it at all. I am very sure that if you removed the callin keyword, your clients would not be able to connect as they would request PAP authentication from the ISP's access concentrators. That would require setting up local username databases on your clients' routers so that the username/password of the ISP access concentrators could be verified against it.

Best regards,


Hi Peter,

Very interesting points indeed! I wish I was wrong.

With due respect, I'd gladly drop off this thread and leave it up to you since you have more expertise

Sent from Cisco Technical Support iPhone App

Peter Paluch
Hall of Fame Cisco Employee

Hello John,

No, no, please do not leave this thread! All your suggestions are welcome!

Regarding this particular configuration snippet I  originally commented, I am simply going against a popular but incorrect  belief I am seeing far too often. Being a teacher, I have a strong  propensity to point out inaccuracies and put things into their correct  place - not as a nitpicker I would like to hope, but rather out of my  desire to help people understand and use things correctly. I apologize  if I embarassed you by my argument or if I was in any way inappropriate.

You are most welcome here, and I definitely want you to continue submitting suggestions how to help solve Dale's problem.

Best regards,



Attached you will find the SH CONTROLLERS ATM/0/0/0 output that is NOT truckated..

Please let me know what you see...


Dale Allen

Hello  Dale  if  it's  pppoe  over  ATM,  then  apply  below  config,

interface ATM0/0/0

no ip address

no ip mroute-cache

no atm ilmi-keepalive

pvc 0/35  <<<  Verify  this  value  with  ISP

  encapsulation aal5mux ppp dialer

  dialer pool-member 1

protocol  ppp  dialer  <<<  Add this  one




Peter Paluch
Hall of Fame Cisco Employee

Hello Jyoti,

I am not sure about that addition you have suggested. It is still PPPoA, not PPPoE. If PPPoE was to be configured, the configuration would be

interface ATM0/0/0

pvc 0/35

pppoe-client dialer-pool-member 1

i.e. it would need to reference PPPoE explicitly.

Best regards,




I HAVE verified this value...

pvc 0/35 <<< Verify this value with ISP


Dale Allen

Peter Paluch
Hall of Fame Cisco Employee


According to your outputs you have provided us with, the PPP on the other side simply does not respond. You are trying to bring up a PPP link and the other side sits there totally quiet.

I suggest verifying that your DSL interface has correctly trained to the DSLAM - use the commands

show controllers atm 0/0/0

show controllers dsl 0/0/0

and post the results here please. If the modem is trained correctly then I surmise that your provider probably uses PPPoEoA instead of PPPoA (if they don't know that they are using IPCP which they are then I also doubt their competency in distinguishing PPPoA from PPPoEoA).

Best regards,


Thanks for writing back and for your attention...

I don't think I got all of the data but here is what I did get...(See attached) . 

And there is no command for show controllers DSL


Couple of quick questions...

How do you shut off Term Monitor ? 

How do you inccrese the buffer to help hold more output from show controllers or show tech support?

Please advise,,,


Peter Paluch
Hall of Fame Cisco Employee


If you want to capture the output, the best way to do it is to use your HyperTerminal or PuTTY function to log everything into a file. This way, you do not need to change the logging buffer size.

Your show controllers atm output is sadly truncated so I am not able to see the most important part of the output whch I was interested in.

The terminal monitor can be deactivated using the no terminal monitor command - however, this is usable only on Telnet and SSH sessions. The console port still receives the logging output. It can be deactivated, but by a different command, and it is something I would rather not do at the moment.

So please try to use the logging function in your terminal emulator software to capture the entire output of the necessary commands and be so kind to post it here.

An additional info: I have sent you a private message - click on the Account link up at the top of the page. Please check it. Thanks!

Best regards,