Kppp, peer not responding (Suse9.2)

Hello All,

I've been searching a solution for a week, and now I give up.
I can dial-up my isp, get logged on the network, but connection will
drop at the 2 min timeout with error 15, "Peer not responding".

This is the relevant part of the logfile:
Jan 3 10:17:15 linux pppd[14698]: PAP authentication succeeded
Jan 3 10:17:15 linux pppd[14698]: sent [CCP ConfReq id=0x1 <deflate
15> <deflate(old#) 15> <bsd v1 15>]
Jan 3 10:17:15 linux pppd[14698]: sent [IPCP ConfReq id=0x1 <compress
VJ 0f 01> <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Jan 3 10:17:16 linux pppd[14698]: rcvd [IPCP ConfReq id=0x1 <addr
10.200.253.166>]
Jan 3 10:17:16 linux pppd[14698]: sent [IPCP ConfAck id=0x1 <addr
10.200.253.166>]
Jan 3 10:17:16 linux pppd[14698]: rcvd [IPCP ConfRej id=0x1 <compress
VJ 0f 01>]
Jan 3 10:17:16 linux pppd[14698]: sent [IPCP ConfReq id=0x2 <addr
0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Jan 3 10:17:18 linux pppd[14698]: sent [CCP ConfReq id=0x1 <deflate
15> <deflate(old#) 15> <bsd v1 15>]
Jan 3 10:17:18 linux pppd[14698]: rcvd [LCP ProtRej id=0x3 80 fd 01 01
00 0f 1a 04 78 00 18 04 78 00 15 03 2f]
Jan 3 10:17:19 linux pppd[14698]: sent [IPCP ConfReq id=0x2 <addr
0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Jan 3 10:17:19 linux pppd[14698]: rcvd [IPCP ConfNak id=0x2 <addr
10.200.253.167> <ms-dns1 194.185.97.134> <ms-dns3 194.185.97.134>]
Jan 3 10:17:19 linux pppd[14698]: sent [IPCP ConfReq id=0x3 <addr
10.200.253.167> <ms-dns1 194.185.97.134> <ms-dns3 194.185.97.134>]
Jan 3 10:17:22 linux pppd[14698]: sent [IPCP ConfReq id=0x3 <addr
10.200.253.167> <ms-dns1 194.185.97.134> <ms-dns3 194.185.97.134>]
Jan 3 10:17:22 linux pppd[14698]: rcvd [IPCP ConfAck id=0x3 <addr
10.200.253.167> <ms-dns1 194.185.97.134> <ms-dns3 194.185.97.134>]
Jan 3 10:17:22 linux pppd[14698]: not replacing default route to eth0
[192.168.1.254]
Jan 3 10:17:22 linux pppd[14698]: local IP address 10.200.253.167
Jan 3 10:17:22 linux pppd[14698]: remote IP address 10.200.253.166
Jan 3 10:17:22 linux pppd[14698]: primary DNS address 194.185.97.134
Jan 3 10:17:22 linux pppd[14698]: secondary DNS address 194.185.97.134
Jan 3 10:17:22 linux pppd[14698]: Script /etc/ppp/ip-up started (pid
14724)
Jan 3 10:17:25 linux pppd[14698]: Script /etc/ppp/ip-up finished (pid
14724), status = 0x0
Jan 3 10:17:45 linux pppd[14698]: sent [LCP EchoReq id=0x1 magic=0x0]
Jan 3 10:17:45 linux pppd[14698]: rcvd [LCP CodeRej id=0x4 09 01 00 08
00 00 00 00]
Jan 3 10:17:45 linux pppd[14698]: LCP: Rcvd Code-Reject for code 9, id
1
Jan 3 10:18:15 linux pppd[14698]: sent [LCP EchoReq id=0x2 magic=0x0]
Jan 3 10:18:15 linux pppd[14698]: rcvd [LCP CodeRej id=0x5 09 02 00 08
00 00 00 00]
Jan 3 10:18:15 linux pppd[14698]: LCP: Rcvd Code-Reject for code 9, id
2
Jan 3 10:18:45 linux pppd[14698]: sent [LCP EchoReq id=0x3 magic=0x0]
Jan 3 10:18:45 linux pppd[14698]: rcvd [LCP CodeRej id=0x6 09 03 00 08
00 00 00 00]
Jan 3 10:18:45 linux pppd[14698]: LCP: Rcvd Code-Reject for code 9, id
3
Jan 3 10:19:15 linux pppd[14698]: No response to 4 echo-requests
Jan 3 10:19:15 linux pppd[14698]: Serial link appears to be
disconnected.
Jan 3 10:19:15 linux pppd[14698]: Script /etc/ppp/ip-down started (pid
15103)
Jan 3 10:19:15 linux pppd[14698]: sent [LCP TermReq id=0x3 "Peer not
responding"]
Jan 3 10:19:15 linux pppd[14698]: rcvd [LCP TermAck id=0x3]
Jan 3 10:19:15 linux pppd[14698]: Connection terminated.
Jan 3 10:19:15 linux pppd[14698]: Connect time 2.0 minutes.
Jan 3 10:19:15 linux pppd[14698]: Sent 156 bytes, received 64 bytes.
Jan 3 10:19:15 linux pppd[14698]: Waiting for 1 child processes...
Jan 3 10:19:15 linux pppd[14698]: script /etc/ppp/ip-down, pid 15103
Jan 3 10:19:18 linux pppd[14698]: Script /etc/ppp/ip-down finished
(pid 15103), status = 0x0
Jan 3 10:19:18 linux pppd[14698]: Connect time 2.0 minutes.
Jan 3 10:19:18 linux pppd[14698]: Sent 156 bytes, received 64 bytes.
Jan 3 10:19:18 linux pppd[14698]: Exit.

I get assigned an IP address, and the DNS is also correct.
It could be a routing issue, because I do have a default route. My
notebook is connected to a lan, and use a default gateway for internet
access.
I would like to use Kppp to use my gprs cell phone when I'm on the go,
but I want to save my standard network configuration.

The /etc/ppp/options file reads:
noipdefault
debug
kdebug 1
noauth
crtscts
lock
modem
asyncmap 0
nodetach
lcp-echo-interval 30
lcp-echo-failure 4
lcp-max-configure 60
lcp-restart 2
idle 600
noipx
file /etc/ppp/filters
usepeerdns

This is file:/etc/ppp/peers/kppp
plugin passwordfd.so
noauth
debug
crtscts
/dev/ttyS0
115200
noipdefault
usepeerdns

Is there some blatant error in these files ?
Thanks for your time,
-GianLuca

Gian wrote:
> Hello All,
>
> I've been searching a solution for a week, and now I give up.
> I can dial-up my isp, get logged on the network, but connection will
> drop at the 2 min timeout with error 15, "Peer not responding".
>
> This is the relevant part of the logfile:
> Jan 3 10:17:15 linux pppd[14698]: PAP authentication succeeded
> Jan 3 10:17:15 linux pppd[14698]: sent [CCP ConfReq id=0x1 <deflate
> 15> <deflate(old#) 15> <bsd v1 15>]
> Jan 3 10:17:15 linux pppd[14698]: sent [IPCP ConfReq id=0x1
<compress
> VJ 0f 01> <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
> Jan 3 10:17:16 linux pppd[14698]: rcvd [IPCP ConfReq id=0x1 <addr
> 10.200.253.166>]
> Jan 3 10:17:16 linux pppd[14698]: sent [IPCP ConfAck id=0x1 <addr
> 10.200.253.166>]
> Jan 3 10:17:16 linux pppd[14698]: rcvd [IPCP ConfRej id=0x1
<compress
> VJ 0f 01>]
> Jan 3 10:17:16 linux pppd[14698]: sent [IPCP ConfReq id=0x2 <addr
> 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
> Jan 3 10:17:18 linux pppd[14698]: sent [CCP ConfReq id=0x1 <deflate
> 15> <deflate(old#) 15> <bsd v1 15>]
> Jan 3 10:17:18 linux pppd[14698]: rcvd [LCP ProtRej id=0x3 80 fd 01
01
> 00 0f 1a 04 78 00 18 04 78 00 15 03 2f]
> Jan 3 10:17:19 linux pppd[14698]: sent [IPCP ConfReq id=0x2 <addr
> 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
> Jan 3 10:17:19 linux pppd[14698]: rcvd [IPCP ConfNak id=0x2 <addr
> 10.200.253.167> <ms-dns1 194.185.97.134> <ms-dns3 194.185.97.134>]
> Jan 3 10:17:19 linux pppd[14698]: sent [IPCP ConfReq id=0x3 <addr
> 10.200.253.167> <ms-dns1 194.185.97.134> <ms-dns3 194.185.97.134>]
> Jan 3 10:17:22 linux pppd[14698]: sent [IPCP ConfReq id=0x3 <addr
> 10.200.253.167> <ms-dns1 194.185.97.134> <ms-dns3 194.185.97.134>]
> Jan 3 10:17:22 linux pppd[14698]: rcvd [IPCP ConfAck id=0x3 <addr
> 10.200.253.167> <ms-dns1 194.185.97.134> <ms-dns3 194.185.97.134>]
> Jan 3 10:17:22 linux pppd[14698]: not replacing default route to
eth0
> [192.168.1.254]
> Jan 3 10:17:22 linux pppd[14698]: local IP address 10.200.253.167
> Jan 3 10:17:22 linux pppd[14698]: remote IP address 10.200.253.166
> Jan 3 10:17:22 linux pppd[14698]: primary DNS address
194.185.97.134
> Jan 3 10:17:22 linux pppd[14698]: secondary DNS address
194.185.97.134
> Jan 3 10:17:22 linux pppd[14698]: Script /etc/ppp/ip-up started (pid
> 14724)
> Jan 3 10:17:25 linux pppd[14698]: Script /etc/ppp/ip-up finished
(pid
> 14724), status = 0x0
> Jan 3 10:17:45 linux pppd[14698]: sent [LCP EchoReq id=0x1
magic=0x0]
> Jan 3 10:17:45 linux pppd[14698]: rcvd [LCP CodeRej id=0x4 09 01 00
08
> 00 00 00 00]
> Jan 3 10:17:45 linux pppd[14698]: LCP: Rcvd Code-Reject for code 9,
id
> 1
> Jan 3 10:18:15 linux pppd[14698]: sent [LCP EchoReq id=0x2
magic=0x0]
> Jan 3 10:18:15 linux pppd[14698]: rcvd [LCP CodeRej id=0x5 09 02 00
08
> 00 00 00 00]
> Jan 3 10:18:15 linux pppd[14698]: LCP: Rcvd Code-Reject for code 9,
id
> 2
> Jan 3 10:18:45 linux pppd[14698]: sent [LCP EchoReq id=0x3
magic=0x0]
> Jan 3 10:18:45 linux pppd[14698]: rcvd [LCP CodeRej id=0x6 09 03 00
08
> 00 00 00 00]
> Jan 3 10:18:45 linux pppd[14698]: LCP: Rcvd Code-Reject for code 9,
id
> 3
> Jan 3 10:19:15 linux pppd[14698]: No response to 4 echo-requests
> Jan 3 10:19:15 linux pppd[14698]: Serial link appears to be
> disconnected.
> Jan 3 10:19:15 linux pppd[14698]: Script /etc/ppp/ip-down started
(pid
> 15103)
> Jan 3 10:19:15 linux pppd[14698]: sent [LCP TermReq id=0x3 "Peer not
> responding"]
> Jan 3 10:19:15 linux pppd[14698]: rcvd [LCP TermAck id=0x3]
> Jan 3 10:19:15 linux pppd[14698]: Connection terminated.
> Jan 3 10:19:15 linux pppd[14698]: Connect time 2.0 minutes.
> Jan 3 10:19:15 linux pppd[14698]: Sent 156 bytes, received 64 bytes.
> Jan 3 10:19:15 linux pppd[14698]: Waiting for 1 child processes...
> Jan 3 10:19:15 linux pppd[14698]: script /etc/ppp/ip-down, pid
15103
> Jan 3 10:19:18 linux pppd[14698]: Script /etc/ppp/ip-down finished
> (pid 15103), status = 0x0
> Jan 3 10:19:18 linux pppd[14698]: Connect time 2.0 minutes.
> Jan 3 10:19:18 linux pppd[14698]: Sent 156 bytes, received 64 bytes.
> Jan 3 10:19:18 linux pppd[14698]: Exit.
>
> I get assigned an IP address, and the DNS is also correct.
> It could be a routing issue, because I do have a default route. My
> notebook is connected to a lan, and use a default gateway for
internet
> access.
> I would like to use Kppp to use my gprs cell phone when I'm on the
go,
> but I want to save my standard network configuration.
>
> The /etc/ppp/options file reads:
> noipdefault
> debug
> kdebug 1
> noauth
> crtscts
> lock
> modem
> asyncmap 0
> nodetach
> lcp-echo-interval 30
> lcp-echo-failure 4
> lcp-max-configure 60
> lcp-restart 2
> idle 600
> noipx
> file /etc/ppp/filters
> usepeerdns
>
> This is file:/etc/ppp/peers/kppp
> plugin passwordfd.so
> noauth
> debug
> crtscts
> /dev/ttyS0
> 115200
> noipdefault
> usepeerdns
>
> Is there some blatant error in these files ?
> Thanks for your time,
> -GianLuca

The problem seems to be that your ISP NAS is not responding to PPP "LCP
echo request" messages. Following logs shows that PPP client is sending
a echo request but ISP PPP is rejecting the packet.

> Jan 3 10:17:45 linux pppd[14698]: sent [LCP EchoReq id=0x1
magic=0x0]
> Jan 3 10:17:45 linux pppd[14698]: rcvd [LCP CodeRej id=0x4 09 01 00
08
> 00 00 00 00]
> Jan 3 10:17:45 linux pppd[14698]: LCP: Rcvd Code-Reject for code 9,
id
> 1
> Jan 3 10:18:15 linux pppd[14698]: sent [LCP EchoReq id=0x2
magic=0x0]
> Jan 3 10:18:15 linux pppd[14698]: rcvd [LCP CodeRej id=0x5 09 02 00
08
> 00 00 00 00]
> Jan 3 10:18:15 linux pppd[14698]: LCP: Rcvd Code-Reject for code 9,
id
> 2
> Jan 3 10:18:45 linux pppd[14698]: sent [LCP EchoReq id=0x3
magic=0x0]
> Jan 3 10:18:45 linux pppd[14698]: rcvd [LCP CodeRej id=0x6 09 03 00
08
> 00 00 00 00]
> Jan 3 10:18:45 linux pppd[14698]: LCP: Rcvd Code-Reject for code 9,
id
> 3
> Jan 3 10:19:15 linux pppd[14698]: No response to 4 echo-requests
> Jan 3 10:19:15 linux pppd[14698]: Serial link appears to be
> disconnected.
> Jan 3 10:19:15 linux pppd[14698]: Script /etc/ppp/ip-down started
(pid
> 15103)

So after time = lcp-echo-interval(30 sec) X lcp-echo-failure(4 retries)
= 120 secs your PPP client detects that server is dead and hence stops
the connection.

> lcp-echo-interval 30
> lcp-echo-failure 4

You may want to try out again by disabling LCP echoing (comment above
options from your options file)

--
Aniruddha

(E-Mail Removed) wrote:
> Gian wrote:
>> Jan 3 10:19:15 linux pppd[14698]: No response to 4 echo-requests
>> Jan 3 10:19:15 linux pppd[14698]: Serial link appears to be
>> disconnected.
>> Jan 3 10:19:15 linux pppd[14698]: Script /etc/ppp/ip-down started
> (pid
>> 15103)

> So after time = lcp-echo-interval(30 sec) X lcp-echo-failure(4 retries)
> = 120 secs your PPP client detects that server is dead and hence stops
> the connection.

>> lcp-echo-interval 30
>> lcp-echo-failure 4

> You may want to try out again by disabling LCP echoing (comment above
> options from your options file)

Note also that RFC 1661 is violated by the ISP's PPP implementation:

Upon reception of an Echo-Request in the LCP Opened state, an
Echo-Reply MUST be transmitted.

I'd get another ISP.

--
Clifford Kite Email: "echo xvgr_yvahk-(E-Mail Removed)|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
/* Bluffing in a poker game can win big; bluffing in a newsgroup
only attracts sharks. */

> So after time = lcp-echo-interval(30 sec) X lcp-echo-failure(4
retries)
> = 120 secs your PPP client detects that server is dead and hence
stops
> the connection.
>
> > lcp-echo-interval 30
> > lcp-echo-failure 4
>
> You may want to try out again by disabling LCP echoing (comment above
> options from your options file)
>
> --
> Aniruddha

Thank you all for your kind replies.
I tried commenting the LCP lines, but it doesn't go through, anyway.
The cell phone says always 0 bytes transmitted when I disconnect.

Now, where is it stored the kppp log file ?
It did not come up this time, because it did not disconnect by itself.
regards,
-Gian

Gian <(E-Mail Removed)> wrote:
>> So after time = lcp-echo-interval(30 sec) X lcp-echo-failure(4
> retries)
>> = 120 secs your PPP client detects that server is dead and hence
> stops
>> the connection.
>>
>> > lcp-echo-interval 30
>> > lcp-echo-failure 4
>>
>> You may want to try out again by disabling LCP echoing (comment above
>> options from your options file)
>>
>> --
>> Aniruddha

> Thank you all for your kind replies.
> I tried commenting the LCP lines, but it doesn't go through, anyway.
> The cell phone says always 0 bytes transmitted when I disconnect.

The Echo-Requests certainly should have gone away when those lines
were commented out.

> Now, where is it stored the kppp log file ?

Don't know. A log file for pppd should be enough anyway.

> It did not come up this time, because it did not disconnect by itself.

That sentence is difficult for me to parse, but it sounds like the
Echo-Requests *did* go away. Otherwise it would disconnect as before.

BTW, note that the log you posted also has the message:

Jan 3 10:17:22 linux pppd[14698]: not replacing default route to
eth0 [192.168.1.254]

Pppd won't override an existing default route and this message means
that you have one through 192.168.1.254. You need to get rid of it.

--
Clifford Kite Email: "echo xvgr_yvahk-(E-Mail Removed)|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
/* The generation of random numbers is too important to be left
to chance. */

Clifford Kite wrote:

> BTW, note that the log you posted also has the message:
>
> Jan 3 10:17:22 linux pppd[14698]: not replacing default route to
> eth0 [192.168.1.254]
>
> Pppd won't override an existing default route and this message means
> that you have one through 192.168.1.254. You need to get rid of it.

it's weird, because I specified defaultroute in the kppd setup window
(customize pppd arguments). I am sure the problem lies here. In this
situation, I try a connection to the web, and the Mozilla windows
shows: Resolving host... but nothing happens, and 0 bytes are
transferred.

According to man pppd:
Add a default route to the system routing tables, using the peer as the
gateway, when IPCP negotiation is successfully completed. This entry is
removed when the PPP connection is broken.

I do have a default route for normal desktop connectivity... In windows
the two settings live happily together..

BTW, sorry if my English is not too clear... I do my best.
thanks for your kind help.
-Gian

On 5 Jan 2005 13:37:18 -0800, Gian <(E-Mail Removed)> wrote:
> Clifford Kite wrote:
>
>> BTW, note that the log you posted also has the message:
>>
>> Jan 3 10:17:22 linux pppd[14698]: not replacing default route to
>> eth0 [192.168.1.254]
>>
>> Pppd won't override an existing default route and this message means
>> that you have one through 192.168.1.254. You need to get rid of it.
>
> it's weird, because I specified defaultroute in the kppd setup window
> (customize pppd arguments). I am sure the problem lies here. In this
> situation, I try a connection to the web, and the Mozilla windows
> shows: Resolving host... but nothing happens, and 0 bytes are
> transferred.
>
> According to man pppd:
> Add a default route to the system routing tables, using the peer as the
> gateway, when IPCP negotiation is successfully completed. This entry is
> removed when the PPP connection is broken.

What is not clear from man pppd is that "defaultroute" does NOT replace an
existing default route, it only sets it if there is none. You apparently
also need "replacedefaultroute" pppd option. The previous default route
should be restored when pppd disconnects.

Gian <(E-Mail Removed)> wrote:
> Clifford Kite wrote:

>> BTW, note that the log you posted also has the message:
>>
>> Jan 3 10:17:22 linux pppd[14698]: not replacing default route to
>> eth0 [192.168.1.254]
>>
>> Pppd won't override an existing default route and this message means
>> that you have one through 192.168.1.254. You need to get rid of it.

> it's weird, because I specified defaultroute in the kppd setup window
> (customize pppd arguments). I am sure the problem lies here. In this
> situation, I try a connection to the web, and the Mozilla windows
> shows: Resolving host... but nothing happens, and 0 bytes are
> transferred.

> According to man pppd:
> Add a default route to the system routing tables, using the peer as the
> gateway, when IPCP negotiation is successfully completed. This entry is
> removed when the PPP connection is broken.

As David Efflandt said (and I should have said) pppd won't replace an
existing default route even with the defaultroute option. He mentions
a replacedefaultroute option, an option which a standard pppd 2.4.2
source does not have, although pppd 2.4.3 apparently does. (I haven't
moved to 2.4.3 because of it's lack of PPP active-filter support for
any current non-CVS version of libpcap)

> I do have a default route for normal desktop connectivity... In windows
> the two settings live happily together..

Windows does show such a default route but it doesn't appear to mean
the same thing as a similar *nix default route does. You shouldn't have
(and don't need) an existing default route with single LAN with a *nix
host - unless you need to connect beyond the LAN. And even then you
may only need a network-specific default route.

The default route through 192.168.1.254 should be removed unless you
*know* it is required (doubtful - but there is a work-around if that
default route is really necessary). In most instances it's removal
is the preferred solution.

> BTW, sorry if my English is not too clear... I do my best.

Doing your best is all anyone can do. We seem to be making progress,
which is good.

--
Clifford Kite Email: "echo xvgr_yvahk-(E-Mail Removed)|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/

Hi Clifford!

In article <(E-Mail Removed)>, Clifford Kite wrote:

>He mentions a replacedefaultroute option, an option which a standard
>pppd 2.4.2 source does not have, although pppd 2.4.3 apparently does.

[compton ~]$ zgrep replacedefault /net/hubble/new/ppp-2.4.3.tar.gz
[compton ~]$

No - it's not there. I'm pretty sure this is another "feature" of kppp.

>(I haven't moved to 2.4.3 because of it's lack of PPP active-filter
>support for any current non-CVS version of libpcap)

Same here. The network I'm dialing into now has 230 tons of windoze
idiots, some of which are 0wn3d, and I see a constant noise of scans
to windoze ports. My firewall blocks that, but the traffic would keep
the idle timer from expiring.

>> I do have a default route for normal desktop connectivity... In windows
>> the two settings live happily together..
>
>Windows does show such a default route but it doesn't appear to mean
>the same thing as a similar *nix default route does.

Not using any version of windoze, I'm obviously not an authority, but the
'Gateway' column in a windoze 'route print' command actually defines the
interface (like we use 'eth0' or 'ppp0' or 'lo') rather than a specific
IP address of a computer.

>> BTW, sorry if my English is not too clear... I do my best.
>
>Doing your best is all anyone can do. We seem to be making progress,
>which is good.

Agreed. The English is not a problem.

Old guy

Moe Trin <(E-Mail Removed)> wrote:
> Hi Clifford!

Hi Moe!

> In article <(E-Mail Removed)>, Clifford Kite wrote:

>>He mentions a replacedefaultroute option, an option which a standard
>>pppd 2.4.2 source does not have, although pppd 2.4.3 apparently does.

> [compton ~]$ zgrep replacedefault /net/hubble/new/ppp-2.4.3.tar.gz
> [compton ~]$

> No - it's not there. I'm pretty sure this is another "feature" of kppp.

You're right. It must be either a feature of kppp or a distribution-
modified pppd. I had thought that kppp was a configuration tool and
dialing frontend to pppd. If that's the case I hate to think of the
kind of hacking kppp would have to do to override the default route.

>>(I haven't moved to 2.4.3 because of it's lack of PPP active-filter
>>support for any current non-CVS version of libpcap)

> Same here. The network I'm dialing into now has 230 tons of windoze
> idiots, some of which are 0wn3d, and I see a constant noise of scans
> to windoze ports. My firewall blocks that, but the traffic would keep
> the idle timer from expiring.

Exactly so, even with a dialup ISP connection there is a lot of similar
noise. Before active-filter started working I had made single-line
pppd patches to prevent the idle timer from being reset by that kind
of foolishness.

--
Clifford Kite Email: "echo xvgr_yvahk-(E-Mail Removed)|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
/* The wealth of a nation is created by the productive labor of its
* citizens. */