Date: Thu, 18 Sep 1997 01:19:23 +0100 From: Brian Somers <brian@awfulhak.org> To: Angelo Turetta <ATuretta@stylo.it>, Tomi Vainio <tomppa@fidata.fi> Cc: freebsd-isp@freebsd.org, Brian Somers <brian@awfulhak.org> Subject: Re: Any reason why 'ppp -direct' might ignore CD transitions? Message-ID: <199709180019.BAA06996@awfulhak.demon.co.uk> In-Reply-To: Your message of "Wed, 17 Sep 1997 20:37:37 %2B0200." <31EBCC36B676D01197E400801E0324950568AB@styloserver.stylo.it>
next in thread | previous in thread | raw e-mail | index | archive | help
Ok, got it (I think). I've updated -current with a change that's available on http://www.freebsd.org/~brian. Can you both try this version (both of you are experiencing the same problem :-O). If things are better, I'll bring it back into 2.2 *very* soon. Thanks. > I'm cc-ing Brian which, reading the latest CVS logs, should be the > maintainer of user mode ppp. My apologies if that's not true. > And BTW, I'm not on this list, so please copy replies to my address. > > I've upgraded my FreeBSD router/terminal server to 2.2-STABLE (it was > running 2.1.0-RELEASE with ppp compiled from the sources of the > 2.2-CURRENT branch dated little more than one year ago, and getty hacked > to implement the :pp: setting in the same way it works now on > 2.2-STABLE) > > I have getty listening to 4 modems, starting usermode 'ppp -direct' > through the :pp: setting of gettytab. All the users have static IP > assigned, that is when they call in the server gives them the IP number > I've put in my ppp.secret file no matter which port they get assigned > to. > > Since I upgraded to RELENG_2_2, ppp fails to recognise carrier loss > every now and then. > On most calls everything goes well, but sometimes after a carrier loss > the link stays up (last event logged: OsLinkup) and ppp doesn't quit. > I suppose this is happening after a client-side timeout, because when > this happens often the same customer calls again in a few minutes. At > that time, if he's assigned a different line, ppp logs an error > 'SetIpDevice: ioctl(SIOCAIFADDR): File exists' and quits. Eventually, > the first ppp (the one locked in the Linkup state) times out too and > exits, which enables the user to call in again. You can find the log > (Carrier Link Phase) of one occurence of the problem attached to this > message (ppp[213] was running for about an hour when the modem hung up: > the user then called back and started ppp[214] which failed to establish > the link because the IP was already in use. ppp[213] terminated only > some minutes after the new connection attempt). > > Please note that I'm sure the user is not trying to connect from two > different modems, as I personally witnessed a case where only 1 modem > was active while 4 ppp processes where running (3 of them in the locked > state). > > While checking ppp.log I've also noticed that if a new call comes on the > same modem the locked ppp is hooked to (thus raising CD again), the old > link is brought down and a new user authentication is executed by the > same instance of ppp (same PID in log file) > > It seems like ppp is trying to wait some time for the carrier to come > back up before terminating. I think this is not the expected behaviour > on a ppp server. > > Is there someone else using user mode ppp on a ppp server? > > I think the 'set reconnect' feature is likely to produce a similar > behaviour, but it's supposed to be meaningful only in case of outgoing > connections, and I've not set it up in my config file. Maybe the > introduction of this feature did break the CD-awareness of ppp when > running as a server. In fact if I 'kill -HUP' a ppp in the locked state, > it logs a 'PPP Terminated (nodial)' event before exiting. > > Thanks for any hints. > > Angelo > aturetta@stylo.it > > > Sep 17 16:58:22 gate1 ppp[213]: Phase: Using interface: tun0 > Sep 17 16:58:22 gate1 ppp[213]: Phase: Listening at port 3000. > Sep 17 16:58:22 gate1 ppp[213]: Phase: PPP Started. > Sep 17 16:58:22 gate1 ppp[213]: Phase: Packet mode enabled > Sep 17 16:58:25 gate1 ppp[213]: Phase: NewPhase: Authenticate > Sep 17 16:58:25 gate1 ppp[213]: Phase: his = 0, mine = c223 > Sep 17 16:58:25 gate1 ppp[213]: Phase: Valsize = 16, Name = oscar > Sep 17 16:58:25 gate1 ppp[213]: Phase: NewPhase: Network > Sep 17 16:58:25 gate1 ppp[213]: Link: myaddr = 193.76.98.1 hisaddr = > 193.76.98.134 > Sep 17 16:58:25 gate1 ppp[213]: Phase: Found interface ed1 for proxy arp > Sep 17 16:58:25 gate1 ppp[213]: Link: OsLinkup: 193.76.98.134 > Sep 17 17:51:16 gate1 ppp[214]: Phase: Using interface: tun1 > Sep 17 17:51:16 gate1 ppp[214]: Phase: Listening at port 3001. > Sep 17 17:51:16 gate1 ppp[214]: Phase: PPP Started. > Sep 17 17:51:16 gate1 ppp[214]: Phase: Packet mode enabled > Sep 17 17:51:18 gate1 ppp[214]: Phase: NewPhase: Authenticate > Sep 17 17:51:18 gate1 ppp[214]: Phase: his = 0, mine = c223 > Sep 17 17:51:19 gate1 ppp[214]: Phase: Valsize = 16, Name = oscar > Sep 17 17:51:19 gate1 ppp[214]: Phase: NewPhase: Network > Sep 17 17:51:19 gate1 ppp[214]: Link: myaddr = 193.76.98.1 hisaddr = > 193.76.98.134 > Sep 17 17:51:19 gate1 ppp[214]: Error: SetIpDevice: ioctl(SIOCAIFADDR): > File exists > Sep 17 17:54:21 gate1 ppp[213]: Link: OsLinkdown: 193.76.98.134 > Sep 17 17:54:21 gate1 ppp[213]: Phase: NewPhase: Terminate > Sep 17 17:54:24 gate1 ppp[213]: Phase: Connected! > Sep 17 17:54:24 gate1 ppp[213]: Phase: NewPhase: Dead > Sep 17 17:54:24 gate1 ppp[213]: Phase: PPP Terminated (dead). > Sep 17 17:55:47 gate1 ppp[214]: Phase: NewPhase: Terminate > Sep 17 17:55:50 gate1 ppp[214]: Phase: Connected! > Sep 17 17:55:50 gate1 ppp[214]: Phase: NewPhase: Dead > Sep 17 17:55:50 gate1 ppp[214]: Phase: PPP Terminated (dead). -- Brian <brian@Awfulhak.org>, <brian@FreeBSD.org>, <bri@OpenBSD.org> <http://www.Awfulhak.org>; Don't _EVER_ lose your sense of humour....
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709180019.BAA06996>