PCI modem, request-route

• Messages sorted by:[ date ][ thread ][ subject ][ author ]

Hi,

On Fri, Nov 26, 1999 at 06:26:23PM +0100, Verwalter Dr.Betz wrote:
> > Look with "tcpdump" on the interface (ppp0?) what's going out.
> 
> But then ppp0 has to be established first.

Hmmm, no idea how this dial-on-demand stuff works.  Maybe there's a debug
switch in diald/request-route to tell you *which* packet caused the 
dialup?  If not, that would be a useful addition.

> After establishing a ppp0-connection I get with 'tcpdump -i ppp0 -l'
> something like:
> 
> 18:01:17.969883 ta1-pc14.fh-landshut.de.1489 > s1.fh-landshut.de.domain:
> 3839+ A? www.eu.microsoft.com. (38)
> 18:01:17.999883 ta1-pc14.fh-landshut.de.1490 > s1.fh-landshut.de.domain:
> 45636+
> (45)

This looks pretty reasonable.

> tcpdump -i lo -l shows:
> 18:15:00.489883 localhost.732 > localhost.sunrpc: udp 56
> 18:15:00.489883 localhost.sunrpc > localhost.732: udp 28

Loopback won't be affected.  That's local stuff, like NFS or "showmount"
or something like this.

[..]
> Symptomatic to my problem seems the start of a second pppd,
> immediately after the first ppp0 connection is established (via
> /sbin/request-route), as shown in /var/log/messages:
> 
> Nov 26 18:14:47 INET pppd[966]: local  IP address 193.175.140.211
> Nov 26 18:14:47 INET pppd[966]: remote IP address 193.175.140.190
> Nov 26 18:14:47 INET pppd[974]: pppd 2.3.5 started by root, uid 0
> Nov 26 18:14:47 INET pppd[974]: Device modem is locked by pid 966
> Nov 26 18:14:47 INET pppd[974]: Exit.

As far as I remember, request-route is deprecated anyway, because it has
tons of race conditions - that could be a reason for the double ppp.

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert@greenie.muc.de
fax: +49-89-35655025                        gert.doering@physik.tu-muenchen.de