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.)

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

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

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

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

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

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

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

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

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.)

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

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

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

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

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

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

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

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

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