Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.networking > #3178 > unrolled thread

Dialup PPP fails after new server, admins at ISP

Back to article view | Back to comp.os.linux.networking

Contents

  Dialup PPP fails after new server, admins at ISP Mike Spencer <mds@bogus.nodomain.nowhere> - 2014-12-08 22:46 -0400
    Re: Dialup PPP fails after new server, admins at ISP Moe Trin <ibuprofin@painkiller.example.tld.invalid> - 2014-12-09 18:08 +0000
      Re: Dialup PPP fails after new server, admins at ISP Mike Spencer <mds@bogus.nodomain.nowhere> - 2014-12-11 04:07 -0400
        Re: Dialup PPP fails after new server, admins at ISP Moe Trin <ibuprofin@painkiller.example.tld.invalid> - 2014-12-11 18:55 +0000
          Re: Dialup PPP fails after new server, admins at ISP Mike Spencer <mds@bogus.nodomain.nowhere> - 2014-12-12 22:34 -0400
            Re: Dialup PPP fails after new server, admins at ISP Moe Trin <ibuprofin@painkiller.example.tld.invalid> - 2014-12-13 22:49 +0000
              Re: Dialup PPP fails after new server, admins at ISP Mike Spencer <mds@bogus.nodomain.nowhere> - 2014-12-15 03:44 -0400
                Re: Dialup PPP fails after new server, admins at ISP Moe Trin <ibuprofin@painkiller.example.tld.invalid> - 2014-12-15 21:55 +0000
                  Re: Dialup PPP fails after new server, admins at ISP Mike Spencer <mds@bogus.nodomain.nowhere> - 2014-12-17 04:44 -0400
                    Re: Dialup PPP fails after new server, admins at ISP Moe Trin <ibuprofin@painkiller.example.tld.invalid> - 2014-12-17 18:43 +0000
                      Re: Dialup PPP fails after new server, admins at ISP Mike Spencer <mds@bogus.nodomain.nowhere> - 2014-12-21 03:26 -0400
                        Re: Dialup PPP fails after new server, admins at ISP Moe Trin <ibuprofin@painkiller.example.tld.invalid> - 2014-12-21 19:19 +0000
    Re: Dialup PPP fails after new server, admins at ISP Michael Black <et472@ncf.ca> - 2014-12-11 15:01 -0500
      Re: Dialup PPP fails after new server, admins at ISP Moe Trin <ibuprofin@painkiller.example.tld.invalid> - 2014-12-12 02:02 +0000

#3178 — Dialup PPP fails after new server, admins at ISP

Up until a month or so ago, I had a working dialup account with
Ca.Inter.Net.  Their dialup phone numbers and machines -- Network
Access Servers or NASs -- were provided by Telus and the account
worked fine. 

Now Fibernetics.ca has taken over Ca.Inter.Net. The Telus phone
numbers stopped working without warning.  The account still exists,
mail server works fine but not dialup PPP.  After some weeks,
Fibernetics provided a toll-free 844 number for dialup access to their
own new server.

Nothing I can do will establish a PPP connection at that number.

  + The number answers and modem hardware handshake complete
    successfully.

  + The NAS then presents a banner and a prompt:

       Username: Login:

  + After submitting a valid username, there's another prompt:

      Password:

    which responds to the password with "% Authentication failed"

But there's a potential gotcha:

Up until Fibernetics took over last month, the Telus NAS presented a
banner and the "Login: " prompt but did not, in fact, expect the
calling user to authenticate that way and would not accept
authentication that way. [1] Instead, it expected Link Control
Protocol (LCP) to begin negotiations immediately.  So I had a
login/authentication configuration that worked that way.  All good.
Worked on my Linux box, worked on my wife's Win-XP system.

No longer.

The support guys at Fibernetics [2] say that:

  + They have installed the dialup software with "out of the box"
    configuration but can't say explicitly what that configuration
    is.

  + Above notwithstanding, they say that I have to implement the ASCII
    7-bit Username: and Password: authentication before beginning
    LCP/PPP.  That authentication fails as described above, whether
    done manually in Minicon or in a script run by pppd.

  + The method of ignoring the ASCII prompt and commencing LCP
    immediately (then depending for authentication on negotiating PAP
    and submitting PAP credentials) also fails.  When I try that, it
    appears [3] that the NAS responds with octet strings similar to
    LCP ConfReq packets but all with bit 7 == 0.  If the NAS is trying
    to send ConfReq packets but they're being reduced to 7-bit, my
    pppd client would correctly drop them.

  + The two "Escalation specialist" support guys both say that I know
    more about this stuff than they do.  I don't think they've read
    the RFCs or even the manual for the dialup software.

In further support of the notion that it's their config, not mine,

  + The system worked flawlessly for both Linux and WIn-XP until
    these guys at Fibernetics took over and put their server in place,
    and 

  + Both the Linux and Win-XP boxen continue to work fine on the same
    phone line when using our other dialup ISP (the one from which I'm
    posting this.)

  + The Fibernetics dialup NAS fails in exactly the same way if I take
    a laptop to a different phoneline, different exchange.

Does anyone know enough about configuring the ISP end of dialup to
tell me what I need to tell the Fibernetics guys so that they can get
their house in order? [4]  I am seriously vexed at this point.

I've had Linux on the desktop for 15 years, Unix user for 25 years,
can read RFCs but I'm not an IT professional, have never run a NOC,
know nothing about analog or digital telecom, Cisco admin or that
level of tech.

Help?  

- Mike

[1] This is, I think, called "Stupid mode" elsewhere on the net.

[2] http://www.fibernetics.ca/team/
    Scroll down to Neil C. or David M.

[3] Appears: From running slsnif to sniff the serial port.  But I'm
    not totally confident in that program so I say "appears".

[4] Alternatively, does anybody have a personal contact inside
    Fibernetics in Ontario whom they (or I) could persuade, bribe or
    prod into getting his fixed? FOAF who knows the CEO?  Live next
    door to the FIbernetics NOC and can walk ovr there and fix them
    up?

-- 
Michael Spencer                  Nova Scotia, Canada

mspencer (at-thing) tallships (dot) ca
http://home.tallships.ca/mspencer/    

[toc] | [next] | [standalone]

#3179

On 08 Dec 2014, in the Usenet newsgroup comp.os.linux.networking, in article
<87bnndk09o.fsf@bogus.nodomain.nowhere>, Mike Spencer wrote:

>After some weeks, Fibernetics provided a toll-free 844 number for
>dialup access to their own new server.

>Nothing I can do will establish a PPP connection at that number.

Sounds like it's time to find another ISP

>  + The number answers and modem hardware handshake complete
>    successfully.

They set up a modem and terminal server...

>  + The NAS then presents a banner and a prompt:
>
>       Username: Login:

but (intentionally? No, "Do not attribute to malice that which can be
explained by blatant stupidity.") forget that this method of logging in
went out of style in 1995 when Microsoft invented the telephone (or
dialin, or something). Windoze has always defaulted to the mode known
as "AutoPPP" because the average windoze user has no clue where to click
on a text Login prompt.

>  + After submitting a valid username, there's another prompt:
>
>      Password:
>
>    which responds to the password with "% Authentication failed"

That would be normal - the server won't tell you if it's the username
or password that's unacceptable.  You can TRY variations of username:
username alone ("mspencer"), and full username ("mspencer@example.com"),
but exactly how they expect a windoze box to connect is beyond me.

>Up until Fibernetics took over last month, the Telus NAS presented a
>banner and the "Login: " prompt but did not, in fact, expect the
>calling user to authenticate that way and would not accept
>authentication that way.

Yup - that's the only way windoze was set up to connect in their "Dial
Up Networking" application.   Running a terminal program to log in to
a BBS was possible with windoze "terminal" or "aftermarket" software
like ProComm, BitCom and the like, but I haven't seen a dialin BBS
service since about 1996, and that didn't provide Internet connectivity.

>All good.   Worked on my Linux box, worked on my wife's Win-XP system.

Yup - been that way since 1995

>The support guys at Fibernetics [2] say that:
>
>  + They have installed the dialup software with "out of the box"
>    configuration but can't say explicitly what that configuration
>    is.

Code speak for "we don't want your dial-up business - you must upgrade
to our new Fiber service".

>  + The method of ignoring the ASCII prompt and commencing LCP
>    immediately (then depending for authentication on negotiating PAP
>    and submitting PAP credentials) also fails.  When I try that, it
>    appears [3] that the NAS responds with octet strings similar to
>    LCP ConfReq packets but all with bit 7 == 0.  If the NAS is trying
>    to send ConfReq packets but they're being reduced to 7-bit, my
>    pppd client would correctly drop them.

[galileo ~]$ cat /etc/ppp/options | column
lock            crtscts         nodetach        defaultroute
/dev/modem      modem           115200          noipdefault
[galileo ~]$ ls -l /etc/ppp/*ap-secrets /etc/resolv.conf
-rw-------   1 root     root       99 Jun 16  2008 /etc/ppp/chap-secrets
-rw-------   1 root     root       94 Jun 16  2008 /etc/ppp/pap-secrets
-rw-r--r--   1 root     root       49 Jun 16  2008 /etc/resolv.conf
[galileo ~]$ cat /usr/local/bin/dialin.example
exec /usr/sbin/pppd  user ibuprofin@example.com connect "/usr/sbin/chat
ABORT BUSY \"\" AT\&F1 OK ATDT2662902 CONNECT \"\d\c\""
[galileo ~]$

NOTE: That's one long (127 characters) line.

NOTE:    CONNECT \\\d\\\c"      also works

The 'connect' option expects one argument. That argument is quoted to
hide embedded spaces.  However, /usr/sbin/chat _also_ needs some stuff
to be quoted, and the backslashes are therefore used to hide the quote
and ampersand (&) character from the 'connect' argument and shell.

The key is the bit after the dialing command.  You've sent the dialing
command (here, ATDT2662902) to the modem, and you expect it to report a
successful modem-to-modem connection ("CONNECT"). The next bit of crap
is from "man chat" and tells /usr/sbin/chat to wait one second ("\d") to
allow everyone to wake up, then tells it to exit (handing over a working
modem connection to pppd) WITHOUT sending a carriage return ("\c")
which would trigger the peer into sending a text based "Login" prompt.
Note that you should set up both /etc/ppp/pap-secret _AND_ chap-secrets
files (files can be identical, although the chap-secrets file might
want a fourth field containing a star - see the pppd man page) to avoid
that little possible problem.

>  + The two "Escalation specialist" support guys both say that I know
>    more about this stuff than they do.  I don't think they've read
>    the RFCs or even the manual for the dialup software.

Code speak for "we don't want your dial-up business - you must upgrade
to our new Fiber service".   Reading the RFCs isn't likely to do them
much good, but reading the manual would - especially looking for the
mechanism to get windoze to be able to dial in ("AutoPPP" mode).

>Does anyone know enough about configuring the ISP end of dialup to
>tell me what I need to tell the Fibernetics guys so that they can get
>their house in order? [4]  I am seriously vexed at this point.

Yes, but he doesn't monitor this Usenet newsgroup - see if he responds
in "comp.protocols.ppp".    Also, to be helpful, he'll need to see the
exact Login banner they send - so he knows _which_ of the many server
implementations is in use.

But the bottom line - find another ISP.   Really.

>[1] This is, I think, called "Stupid mode" elsewhere on the net.

That's what WvDial called it - because they couldn't believe that ISPs
would present a text prompt when they forced it (by sending a carriage
return, or several of them), and then not have the equivalent of an
/etc/passwd file to actually accept a text login.  They completely
ignored that in windoze DUN, you never saw a login prompt.

        Old guy

[toc] | [prev] | [next] | [standalone]

#3180

Thanks, Old Guy, for your thoughful reply.  For now, I'm going to
stick with the technical stuff and leave your other remarks, however
cogent ;-), for a later reply.

One part of the problem has been indentified: When Fibernetics took
over the actual servers for ca.inter.net, they screwed up part of the
authentication database.  That's been dealt with and now my wife's
Win-XP box can connect via dialup and PPP to the new server.

Still no luck with Linux. More details up-thread on
comp.os.linux.networking. 

Moe Trin <ibuprofin@painkiller.example.tld.invalid> wrote:

> Mike Spencer wrote:
>
>> Does anyone know enough about configuring the ISP end of dialup to
>> tell me what I need to tell the Fibernetics guys so that they can
>> get their house in order?  I am seriously vexed at this point.
>
> Yes, but he doesn't monitor this Usenet newsgroup - see if he
> responds in "comp.protocols.ppp".  Also, to be helpful, he'll need
> to see the exact Login banner they send - so he knows _which_ of the
> many server implementations is in use.

(So: Cross posting to comp.protocols.ppp)

Since Win-XP can now connect, this is (probably?) no longer about
telling the Fibernetics admins what to do.  I need to figure out how
to connect with Linux.

If I connect using Minicom, this is the banner I see:

    atdt18442449946
    CONNECT 24000/ARQ/V34/LAPM/V42BIS
    C
    ; TOR01AD-AS54a.ne.fibernetics.ca        3/33       ^G


    User Access Verification

    Username: login: mspencer1@ca.inter.net
    Password: <passwd entered>

    % Authentication failed

That's an actual control-G there that I've replaced with caret-G for
usenet context.  And what's with that single 'C' character?
TOR01AD-AS54a.ne.fibernetics.ca has no DNS A record but is ID'd by
RDNS as 208.72.120.45.


Here are the the pppd script and chat script that I invoke:


   #!/bin/tcsh -f

   setenv TELEPHONE 18442449946

   set LOCAL_IP  = 0.0.0.0 
   set REMOTE_IP = 0.0.0.0
   set NETMASK   = 255.255.255.0
   set DIALER_SCRIPT=/home/mds/bin/istar-dialer

   eval /usr/sbin/pppd kdebug 7 debug lock modem crtscts /dev/ttyS0 115200 \
    asyncmap 20A0000 escape FF  ${LOCAL_IP}:$REMOTE_IP \
    noipdefault netmask $NETMASK defaultroute \
    remotename istar user mspencer1@ca.inter.net connect $DIALER_SCRIPT &
--------------

    #!/bin/sh

    exec /usr/sbin/chat -e -v           \
	TIMEOUT		3			        \
	ABORT		'BUSY'              \
	ABORT		'NO ANSWER'         \
    ABORT       'NO DIALTONE'       \
	''		    'ATZ'               \
	'OK-+++\c-OK'	"ATV1Q0&C1&D2X4S0=0H0S7=60"			 \
	TIMEOUT		120				     \
	OK		"ATDT$TELEPHONE"	     \
    CONNECT "\d\c"
--------------------------------
    
I've tried variations of the last "send" string, "\d\c", "\\d\\c", "\c".
as well as adding

               \
    BIS  "\c"

to the above.

After running the above, /var/log/ppp has this to say:

    Dec 11 01:16:02 bogus chat[5452]: ATDT18442449946^M^M
    Dec 11 01:16:02 bogus chat[5452]: CONNECT
    Dec 11 01:16:02 bogus chat[5452]:  -- got it 
    Dec 11 01:16:02 bogus chat[5452]: send (\d)
    Dec 11 01:16:03 bogus pppd[5450]: Serial connection established.
    Dec 11 01:16:03 bogus pppd[5450]: using channel 7
    Dec 11 01:16:03 bogus pppd[5450]: Using interface ppp0
    Dec 11 01:16:03 bogus pppd[5450]: Connect: ppp0 <--> /dev/ttyS0
    Dec 11 01:16:04 bogus pppd[5450]: sent [LCP ConfReq id=0x1 
          <asyncmap 0x20a0000> <magic 0x7b6b2af6> <pcomp> <accomp>]
    Dec 11 01:16:31 bogus last message repeated 9 times
    Dec 11 01:16:34 bogus pppd[5450]: LCP: timeout sending Config-Requests 
    Dec 11 01:16:34 bogus pppd[5450]: Connection terminated.
    Dec 11 01:16:34 bogus pppd[5450]: Receive serial link is not 8-bit clean:
    Dec 11 01:16:34 bogus pppd[5450]: Problem: all had bit 7 set to 0
    Dec 11 01:16:34 bogus pppd[5450]: Hangup (SIGHUP)
    Dec 11 01:16:34 bogus pppd[5450]: Modem hangup
    Dec 11 01:16:34 bogus pppd[5450]: Exit.


I'm not fuly confident in slsnif (does /dev stuff I don't fully
understand) but I used it to sniff the serial port and it appears that
the remote host is responding to my ConfReq packets with octets
similar to the ones I send except that all of them are 7-bit, tending
to confirm what pppd reports in the log.  pppd would be correct in
ignoring that as not LCP packets.

At the point where pppd reports sending ConfReq packets, slsnif
reports that I'm sending:

     7e 7d df 7d 23 c0 21 7d   21 7d 21 7d 20 7d 34 7d 
     22 7d 26 7d 22 7d 2a 7d   20 7d 20 7d 25 7d 26 ac 
     ba 83 7d 27 7d 27 7d 22   7d 28 7d 22 ba 7d 2c 7e 

to which the server replies:

     7e 7d 5f 7d 23 40 21 7d   21 7d 21 7d 20 7d 34 7d
     22 7d 26 7d 22 7d 2a 7d   20 7d 20 7d 25 7d 26 2c 
     3a


My wife's Win-XP log reports (on a successful connection) how many
bytes exchanged but regretably doesn't report the actual octet values
exchanged in the LCP/PPP handshake.  (I haven't used Windoes since
3.1. There may be helpful logs on her machine that I don't know
about. ??)

I might reiterate that I have two dialup ISPs; one is working fine for
both Win-XP and Linux; the failing one worked fine with PAP auth
until Fibernetics replaced the server with a new one and "out of the
box" software; now that one works for Win-XP but not Linux.

I'm stumped.  I don't know how to trick the server into responding
correctly to my LCP packets.

Cross-posted to comp.protocols.ppp and comp.os.linux.networking.

Any guidance very welcome,
- Mike

-- 
Mike Spencer                  Nova Scotia, Canada

[toc] | [prev] | [next] | [standalone]

#3182

On 11 Dec 2014, in the Usenet newsgroups comp.os.linux.networking and
comp.protocols.ppp, in article <871to638zr.fsf@bogus.nodomain.nowhere>,
Mike Spencer wrote:

>One part of the problem has been indentified: When Fibernetics took
>over the actual servers for ca.inter.net, they screwed up part of the
>authentication database.

That really has happened before, and it drives people crazy.

>That's been dealt with and now my wife's Win-XP box can connect via
>dialup and PPP to the new server.

which puts us back into familiar territory.

>Since Win-XP can now connect, this is (probably?) no longer about
>telling the Fibernetics admins what to do.  I need to figure out how
>to connect with Linux.

Exactly - and we revert to the classic problem that "something" you
are doing is sending text to the peer at the wrong time.  It's going
to revolve around that 'chat' dialog.  As you are aware, a text-based
attempt to log in is not going to work, and we've GOT to emulate what
windoze does exactly.

>Here are the the pppd script and chat script that I invoke:

>   #!/bin/tcsh -f

Hold on a second, while I attempt to remember how a C shell works - I
haven't used one since about 1995 on SunOS 4.1.3   ;-)

COMMENT:  You're making things more complicated than you need to.

>   set LOCAL_IP  = 0.0.0.0 
>   set REMOTE_IP = 0.0.0.0
>   set NETMASK   = 255.255.255.0

Not needed

>   eval /usr/sbin/pppd

That giant crash you just heard is me trying to find my O'Reilly "UNIX
In A Nutshell" book...   OK, I think.

>kdebug 7 debug

Not needed - The 'debug' depends on you setting up your logging
daemon (/etc/syslog.conf perhaps) to put "daemon.debug" messages into
a known file.

>lock modem crtscts /dev/ttyS0 115200

OK

>asyncmap 20A0000 escape FF  ${LOCAL_IP}:$REMOTE_IP

PROBABLY not needed

>noipdefault

probably not needed.  The peer is going to supply both addresses of
the link.

>netmask $NETMASK

Not needed

>defaultroute

OK

>remotename istar

PROBABLY not needed

>user mspencer1@ca.inter.net connect $DIALER_SCRIPT &

OK

>    #!/bin/sh
>    exec /usr/sbin/chat -e -v

OK

>        TIMEOUT         3                               \ 
>        ABORT           'BUSY'              \ 
>        ABORT           'NO ANSWER'         \ 
>    ABORT       'NO DIALTONE'       \ 

I usually ignore dinking with the TIMEOUT - the default is 45 seconds
and if the modem takes any extra time at all, there's something else
that needs to be looked at.

>        ''                  'ATZ'               \ 
>        'OK-+++\c-OK'   "ATV1Q0&C1&D2X4S0=0H0S7=60"                  

1.  Check your modem manual - ATZ resets the modem to "some" stored
condition, and I normally use AT&Fn (where n may be 0 or 1 depending
on the brand) which resets things to "factory defaults".
2.  The "OK-+++\c-OK" sequence makes no sense.  Traditionally, this
was to expect the modem to respond with an "OK", and if it didn't,
send the Hayes command escape sequence to take the modem back to
command mode (under the assumption that it thought it was connected
and off-hook). It then sent a ATH0 which was supposed to hang up
the phone.   If the modem is somehow in this weird mode, I'd rather
know about it now than at the end of the month when I get an enormous
phone bill from the modem keeping the line tied up.
3. The last command sequence is modem brand dependent, but normally
would be trying to set things to sensible conditions - which is what
the modem initialization/reset string "should" be doing.

>        TIMEOUT         120                                  \ 
>        OK              "ATDT$TELEPHONE"             \ 
>    CONNECT "\d\c"

As above on the timeout - otherwise OK

>I've tried variations of the last "send" string, "\d\c", "\\d\\c",
>"\c".  as well as adding

>    BIS  "\c"

This is the area where the problem lies.

>After running the above, /var/log/ppp has this to say:
>
>    Dec 11 01:16:02 bogus chat[5452]: ATDT18442449946^M^M
>    Dec 11 01:16:02 bogus chat[5452]: CONNECT
>    Dec 11 01:16:02 bogus chat[5452]:  -- got it 
>    Dec 11 01:16:02 bogus chat[5452]: send (\d)
>    Dec 11 01:16:03 bogus pppd[5450]: Serial connection established.

OK, now _that_ says things worked.

>    Dec 11 01:16:34 bogus pppd[5450]: Receive serial link is not
>8-bit clean:
>    Dec 11 01:16:34 bogus pppd[5450]: Problem: all had bit 7 set to 0

And that says you're talking to a terminal server, rather than a ppp
daemon.  "It was something that you said" - but I don't see you saying
anything.  The "send (\d)" is ``normal'' as I just proved to myself by
connecting to a local ISP and seeing

   CONNECT
   -- got it
   send (\d)
   chat:  Dec 11 11:31:33 CONNECT 45333/ARQ/V92/LAPM/V44
   Serial connection established.
   Using interface ppp0
   Connect: ppp0 <--> /dev/ttyACM0
   PAP authentication succeeded

The '/dev/ttyACM0' is a US Robotics 5637  USB modem, and I told chat
to "REPORT CONNECT" which shows the text that the modem returned.

>I'm not fuly confident in slsnif (does /dev stuff I don't fully
>understand) but I used it to sniff the serial port and it appears that
>the remote host is responding to my ConfReq packets with octets
>similar to the ones I send except that all of them are 7-bit, tending
>to confirm what pppd reports in the log.

The terminal server is (I think) just echoing what you sent.

>My wife's Win-XP log reports (on a successful connection) how many
>bytes exchanged but regretably doesn't report the actual octet values
>exchanged in the LCP/PPP handshake.  (I haven't used Windoes since
>3.1. There may be helpful logs on her machine that I don't know
>about. ??)

I'm in the same boat - I have notes that say "go to Control Panel ->
Modems -> Properties -> Connection -> Advanced" and check Record a
log file"  but I don't think it's going to help us here.

>I might reiterate that I have two dialup ISPs; one is working fine
>for both Win-XP and Linux; the failing one worked fine with PAP auth
>until Fibernetics replaced the server with a new one and "out of the
>box" software; now that one works for Win-XP but not Linux.

Are you using the "same" dialin scripts?   Something your Fibernetics
script is doing is sending the peer into text mode.   Let me see if
I can gather the pieces together here:

1.  TEMPORARILY rename /etc/ppp/options  to /etc/ppp/OPTIONS to get it
out of the way.
2.  Run the following (enormous) one-line script. As long as you're
running a text-based shell, the actual shell shouldn't matter (i.e.
/bin/sh, /bin/bash, /bin/csh, /bin/dash or /bin/ksh should ALL work).

 exec /usr/sbin/pppd user mspencer1@ca.inter.net lock crtscts 
  nodetach defaultroute modem 115200 noipdefault /dev/modem connect 
  "/usr/sbin/chat -v ABORT BUSY \"\" AT\&F1 OK ATDT18442449946
  CONNECT \"\d\c\""

That's 200 characters long.  I think I've got the name and number
correct, and the rest is the minimum needed to get things going.  Cut
and paste that as one line to a script, and try it.  

I mentioned duplicating /etc/ppp/pap-secrets to /etc/ppp/chap-secrets
just to cover all bases.  There's no sign that it's a problem here,
but I have a dial-up account with an ISP that has nine "local" access
numbers that actually connect to three different Point-Of-Presence
providers (much like Telus was for you), and one of them insists on
using CHAP, while another insists on PAP, and the third requests
CHAP but will fall back to PAP if I refuse CHAP, and this is all the
"same" ISP/account.

>I'm stumped.  I don't know how to trick the server into responding
>correctly to my LCP packets.

The trick is to avoid sending it into text-mode by sending anything
with chat (or equal).  Once the peer goes into text-mode, the game is
over, and there's nothing to do but hang up and try again more
carefully.  ;-)

        Old guy

[toc] | [prev] | [next] | [standalone]

#3185

Skipping ahead and, once again, beginning with the technical stuff, 

Moe Trin <ibuprofin@painkiller.example.tld.invalid> wrote:

> Mike Spencer wrote:
>
>> I might reiterate that I have two dialup ISPs; one is working fine
>> for both Win-XP and Linux; the failing one worked fine with PAP
>> auth until Fibernetics replaced the server with a new one and "out
>> of the box" software; now that one works for Win-XP but not Linux.
>
> Are you using the "same" dialin scripts?  

No. The other, still locally managed, ISP is still using text mode
auth.

> Something your Fibernetics script is doing is sending the peer into
> text mode.  Let me see if I can gather the pieces together here:
>
> 1.  TEMPORARILY rename /etc/ppp/options to /etc/ppp/OPTIONS to get
> it out of the way.

Not relevant if the connection is never getting far enough into LCP to
negotiate PAP (or CHAP or whatever).

>> remotename istar [in my pppd invocation]
>
> PROBABLY not needed

My pap-secrets file has:

   <username>  "istar" <password>

I think if I replaced "istar" with "*", then "remotename istar"
wouldn't be needed in the pppd invocation. Otherwise, it is needed.

> 2.  Run the following (enormous) one-line script. As long as you're
> running a text-based shell, the actual shell shouldn't matter (i.e.
> /bin/sh, /bin/bash, /bin/csh, /bin/dash or /bin/ksh should ALL
> work).
>
>  exec /usr/sbin/pppd user mspencer1@ca.inter.net lock crtscts 
>   nodetach defaultroute modem 115200 noipdefault /dev/modem connect 
>   "/usr/sbin/chat -v ABORT BUSY \"\" AT\&F1 OK ATDT18442449946
>   CONNECT \"\d\c\""

Bingo!  That connects.  I owe you a beer (or Laphroig or other
beverage of choice) should you be in Nova Scotia.

So: doing extensive, if not *quite* exhaustive,  testing, it appears
that the source of the problem was the "escape FF" option to pppd.
The other item you flagged as "not needed",

>> set LOCAL_IP  = 0.0.0.0 
>> set REMOTE_IP = 0.0.0.0
>> set NETMASK   = 255.255.255.0
>> [pppd ...] kdebug 7 debug
>> [pppd ...] netmask $NETMASK
>
> Not needed...
>
>> [pppd ...] noipdefault
>> [pppd ...] asyncmap 20A0000 ${LOCAL_IP}:$REMOTE_IP
>
> PROBABLY not needed

don't seem make any difference one way or the other. But removing or
inserting "escape FF" turns it on and off.

I have no recollection where that (or the other "not needed") elements
came from, lost in the distant past after several changes, alarums and
excursions. 

So now I've ported your one-liner into a stripped-down script to call
pppd which in turn references another that runs your chat invocation.

An aside on the modem init: The Win-XP log *does* show the modem init
strings XP uses. I see some that don't appear in any of the Hayes or
USR docs I have:

   +MR=2;
   +DR=1;
   +ER=1;
   W2
   +ES=3,0,2;
   +DS=3;
   +IFC=2,2;
   #ud

All but the last produce ERROR responses from my modem. AT#UD produces
what appears to be cryptic diagnostic info.  Dunno what *that's* about.

> ...I have a dial-up account with an ISP that has nine "local" access
> numbers that actually connect to three different Point-Of-Presence
> providers (much like Telus was for you), and one of them insists on
> using CHAP, while another insists on PAP, and the third requests
> CHAP but will fall back to PAP if I refuse CHAP, and this is all the
> "same" ISP/account.

Isn't that nice? :-\ With my two completely differentr ISPs, I have a
script, called from each of the scripts that starts a connection to
one or the other ISP, that swaps in the right version of
/etc/mail/mailertable.db so sendmail will go to the right smarthost
for outgoing mail.

In your previous post, you wrote:

> Sounds like it's time to find another ISP.

Easier said than done where I am.  With a lot of bother (with
antennae, cables, poles, guys in the yard trying to get signal
somewhere) I could have wireless broadband, just one notch faster than
the very  slowest of wired broadband services.

In any case, I've been with the offending ISP since they were a bunch
of guys I knew doing a startup in Nova Scotia in the mid-90s. IPO'd,
borged, spun off, mergered, sold, sold again but I'm a long-time
customer. Better the devil you know than the devil you don't. Frying
pan/fire etc.  I'll have to bite the wax tadpole and do the Rural
Wireless one of these days.

>> [Quoting various stupid or false assertions by "support"...]
>
> Code speak for "we don't want your dial-up business - you must
> upgrade to our new Fiber service".

Oddly, Fibernetics (or their subsidiary Worldline) seems to be
advertising dialup.  OTOH, their mojo seems to be centered around the
newest, cheapest, fastest (and dirtiest?  No 911?) telecom tech. And
their fancy telecom service isn't available here in any case.


Thank you very much for your point-by-point attention. Now, if the
torrential rain will just stop, I can get out into the yard or the
blacksmith shop and do something more productive than try to fix
something that somebody else broke. (You're in Phoenix? Torrential
rain is probably not a problem there. :-)

Best & tnx,
- Mike

-- 
Michael Spencer                  Nova Scotia, Canada       .~. 
                                                           /V\ 
                                                          /( )\
http://home.tallships.ca/mspencer/                        ^^-^^

[toc] | [prev] | [next] | [standalone]

#3186

On 12 Dec 2014 22:34:50 -0400, in the Usenet newsgroups comp.protocols.ppp and
comp.os.linux.networking, in article <87r3w4s2et.fsf@bogus.nodomain.nowhere>,
Mike Spencer wrote:

>Moe Trin <ibuprofin@painkiller.example.tld.invalid> wrote:

>>> Mike Spencer wrote:

>> Are you using the "same" dialin scripts?  

>No. The other, still locally managed, ISP is still using text mode
>auth.

Wow!  How do they get windoze boxes to connect?   If they're using the
ordinary windoze Dial-Up-Networking app, that's a non-text mode, and
you're very lucky that the ISP went the extra mile to configure the
text mode.

>> 1.  TEMPORARILY rename /etc/ppp/options to /etc/ppp/OPTIONS to get
>> it out of the way.

>Not relevant if the connection is never getting far enough into LCP to
>negotiate PAP (or CHAP or whatever).

Actually, it depends on what you've got in there. The file is read
when the pppd program starts, not when it needs a particular variable.
The idea was to avoid accidental confusion.

>> PROBABLY not needed

>My pap-secrets file has:

>   <username>  "istar" <password>

>I think if I replaced "istar" with "*", then "remotename istar"
>wouldn't be needed in the pppd invocation. Otherwise, it is needed.

Correct.  I use the 'user' option to select the right secret to use
(like you, I have multiple ISPs, and my single dialing script takes
a number to specify which of <currently> 16 phone-numbers/ISPs to use
OR the word "next" to use the "next" number in rotation).

>> 2.  Run the following (enormous) one-line script.

>Bingo!  That connects.  I owe you a beer (or Laphroig or other
>beverage of choice) should you be in Nova Scotia.

Haven't been there in maybe 35 years, but glad to be able to help.

>So: doing extensive, if not *quite* exhaustive,  testing, it appears
>that the source of the problem was the "escape FF" option to pppd.

James?       I _think_ that might work if you used "escape 0xff", but
the usual mantra is "if you don't KNOW you need it, don't use it". (My
"C" language skills are decidedly "emergency use only", and I don't
see the clues I need in the ppp-2.4.7/pppd/options.c source file.)

>I have no recollection where that (or the other "not needed")
>elements came from, lost in the distant past after several changes,
>alarums and excursions. 

That's partly why I always recommend using that "one-liner" to see if
you can get things working.

>So now I've ported your one-liner into a stripped-down script to call
>pppd which in turn references another that runs your chat invocation.

That will work!

>An aside on the modem init: The Win-XP log *does* show the modem init
>strings XP uses. I see some that don't appear in any of the Hayes or
>USR docs I have:

Supposedly, microsoft did query the various modem manufacturers to try
to get "best" strings, to use, but that assumes windoze can ID the
modem (or the user manages to tell windoze the right stuff).   I've
found using the factory defaults works every time.   "A" problem about
using ATZ is that it may pull up a "saved" configuration (AT&Wn on USR
modems) that was b0rken accidentally.  On the other hand, virtually
every modem knows ATZ, but not all have a AT&Fn or equal.

>I see some that don't appear in any of the Hayes or USR docs I have:

>   +MR=2;           +DR=1;         +ER=1;         +ES=3,0,2;
>   +DS=3;           +IFC=2,2;

Plus commands are often Rockwell chip-set, and refer to FAX modes.

>   W2

Rockwell - report DCE speed on connect, rather than DTE (port) speed.

>   #ud

Got me there - not in any of my books

>> ...I have a dial-up account with an ISP that has nine "local"
>> access numbers that actually connect to three different
>> Point-Of-Presence providers 

>Isn't that nice? :-\ With my two completely differentr ISPs, I have a
>script, called from each of the scripts that starts a connection to
>one or the other ISP, that swaps in the right version of
>/etc/mail/mailertable.db so sendmail will go to the right smarthost
>for outgoing mail.

[fermi ~]$ wc /usr/local/bin/dialin
 189  539 5055 /usr/local/bin/dialin
[fermi ~]$ wc /etc/ppp/ip-*local
  31  167  984 /etc/ppp/ip-down.local
 127  640 4492 /etc/ppp/ip-up.local
 158  807 5476 total
[fermi ~]$

Lots of 'if elif else' and and a couple of case statements.  ;-)

>> Sounds like it's time to find another ISP.

>Easier said than done where I am.  With a lot of bother (with
>antennae, cables, poles, guys in the yard trying to get signal
>somewhere) I could have wireless broadband, just one notch faster
>than the very  slowest of wired broadband services.

In 1996, we got transferred to Phoenix, Arizona, which is not all that
bad, though quite large. I'm about 21 miles North of city hall (but
still 6 miles South of the northern city boundary) which is a bit off
the beaten path.  When we moved here, the only options were a not
very reliable (but expensive) wireless link, or the standard copper
telephones.  We went with the latter (had three lines - one for phone,
one for "our" modem use, and one provided by my wife's employer for
business use).  The local cable company (Cox) finally dragged in some
lines (everything here is underground - we see several thunderstorms
in the Metro area each year that blow down a half mile or so of pole
line).  Not to be out-done, the local telco (US West, which was borged
into QWest, which has been bought by CenturyLink) pulled fiber far
enough to set up road-side Remote Access Multiplexers to permit DSL
in the area using existing copper.  Currently, CenturyLink has pulled
fiber into the local streets, and is flogging that as the latest
greatest thing ever...  (at exorbitant but wildly varying quoted
prices, plus taxes and fees).

>In any case, I've been with the offending ISP since they were a bunch
>of guys I knew doing a startup in Nova Scotia in the mid-90s. IPO'd,
>borged, spun off, mergered, sold, sold again but I'm a long-time
>customer. Better the devil you know than the devil you don't. Frying
>pan/fire etc.  I'll have to bite the wax tadpole and do the Rural
>Wireless one of these days.

Yup - know the problem all too well.

>> Code speak for "we don't want your dial-up business - you must
>> upgrade to our new Fiber service".

and now you have an idea where I'm coming from with that.   Verizon,
which now owns/operates the copper in the New York city region has
been pushing this one hard. See news://comp.risks/  such as Risks-
Forum Digest Volume 28 issues 01 ("When the Landline Is a Lifeline")
and 20 ("How Verizon lets its copper network decay to force phone
customers onto fiber") as examples.

>Thank you very much for your point-by-point attention.

Glad to be able to help!

>Now, if the torrential rain will just stop, I can get out into the
>yard or the blacksmith shop and do something more productive than
>try to fix something that somebody else broke. (You're in Phoenix?
>Torrential rain is probably not a problem there. :-)

Actually, we had a deluge a couple of weeks ago that flooded out the
Interstate 10 when several underpasses had their drains clogged.  And
over this last night, I got 0.35 inches, which brings me to 11.33
inches for the year which is a bit over my 10-year average (10.90
inch).  The official City of Phoenix average is 7.66 inch and the
current, 8.35 inches.  Most of the rainfall here is thunderstorms
("Cloudburst" from "Grand Canyon Suite" by Ferde Grofe'), so rain
tends to be hit-or-miss. This shows up in the "standard deviation" of
the annual rates - in my case, it's 3.57", and  I've seen years with
5.11 to 17.44 inches at the extremes.  Phoenix has longer records than
I do, and their extremes are 2.82 (1956) to 19.73 (1905) inches for a
calender year.   Hmmm... I hear thunder now... and it is spitting.

        Old guy

[toc] | [prev] | [next] | [standalone]

#3189

Moe Trin <ibuprofin@painkiller.example.tld.invalid> writes:

> On 12 Dec 2014 22:34:50 -0400, on newsgroups comp.protocols.ppp and
> comp.os.linux.networking, in article <87r3w4s2et.fsf@bogus.nodomain.nowhere>,
> Mike Spencer wrote:
> 
> 
> Are you using the "same" dialin scripts?  
> 
>> No. The other, still locally managed, ISP is still using text mode
>> auth.
> 
> Wow!  How do they get windoze boxes to connect?   If they're using the
> ordinary windoze Dial-Up-Networking app, that's a non-text mode, and
> you're very lucky that the ISP went the extra mile to configure the
> text mode.

I have to assume that there is a server config such that if Windoes
does whatever it does, it's recognized while if you submit text auth,
*that* is recognized.  I leave it alone on an If It Ain't Broke, Don't
Fix It basis.  In any case, I can jump in the car and get to *that*
ISP's NOC in an hour or so where the admin will be happy to offer me a
coffee. 

> Actually, it depends on what you've got in there. The file
> [/etc/ppp/options] is read when the pppd program starts, not when it
> needs a particular variable.  The idea was to avoid accidental
> confusion.

Didn't know that.


>> I owe you a beer (or Laphroig or other
>> beverage of choice) should you be in Nova Scotia.
> 
> Haven't been there in maybe 35 years...

Oh, well.  I haven't been in AZ since 1947.

> ...but glad to be able to help.

And much appreciated.

> ...but
> the usual mantra is "if you don't KNOW you need it, don't use it". 

Noted for future reference.

> Code speak for "we don't want your dial-up business - you must
> upgrade to our new Fiber service".
> 
> and now you have an idea where I'm coming from with that.   Verizon,
> which now owns/operates the copper in the New York city region has
> been pushing this one hard. See news://comp.risks/  such as Risks-
> Forum Digest Volume 28 issues 01 ("When the Landline Is a Lifeline")
> and 20 ("How Verizon lets its copper network decay to force phone
> customers onto fiber") as examples.

Yeah. I follow comp.risks.  I doubt that our telco -- recently merged
with Bell Canada -- is going to abandon copper real soon, given the
number of very rural villages, hamlets and single houses.  But I
wouldn't put more than ten bucks on a bet.

> 
>> Thank you very much for your point-by-point attention.
> 
> Glad to be able to help!
> 
>> Now, if the torrential rain will just stop, I can get out into the
>> yard or the blacksmith shop and do something more productive than
>> try to fix something that somebody else broke. (You're in Phoenix?
>> Torrential rain is probably not a problem there. :-)
> 
> Actually, we had a deluge a couple of weeks ago that flooded out the
> Interstate 10 when several underpasses had their drains clogged.  And
> over this last night, I got 0.35 inches, which brings me to 11.33
> inches for the year which is a bit over my 10-year average (10.90
> inch). 

We had about 4" in 36 to 48 hours. That was a follow-on to an already
very rainy autumn.  At the peak, we had between 5 and 10
gallons/minute seeping into our dry-stone dirt-floor cellar. I don't
know the typical rainfall average but it's very much on the wet side.

tnx,

-- 
Mike Spencer                  Nova Scotia, Canada

[toc] | [prev] | [next] | [standalone]

#3190

On 15 Dec 2014, in the Usenet newsgroup comp.os.linux.networking, in article
<877fxt4at9.fsf@bogus.nodomain.nowhere>, Mike Spencer wrote:

>Moe Trin <ibuprofin@painkiller.example.tld.invalid> writes:

>> Mike Spencer wrote:

>>> No. The other, still locally managed, ISP is still using text mode
>>> auth.

>> Wow!  How do they get windoze boxes to connect?   If they're using
>> the ordinary windoze Dial-Up-Networking app, that's a non-text
>> mode, and you're very lucky that the ISP went the extra mile to
>> configure the text mode.

>I have to assume that there is a server config such that if Windoes
>does whatever it does, it's recognized while if you submit text auth,
>*that* is recognized.

Windoze uses the "AutoPPP" mode where as soon as the modem reports a
connection, it begins sending ppp frames.  Windoze never looks for a
text prompt.  For a while, windoze-9x and NT-3.x might be set to send
the text string "CLIENT" to the peer, but that broke so many things
(it only worked with NT servers) that microsoft dropped that feature.

>I leave it alone on an If It Ain't Broke, Don't Fix It basis.  In any
>case, I can jump in the car and get to *that* ISP's NOC in an hour or
>so where the admin will be happy to offer me a coffee. 

I hear you!  ;-)    For Fibernetics, we used the one liner

  exec /usr/sbin/pppd user mspencer1@ca.inter.net lock crtscts 
    nodetach defaultroute modem 115200 noipdefault /dev/modem connect 
    "/usr/sbin/chat -v ABORT BUSY \"\" AT\&F1 OK ATDT18442449946
    CONNECT \"\d\c\""

For this other ISP, you'd have to change "user mspencer1@ca.inter.net"
to what-ever is appropriate, and change the phone number.  You'd also
have to have /etc/ppp/*ap-secrets set with the matching secrets, and
that should be it. (I'm assuming you've done what-ever to have the
DNS resolving set up.)  You can do that in a similar dialing script,
or make a giant mess of things as I have:

[fermi ~]$ wc /usr/local/bin/dialin
 189  539 5055 /usr/local/bin/dialin
[fermi ~]$ grep connect /usr/local/bin/dialin
   /usr/sbin/pppd $DEV ipparam $IPPAR $SPEED user $USERNAME connect
 "/usr/sbin/chat REPORT CONNECT ABORT \"NO DIALTONE\" ABORT BUSY \"\"
 $INITSTR OK ATDT$PHNUM CONNECT \"\d\c\""
[fermi ~]$

I set all of the "common to all" stuff in /etc/ppp/options.  "$DEV" is
set to the appropriate device name (/dev/ttyS1 for RS232 ports,
/dev/ttyACM0 for USB modems) with $INITSTR being the "correct" init
string for that modem, while $SPEED sets the port speed (115200 for
the RS232 ports, 460800 for USB).  $IPPAR is a variable passed (as $6)
to /etc/ppp/ip-[up|down].local to select the appropriate DNS resolver,
smart-host, etc. using a case statement, and $USERNAME and $PHNUM (and
$IPPAR) are set in case statements in the dialin script for ISP and
access number.   As the $USERNAME is different for each ISP, pppd has
no problem finding the correct secret in /etc/ppp/*ap-secrets.

>> the usual mantra is "if you don't KNOW you need it, don't use it". 

>Noted for future reference.

The ANU pppd program is _very_ versatile, and includes a lot of stuff
that is not really usable by the average user/setup.  If you look at
the pppd man page, there are 166 different options listed which is
worse than GNU "ls".   ;-)

>> Actually, we had a deluge a couple of weeks ago that flooded out
>> the Interstate 10 when several underpasses had their drains
>> clogged.  And over this last night, I got 0.35 inches, which
>> brings me to 11.33 inches for the year which is a bit over my
>> 10-year average (10.90 inch). 

We got 0.14" more Saturday afternoon, and the forecasters are telling
us to expect rain Tuesday/Wednesday, and possibly even more on next
weekend.

>We had about 4" in 36 to 48 hours. That was a follow-on to an already
>very rainy autumn.  At the peak, we had between 5 and 10
>gallons/minute seeping into our dry-stone dirt-floor cellar.

Slight opposite problem here - there are a number of dry river and
creek beds here - and in a thunderstorm, we MAY get a small flood as
the water attempts to run off.  Because such flooding is relatively
rare, the local roads and highways often DON'T have a bridge over
them - just grade the roadway across the stream - pave it if it's
a street that gets more than occasional use.  Why pay for a bridge or
culvert you almost never need?  ;-)  Instead, they put up a standard
road warning signs ("Road Subject To Flooding" and "Do Not Cross If
Flooded") which is cheaper, and gives the driver a "Head's Up"
warning.  That's why we also have what is legally called the "Stupid
Motorist" law, which says that if you drive into a flooded wash, creek
or river-bed and have to be rescued, you pay the costs of that rescue
to the town/city/county/state department that rescues you.

>I don't know the typical rainfall average but it's very much on the
>wet side.

If I can believe Environment Canada, you're probably right around 60
inches/year.   Wet, but not the worst place I've ever heard of ;-)

        Old guy

[toc] | [prev] | [next] | [standalone]

#3191

Moe Trin <ibuprofin@painkiller.example.tld.invalid> writes:

> For this other ISP, you'd have to....have to have
> /etc/ppp/*ap-secrets set with the matching secrets, and that should
> be it. (I'm assuming you've done what-ever to have the DNS resolving
> set up.)

Annoyingly, /etc/resolv.conf is read when inetd starts.  So my plan to
swap in (from a notionally hidden directory) a unique version of that
file each time I dial one or the other ISP doesn't work.  I just put 3
entries in resolv.conf: one for each ISP plus a google DNS host.  I
guess I could kill -HUP inetd each time after the swap.  The swap
business works for sendmail to reference the right smarthost for the
current ISP.

> If I can believe Environment Canada, you're probably right around 60
> inches/year.   Wet, but not the worst place I've ever heard of ;-)

No, not the worst.  Makes for badly leached topsoil, spectacular mud
time in spring and sometimes difficulty getting the hay made.  My very
first day in NS, in 1967, I was amazed that everybody was out making
hay on Aug. 10.  I asked a farmer and he said, "It's the first time
we've had the weather to do it."  Normally, we make hay in late June,
into early or mid July.

-- 
Mike Spencer                  Nova Scotia, Canada

[toc] | [prev] | [next] | [standalone]

#3192

On 17 Dec 2014, in the Usenet newsgroup comp.os.linux.networking, in article
<87r3vyis2z.fsf@bogus.nodomain.nowhere>, Mike Spencer wrote:

>Moe Trin <ibuprofin@painkiller.example.tld.invalid> writes:

>> I'm assuming you've done what-ever to have the DNS resolving set up.

>Annoyingly, /etc/resolv.conf is read when inetd starts.  So my plan
>to swap in (from a notionally hidden directory) a unique version of
>that file each time I dial one or the other ISP doesn't work.

What went wrong?

I can't say I've run into any problems, though I'm also not running
inetd (all servers on the dial-out box are running 'stand-alone'
rather than using the inetd or xinetd super-server). I've successfully
used the ppp option "usepeerdns" which will get nameserver address(es)
from the peer (the microsoft way), and pppd then sets two internal
variables (DNS1 and DNS2) and creates a file /var/run/ppp/resolv.conf
file containing one or two nameserver lines with the address(es)
supplied by the peer.  I then used /etc/ppp/ip-up.local to

    mv /etc/resolv.conf /etc/resolv.conf.previous
    mv /var/run/ppp/resolv.conf  /etc/resolv.conf

while /etc/ppp/ip-down.local contained

    mv /etc/resolv.conf.previous /etc/resolv.conf

to revert things when the link goes down.  I don't use any other
directives in /etc/resolv.conf, but if needed, you could 'echo' append
them to the pppd created file.  Hosts on the house LAN are all in the
/etc/hosts file and /etc/nsswitch.conf is set with

    hosts:      files dns

(I don't use the Avahi service).    My "normal" setup is to run a full
nameserver on a local host - authoritative for the local LAN and doing
full recursive queries for external lookups, and all local hosts look
there, rather than to the ISP's nameservers.  That's probably overkill
for most people.

>I guess I could kill -HUP inetd each time after the swap.

That should work if that's the problem.

>I just put 3 entries in resolv.conf: one for each ISP plus a google
>DNS host.

I tend to avoid mixing servers like that.  Unless you have "options
rotate" in /etc/resolv.conf, you're likely to be sending most of the
DNS queries to the nameserver listed first in /etc/resolv.conf.  The
concept is that the resolver believes the "first" response it receives
from any nameserver, and if nameserver A replies "NXDOMAIN", it has
no need to ask nameserver B or C because it _has_ an answer.  Multiple
nameserver declarations are there for redundancy, not for "if you
don't like the answer from one, ask the second/third".  Thus, any
nameserver you ask should provide the same "correct" answer, or not
respond at all.

        Old guy

[toc] | [prev] | [next] | [standalone]

#3195

Moe Trin <ibuprofin@painkiller.example.tld.invalid> writes:

> I've successfully used the ppp option "usepeerdns" which will get
> nameserver address(es) from the peer (the microsoft way), and pppd
> then sets two internal variables (DNS1 and DNS2) and creates a file
> /var/run/ppp/resolv.conf file containing one or two nameserver lines
> with the address(es) supplied by the peer.
> [ snip further details]

Huh.  Cool.  I didn't know how that was supposed to work.  I'll have
to try that.  I can dick around with hiding or restoring
/etc/resolve.conf  as needed.

I dislike the idea that we should all just use google's open DNS
server.  I've also noted tha some wi-fi access points have a feature
that points all DNS requests back to the manufacturer of the wireless
router.  I think that's pretty wierd but I haven't had occasion to
look at it closely.

-- 
Mike Spencer                  Nova Scotia, Canada

[toc] | [prev] | [next] | [standalone]

#3196

On 21 Dec 2014, in the Usenet newsgroup comp.os.linux.networking, in article
<87bnmxv4ys.fsf@bogus.nodomain.nowhere>, Mike Spencer wrote:

>> "usepeerdns"

>Huh.  Cool.  I didn't know how that was supposed to work.  I'll have
>to try that.  I can dick around with hiding or restoring
>/etc/resolve.conf  as needed.

The option was added in ppp-2.3.6 in 1999.  Before that, I had the
/etc/ppp/ip-up script looking at the peer's IP address (which is passed
to the script as one of six variables by pppd), and selecting a pair
of DNS addresses with a "case" statement based on that.   The dialin
box at home runs 24/7, so it was set up as a caching/forwarding name
server (some distributions have a package for this - perhaps "dnsmasq")
for the hosts behind it.   The hoop to jump through was when the ppp
link came up, the program has to be told the "new" or current IPs of
the hosts to forward to, and then told to re-read it's configuration
file.  The DNS-HOWTO

   DNS HOWTO       Updated: Dec 2001. How to become a totally "small
                   time" DNS admin.

 -rw-rw-r--    1 gferg    ldp         91563 Dec 23  2001 DNS-HOWTO

explains how to set this up.  Resetting the 'forwarders' directive in
/etc/named.conf was just a variation of kicking /etc/resolv.conf.  As I
now run a small recursive DNS server, I'm not doing this any more.  The
real question would be "do I really need to do this?"   ;-)

>I dislike the idea that we should all just use google's open DNS
>server. 

They are far from the only choice -  See

 http://www.tech-faq.com/public-dns-servers.html
 http://pcsupport.about.com/od/tipstricks/a/free-public-dns-servers.htm

for other available servers.  Like television, google is an advertising
service and their whole existence revolves around finding ways to hit
you with more "targeted" ads.  The public services they perform are
like the programming on TV - meant to entice you to view the ads.

>I've also noted tha some wi-fi access points have a feature that
>points all DNS requests back to the manufacturer of the wireless
>router.  I think that's pretty wierd but I haven't had occasion to
>look at it closely.

I suspect that's the result of an incomplete install or setup, where
whoever set up the access point failed to change the DNS server address
that gets handed out by the DHCP server (RFC2132 section 3.8), and the
router still has a factory default value.

        Old guy

[toc] | [prev] | [next] | [standalone]

#3183

On Mon, 8 Dec 2014, Mike Spencer wrote:

>
> Up until a month or so ago, I had a working dialup account with
> Ca.Inter.Net.  Their dialup phone numbers and machines -- Network
> Access Servers or NASs -- were provided by Telus and the account
> worked fine.
>
> Now Fibernetics.ca has taken over Ca.Inter.Net. The Telus phone
> numbers stopped working without warning.  The account still exists,
> mail server works fine but not dialup PPP.  After some weeks,
> Fibernetics provided a toll-free 844 number for dialup access to their
> own new server.
>
> Nothing I can do will establish a PPP connection at that number.
>
The ISP that I had from 2006 to 2012 (and which I still keep a shell 
account with), I had problems when I moved to them, instead of just the 
username, it wanted the whole email address.  Not something I expected, 
and I assumed it was an attempt to make it that much harder for someone to 
figure out how to break in.

Then aoubt 2010, they got a new phone number for dial-up, and it seemed 
like they were outsourcing, consolidating with other companies that still 
wanted to offer dial-up without having to maintain a block of modems that 
might not actually be used much.  I had the feeling I was one of the last 
dialup users, but have no statistics for that.

But when the phone number changed, it became more complicated.  If I 
recall properly (I only had to configure it once, and that was a few years 
back, and the file isn't on the old computer), there was a new username, 
and perhaps password, for the login at the third party server.  That makes 
sense, the third party wants only legit users to get in, but the ISP 
doesn't want to hand over a list of users and passwords.

So I wonder if a new, or at least modified username and/or password is 
required with this new system.  That would explain why you can the old 
mailserver but can't use the dialup.

That doesn't explain why they didn't tell you this.  Software isn't going 
to know that suddenly a new username is needed, and know the format.

This sort of thing can be annoying, "is it me or is it the ISP" and of 
course the software at their end doesn't want to be very specific, since 
it might give away clues to someone wanting to break in.

   Michael

[toc] | [prev] | [next] | [standalone]

#3184

On Thu, 11 Dec 2014, in the Usenet newsgroup comp.os.linux.networking, in
article <alpine.LNX.2.02.1412111451440.14907@darkstar.example.org>, Michael
Black wrote:

>The ISP that I had from 2006 to 2012 (and which I still keep a shell 
>account with), I had problems when I moved to them, instead of just
>the username, it wanted the whole email address.  Not something I
>expected, and I assumed it was an attempt to make it that much harder
>for someone to figure out how to break in.

Probably due to the method of authenticating more than worrying about
break-ins.  If you think about it, in the olde days, your username
was the same as your mail name, and equally public,

>Then aoubt 2010, they got a new phone number for dial-up, and it
>seemed like they were outsourcing, consolidating with other companies
>that still wanted to offer dial-up without having to maintain a block
>of modems that might not actually be used much.

Yup - that has been going around. My "primary" dial-in ISP went to
"Point of Presence" providers in 2006.   It did result in having more
local numbers, but as the entire metropolitan area is in the local
call range, this wasn't really required.

>I had the feeling I was one of the last dialup users, but have no
>statistics for that.

Doing a search for dialin service will likely turn up a fair number of
providers for your area.  Last I looked here in Phoenix, there were
over a dozen.  Looking at their web-sites and checking out the access
numbers, it appeared that they were all using one of four or five
POPs

>But when the phone number changed, it became more complicated.  If I 
>recall properly (I only had to configure it once, and that was a few
>years back, and the file isn't on the old computer), there was a new
>username, and perhaps password, for the login at the third party
>server.  That makes sense, the third party wants only legit users to
>get in, but the ISP doesn't want to hand over a list of users and
>passwords.

No idea why that would be the case. Authentication is done via remote
servers.  See the RFCs

   2865 Remote Authentication Dial In User Service (RADIUS). C. Rigney,
        S. Willens, A. Rubens, W. Simpson. June 2000. (Format:
        TXT=146456 bytes) (Obsoletes RFC2138) (Updated by RFC2868,
        RFC3575, RFC5080, RFC6929) (Status: DRAFT STANDARD)

>So I wonder if a new, or at least modified username and/or password
>is required with this new system.  That would explain why you can the
>old mailserver but can't use the dialup.

See his second post

>That doesn't explain why they didn't tell you this.  Software isn't
>going to know that suddenly a new username is needed, and know the
>format.

We could tell you, but then we'd have to shoot you  ;-)

>This sort of thing can be annoying, "is it me or is it the ISP" and
>of course the software at their end doesn't want to be very specific,
>since it might give away clues to someone wanting to break in.

Less likely - NORMALLY, they will tell you what crap to put where in
the windoze dialup networking application, and if you are VERY lucky
they may know how to do so for MacOS (but I wouldn't count on it).
If you are using Linux or *BSD or something,  they can't be bothered
learning how to use the many available tools/applications.

I'm somewhat more disappointed, because every distribution has/had
their own little tool, and every one seemed to be barking up the
wrong tree.   WvDial still cracks me up - the authors went to great
lengths to create a tool that would find a text based login prompt
no matter how much the ISP may have tried to hide it, and were miffed
to discover that text based logins went out of style in 1995 because
every ISP was toeing the line to follow the AutoPPP standard required
by microsoft for windoze.

        Old guy

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.networking

csiph-web