When I look a statistics on a windows dial-up client I see that only windows side is compressing the transmitted data. The compression ratio is ~25% on transmission and 0% on reception. Does this mean that TCP/IP v5.0 pppd v2.3.5 does not feature “software compression”?
If it indeed features it - how to turn it on?
Tony.
There is no soft compression supported, so no way to “turn it on”.
-xtang
Tony <mts.spb.suxx@mail.ru> wrote in message news:opscgvkrvko93ri4@mobile…
When I look a statistics on a windows dial-up client I see that only
windows side is compressing the transmitted data. The compression ratio is
~25% on transmission and 0% on reception. Does this mean that TCP/IP v5.0
pppd v2.3.5 does not feature “software compression”?
If it indeed features it - how to turn it on?
Tony.
Hello, Xiaodan!
It’s me, AnthonyOZ.
Thank you, now I’m able to authenticate callers with pppd v2.3.5! The reason was - as you supposed - the allowed remote IPs are not optional any more but mandatory in the /etc/ppp/pap-secrets. I wish the docs and diagnostics were more precise.
On Mon, 9 Aug 2004 13:11:48 -0400, Xiaodan Tang <xtang@qnx.com> wrote:
There is no soft compression supported, so no way to “turn it on”.
Are there any plans to implement it?
Tony.
On Mon, 9 Aug 2004 13:11:48 -0400, Xiaodan Tang <xtang@qnx.com> wrote:
There is no soft compression supported, so no way to “turn it on”.
Does this mean that in win->qnx4 direction there is no compression too? Or pppd v2.3.5 does support un-compression only and this why I do see some %'s from windows side?
Tony.
I don’t think it will compress from win->qnx4 direction. Compression or not,
is negotiated
at the beginning, and the QNX4 pppd will refuse such thing.
If you start pppd with debug, and watch the syslogd output, you should be
able
to see QNX4 pppd reject remote options.
-xtang
Tony <mts.spb.suxx@mail.ru> wrote in message news:opscg9nupko93ri4@mobile…
On Mon, 9 Aug 2004 13:11:48 -0400, Xiaodan Tang <> xtang@qnx.com> > wrote:
There is no soft compression supported, so no way to “turn it on”.
Does this mean that in win->qnx4 direction there is no compression too? Or
pppd v2.3.5 does support un-compression only and this why I do see some %'s
from windows side?
Tony.
On Tue, 10 Aug 2004 13:23:49 -0400, Xiaodan Tang <xtang@qnx.com> wrote:
I don’t think it will compress from win->qnx4 direction. Compression or not,
is negotiated at the beginning, and the QNX4 pppd will refuse such thing.If you start pppd with debug, and watch the syslogd output, you should be
able to see QNX4 pppd reject remote options.
Below is a start of a connection…
Please explain what was negotiated at “Aug 13 15:11:33”. Seems, pppd has agreed on receiving a compressed data. Or, it was just a headers compression?
As I sayd before - windows box reports some degree of win->qnx flow compressed.
Aug 13 15:11:30 localhost pppd[646]: Could not set session: Operation not permitted
Aug 13 15:11:30 localhost pppd[646]: pppd 2.3.5 started by System, uid 0
Aug 13 15:11:30 localhost pppd[646]: Using interface vp0
Aug 13 15:11:30 localhost pppd[646]: Connect: vp0 <–> //3/dev/ser2
Aug 13 15:11:30 localhost pppd[646]: sent [LCP ConfReq id=0x1 <magic 0x1f4e7ccd> ]
Aug 13 15:11:31 localhost pppd[646]: rcvd [LCP ConfAck id=0x1 <magic 0x1f4e7ccd> ]
Aug 13 15:11:32 localhost pppd[646]: rcvd [LCP ConfReq id=0x2 <asyncmap 0x0> <magic 0x57f91ee5> <callback 0x600>]
Aug 13 15:11:32 localhost pppd[646]: sent [LCP ConfRej id=0x2 <callback 0x623>]
Aug 13 15:11:33 localhost pppd[646]: rcvd [LCP ConfReq id=0x3 <asyncmap 0x0> <magic 0x57f91ee5> ]
Aug 13 15:11:33 localhost pppd[646]: sent [LCP ConfAck id=0x3 <asyncmap 0x0> <magic 0x57f91ee5> ]
Aug 13 15:11:33 localhost pppd[646]: rcvd [LCP code=0xc id=0x4 57 f9 1e e5 4d 53 52 41 53 56 35 2e 31 30]
Aug 13 15:11:33 localhost pppd[646]: sent [LCP CodeRej id=0x2 0c 04 00 12 57 f9 1e e5 4d 53 52 41 53 56 35 2e 31 30]
Aug 13 15:11:33 localhost pppd[646]: rcvd [LCP code=0xc id=0x5 57 f9 1e e5 4d 53 52 41 53 2d 31 2d 45 44 49 54 4f 52 49 41 4c]
Aug 13 15:11:33 localhost pppd[646]: sent [LCP CodeRej id=0x3 0c 05 00 19 57 f9 1e e5 4d 53 52 41 53 2d 31 2d 45 44 49 54 4f 52 49 41 4c]
Aug 13 15:11:33 localhost pppd[646]: rcvd [PAP AuthReq id=0x45 user=“ftp” password=“IYEiKzci”]
Aug 13 15:11:33 localhost pppd[646]: sent [PAP AuthAck id=0x45 “Login ok”]
Aug 13 15:11:33 localhost pppd[646]: sent [IPCP ConfReq id=0x1 <addr 192.168.40.40> <compress VJ 0f 01>]
Aug 13 15:11:33 localhost pppd[646]: rcvd [proto=0x80fd] 01 06 00 0a 12 06 00 00 00 01
Aug 13 15:11:33 localhost pppd[646]: Unsupported protocol (0x80fd) received
Aug 13 15:11:33 localhost pppd[646]: sent [LCP ProtRej id=0x4 80 fd 01 06 00 0a 12 06 00 00 00 01]
Aug 13 15:11:33 localhost pppd[646]: rcvd [IPCP ConfReq id=0x7 <compress VJ 0f 01> <addr 0.0.0.0> <ms-dns 0.0.0.0> <ms-wins 0.0.0.0> <ms-dns 0.0.0.0> <ms-wins 0.0.0.0>]
Aug 13 15:11:33 localhost pppd[646]: sent [IPCP ConfRej id=0x7 <ms-dns 0.0.0.0> <ms-wins 0.0.0.0> <ms-dns 0.0.0.0> <ms-wins 0.0.0.0>]
Aug 13 15:11:33 localhost pppd[646]: rcvd [IPCP ConfAck id=0x1 <addr 192.168.40.40> <compress VJ 0f 01>]
Aug 13 15:11:33 localhost pppd[646]: rcvd [IPCP ConfReq id=0x8 <compress VJ 0f 01> <addr 0.0.0.0>]
Aug 13 15:11:33 localhost pppd[646]: sent [IPCP ConfNak id=0x8 <addr 192.168.40.41>]
Aug 13 15:11:33 localhost pppd[646]: rcvd [IPCP ConfReq id=0x9 <compress VJ 0f 01> <addr 192.168.40.41>]
Aug 13 15:11:33 localhost pppd[646]: sent [IPCP ConfAck id=0x9 <compress VJ 0f 01> <addr 192.168.40.41>]
Aug 13 15:11:33 localhost pppd[646]: found interface en1 for proxy arp
Aug 13 15:11:33 localhost pppd[646]: local IP address 192.168.40.40
Aug 13 15:11:33 localhost pppd[646]: remote IP address 192.168.40.41
Tony.