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

Groups > comp.os.linux.networking > #3185

Re: Dialup PPP fails after new server, admins at ISP

Cross-posted to 2 groups.

Show all headers | View raw

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/                        ^^-^^

Back to comp.os.linux.networking | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web