Date: 12 Nov 1997 00:19:19 -0500 From: Chris Shenton <chris@absinthe.i3inc.com> To: Archie Cobbs <archie@whistle.com> Cc: hackers@FreeBSD.ORG Subject: Re: mpd -- configuration for "server" side? Message-ID: <87n2ja8zag.fsf@absinthe.i3inc.com> In-Reply-To: Archie Cobbs's message of Tue, 11 Nov 1997 18:42:46 -0800 (PST) References: <199711120242.SAA08550@bubba.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Archie Cobbs <archie@whistle.com> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?87n2ja8zag.fsf>