Using PPP to dial-in to ISP - Mandriva

This is a discussion on Using PPP to dial-in to ISP - Mandriva ; I have a dual-boot system, Win98 and MD2007.0 Late last year, my ISP had to change from a local call number to a national call number. Since changing, I have not been able to get KPPP to establish a connection. ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 39

Thread: Using PPP to dial-in to ISP

  1. Using PPP to dial-in to ISP

    I have a dual-boot system, Win98 and MD2007.0

    Late last year, my ISP had to change from a local call number to a
    national call number. Since changing, I have not been able to get KPPP
    to establish a connection.

    Using Win98, I can dial into my ISP, get mail, surf, etc.

    With MD2007, KPPP dials in, PPP starts but then the connection is
    refused and I get a PPP Logfile like this:-

    Quote:-
    Feb 20 17:03:45 www pppd[6447]: pppd 2.4.3 started by daniel, uid 500
    Feb 20 17:03:45 www pppd[6447]: using channel 3
    Feb 20 17:03:45 www pppd[6447]: Using interface ppp0
    Feb 20 17:03:45 www pppd[6447]: Connect: ppp0 <--> /dev/ttyS0
    Feb 20 17:03:45 www pppd[6447]: sent [LCP ConfReq id=0x1
    ]
    Feb 20 17:03:46 www pppd[6447]: rcvd [LCP ConfReq id=0xe 0xa0000>
    ]
    Feb 20 17:03:46 www pppd[6447]: sent [LCP ConfRej id=0xe ]
    Feb 20 17:03:46 www pppd[6447]: rcvd [LCP ConfAck id=0x1
    ]
    Feb 20 17:03:46 www pppd[6447]: rcvd [LCP ConfReq id=0xf 0xa0000> [local:63.68.61.70]>]
    Feb 20 17:03:46 www pppd[6447]: sent [LCP ConfAck id=0xf 0xa0000> [local:63.68.61.70]>]
    Feb 20 17:03:46 www pppd[6447]: sent [PAP AuthReq id=0x1
    user="dxmm@albury.net.au" password=]
    Feb 20 17:03:46 www pppd[6447]: rcvd [LCP ConfReq id=0xe7
    ]
    Feb 20 17:03:46 www pppd[6447]: sent [LCP ConfReq id=0x2
    ]
    Feb 20 17:03:46 www pppd[6447]: sent [LCP ConfAck id=0xe7
    ]
    Feb 20 17:03:46 www pppd[6447]: rcvd [LCP ConfRej id=0x2
    ]
    Feb 20 17:03:46 www pppd[6447]: sent [LCP ConfReq id=0x3 ]
    Feb 20 17:03:46 www pppd[6447]: rcvd [LCP ConfAck id=0x3 ]
    Feb 20 17:03:46 www pppd[6447]: sent [PAP AuthReq id=0x2
    user="dxmm@albury.net.au" password=]
    Feb 20 17:03:49 www pppd[6447]: sent [PAP AuthReq id=0x3
    user="dxmm@albury.net.au" password=]
    Feb 20 17:03:52 www pppd[6447]: sent [PAP AuthReq id=0x4
    user="dxmm@albury.net.au" password=]
    Feb 20 17:03:55 www pppd[6447]: sent [PAP AuthReq id=0x5
    user="dxmm@albury.net.au" password=]
    Feb 20 17:03:58 www pppd[6447]: sent [PAP AuthReq id=0x6
    user="dxmm@albury.net.au" password=]
    Feb 20 17:04:01 www pppd[6447]: sent [PAP AuthReq id=0x7
    user="dxmm@albury.net.au" password=]
    Feb 20 17:04:04 www pppd[6447]: sent [PAP AuthReq id=0x8
    user="dxmm@albury.net.au" password=]
    Feb 20 17:04:07 www pppd[6447]: sent [PAP AuthReq id=0x9
    user="dxmm@albury.net.au" password=]
    Feb 20 17:04:10 www pppd[6447]: sent [PAP AuthReq id=0xa
    user="dxmm@albury.net.au" password=]
    Feb 20 17:04:13 www pppd[6447]: sent [PAP AuthReq id=0xb
    user="dxmm@albury.net.au" password=]
    Feb 20 17:04:16 www pppd[6447]: No response to PAP authenticate-requests
    Feb 20 17:04:16 www pppd[6447]: sent [LCP TermReq id=0x4 "Failed to
    authenticate ourselves to peer"]
    Feb 20 17:04:19 www pppd[6447]: sent [LCP TermReq id=0x5 "Failed to
    authenticate ourselves to peer"]
    Feb 20 17:04:20 www pppd[6447]: Hangup (SIGHUP)
    Feb 20 17:04:20 www pppd[6447]: Modem hangup
    Feb 20 17:04:20 www pppd[6447]: Connection terminated.
    Feb 20 17:04:20 www pppd[6447]: Exit.
    End Quote

    Seems to me, I sending my user name and password heaps of times, but,
    for some reason, the ISP's server doesn't want to let me in.

    Anybody got any clues???

    TIA

    Daniel

    --
    Posted via a free Usenet account from http://www.teranews.com


  2. Re: Using PPP to dial-in to ISP

    On Wed, 20 Feb 2008 02:32:18 -0500, Daniel wrote:

    > With MD2007, KPPP dials in, PPP starts but then the connection is
    > refused and I get a PPP Logfile like this:-


    Please add the dump option to /etc/ppp/options, so we can see exactly
    which settings, it is using. Also add ...

    noccp
    nodeflate
    nobsdcomp

    to ensure there is not a problem being cause by a windows server
    trying to insist on an ms compression format, that ppp does not support.

    > Feb 20 17:03:46 www pppd[6447]: rcvd [LCP ConfReq id=0xe > 0xa0000>
    > ]
    > Feb 20 17:03:46 www pppd[6447]: sent [LCP ConfRej id=0xe ]


    What do you have for mru and mtu in options? Either leave them out,
    or, if they are not currently in the options file, set them both to 1524,
    as in ...

    mru 1524
    mtu 1524

    Then post the ppp output from syslog again.

    Regards, Dave Hodgins
    --
    Change nomail.afraid.org to ody.ca to reply by email.
    (nomail.afraid.org has been set up specifically for
    use in usenet. Feel free to use it yourself.)

  3. Re: Using PPP to dial-in to ISP

    David W. Hodgins wrote:
    > On Wed, 20 Feb 2008 02:32:18 -0500, Daniel wrote:
    >
    >> With MD2007, KPPP dials in, PPP starts but then the connection is
    >> refused and I get a PPP Logfile like this:-

    >
    > Please add the dump option to /etc/ppp/options, so we can see exactly
    > which settings, it is using. Also add ...
    >
    > noccp
    > nodeflate
    > nobsdcomp
    >
    > to ensure there is not a problem being cause by a windows server
    > trying to insist on an ms compression format, that ppp does not support.
    >
    >> Feb 20 17:03:46 www pppd[6447]: rcvd [LCP ConfReq id=0xe >> 0xa0000>
    >> ]
    >> Feb 20 17:03:46 www pppd[6447]: sent [LCP ConfRej id=0xe ]

    >
    > What do you have for mru and mtu in options? Either leave them out,
    > or, if they are not currently in the options file, set them both to 1524,
    > as in ...
    >
    > mru 1524
    > mtu 1524
    >
    > Then post the ppp output from syslog again.
    >
    > Regards, Dave Hodgins


    Will do and report back in about 6-8 hrs.

    Daniel

    --
    Posted via a free Usenet account from http://www.teranews.com


  4. Re: Using PPP to dial-in to ISP

    On Wed, 20 Feb 2008, in the Usenet newsgroup alt.os.linux.mandriva, in article
    <47bbcbfd$0$25994$88260bb3@free.teranews.com>, Daniel wrote:

    >Late last year, my ISP had to change from a local call number to a
    >national call number. Since changing, I have not been able to get
    >KPPP to establish a connection.


    OK, this is a continuation of a thread from mid-November in this
    group ("Cannot connect via kppp"), and as I recall the ISP was saying
    that they saw your attempts, but... yeah, they saw your authentication
    token and approved it, but you never saw any indications.

    >With MD2007, KPPP dials in, PPP starts but then the connection is
    >refused and I get a PPP Logfile like this:-


    >Feb 20 17:03:45 www pppd[6447]: sent [LCP ConfReq id=0x1
    > ]
    >Feb 20 17:03:46 www pppd[6447]: rcvd [LCP ConfReq id=0xe >0xa0000>
    >]


    Add option 'asyncmap 0xa0000' to cope with a misconfigured terminal
    server (0xa0000 is "software flow control" a.k.a XON/XOFF). The idea
    is that there are some horribly b0rken ppp server implementations out
    there, SOME OF WHICH don't operate correctly if the 'asyncmap' isn't
    the same in both directions. A rule of thumb is that if the peer is
    proposing an asyncmap, you should match it. (asyncmap tells which of
    the 32 "control" characters should be escaped. The default is none, but
    some implementations (generally from such sterling followers of standards
    as microsoft) assume that either side proposing an asyncmap expects it to
    be symmetrical - I want to to escape this/that and I will do so without
    further ado.) This can cause "misinterpretation" of the bit stream.

    Starting from the top:

    >Feb 20 17:03:45 www pppd[6447]: sent [LCP ConfReq id=0x1
    > ]


    Vanilla request EXCEPT you are asking for asyncmap 0x0 which is the
    default.

    >Feb 20 17:03:46 www pppd[6447]: rcvd [LCP ConfReq id=0xe >0xa0000>
    >]


    Peer wants 'asyncmap 0xa0000' PAP, magic (to identify loopback conditions)
    ppp protocol field compression, Address/Control compression, and multi-
    link.

    >Feb 20 17:03:46 www pppd[6447]: sent [LCP ConfRej id=0xe ]


    You reject the idea of multi-link (which is fine). You might try
    adding 'noendpoint' but I'm not sure it's important.

    >Feb 20 17:03:46 www pppd[6447]: rcvd [LCP ConfAck id=0x1
    > ]


    The peer acks your options

    >Feb 20 17:03:46 www pppd[6447]: rcvd [LCP ConfReq id=0xf >0xa0000> >[local:63.68.61.70]>]
    >Feb 20 17:03:46 www pppd[6447]: sent [LCP ConfAck id=0xf >0xa0000> >[local:63.68.61.70]>]


    The peer comes back and tries again without the MRRU option - you
    approve it.

    >Feb 20 17:03:46 www pppd[6447]: sent [PAP AuthReq id=0x1
    >user="dxmm@albury.net.au" password=]


    You try to send an authentication packet - expected.

    >Feb 20 17:03:46 www pppd[6447]: rcvd [LCP ConfReq id=0xe7
    > ]


    And this is unexpected. The peer has again proposed options, as if it
    has not heard the acceptance above.

    >Feb 20 17:03:46 www pppd[6447]: sent [LCP ConfReq id=0x2
    > ]


    And you restart as well - assuming that the peer didn't hear your earlier
    agreement.

    >Feb 20 17:03:46 www pppd[6447]: sent [LCP ConfAck id=0xe7
    > ]


    You ack this new proposal,

    >Feb 20 17:03:46 www pppd[6447]: rcvd [LCP ConfRej id=0x2
    > ]


    And the peer comes back and says it doesn't want these options.

    >Feb 20 17:03:46 www pppd[6447]: sent [LCP ConfReq id=0x3 ]
    >Feb 20 17:03:46 www pppd[6447]: rcvd [LCP ConfAck id=0x3 ]


    You comply, and the peer agrees with your new try, and that's the last we
    hear from the peer.

    >Seems to me, I sending my user name and password heaps of times, but,
    >for some reason, the ISP's server doesn't want to let me in.


    APPARENTLY because it can no longer decode the bit stream. Try two
    new options

    asyncmap 0xa0000 (This is the important one)
    noendpoint (this is less important)

    Old guy

  5. Re: Using PPP to dial-in to ISP

    On Wed, 20 Feb 2008, in the Usenet newsgroup alt.os.linux.mandriva, in article
    , David W. Hodgins wrote:

    >Please add the dump option to /etc/ppp/options, so we can see exactly
    >which settings, it is using.


    Good point, though things are pretty obvious based on the log.

    >Also add ...
    >
    >noccp
    >nodeflate
    >nobsdcomp
    >
    >to ensure there is not a problem being cause by a windows server
    >trying to insist on an ms compression format, that ppp does not support.


    Except we haven't gotten to the CCP stage yet. Check the man page, as
    'noccp' disables all CCP (Compression Configuration Protocol) making the
    other two unnecessary. Also, 'deflate' and 'bsdcomp' are the only two
    "free" compression algorithms ANU ppp knows, and it would automagically
    reject the microsoft algorithms - just as any windoze box would reject
    the two free algorithms.

    >> Feb 20 17:03:46 www pppd[6447]: sent [LCP ConfRej id=0xe ]

    >
    >What do you have for mru and mtu in options?


    mru n Set the MRU [Maximum Receive Unit] value to n. Pppd will
    ask the peer to send packets of no more than n bytes. The
    value of n must be between 128 and 16384; the default is
    1500.

    mtu n Set the MTU [Maximum Transmit Unit] value to n. Unless
    the peer requests a smaller value via MRU negotiation,
    pppd will request that the kernel networking code send
    data packets of no more than n bytes through the PPP net-
    work interface.

    mrru n Sets the Maximum Reconstructed Receive Unit to n. The
    MRRU is the maximum size for a received packet on a multi-
    link bundle, and is analogous to the MRU for the individ-
    ual links. This option is currently only available under
    Linux, and only has any effect if multilink is enabled
    (see the multilink option).

    Nope! mru and mtu have no effect on mrru - which is a multi-link
    problem.

    >Either leave them out, or, if they are not currently in the options
    >file, set them both to 1524, as in ...


    Why? The defaults of 1500 are adequate, and need only be changed on
    "slow" links (meaning <33.8k in interactive (remote server echoing back
    your keystrokes - telnet most commonly), or when using the PPPover$FOO
    protocols (PPPoE or PPPoA) because the "over$FOO" adds some bits making
    the packets oversized for normal links.

    Old guy

  6. Re: Using PPP to dial-in to ISP

    On Wed, 20 Feb 2008, in the Usenet newsgroup alt.os.linux.mandriva, in article
    <47bbcbfd$0$25994$88260bb3@free.teranews.com>, Daniel wrote:


    One other thought - perhaps a better option to try is

    receive-all
    With this option, pppd will accept all control characters
    from the peer, including those marked in the receive
    asyncmap. Without this option, pppd will discard those
    characters as specified in RFC1662. This option should
    only be needed if the peer is buggy.

    and see if that allows negotiations to continue. Depending how your
    pppd and kernel were compiled, there _MIGHT_ be some information in
    the otherwise very useless "kdebug" output - specifically the
    indication of frames being dropped. "kdebug 7" would show this, but
    is very wasteful of log space (and assumes kernel:debug output is
    directed to an appropriate file by /etc/syslog.conf). "kdebug" is
    NORMALLY a useless option, and is rarely suggested.

    Also, the option "nomp" or "nomultilink" could be used to disable the
    MRRU negitiations if that were to be a problem - it should not be.

    Old guy

  7. Re: Using PPP to dial-in to ISP

    David W. Hodgins wrote:
    > On Wed, 20 Feb 2008 02:32:18 -0500, Daniel wrote:
    >
    >> With MD2007, KPPP dials in, PPP starts but then the connection is
    >> refused and I get a PPP Logfile like this:-

    >
    > Please add the dump option to /etc/ppp/options, so we can see exactly
    > which settings, it is using. Also add ...
    >
    > noccp
    > nodeflate
    > nobsdcomp
    >
    > to ensure there is not a problem being cause by a windows server
    > trying to insist on an ms compression format, that ppp does not support.
    >
    >> Feb 20 17:03:46 www pppd[6447]: rcvd [LCP ConfReq id=0xe >> 0xa0000>
    >> ]
    >> Feb 20 17:03:46 www pppd[6447]: sent [LCP ConfRej id=0xe ]

    >
    > What do you have for mru and mtu in options? Either leave them out,
    > or, if they are not currently in the options file, set them both to 1524,
    > as in ...
    >
    > mru 1524
    > mtu 1524
    >
    > Then post the ppp output from syslog again.
    >
    > Regards, Dave Hodgins


    O.K. Here we go.

    The Customised pppd Arguments are:-
    debug
    mru 1524
    mtu 1524

    /etc/ppp/options is:-
    dump
    lock
    noauth
    noipdefault
    usepeerdns
    noccp
    nodeflate
    nobsdcomp

    and PPP logfile shows:-
    Feb 21 17:56:57 www pppd[6314]: pppd options in effect:
    Feb 21 17:56:57 www pppd[6314]: debug^I^I# (from command line)
    Feb 21 17:56:57 www pppd[6314]: -detach^I^I# (from command line)
    Feb 21 17:56:57 www pppd[6314]: dump^I^I# (from /etc/ppp/options)
    Feb 21 17:56:57 www pppd[6314]: noauth^I^I# (from /etc/ppp/options)
    Feb 21 17:56:57 www pppd[6314]: -chap^I^I# (from command line)
    Feb 21 17:56:57 www pppd[6314]: user dxmm@albury.net.au^I^I# (from
    command line)
    Feb 21 17:56:57 www pppd[6314]: 38400^I^I# (from command line)
    Feb 21 17:56:57 www pppd[6314]: lock^I^I# (from /etc/ppp/options)
    Feb 21 17:56:57 www pppd[6314]: mru 1524^I^I# (from command line)
    Feb 21 17:56:57 www pppd[6314]: mtu 1524^I^I# (from command line)
    Feb 21 17:56:57 www pppd[6314]: noipdefault^I^I# (from /etc/ppp/options)
    Feb 21 17:56:57 www pppd[6314]: usepeerdns^I^I# (from command line)
    Feb 21 17:56:57 www pppd[6314]: noccp^I^I# (from /etc/ppp/options)
    Feb 21 17:56:57 www pppd[6314]: nobsdcomp^I^I# (from /etc/ppp/options)
    Feb 21 17:56:57 www pppd[6314]: nodeflate^I^I# (from /etc/ppp/options)
    Feb 21 17:56:57 www pppd[6314]: pppd 2.4.3 started by daniel, uid 500
    Feb 21 17:56:57 www pppd[6314]: using channel 1
    Feb 21 17:56:57 www pppd[6314]: Using interface ppp0
    Feb 21 17:56:57 www pppd[6314]: Connect: ppp0 <--> /dev/ttyS0
    Feb 21 17:56:57 www pppd[6314]: sent [LCP ConfReq id=0x1
    ]
    Feb 21 17:56:57 www pppd[6314]: rcvd [LCP ConfReq id=0x1e 0xa0000>
    ]
    Feb 21 17:56:57 www pppd[6314]: sent [LCP ConfRej id=0x1e ]
    Feb 21 17:56:57 www pppd[6314]: rcvd [LCP ConfAck id=0x1
    ]
    Feb 21 17:56:57 www pppd[6314]: rcvd [LCP ConfReq id=0x1f 0xa0000> [local:63.68.61.70]>]
    Feb 21 17:56:57 www pppd[6314]: sent [LCP ConfAck id=0x1f 0xa0000> [local:63.68.61.70]>]
    Feb 21 17:56:57 www pppd[6314]: sent [PAP AuthReq id=0x1
    user="dxmm@albury.net.au" password=]
    Feb 21 17:56:58 www pppd[6314]: rcvd [LCP ConfReq id=0x58
    ]
    Feb 21 17:56:58 www pppd[6314]: sent [LCP ConfReq id=0x2
    ]
    Feb 21 17:56:58 www pppd[6314]: sent [LCP ConfAck id=0x58
    ]
    Feb 21 17:56:58 www pppd[6314]: rcvd [LCP ConfRej id=0x2
    ]
    Feb 21 17:56:58 www pppd[6314]: sent [LCP ConfReq id=0x3
    ]
    Feb 21 17:56:58 www pppd[6314]: rcvd [LCP ConfNak id=0x3 ]
    Feb 21 17:56:58 www pppd[6314]: sent [LCP ConfReq id=0x4 ]
    Feb 21 17:56:58 www pppd[6314]: rcvd [LCP ConfAck id=0x4 ]
    Feb 21 17:56:58 www pppd[6314]: sent [PAP AuthReq id=0x2
    user="dxmm@albury.net.au" password=]
    Feb 21 17:57:01 www pppd[6314]: sent [PAP AuthReq id=0x3
    user="dxmm@albury.net.au" password=]
    Feb 21 17:57:04 www pppd[6314]: sent [PAP AuthReq id=0x4
    user="dxmm@albury.net.au" password=]
    Feb 21 17:57:07 www pppd[6314]: sent [PAP AuthReq id=0x5
    user="dxmm@albury.net.au" password=]
    Feb 21 17:57:10 www pppd[6314]: sent [PAP AuthReq id=0x6
    user="dxmm@albury.net.au" password=]
    Feb 21 17:57:13 www pppd[6314]: sent [PAP AuthReq id=0x7
    user="dxmm@albury.net.au" password=]
    Feb 21 17:57:16 www pppd[6314]: sent [PAP AuthReq id=0x8
    user="dxmm@albury.net.au" password=]
    Feb 21 17:57:19 www pppd[6314]: sent [PAP AuthReq id=0x9
    user="dxmm@albury.net.au" password=]
    Feb 21 17:57:22 www pppd[6314]: sent [PAP AuthReq id=0xa
    user="dxmm@albury.net.au" password=]
    Feb 21 17:57:25 www pppd[6314]: sent [PAP AuthReq id=0xb
    user="dxmm@albury.net.au" password=]
    Feb 21 17:57:28 www pppd[6314]: No response to PAP authenticate-requests
    Feb 21 17:57:28 www pppd[6314]: sent [LCP TermReq id=0x5 "Failed to
    authenticate ourselves to peer"]
    Feb 21 17:57:31 www pppd[6314]: sent [LCP TermReq id=0x6 "Failed to
    authenticate ourselves to peer"]
    Feb 21 17:57:31 www pppd[6314]: Hangup (SIGHUP)
    Feb 21 17:57:31 www pppd[6314]: Modem hangup
    Feb 21 17:57:31 www pppd[6314]: Connection terminated.
    Feb 21 17:57:31 www pppd[6314]: Exit.

    --
    Posted via a free Usenet account from http://www.teranews.com


  8. Re: Using PPP to dial-in to ISP

    Moe Trin wrote:
    > On Wed, 20 Feb 2008, in the Usenet newsgroup alt.os.linux.mandriva, in article
    > , David W. Hodgins wrote:
    >




    >
    >> Either leave them out, or, if they are not currently in the options
    >> file, set them both to 1524, as in ...

    >
    > Why? The defaults of 1500 are adequate, and need only be changed on
    > "slow" links (meaning <33.8k in interactive (remote server echoing back
    > your keystrokes - telnet most commonly), or when using the PPPover$FOO
    > protocols (PPPoE or PPPoA) because the "over$FOO" adds some bits making
    > the packets oversized for normal links.
    >
    > Old guy


    In trying to get this thing working, Moe, I put in a complaint to the
    local Telco (last Oct-Nov), so their tech had me do some line testing
    with them (whilst they were about 2000 miles away) and then had me limit
    Win98 DUN to 19K (thats all they guarantee).

    Prior to having to change the 'phone number that I dialed into, Kppp was
    set at 115k, and things worked well enough, but now........arghhhhhhh!

    Daniel

    --
    Posted via a free Usenet account from http://www.teranews.com


  9. Re: Using PPP to dial-in to ISP

    Moe Trin wrote:
    > On Wed, 20 Feb 2008, in the Usenet newsgroup alt.os.linux.mandriva, in article
    > <47bbcbfd$0$25994$88260bb3@free.teranews.com>, Daniel wrote:
    >
    >> Late last year, my ISP had to change from a local call number to a
    >> national call number. Since changing, I have not been able to get
    >> KPPP to establish a connection.

    >
    > OK, this is a continuation of a thread from mid-November in this
    > group ("Cannot connect via kppp"), and as I recall the ISP was saying
    > that they saw your attempts, but... yeah, they saw your authentication
    > token and approved it, but you never saw any indications.
    >


    For an "Old Guy", you've got a good memory!

    >> With MD2007, KPPP dials in, PPP starts but then the connection is
    >> refused and I get a PPP Logfile like this:-

    >
    >> Feb 20 17:03:45 www pppd[6447]: sent [LCP ConfReq id=0x1
    >> ]
    >> Feb 20 17:03:46 www pppd[6447]: rcvd [LCP ConfReq id=0xe >> 0xa0000>
    >> ]

    >
    > Add option 'asyncmap 0xa0000' to cope with a misconfigured terminal
    > server (0xa0000 is "software flow control" a.k.a XON/XOFF). The idea
    > is that there are some horribly b0rken ppp server implementations out
    > there, SOME OF WHICH don't operate correctly if the 'asyncmap' isn't
    > the same in both directions. A rule of thumb is that if the peer is
    > proposing an asyncmap, you should match it. (asyncmap tells which of
    > the 32 "control" characters should be escaped. The default is none, but
    > some implementations (generally from such sterling followers of standards
    > as microsoft) assume that either side proposing an asyncmap expects it to
    > be symmetrical - I want to to escape this/that and I will do so without
    > further ado.) This can cause "misinterpretation" of the bit stream.
    >
    > Starting from the top:
    >
    >> Feb 20 17:03:45 www pppd[6447]: sent [LCP ConfReq id=0x1
    >> ]

    >
    > Vanilla request EXCEPT you are asking for asyncmap 0x0 which is the
    > default.
    >
    >> Feb 20 17:03:46 www pppd[6447]: rcvd [LCP ConfReq id=0xe >> 0xa0000>
    >> ]

    >
    > Peer wants 'asyncmap 0xa0000' PAP, magic (to identify loopback conditions)
    > ppp protocol field compression, Address/Control compression, and multi-
    > link.
    >
    >> Feb 20 17:03:46 www pppd[6447]: sent [LCP ConfRej id=0xe ]

    >
    > You reject the idea of multi-link (which is fine). You might try
    > adding 'noendpoint' but I'm not sure it's important.
    >
    >> Feb 20 17:03:46 www pppd[6447]: rcvd [LCP ConfAck id=0x1
    >> ]

    >
    > The peer acks your options
    >
    >> Feb 20 17:03:46 www pppd[6447]: rcvd [LCP ConfReq id=0xf >> 0xa0000> >> [local:63.68.61.70]>]
    >> Feb 20 17:03:46 www pppd[6447]: sent [LCP ConfAck id=0xf >> 0xa0000> >> [local:63.68.61.70]>]

    >
    > The peer comes back and tries again without the MRRU option - you
    > approve it.
    >
    >> Feb 20 17:03:46 www pppd[6447]: sent [PAP AuthReq id=0x1
    >> user="dxmm@albury.net.au" password=]

    >
    > You try to send an authentication packet - expected.
    >
    >> Feb 20 17:03:46 www pppd[6447]: rcvd [LCP ConfReq id=0xe7
    >> ]

    >
    > And this is unexpected. The peer has again proposed options, as if it
    > has not heard the acceptance above.
    >
    >> Feb 20 17:03:46 www pppd[6447]: sent [LCP ConfReq id=0x2
    >> ]

    >
    > And you restart as well - assuming that the peer didn't hear your earlier
    > agreement.
    >
    >> Feb 20 17:03:46 www pppd[6447]: sent [LCP ConfAck id=0xe7
    >> ]

    >
    > You ack this new proposal,
    >
    >> Feb 20 17:03:46 www pppd[6447]: rcvd [LCP ConfRej id=0x2
    >> ]

    >
    > And the peer comes back and says it doesn't want these options.
    >
    >> Feb 20 17:03:46 www pppd[6447]: sent [LCP ConfReq id=0x3 ]
    >> Feb 20 17:03:46 www pppd[6447]: rcvd [LCP ConfAck id=0x3 ]

    >
    > You comply, and the peer agrees with your new try, and that's the last we
    > hear from the peer.
    >
    >> Seems to me, I sending my user name and password heaps of times, but,
    >> for some reason, the ISP's server doesn't want to let me in.

    >
    > APPARENTLY because it can no longer decode the bit stream. Try two
    > new options
    >
    > asyncmap 0xa0000 (This is the important one)
    > noendpoint (this is less important)
    >
    > Old guy


    Moe, in the PPP logfile listing "asyncmap 0xa0000" is received and then
    sent at Feb 20 17:03:46, so, it seems, my computer and the ISP server
    come to that arrangement, so do I need to declare it??

    I think we might have tried it last time, and it didn't get things going!

    As I've got to add the "noendpoint", I guess I can add the asyncmap anyway.

    Thanks for you efforts.

    Daniel

    --
    Posted via a free Usenet account from http://www.teranews.com


  10. Re: Using PPP to dial-in to ISP

    Moe Trin wrote:
    > On Wed, 20 Feb 2008, in the Usenet newsgroup alt.os.linux.mandriva, in article
    > <47bbcbfd$0$25994$88260bb3@free.teranews.com>, Daniel wrote:
    >
    >
    > One other thought - perhaps a better option to try is
    >
    > receive-all
    > With this option, pppd will accept all control characters
    > from the peer, including those marked in the receive
    > asyncmap. Without this option, pppd will discard those
    > characters as specified in RFC1662. This option should
    > only be needed if the peer is buggy.
    >
    > and see if that allows negotiations to continue. Depending how your
    > pppd and kernel were compiled, there _MIGHT_ be some information in
    > the otherwise very useless "kdebug" output - specifically the
    > indication of frames being dropped. "kdebug 7" would show this, but
    > is very wasteful of log space (and assumes kernel:debug output is
    > directed to an appropriate file by /etc/syslog.conf). "kdebug" is
    > NORMALLY a useless option, and is rarely suggested.
    >
    > Also, the option "nomp" or "nomultilink" could be used to disable the
    > MRRU negitiations if that were to be a problem - it should not be.
    >
    > Old guy


    Where would I add these three, Moe? are they Customise PPD Arguments or
    do they go in syslog.conf?

    pppd and Kernel are stock standard MD2007.0

    Daniel

    --
    Posted via a free Usenet account from http://www.teranews.com


  11. Re: Using PPP to dial-in to ISP

    On Thu, 21 Feb 2008 02:24:09 -0500, Daniel wrote:

    > O.K. Here we go.


    Beyond my knowledge. Stick with Moe Trin's advice. My advice was based
    on problems I had with my isp, which would accept bsd, or the ms compression
    protocol, but one of their servers would constantly drop packets, if bsd
    was in use, and of course pppd doesn't support the ms compression protocol.

    As Moe Trin pointed out, your session is failing before it even gets to
    the point of negotiating compression.

    Regard, Dave Hodgins

    --
    Change nomail.afraid.org to ody.ca to reply by email.
    (nomail.afraid.org has been set up specifically for
    use in usenet. Feel free to use it yourself.)

  12. Re: Using PPP to dial-in to ISP

    On Thu, 21 Feb 2008, in the Usenet newsgroup alt.os.linux.mandriva, in article
    <47bd2130$0$25980$88260bb3@free.teranews.com>, Daniel wrote:

    >Moe Trin wrote:


    >> OK, this is a continuation of a thread from mid-November in this
    >> group ("Cannot connect via kppp"), and as I recall the ISP was saying
    >> that they saw your attempts, but... yeah, they saw your authentication
    >> token and approved it, but you never saw any indications.

    >
    >For an "Old Guy", you've got a good memory!


    There aren't that many ppp related posts any more, and the domain name
    you are using sounds familiar. Oh, and my news spool had the thread
    still available ;-)

    >Moe, in the PPP logfile listing "asyncmap 0xa0000" is received and then
    >sent at Feb 20 17:03:46, so, it seems, my computer and the ISP server
    >come to that arrangement, so do I need to declare it??


    Negotiations for stuff like this are "independent" of direction. The
    man page says:

    asyncmap map
    This option sets the Async-Control-Character-Map (ACCM)
    for this end of the link. The ACCM is a set of 32 bits,
    one for each of the ASCII control characters with values
    from 0 to 31, where a 1 bit indicates that the correspond-
    ing control character should not be used in PPP packets
    sent to this system.

    so we're setting up the fact that you won't send the characters that are
    XON and XOFF (0x11 and 0x13) without escaping them. This says nothing
    about the peer sending the character to you. Therein may lie the
    problem.

    >I think we might have tried it last time, and it didn't get things going!


    It was mentioned in the thread in November, but I don't see you
    reporting back one way or the other.

    Old guy

  13. Re: Using PPP to dial-in to ISP

    On Thu, 21 Feb 2008, in the Usenet newsgroup alt.os.linux.mandriva, in article
    <47bd1ddb$0$26580$88260bb3@free.teranews.com>, Daniel wrote:

    >Moe Trin wrote:


    >> Why? The defaults of 1500 are adequate, and need only be changed
    >> on "slow" links (meaning <33.8k in interactive (remote server
    >> echoing back your keystrokes - telnet most commonly), or when using
    >> the PPPover$FOO protocols (PPPoE or PPPoA) because the "over$FOO"
    >> adds some bits making the packets oversized for normal links.


    >In trying to get this thing working, Moe, I put in a complaint to the
    >local Telco (last Oct-Nov), so their tech had me do some line testing
    >with them (whilst they were about 2000 miles away) and then had me
    >limit Win98 DUN to 19K (thats all they guarantee).


    Pity the tech has no clue what they are doing. There are two speeds
    involved. The first which everyone hears about is the "modem" speed
    that is negotiated. This relates to how fast the bits are moving over
    the actual telephone wire. A "normal" voice telephone conversation
    traditionally operates over the frequency range 300 to 3000 Hertz
    (certainly not "Hi-Fi", but quite adequate to transmit the human
    voice). You are only getting a "voice grade" telephone circuit
    (unless you are paying a LOT more). Long ago, modem manufacturers
    discovered certain "tricks" they could use to pack in a lot more bits.
    Your bog-standard V90 or V92 modem (56k) is using a series of tones
    and variations in volume so that each bit of sound on the wire (a Baud)
    may carry as 16 bits of information (based on 4 phase shifts and four
    volume levels), while remaining within the limits of the voice grade
    circuit.

    There is a second speed, which is the "serial port" speed, or how
    fast your computer talks to your modem. This is likely the speed you
    see applications dinking with, as the "command" to set the rate is
    pretty standardized, while the modem command used to set the over-the-
    wire speed _limits_ varies all over the lot (even Hayes didn't follow
    the Hayes command standards - you expect others to do so???). Further,
    there are a LOT of modem speeds (15 speeds between 33.6 and 57.3), and
    these speeds are negotiated between the modems ALONE (subject to a
    manufacturer specific limits - USR AT&N30 says max speed 56k, while
    AT&U17 says min speed 33.3k, but there are also S-registers to set the
    mode, such as V.21, V.22, V.32, V.32bis, V.34 which also set min/max
    speeds, whereas the Rockwell based modems I have only have the mode
    selections). The _serial_ port speeds are fewer - 300, 600, 1200, 1800,
    2000, 2400, 3600, 4800, 7200, 9600, 19200, 38400, 57600, 115200, 230400
    and 460800 though the last two require special hardware. If your
    computer's serial port is using a 16550A or later UART (you'd see this
    in the boot messages), and your modem was built after roughly 1992
    (which is to say a 28.8k or faster), then 115200 is the recommended
    speed. Setting the serial port speed has no real effect on how
    the modems negotiate the over-the-wire speed. You would want the
    speed to be adequate (1:1 for an uncompressed connection, 4:1 if the
    modems negotiate V.42 data compression) so the serial port isn't
    always telling the modem to stop sending bits until it can catch up,
    but this tends to show up as a data transfer rate limitation, rather
    than the inability of making the connection in the first place.

    Old guy

  14. Re: Using PPP to dial-in to ISP

    On Thu, 21 Feb 2008, in the Usenet newsgroup alt.os.linux.mandriva, in article
    <47bd223f$0$25980$88260bb3@free.teranews.com>, Daniel wrote:

    >Moe Trin wrote:


    >> One other thought - perhaps a better option to try is
    >>
    >> receive-all


    >Where would I add these three, Moe? are they Customise PPD Arguments or
    >do they go in syslog.conf?


    Recall I don't use KPPP et.al, but these are options to pppd, and you
    would probably put them in the custom arguments section of KPPP.

    The 'kernel:debug' setting in /etc/syslog.conf may already exist. If
    it is needed as mentioned in November

    This log is obtained by having the pppd daemon in the debug mode, and
    having the syslogd (system logging daemon) route this information to
    an appropriate file. This is done by the following lines in
    /etc/syslog.conf

    daemon.=debug;local2.=info /var/log/ppp.debug

    (that is a tab, not a bunch of spaces), and restarting syslogd so that
    it re-reads the configuration file. On my system, this is done by

    killall -HUP syslogd

    but let's try the 'receive-all' option first.

    Old guy

  15. Re: Using PPP to dial-in to ISP

    On Thu, 21 Feb 2008, in the Usenet newsgroup alt.os.linux.mandriva, in article
    <47bd1b95$0$13966$88260bb3@free.teranews.com>, Daniel wrote:

    >The Customised pppd Arguments are:-
    >debug
    >mru 1524
    >mtu 1524


    mtu/mru not needed, but not effecting anything OK

    >/etc/ppp/options is:-
    >dump
    >lock
    >noauth


    noauth shouldn't be needed, but not effecting anything OK

    >usepeerdns
    >noccp
    >nodeflate
    >nobsdcomp


    The last three _probably_ are not useful.

    >and PPP logfile shows:-
    >Feb 21 17:56:57 www pppd[6314]: pppd options in effect:
    >Feb 21 17:56:57 www pppd[6314]: debug^I^I# (from command line)
    >Feb 21 17:56:57 www pppd[6314]: -detach^I^I# (from command line)
    >Feb 21 17:56:57 www pppd[6314]: dump^I^I# (from /etc/ppp/options)
    >Feb 21 17:56:57 www pppd[6314]: noauth^I^I# (from /etc/ppp/options)
    >Feb 21 17:56:57 www pppd[6314]: -chap^I^I# (from command line)


    The -chap is a bogus option from KPPP - it USED to mean "refuse-chap"
    but was renamed in ppp-2.3.0 back in 1997. Apparently the KPPP authors
    missed the word.

    >Feb 21 17:56:57 www pppd[6314]: 38400^I^I# (from command line)


    I'd like to see that back up to 115200 when you get things running.

    Hmmm - an interesting item is that there isn't a 'defaultroute' option
    shown. I'd expect this to be supplied by KPPP, as without it, when you
    connect you will only be able to speak to the peer (unless KPPP is
    futzing with the default route on it's own).

    Anyway, it looks from this output that you could try the 'receive-all'
    option in either the 'Customised pppd Arguments' or '/etc/ppp/options'
    files.

    Old guy

  16. Re: Using PPP to dial-in to ISP

    Moe Trin wrote:
    > On Thu, 21 Feb 2008, in the Usenet newsgroup alt.os.linux.mandriva, in article
    > <47bd1ddb$0$26580$88260bb3@free.teranews.com>, Daniel wrote:
    >
    >> Moe Trin wrote:

    >
    >>> Why? The defaults of 1500 are adequate, and need only be changed
    >>> on "slow" links (meaning <33.8k in interactive (remote server
    >>> echoing back your keystrokes - telnet most commonly), or when using
    >>> the PPPover$FOO protocols (PPPoE or PPPoA) because the "over$FOO"
    >>> adds some bits making the packets oversized for normal links.

    >
    >> In trying to get this thing working, Moe, I put in a complaint to the
    >> local Telco (last Oct-Nov), so their tech had me do some line testing
    >> with them (whilst they were about 2000 miles away) and then had me
    >> limit Win98 DUN to 19K (thats all they guarantee).

    >
    > Pity the tech has no clue what they are doing. There are two speeds
    > involved. The first which everyone hears about is the "modem" speed
    > that is negotiated. This relates to how fast the bits are moving over
    > the actual telephone wire. A "normal" voice telephone conversation
    > traditionally operates over the frequency range 300 to 3000 Hertz
    > (certainly not "Hi-Fi", but quite adequate to transmit the human
    > voice). You are only getting a "voice grade" telephone circuit
    > (unless you are paying a LOT more). Long ago, modem manufacturers
    > discovered certain "tricks" they could use to pack in a lot more bits.
    > Your bog-standard V90 or V92 modem (56k) is using a series of tones
    > and variations in volume so that each bit of sound on the wire (a Baud)
    > may carry as 16 bits of information (based on 4 phase shifts and four
    > volume levels), while remaining within the limits of the voice grade
    > circuit.
    >


    I knew about the phase-shifting but didn't know about the volume
    variations. But as all the (same frequency) volumes would be attenuated
    to the same extent over a line, they would still arrive at the other end
    in the same proportions, I suppose.

    > There is a second speed, which is the "serial port" speed, or how
    > fast your computer talks to your modem. This is likely the speed you
    > see applications dinking with, as the "command" to set the rate is
    > pretty standardized, while the modem command used to set the over-the-
    > wire speed _limits_ varies all over the lot (even Hayes didn't follow
    > the Hayes command standards - you expect others to do so???). Further,
    > there are a LOT of modem speeds (15 speeds between 33.6 and 57.3), and
    > these speeds are negotiated between the modems ALONE (subject to a
    > manufacturer specific limits - USR AT&N30 says max speed 56k, while
    > AT&U17 says min speed 33.3k, but there are also S-registers to set the
    > mode, such as V.21, V.22, V.32, V.32bis, V.34 which also set min/max
    > speeds, whereas the Rockwell based modems I have only have the mode
    > selections). The _serial_ port speeds are fewer - 300, 600, 1200, 1800,
    > 2000, 2400, 3600, 4800, 7200, 9600, 19200, 38400, 57600, 115200, 230400
    > and 460800 though the last two require special hardware. If your
    > computer's serial port is using a 16550A or later UART (you'd see this
    > in the boot messages), and your modem was built after roughly 1992
    > (which is to say a 28.8k or faster), then 115200 is the recommended
    > speed. Setting the serial port speed has no real effect on how
    > the modems negotiate the over-the-wire speed. You would want the
    > speed to be adequate (1:1 for an uncompressed connection, 4:1 if the
    > modems negotiate V.42 data compression) so the serial port isn't
    > always telling the modem to stop sending bits until it can catch up,
    > but this tends to show up as a data transfer rate limitation, rather
    > than the inability of making the connection in the first place.
    >
    > Old guy


    Yes, the Telco tech gave me a script to set on DUN to limit it to 33k, I
    think), so if the computer is only sending at 33k, that, in effect, will
    limit the modem to speed as well, unless the modems started sending in
    bursts.

    Daniel

    --
    Posted via a free Usenet account from http://www.teranews.com


  17. Re: Using PPP to dial-in to ISP

    David W. Hodgins wrote:
    > On Thu, 21 Feb 2008 02:24:09 -0500, Daniel wrote:
    >
    >> O.K. Here we go.

    >
    > Beyond my knowledge. Stick with Moe Trin's advice. My advice was based
    > on problems I had with my isp, which would accept bsd, or the ms compression
    > protocol, but one of their servers would constantly drop packets, if bsd
    > was in use, and of course pppd doesn't support the ms compression protocol.
    >
    > As Moe Trin pointed out, your session is failing before it even gets to
    > the point of negotiating compression.
    >
    > Regard, Dave Hodgins
    >


    Thanks for trying.

    Daniel

    --
    Posted via a free Usenet account from http://www.teranews.com


  18. Re: Using PPP to dial-in to ISP

    Moe Trin wrote:
    > On Thu, 21 Feb 2008, in the Usenet newsgroup alt.os.linux.mandriva, in article
    > <47bd2130$0$25980$88260bb3@free.teranews.com>, Daniel wrote:
    >
    >> Moe Trin wrote:

    >
    >>> OK, this is a continuation of a thread from mid-November in this
    >>> group ("Cannot connect via kppp"), and as I recall the ISP was saying
    >>> that they saw your attempts, but... yeah, they saw your authentication
    >>> token and approved it, but you never saw any indications.

    >> For an "Old Guy", you've got a good memory!

    >
    > There aren't that many ppp related posts any more, and the domain name
    > you are using sounds familiar. Oh, and my news spool had the thread
    > still available ;-)
    >
    >> Moe, in the PPP logfile listing "asyncmap 0xa0000" is received and then
    >> sent at Feb 20 17:03:46, so, it seems, my computer and the ISP server
    >> come to that arrangement, so do I need to declare it??

    >
    > Negotiations for stuff like this are "independent" of direction. The
    > man page says:
    >
    > asyncmap map
    > This option sets the Async-Control-Character-Map (ACCM)
    > for this end of the link. The ACCM is a set of 32 bits,
    > one for each of the ASCII control characters with values
    > from 0 to 31, where a 1 bit indicates that the correspond-
    > ing control character should not be used in PPP packets
    > sent to this system.
    >
    > so we're setting up the fact that you won't send the characters that are
    > XON and XOFF (0x11 and 0x13) without escaping them. This says nothing
    > about the peer sending the character to you. Therein may lie the
    > problem.
    >
    >> I think we might have tried it last time, and it didn't get things going!

    >
    > It was mentioned in the thread in November, but I don't see you
    > reporting back one way or the other.
    >
    > Old guy


    Three cheers for "Old Guy"! Hip-Hip---- sort of!!

    The Kppp is, apparently, getting me onto my ISP's server, now! Didn't
    know if it was the "asyncmap", the "noendpoint" or the late entry
    "receive-all".

    However...... I am, apparently, connecting to the ISP, but neither my
    SeaMonkey nor Konqueror can actually get out into the web! I think this
    might stem back from the November actions, where I might have mentioned
    that, as a work-a-round, my ISP set me up with an Ethernet Card working
    through a WebRamp to the modem, so I think need to stop trying to work
    through the Ethernet card and start sending stuff straight to the modem.

    What do I need to do to change this arrangement?? Can you answer here,
    or would you prefer I start a new thread??

    Thanks

    Daniel

    --
    Posted via a free Usenet account from http://www.teranews.com


  19. Re: Using PPP to dial-in to ISP

    On Fri, 22 Feb 2008, in the Usenet newsgroup alt.os.linux.mandriva, in article
    <47bdf652$0$25977$88260bb3@free.teranews.com>, Daniel wrote:

    >Moe Trin wrote:


    >> Your bog-standard V90 or V92 modem (56k) is using a series of tones
    >> and variations in volume so that each bit of sound on the wire (a Baud)
    >> may carry as 16 bits of information (based on 4 phase shifts and four
    >> volume levels), while remaining within the limits of the voice grade
    >> circuit.

    >
    >I knew about the phase-shifting but didn't know about the volume
    >variations. But as all the (same frequency) volumes would be attenuated
    >to the same extent over a line, they would still arrive at the other end
    >in the same proportions, I suppose.


    "trellis modulation" The four amplitudes are far enough apart as to
    avoid confusion, and if the modems negotiated error correction (V.42)
    is nearly transparent. Yes, there is frequency dependent attenuation,
    but the difference is relatively small, and it rarely changes quickly
    enough to be a factor.

    >Yes, the Telco tech gave me a script to set on DUN to limit it to 33k,
    >I think), so if the computer is only sending at 33k, that, in effect,
    >will limit the modem to speed as well, unless the modems started sending
    >in bursts.


    The most common way to do that today is to disable V.90 and/or V.92
    modulation, and let the modems negotiate a V.34bis connection. Actually,
    V.34 and V.34bis are slightly more picky about line quality than
    either V.90 or V.92. The difference a few years of technology makes.

    The modem verses port speed question may show up as "slower" data
    transfers, but that's about it. If the modems negotiate a (example)
    V.90 connection at 56k down, 33.6k up, they will pump the bits out at
    that rate. The computer attached to the modem then has the problem of
    loading/unloading the modem. Were you to actually put an oscilloscope
    on the line and look at what's going on, your clue that the port speed
    is "mismatched" is likely to be "jerky" or spurts of data. The minimum
    packet over a ppp link is typically 48 octets (maximum somewhere around
    1550), but the 16550A UART is only 8 bytes deep, so the computer has to
    be talking to that modem on a regular basis to try to keep up. The
    minor thing to remember is that the telephone link is asynchronous,
    and it sends a byte at a time (at the 33.6k or 56k or what-ever) rate,
    but the overall rate will be lower if the UART isn't being filled or
    emptied at a timely rate, because _between_ bytes, it's sending the
    "stop bit" signal (logical high) until the next byte is ready to go.

    Old guy

  20. Re: Using PPP to dial-in to ISP

    On Fri, 22 Feb 2008, in the Usenet newsgroup alt.os.linux.mandriva, in article
    <47bdf990$0$26072$88260bb3@free.teranews.com>, Daniel wrote:

    >Three cheers for "Old Guy"! Hip-Hip---- sort of!!


    Hey, it's a start ;-)

    >The Kppp is, apparently, getting me onto my ISP's server, now! Didn't
    >know if it was the "asyncmap", the "noendpoint" or the late entry
    >"receive-all".


    Probably the later, but no matter.

    >However...... I am, apparently, connecting to the ISP, but neither my

    SeaMonkey nor Konqueror can actually get out into the web!

    Find a command prompt, and run the commands '/sbin/ifconfig -a' and
    '/sbin/route -n' before, during and after dialing in. Before, you
    should see any local network stuff, PERHAPS sometime like

    [van-allen ~]$ /sbin/ifconfig -a
    eth0 Link encap:Ethernet HWaddr 00:60:97:32:4A:6A
    inet addr:192.0.2.11 Bcast:192.0.2.255 Mask:255.255.255.0
    UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:6 errors:0 dropped:0 overruns:0 frame:0
    TX packets:45 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:989 (989.0 b) TX bytes:5154 (5.0 Kb)
    Interrupt:5 Base address:0x220

    lo Link encap:Local Loopback
    inet addr:127.0.0.1 Mask:255.0.0.0
    UP LOOPBACK RUNNING MTU:16436 Metric:1
    RX packets:202 errors:0 dropped:0 overruns:0 frame:0
    TX packets:202 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:12691 (12.3 Kb) TX bytes:12691 (12.3 Kb)
    [van-allen ~]$ /sbin/route -n
    Kernel IP routing table
    Destination Gateway Genmask Flags Metric Ref Use Iface
    192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 4198 eth0
    127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 20 lo
    [van-allen ~]$

    This should be similar after you hang up. DURING THE CALL, there should
    be a ppp0 list, which might look like

    ppp0 Link encap:Point-to-Point Protocol
    inet addr:198.18.180.190 P-t-P:192.168.195.11 Mask:255.0.0.0
    UP POINTOPOINT RUNNING MTU:1500 Metric:1
    RX packets:5973 errors:0 dropped:0 overruns:0 frame:0
    TX packets:4251 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0
    Memory:964038-964c04

    and this should add _TWO_ lines to the routing table:

    [van-allen ~]$ /sbin/route -n
    Kernel IP routing table
    Destination Gateway Genmask Flags Metric Ref Use Iface
    192.168.195.11 0.0.0.0 255.255.255.255 UH 0 0 1 ppp0
    192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 4198 eth0
    127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 20 lo
    0.0.0.0 192.168.195.11 0.0.0.0 UG 0 0 5 ppp0
    [van-allen ~]$

    The top line says there is a route to the peer at the other end of the
    telephone line. The bottom line says that packets OTHER THAN those
    destined for 192.168.1.0/24 and 127.0.0.0/8 should be sent to the
    peer (here, 192.168.195.11) and that peer will forward the packets to
    the appropriate destination. Based on your Thu, 21 Feb 2008 18:24:09
    +1100 posting (Message-ID: <47bd1b95$0$13966$88260bb3@free.teranews.com>),
    you may be missing a switch in the kppp setup to use this link as the
    default. The pppd option 'defaultroute' is what controls pppd here.

    >I think this might stem back from the November actions, where I might
    >have mentioned that, as a work-a-round, my ISP set me up with an Ethernet
    >Card working through a WebRamp to the modem, so I think need to stop trying
    >to work through the Ethernet card and start sending stuff straight to the
    >modem.


    What else is on the Ethernet link?

    >What do I need to do to change this arrangement?? Can you answer here,
    >or would you prefer I start a new thread??


    This should do it. One last check is to see that WHILE DIALED IN, there
    are appropriate nameservers listed in /etc/resolv.conf.

    Old guy

+ Reply to Thread
Page 1 of 2 1 2 LastLast