Date: Thu, 30 Jul 1998 16:00:30 +0200 From: Gerald Heinig <heinig@hdz-ima.rwth-aachen.de> To: hm@hcs.de Cc: ISDN Mailinglist <freebsd-isdn@FreeBSD.ORG> Subject: Tracing Kernel code (isppp) & possible isdnd bug Message-ID: <35C07C7E.E57ECB9C@hdz-ima.rwth-aachen.de> References: <m0y6xNs-0000gaC@hcswork.hcs.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi all, I've come across a bug in i4b which unfortunately isn't easily reproducible. I've set up my isdnd.rc file for normal dialup operation with the college (no callback & stuff) and instructed isdnd to redial up to 10 times at 5 second intervals. This has worked very well up until the latest alpha release (the current one - I believe it's 10.07.98). I don't think the previous release had this problem, though the more I think about it, the less sure I get... Basically, i4b dials, *seems* to get an active connection and then releases the line about 2 or 3 seconds afterwards. It then re-dials and says it has an active connection, only to release it again after 2-3 seconds and so on, up until 10 tries, when it stops. I've emphasised the "seems" because I'm not actually sure whether the connection could really be established. Our university dialup server gets rather congested after 21:00 hours (until about 00:30 or so) and I've often experienced difficulties getting a port between these times. Those are also the times when I usually come across this problem. At the moment (coming up to 16:00) there's been no problem at all dialing in to college. Now, I'd like to investigate this problem, because it's definitely a bug: (if the line is unavailable, then isdnd's claim about an active connection is false; if the connection really is active, then i4b shouldn't release it without manual intervention). I have a hunch that the problem lies with the ppp code (isppp). My question is: what tools are available for kernel tracing? I'll obviously see whether I can get enough info with isdntrace, but I wouldn't count on it. cheers, Gerald PS. Why do I think isppp is the culprit? Because a kill & restart of isdnd doesn't always solve the problem. PPS. I've just remembered that the "no traffic timeout" behaves erratically as well. It certainly doesn't hang up after 180 seconds of inactivity. I'll double check the outgoing &incoming packets, just to be sure. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?35C07C7E.E57ECB9C>