Date: Thu, 20 Jul 1995 01:43:27 +0000 From: "Mike O'Brien" <obrien@leonardo.net> To: freebsd-questions@freebsd.org Subject: Demand dial with IIJ PPP - ANSWER! (LONG) Message-ID: <199507200143.BAA00248@mr-p.protocorp.com>
next in thread | raw e-mail | index | archive | help
I have dial-on-demand working perfectly, I think, with IIJ PPP. It turns out that it must be set up exactly right - there is no room for slack in the ppp.conf file or it just won't work. If it's underspecified, the necessary route is not initialized, so PPP is never triggered through the tunnel device. If it's overspecified, the ISP on the other end will be unable to find common ground with you, and PPP negotiations will fail. As delivered, ppp.conf.sample is underspecified. Here are the relevant parts of my ppp.conf file: # # Default setup. Executed always when PPP is invoked. # default: set device /dev/cuaa1 set speed 38400 disable lqr deny lqr set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" ATE1Q0 OK-AT-OK \\dATDT\\T TIMEOUT 40 CONNECT" This is stock; I changed nothing. FWIW, the 'lqr' is something like Line Quality Report, which is an info packet that the two PPPs can exchange, gossiping about the percieved quality of the line. Ohno-san has apparently decided he doesn't want to do this, and who am I to argue? FWIW there is a second, optional argument to the 'timeout' command which gives the frequency with which LQR reports should be sent. # # Another on demand example # If peer assign some IP address for us, and we can't predict it # until we make a connection, use 0 as local side address. # pmdemand: set debug phase chat lcp set phone 5551212 set login "TIMEOUT 5 ogin:-\\r-ogin: YouWish word: FatChance" set timeout 600 set ifaddr 198.147.97.0/24 198.147.97.1/24 add 0 255.255.255.0 HISADDR This is where the magic lives. IIJ PPP is woken up by the receipt of packets destined for the 'tun0' device. That means that that device must be configured, and a route to that device must be established. All those zeroes in the sample file just don't cut it. So, in the 'set ifaddr' command, we say that our address is going to be somewhere in net 198.147.97.0, and that the foreign end is going to be in the same net, and will probably be host number 1. We MUST set OUR address as being in that net, or the route we're trying to establish in the next line has no anchor. Then we set a default route to that foreign host, in the 'add' line. This line must also be there, and must have HISADDR in it, or the route won't be established and PPP will never wake up. Note the '/24' in two places in the 'set ifaddr' line. These must likewise be there, or the interface will be overspecified, and the PPP negotiations that follow login will fail to agree on addresses for the link endpoints. Also, note the 255.255.255.0 netmask in the 'add' command. I believe this is also critical, because otherwise the route won't be commensurate with the interface definition in the previous line. Remember, before PPP has woken up and negotiated a final address, these "prototype" addresses are all the kernel has to work with to determine that packets should be sent to the tunnel device. That means the netmask had better be right, or the route might as well not exist. At least, that's my theory. And, thank goodness, it seems to work: no pings necessary to bring up the connection, just pure, sweet, dial on demand. Thank heavens. Oh yeah, if you want to fiddle, you will probably want to cut down on the logging. The example above is, shall we say, verbose. :-) Glad I was finally able to come up with an answer; I've asked so many questions it feels good to come up with an answer for a change. Mike O'Brien
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199507200143.BAA00248>