Dialup PPP fails after new server, admins at ISP

Discussion in 'Linux Networking' started by Mike Spencer, Dec 9, 2014.

  1. Mike Spencer

    Mike Spencer Guest

    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?
     
    Mike Spencer, Dec 9, 2014
    #1
    1. Advertisements

  2. Mike Spencer

    Moe Trin Guest

    On 08 Dec 2014, in the Usenet newsgroup comp.os.linux.networking, in article
    Sounds like it's time to find another ISP
    They set up a modem and terminal server...
    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.
    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 (""),
    but exactly how they expect a windoze box to connect is beyond me.
    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.
    Yup - been that way since 1995
    Code speak for "we don't want your dial-up business - you must upgrade
    to our new Fiber service".
    [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 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.
    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).
    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.
    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
     
    Moe Trin, Dec 9, 2014
    #2
    1. Advertisements

  3. Mike Spencer

    Mike Spencer Guest

    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.

    (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:
    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 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, Dec 11, 2014
    #3
  4. Mike Spencer

    Moe Trin Guest

    That really has happened before, and it drives people crazy.
    which puts us back into familiar territory.
    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.
    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.
    Not needed
    That giant crash you just heard is me trying to find my O'Reilly "UNIX
    In A Nutshell" book... OK, I think.
    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.
    PROBABLY not needed
    probably not needed. The peer is going to supply both addresses of
    the link.
    Not needed
    PROBABLY not needed
    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.
    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.
    As above on the timeout - otherwise OK
    This is the area where the problem lies.
    OK, now _that_ says things worked.
    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.
    The terminal server is (I think) just echoing what you sent.
    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.
    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 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.
    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
     
    Moe Trin, Dec 11, 2014
    #4
  5. 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
     
    Michael Black, Dec 11, 2014
    #5
  6. Mike Spencer

    Moe Trin Guest

    On Thu, 11 Dec 2014, in the Usenet newsgroup comp.os.linux.networking, 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,
    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.
    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
    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)
    See his second post
    We could tell you, but then we'd have to shoot you ;-)
    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
     
    Moe Trin, Dec 12, 2014
    #6
  7. Mike Spencer

    Mike Spencer Guest

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

    No. The other, still locally managed, ISP is still using text mode
    auth.
    Not relevant if the connection is never getting far enough into LCP to
    negotiate PAP (or CHAP or whatever).
    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.
    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",
    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.
    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.

    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.
    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
     
    Mike Spencer, Dec 13, 2014
    #7
  8. Mike Spencer

    Moe Trin Guest

    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.
    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.
    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
    Haven't been there in maybe 35 years, but glad to be able to help.
    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.)
    That's partly why I always recommend using that "one-liner" to see if
    you can get things working.
    That will work!
    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.
    Plus commands are often Rockwell chip-set, and refer to FAX modes.
    Rockwell - report DCE speed on connect, rather than DTE (port) speed.
    Got me there - not in any of my books
    [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. ;-)
    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).
    Yup - know the problem all too well.

    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.
    Glad to be able to help!
    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
     
    Moe Trin, Dec 13, 2014
    #8
  9. Mike Spencer

    Mike Spencer Guest

    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.
    Didn't know that.

    Oh, well. I haven't been in AZ since 1947.
    And much appreciated.
    Noted for future reference.
    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.
    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, Dec 15, 2014
    #9
  10. Mike Spencer

    Moe Trin Guest

    On 15 Dec 2014, in the Usenet newsgroup comp.os.linux.networking, in article
    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 hear you! ;-) For Fibernetics, we used the one liner

    exec /usr/sbin/pppd user 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 "
    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 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". ;-)

    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.
    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.
    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
     
    Moe Trin, Dec 15, 2014
    #10
  11. Mike Spencer

    Mike Spencer Guest

    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.
    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, Dec 17, 2014
    #11
  12. Mike Spencer

    Moe Trin Guest

    On 17 Dec 2014, in the Usenet newsgroup comp.os.linux.networking, in article
    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.
    That should work if that's the problem.
    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
     
    Moe Trin, Dec 17, 2014
    #12
  13. Mike Spencer

    Mike Spencer Guest

    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, Dec 21, 2014
    #13
  14. Mike Spencer

    Moe Trin Guest

    On 21 Dec 2014, in the Usenet newsgroup comp.os.linux.networking, in article
    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?" ;-)
    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 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
     
    Moe Trin, Dec 21, 2014
    #14
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.