On Tue, 18 Jan 2000, Mithun Bhattacharya wrote:
|I am trying to analyse my connection to our ISP and would appreciate it
|if someone could point out if I have made some mistakes. As you will
|notice the log has been generated by running pppd using the option
|debug.
|
|My current setup:
|ppp version 2.3.10 installed as a rpm downloaded from cs.anu.edu.au
|$>uname -a
|Linux valium 2.3.3 #18 Sat Oct 16 17:43:43 IST 1999 i686 unknown
|(This is SUSE 6.x I believe it is 6.0 but I can't be sure)
|using a 33.6 Hayes modem.
|pppd invoked as
|/usr/sbin/pppd /dev/modem mtu 4096 mru 296 115200 noipdefault netmask
|255.255.0.0 persist asyncmap 20A0000 defaultroute user xxxxx debug
|connect /etc/ppp/scripts/dialer
That's a large mtu, the PPP RFC only requires that a PPP implementation be
able to receive 1500 and mtu is not a negotiated LCP option. I'd use mtu
576 and mru 576, which are likely to cause the least trouble. The asyncmap
I'd choose is asyncmap a0000. I'd drop the netmask option, it can be
meaningful but is generally useless.
|-------------------------------------------------------------------------------------------------------------------
|
|Dec 11 09:41:41 valium pppd[1001]: Connect: ppp0 <--> /dev/modem
|Dec 11 09:41:41 valium chat[1002]: CONNECT
|Dec 11 09:41:41 valium chat[1002]: -- got it
|Dec 11 09:41:42 valium pppd[1001]: sent [LCP ConfReq id=0x1 <mru 296>
|<asyncmap 0x20a0000> <magic 0x161cd4df>]
| I am requesting a MRU of 296 and have supplied a asyncmap 0x20a0000
|- frankly speaking I don't know how this affects the ppp link. The
Speaking from personal experience MRUs from 296 to 1500 have never changed
the performance noticeable.
|ISP is a new one so they must be having all the latest and greatest
|Windows has to offer...
;(
|
|Dec 11 09:41:42 valium pppd[1001]: rcvd [LCP ConfReq id=0x1 <asyncmap
|0x0> <auth pap> <magic 0x6286d1cf> <pcomp> <accomp>]
| my ISP says something about the asyncmap (I don't know what!!) and
|requests for pcomp and accomp (protocol field compression and
|Address/Control compression - pretty legitimate request I would say)
The peer request that it send all Control Characters unescaped. This
improves the PPP performance by reducing the overhead of sending these
escaped.
|Dec 11 09:41:42 valium pppd[1001]: sent [LCP ConfRej id=0x1 <pcomp>
|<accomp>]
| Hmm ppp doesn't like pcomp and accomp ???!!!!!!!
No modules?
|Dec 11 09:41:42 valium pppd[1001]: rcvd [LCP ConfReq id=0x2 <asyncmap
|0x0> <auth pap> <magic 0x6286d1cf>]
| ISP asks for PAP authentication.
|
|Dec 11 09:41:42 valium pppd[1001]: sent [LCP ConfAck id=0x2 <asyncmap
|0x0> <auth pap> <magic 0x6286d1cf>]
| pppd acknowledges PAP authentication - what's the magic thing ???
A magic number is used to detect looped back conditions where pppd is
talking to itself.
|Dec 11 09:41:45 valium pppd[1001]: sent [LCP ConfReq id=0x1 <mru 296>
|<asyncmap 0x20a0000> <magic 0x161cd4df>]
| pppd again requests for a mru 296 and the asyncmap
|
|Dec 11 09:41:45 valium pppd[1001]: rcvd [LCP ConfAck id=0x1 <mru 296>
|<asyncmap 0x20a0000> <magic 0x161cd4df>]
| nice ISP accepts the mru :)
|
|Dec 11 09:41:45 valium pppd[1001]: sent [PAP AuthReq id=0x1
|user="xxxxxx" password="xxxxxx"]
| userid and password sent by pppd
|
|Dec 11 09:41:45 valium pppd[1001]: rcvd [PAP AuthAck id=0x1 ""]
| ISP says PAP authentication successful
|
|Dec 11 09:41:45 valium pppd[1001]: sent [IPCP ConfReq id=0x1 <addr
|0.0.0.0>]
| Don't know what this line means
Requesting 0.0.0.0 is the way to ask the peer to provide your IP address
for the PPP link.
|Dec 11 09:41:45 valium kernel: PPP Deflate Compression module registered
|
| This comes in intermittently - what makes the kernel decide to load
|the PPP Deflate module ?? possible because the module was already there
|???
That guess is as good as any I can make.
|Dec 11 09:41:45 valium pppd[1001]: sent [CCP ConfReq id=0x1 <deflate 15>
|<deflate(old#) 15>]
| pppd says it can use deflate 15 (two kinds of compression...)
Only one can be used, the first in the request is usually the preferred
compression.
|Dec 11 09:41:45 valium pppd[1001]: rcvd [IPCP ConfReq id=0x3 <compress
|VJ 0f 01> <addr 202.56.230.44>]
| ISP doesn't say anything about the previous request but it gives
|it's preference for VJ (assuming Van Jacobson style TCP/IP header
|compression per pppd man????) It sends me my IP address
CCP and IPCP (with VJ) are negotiated independently. VJ is not a CCP.
|Dec 11 09:41:45 valium pppd[1001]: sent [IPCP ConfRej id=0x3 <compress
|VJ 0f 01>]
| hmm pppd doesn't like this either and rejects the compression
|mechnism...
No module?
|Dec 11 09:41:45 valium pppd[1001]: rcvd [CCP ConfReq id=0x4 < 12 06 00
|00 00 01> < 11 05 00 01 03> <bsd v1 12> <predictor 1>]
| ISP says ok lets try bsd compression version 1 or 12 ?? Also it is
|game for predictor 1
| predictor 1 is the intersting thing pppd knows about it but it
|doesn't support the compression - why so ?? (as inferred from doing a
|grep on the ppp source code !!!)
Grepping the pppd 2.3.11 source code shows many lines referring to
predictor. Maybe the kernel doesn't support it, as implied in the
pppd man pages.
|Dec 11 09:41:45 valium pppd[1001]: sent [CCP ConfRej id=0x4 < 12 06 00
|00 00 01> < 11 05 00 01 03> <bsd v1 12>]
| pppd says no I don't like bsd compression either.
No module?
|Dec 11 09:41:45 valium pppd[1001]: rcvd [IPCP ConfNak id=0x1 <addr
|202.56.228.200>]
| pppd says I don't like the IP address given earlier
No, the peer says that in response to the 0.0.0.0 request by pppd, and
offers 202.56.228.200 for pppd to use as it's IP address for the PPP link.
|Dec 11 09:41:45 valium pppd[1001]: sent [IPCP ConfReq id=0x2 <addr
|202.56.228.200>]
| pppd says I need acknowledgement for the IP address given earlier ??
|- why would it do so ??
That's RFC standard PPP negotiation.
|Dec 11 09:41:45 valium pppd[1001]: rcvd [CCP ConfRej id=0x1 <deflate 15>
|<deflate(old#) 15>]
| ISP says I don't like the PPP deflate compression which pppd had
|suggested.
|
|Dec 11 09:41:45 valium pppd[1001]: sent [CCP ConfReq id=0x2]
| pppd didn't get to hear about it's request for IP address
|acknowledgement
No, pppd just wants to bring CCP to the open state with no compression
negotiated, a good way to end the CCP negotiations.
|Dec 11 09:41:45 valium pppd[1001]: rcvd [IPCP ConfReq id=0x5 <addr
|202.56.230.44>]
| ISP sends it's dialin server's IP address.
|
|Dec 11 09:41:45 valium pppd[1001]: sent [IPCP ConfAck id=0x5 <addr
|202.56.230.44>]
| pppd acknowledges server's IP address
|
|Dec 11 09:41:45 valium pppd[1001]: rcvd [CCP ConfReq id=0x6 <predictor
|1>]
| ISP requests conformation for predictor 1 type of compression.
|
|Dec 11 09:41:46 valium modprobe: can't locate module ppp-compress-1
| kernel tries to find the predictor 1/ppp-compress-1 module
|
|Dec 11 09:41:46 valium pppd[1001]: sent [CCP ConfRej id=0x6 <predictor
|1>]
| kernel couldn't find the module - so pppd rejects the compression
|
|Dec 11 09:41:46 valium pppd[1001]: rcvd [IPCP ConfAck id=0x2 <addr
|202.56.228.20
|0>]
| ISP acknowledges the localhost's IP address
|
|Dec 11 09:41:46 valium pppd[1001]: local IP address 202.56.228.200
|Dec 11 09:41:46 valium pppd[1001]: remote IP address 202.56.230.44
|Dec 11 09:41:46 valium pppd[1001]: Script /etc/ppp/ip-up started (pid
|1007)
|Dec 11 09:41:46 valium pppd[1001]: rcvd [CCP ConfAck id=0x2]
|Dec 11 09:41:46 valium pppd[1001]: Script /etc/ppp/ip-up finished (pid
|1007), status = 0x0
|Dec 11 09:41:46 valium pppd[1001]: rcvd [CCP ConfReq id=0x7]
|Dec 11 09:41:46 valium pppd[1001]: sent [CCP ConfAck id=0x7]
The peer ACKs the "empty" pppd CCP request and sends one of it's own, which
pppd ACKS. This is the right way to end CCP negotiations when there are
no common CCP algorithms.
|-------------------------------------------------------
|Now to my question is there something we can do about this or am
|I doomed to a compression less connection through Linux. Also
You can have BSD CCP with the bsd_comp module. The predictor CCP, probably
not, but I'm not sure about that. The deflates were rejected by the peer.
Actually you may not need compression if the connection is a regular PPP
connection via Telco lines and a modem. The modem itself provides
the compression, and you can only compress so much.
|I sprinkled a couple of questions throughout the log which I would
|really like to know the answers too - if someone could point me towards
|the right place I would go have a look - ofcourse if someone can explain
|the whole thing in simple words I am sure many would benefit from it :).
Whew! I don't want to do that again soon. :)
|-----------------------------------
|>From PPP-FAQ:
| Another common compressor is called Predictor-1. This will take less
| memory and run faster. However, its compression is not as good in that
| it will send a little more data than the equivalent frame given to the
| BSD compressor
|
|(How do I use it ??)
It appears that the kernel doesn't support the Predictor-1 CCP. BSD CCP is
available using a module.
Now a request for you: Post only in regular text, don't post or duplicate
the message in HTML.
---
Clifford Kite Not a guru. (tm)
-
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to [EMAIL PROTECTED]
