From owner-freebsd-hackers Tue Nov 11 21:19:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA06847 for hackers-outgoing; Tue, 11 Nov 1997 21:19:57 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from absinthe.i3inc.com (Absinthe.i3inc.com [209.31.147.194]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA06827 for ; Tue, 11 Nov 1997 21:19:50 -0800 (PST) (envelope-from chris@absinthe.i3inc.com) Received: (from chris@localhost) by absinthe.i3inc.com (8.7.2/8.7.2) id AAA02620; Wed, 12 Nov 1997 00:19:20 -0500 (EST) To: Archie Cobbs Cc: hackers@FreeBSD.ORG Subject: Re: mpd -- configuration for "server" side? References: <199711120242.SAA08550@bubba.whistle.com> From: Chris Shenton Date: 12 Nov 1997 00:19:19 -0500 In-Reply-To: Archie Cobbs's message of Tue, 11 Nov 1997 18:42:46 -0800 (PST) Message-ID: <87n2ja8zag.fsf@absinthe.i3inc.com> Lines: 81 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Archie Cobbs writes: > Try "set iface disable on-demand" instead of enabling it. > This will make it NOT wait for an outgoing packet before > trying to "connect" -- by listening for an incoming call. > Check that the tunnel interface is up and has addresses > after mpd is started. > > Admittedly, this is confusing because there are two things > you have to tweak to turn dial-on-demand on or off. That seems to have done it. "set iface disable on-demand" gets the daemon to camp on the device; I had to use /dev/cuaa0 rather than /dev/ttyd0 (unlike getty). Using "set bundle disable bw-manage" didn't seem to have any effect -- seems to work with it enabled too. It looks like the tun isn't instantiated until the call is answered -- is this a problem? Thanks! Now I can try to actually use multiple links :-) Couple of behavioral comments and questions: 1. On the "server side" I see complaints in the logs which usually, after 6 repetitions or so, have caused the "server" to drop the link: Nov 12 00:16:06 Placebo mpd: [usr0] LCP: no reply to 1 echo request(s) 2. This time, the link drops due to idle time-out; "server" logs: Nov 12 00:20:48 Placebo mpd: [sisyphus] idle timeout after 300 seconds Nov 12 00:20:48 Placebo mpd: [sisyphus] closing link "usr0"... Nov 12 00:20:48 Placebo mpd: [usr0] got msg MSG_CLOSE Nov 12 00:20:48 Placebo mpd: [usr0] LCP: Close event Nov 12 00:20:48 Placebo mpd: [usr0] LCP: state change Opened --> Closing Nov 12 00:20:48 Placebo mpd: [usr0] LCP: phase shift NETWORK --> TERMINATE Nov 12 00:20:48 Placebo mpd: [sisyphus] up: 0 links, total bandwidth 0 bps Nov 12 00:20:48 Placebo mpd: [sisyphus] closing link "usr0"... Nov 12 00:20:48 Placebo mpd: [usr0] LCP: SendTerminateReq #2 Nov 12 00:20:48 Placebo mpd: [usr0] LCP: LayerDown Nov 12 00:20:48 Placebo mpd: [usr0] got msg MSG_CLOSE Nov 12 00:20:48 Placebo mpd: [usr0] LCP: Close event Nov 12 00:20:48 Placebo mpd: [usr0] LCP: rec'd Terminate Ack #2 (Closing) Nov 12 00:20:48 Placebo mpd: [usr0] LCP: state change Closing --> Closed Nov 12 00:20:48 Placebo mpd: [usr0] LCP: phase shift TERMINATE --> ESTABLISH Nov 12 00:20:48 Placebo mpd: [usr0] LCP: LayerFinish Nov 12 00:20:48 Placebo mpd: [usr0] Closing physical layer in state UP Nov 12 00:20:48 Placebo mpd: [usr0] got msg MSG_DOWN Nov 12 00:20:48 Placebo mpd: [usr0] LCP: Down event Nov 12 00:20:48 Placebo mpd: [usr0] LCP: state change Closed --> Initial Nov 12 00:20:48 Placebo mpd: [usr0] LCP: phase shift ESTABLISH --> DEAD 3. Triggering demand causes the client side to attempt to re-establish the link, but the *server* is still sitting there at LCP DEAD. It never goes back to waiting by the phone. How to I get it to reset so that it will handle repeated incoming demand dials? 4. Can I set it up so that demand is there to ensure that if the link goes down it will get re-established, but that it never times out from being idle? My POTS line is unmetered, but I have a finite amount of "free" calls I can make per month. Does idle=0 imply infinite connection? (or hangup immediately, like an Ascend? :-) 5. Something in my mpd.conf and/or mpd.links sometimes generates "Line too long, truncated" warnings. The error doesn't identify which file, line number, or the line contents. It seems usually to associated with the "load log-normal" if the "log-normal:" specifier has stuff after it like miscellaneous comments, possibly even separated with the desired blank line. It would be real nice to have file:line identifiers to track this down, or at least a dislay of the offending line. Perhaps there's some confusion parsing the file looking for the last hunk and my trailing comments may be throwing it off? Thanks for your help.