Subject: Re: filter expression for demand-ppp that understands vj-compression?
To: John Kohl <jtk@kolvir.arlington.ma.us>
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
List: current-users
Date: 05/13/1996 00:01:19
>I use PPP with an active-filter for on-demand dialup to my ISP.
>I want it to wake up on any TCP connection that's not smtp, or on
>udp/kerberos.
>
>This filter does most of what I want:
>	active-filter 'udp port kerberos or udp port kerberos4 or (tcp and
>not tcp port smtp)'
>
>but it apparently (from experience) somehow does not wake up for certain
>packets.

That's odd, because I have a much more complicated filter rule, yet I
can just hit return in a telnet or rlogin window and the connection redials
just fine.

I _have_ noticed that there is a small window (5-8 seconds) when pppd
drops the connection where packets to the ppp interface will return
"No route to host".  But after this small timeout everything goes back
to normal.

>I suspect it's related to not recognizing VJ compression packets, but
>I'm not sure.  When I leave the connection idle, it shuts down with this
>(according to tcpdump):
>
>20:20:11.115996 [|ip]

I believe these are LCP or IPCP control packets - I see similar things
like that when I use lcp-echo.

>When I try to type again at the telnet connection, tcpdump sees this:
>20:21:05.230184 204.215.140.63.2785 > 18.71.0.20.23: P 63:65(2) ack 3690 win 16384 
>[tos 0x10]
>
>but pppd doesn't reopen the connection.  If I open another TCP
>connection from scratch, pppd will wake up and reconnect the PPP link.
>
>So, can somebody suggest either (a) a filter expression that does what I
>want here, or (b) what's broken in pppd's filter interpretation?

My only suggestion would be to try the above bpf filter rule with tcpdump
and see if you get the same packets from tcpdump as you do from bpf.  AFAIK,
the code to do the filter stuff for pppd is ripped right from the same
library that tcpdump uses, so theoretically there shouldn't be any
bugs there.

The only other thing I can suggest to try is turning off VJ header
compression (I did this since the remote system I connect to doesn't like
packets with IP options and VJ header compression).  I abuse the active-filter
a whole lot, and it's been pretty bulletproof for me, so feel free to bug
me if you have questions.

--Ken