From owner-freebsd-hackers Fri Aug 25 09:13:57 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id JAA12951 for hackers-outgoing; Fri, 25 Aug 1995 09:13:57 -0700 Received: from tesla.cview.com (tesla.cview.com [204.95.57.17]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id JAA12903 ; Fri, 25 Aug 1995 09:13:48 -0700 Received: by tesla.cview.com (Smail3.1.29.0 #1) id m0sm1O5-0001E4C; Fri, 25 Aug 95 11:13 CDT Message-Id: From: malenovi@cview.com (Nik Malenovic) Subject: Q: ppp.slattach bugs/ppp server/load balancing To: freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org Date: Fri, 25 Aug 1995 11:13:45 -0500 (CDT) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4817 Sender: hackers-owner@freebsd.org Precedence: bulk Hi folks - I just joined in on freebsd-* mailing list, so I apologize if this has been discussed - I don't have access to mailing lists archives. I am crossposting this to freebsd-hackers and freebsd-questions here is what I am about to ask: 1. slattach bug 2. ppp (iij) bug 3. question about load balancing (specificly over ppp links) 4. ppp server questions - offer of dynamic ip pppd server and misc. here we go. 1. has the slattach bug been fixed? under pre-2.0.5-950622-SNAP and the mentioned release, slattach has a bug - it doesn't release the comunication device when redialing - that would cause your kermit to time out becuase it's not able to open the comm device. I fixed it with the simple function call - which I am including at the end of the message: 2. ppp (iij) has a bug - try having your tunnel device as a 9th on the device list (netstat -i) - the bug is that the buffer was preset and too small for the systems that have more then 8 slip/ppp/tunel devices total. I am including the relevant 2 liner code fix at the end. 3. has any work been done on load balancing? I know Linux has it working, but I don't see it in 2.0.5-950622-SNAP - so is anyone working on it? If not, is anyone planning to do any work on it? 4. I am using ppp EXTENSIVELY - I even wrote dynamic ip ppp server - so here are a few ppp-related Qs: a. is there a FAQ on dynamic ppp? I wrote a doc for internal use on dynamic ip ppp server - whom do I talk to to make it available for wider use? maybe included in /usr/share/FAQ? b. I am getting LOTZA reboots with pppd - specially if my dialup ppp client hungs up (or gets a call when his call waiting is on, or when somebody else picks up the phone (and wonders what all that noise is about :-)). Has anyone been working extensively with pppd to help me out with those kind of problems? c. I am also getting reconnection problems with pppd - there are two subproblems: - when my connection is violently broken (without graceful shutdown), when I reconnect, pppd will refuse to start up firing of a message: ioctl(SIOCAIFADDR): Address already exists in other words - it trying to add a route to the ppp client but the route allready exists - so it fails miserably. the only solution so far has been to wait for some time and retry again. - when the connection is broken on my ppp link to another node - let's say I reboot, but the physical link is still up (i.e. the phone call is still in progress and modems have not hung up), I can't reconnect - slip does this automaticaly i.e. when you fire off slattach - if it's connected to the other side - it just keep going --- can I achieve similar effect under FreeBSD? - sometimes when I disconnect normally ppp client from FreeBSD pppd server, it "forgets" that the phone call has ended and keeps the ppp user process going. :( when it happened I tried experimenting and sending -HUP signal to the client ppp process but it would ignore it. any help? - Anyone willing to chat a bit more about ppp? :) I am just right out ready to kill for a chat with somebody who knows ppp extensively. thank you for reading. Nik -- malenovi@cview.com -------------------------------------------------- CODE: 1. slattach problem - in slattach.c: /* Close all FDs, fork */ void release_line() { int ttydisc = TTYDISC; ioctl(fd, TIOCSETD, &ttydisc); /* reset to tty discipline */ (void)close(STDIN_FILENO); /* close FDs before forking. */ (void)close(STDOUT_FILENO); (void)close(STDERR_FILENO); if (fd > 2) (void)close(fd); signal(SIGHUP, SIG_IGN); /* ignore HUP signal when parent dies. */ daemon(0,0); /* fork, setsid, chdir /, and close std*. */ while (getppid () != 1) sleep (1); /* Wait for parent to die. */ if ((int)signal(SIGHUP,sighup_handler) < 0) /* Re-enable HUP signal */ syslog(LOG_NOTICE,"cannot install SIGHUP handler: %m"); } and then add in: /* signup_handler() is invoked when carrier drops, eg. before redial. */ void sighup_handler() { if(exiting) return; again: /* invoke a shell for redial_cmd or punt. */ if (redial_cmd) { syslog(LOG_NOTICE,"SIGHUP on %s (sl%d); running %s", dev,unit,redial_cmd); /* * First close the slip line in case redial_cmd wants it * (like to use kermit to redial). */ release_line(); /* System() the redial command */ if (system(redial_cmd)) goto again; acquire_line(); setup_line(CLOCAL); ... [snip] [snip] [snip] ... -------------------------------------------------- 2. ppp (iij) problem - from route.c: int GetIfIndex(name) char *name; { #define NUM_DEVICES 8*10 struct ifreq *ifrp; int s, len, elen, index; struct ifconf ifconfs; struct ifreq reqbuf[4*NUM_DEVICES]; ... [snip] [snip] [snip] ... --------------------------------------------------