From owner-freebsd-isdn Sun Jan 31 01:32:13 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA03680 for freebsd-isdn-outgoing; Sun, 31 Jan 1999 01:32:13 -0800 (PST) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from mail.ppp.net (mail.ppp.net [194.64.12.35]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA03672; Sun, 31 Jan 1999 01:32:08 -0800 (PST) (envelope-from ernie!bert.kts.org!hm@ppp.net) Received: from casparc.ppp.net (casparc2.ppp.net [194.64.12.42]) by mail.ppp.net (8.8.8/8.8.8) with SMTP id KAA27927; Sun, 31 Jan 1999 10:32:02 +0100 Received: from ernie by casparc.ppp.net with uucp (Smail3.1.28.1 #1) id m106tEX-002ZjZC; Sun, 31 Jan 99 10:32 MET Received: from bert.kts.org([194.55.156.2]) (2422 bytes) by ernie.kts.org via sendmail with P:smtp/R:smart_host/T:uux (sender: ) id for ; Sun, 31 Jan 1999 10:07:56 +0100 (CET) (Smail-3.2.0.103 1998-Oct-9 #3 built 1998-Dec-9) Received: from localhost (1980 bytes) by bert.kts.org via sendmail with P:stdio/R:smart_host/T:smtp (sender: ) (ident using unix) id for ; Sun, 31 Jan 1999 10:08:07 +0100 (CET) (Smail-3.2.0.103 1998-Oct-9 #4 built 1998-Dec-26) Message-Id: From: hm@kts.org (Hellmuth Michaelis) Subject: Re: If they US contingent wants ISDN4BSD... In-Reply-To: <199901302135.NAA10780@bubba.whistle.com> from Archie Cobbs at "Jan 30, 1999 1:35:28 pm" To: archie@whistle.com (Archie Cobbs) Date: Sun, 31 Jan 1999 10:08:07 +0100 (CET) Cc: phk@FreeBSD.ORG, isdn@FreeBSD.ORG Organization: Kitchen Table Systems Reply-To: hm@kts.org X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Archie Cobbs wrote: > > How about they find something like this: > > > > http://www.tesales.com/monspec2.htm > > > > and send it to Hellmuth ? > > Or better yet, somebody should give him ssh access to a machine > that's connected to a real ISDN line and has a Teles card in it... > With $499 PC's for sale, that'd probably be cheaper :-) Take volume IP internet access charges and telephone costs ("hey, please write down the panic output and press reset ....") into account and you'll end up with something horrible expensive for that solution - phk's idea is much cheaper, easier and faster (also, such a device is just needed for the development time, after that it may go back to where it came from. Debugging should be no problem with that $499 setup). Not to talk about that the one in the US will probably not pick up his phone anymore after 10 such calls at 3 o'clock in the morning US time. Having written, bootstrapped and debugged the i4b stack, i am quite shure that developing a US stack remotely with such a setup makes no sense at all (for me). Either the stack moves to Hamburg or Hamburg moves to the stack (or - even better - nothing moves and someone from the US does it). hellmuth -- Hellmuth Michaelis hm@kts.org Hamburg, Europe We all live in a yellow subroutine, yellow subroutine, yellow subroutine ... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Sun Jan 31 02:24:33 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA07036 for freebsd-isdn-outgoing; Sun, 31 Jan 1999 02:24:33 -0800 (PST) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from linteuto.teuto.de (linteuto.teuto.de [194.77.23.26]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA07031; Sun, 31 Jan 1999 02:24:31 -0800 (PST) (envelope-from martin@rumolt.teuto.de) Received: from rumolt.teuto.de (root@rumolt.teuto.de [212.8.203.81]) by linteuto.teuto.de (8.8.7/8.8.7) with ESMTP id LAA21609; Sun, 31 Jan 1999 11:24:29 +0100 Received: (from martin@localhost) by rumolt.teuto.de (8.8.8/8.8.7) id LAA03880; Sun, 31 Jan 1999 11:17:05 +0100 (MET) From: Martin Husemann Message-Id: <199901311017.LAA03880@rumolt.teuto.de> Subject: Re: If they US contingent wants ISDN4BSD... To: archie@whistle.com (Archie Cobbs) Date: Sun, 31 Jan 1999 11:17:04 +0100 (MET) Cc: phk@FreeBSD.ORG, isdn@FreeBSD.ORG In-Reply-To: <199901302135.NAA10780@bubba.whistle.com> from "Archie Cobbs" at Jan 30, 99 01:35:28 pm Organization: Crusaders Catering Services Inc. ;-) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Or better yet, somebody should give him ssh access to a machine > that's connected to a real ISDN line and has a Teles card in it... That's exactly what has been offered. No, not a Teles card, but the USR Sportster TA intern that is already supported by I4B. We still don't have the specs at hand, but that's beeing sorted out too. Martin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Sun Jan 31 04:15:54 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA21711 for freebsd-isdn-outgoing; Sun, 31 Jan 1999 04:15:54 -0800 (PST) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from server.amis.net (server.amis.net [195.10.52.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA21699 for ; Sun, 31 Jan 1999 04:15:50 -0800 (PST) (envelope-from blaz@gold.amis.net) Received: (from uucp@localhost) by server.amis.net (8.8.8/8.8.8) with UUCP id NAA12760 for freebsd-isdn@freebsd.org; Sun, 31 Jan 1999 13:15:44 +0100 (CET) Received: (qmail 332 invoked by uid 1000); 31 Jan 1999 12:15:19 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 31 Jan 1999 12:15:19 -0000 Date: Sun, 31 Jan 1999 13:15:19 +0100 (CET) From: Blaz Zupan To: freebsd-isdn@FreeBSD.ORG Subject: Occasional failure with i4b 0.70 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org isdn4bsd 0.63 was working without a single problem on my setup. When 0.70 came out I immediately upgraded and when 0.70 was integrated into FreeBSD I started using the integrated version. But with 0.70, calls sometimes fail. I have to do "ifconfig isp0 down" and then "ifconfig isp0 up" to get it working again. When it last failed, I caught the following messages in my system log: Jan 31 12:35:09 gold /kernel: i4b: unit 0, assigned TEI = 124 = 0x7c Jan 31 12:35:17 gold /kernel: i4b-L2-i4b_i_frame_queued_up: V(S) == ((V(A) + k) & 127)! Jan 31 12:35:17 gold /kernel: i4b-L2-i4b_i_frame_queued_up: state = ST_MULTIFR Jan 31 12:35:17 gold /kernel: i4b-L2-i4b_print_l2var: unit0 V(R)=4, V(S)=3, V(A)=2,ACKP=0,PBSY=0,OBSY=0 Jan 31 12:35:21 gold /kernel: i4b-L3-T313_timeout: CONN ACK not received, cr = 1 Jan 31 12:35:21 gold /kernel: i4b-L3-next_l3state: FSM illegal state, state = ST_U0 - Null, event = EV_T313EXP - T313 timeout! Jan 31 12:35:21 gold /kernel: i4b-L3-i4b_decode_q931: cannot find calldescriptor for cr = 0x1, crflag = 0x0, msg = 0x4d, frame = 0x4d Jan 31 12:42:32 gold /kernel: i4b-L3-T308_timeout: REL not answered, cr = 2 Jan 31 12:42:32 gold /kernel: i4b-L3-next_l3state: FSM illegal state, state = ST_U12 - Disc Ind, event = EV_T308EXP - T308 timeout! Jan 31 12:58:10 gold /kernel: i4b-L3-T303_timeout: SETUP not answered, cr = 46 Jan 31 12:58:19 gold /kernel: i4b-L3-T313_timeout: CONN ACK not received, cr = 1 Jan 31 12:58:19 gold /kernel: i4b-L3-F_SIGN: FSM function F_SIGN executing Jan 31 12:58:19 gold /kernel: i4b-L3-F_UEM: FSM function F_UEM executing, state = ST_U11 - Disc Req Jan 31 12:58:19 gold /kernel: i4b-L3-i4b_decode_q931: cannot find calldescriptor for cr = 0x1, crflag = 0x0, msg = 0x7d, frame = 0x7d 0x8 0x4 0x82 0xe4 0x98 0x8 0x14 0x1 0x13 Jan 31 12:58:23 gold /kernel: i4b-L3-i4b_decode_q931: cannot find calldescriptor for cr = 0x1, crflag = 0x0, msg = 0x4d, frame = 0x4d Jan 31 12:58:38 gold /kernel: i4b-L1-timer4_expired: state = F3 Deactivated Has anybody seen this? The switch is Siemens EWSD, I'm using a Teles S0/16.3 card, which is connected to a Ascom NT+2ab NT. All of this is running on a AMD5x86 box with a 4.0-CURRENT kernel as of today. It is hard to reproduce this problem, sometimes it doesn't happen for days and sometimes it happens twice in a couple of hours. If I should turn on any other debugging, please tell me. If I don't receive any response, I'll try to enable as much debugging as I can and then send-pr it. Blaz Zupan, blaz@medinet.si, http://home.amis.net/blaz Medinet d.o.o., Linhartova 21, 2000 Maribor, Slovenia To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Sun Jan 31 05:43:28 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA29675 for freebsd-isdn-outgoing; Sun, 31 Jan 1999 05:43:28 -0800 (PST) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from hcsext.hcs.de (hcsext.hcs.de [194.123.40.2]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id FAA29670 for ; Sun, 31 Jan 1999 05:43:22 -0800 (PST) (envelope-from hm@hcs.de) Received: from hcswork.hcs.de([192.76.124.5]) (2125 bytes) by hcsext.hcs.de via sendmail with P:smtp/R:inet_hosts/T:smtp (sender: ) id for ; Sun, 31 Jan 1999 14:43:18 +0100 (CET) (Smail-3.2.0.104 1998-Nov-20 #1 built 1998-Dec-11) Received: by hcswork.hcs.de (Smail3.1.29.0 #12) id m106x9e-00004aC; Sun, 31 Jan 99 14:43 MET Message-Id: From: hm@hcs.de (Hellmuth Michaelis) Subject: Re: Occasional failure with i4b 0.70 In-Reply-To: from Blaz Zupan at "Jan 31, 99 01:15:19 pm" To: blaz@gold.amis.net (Blaz Zupan) Date: Sun, 31 Jan 1999 14:43:14 +0100 (MET) Cc: freebsd-isdn@FreeBSD.ORG Reply-To: hm@hcs.de Organization: HCS Hanseatischer Computerservice GmbH X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >From the keyboard of Blaz Zupan: > But with 0.70, calls sometimes fail. I have to do "ifconfig isp0 down" and > then "ifconfig isp0 up" to get it working again. When it last failed, I > caught the following messages in my system log: > > Jan 31 12:35:09 gold /kernel: i4b: unit 0, assigned TEI = 124 = 0x7c > Jan 31 12:35:17 gold /kernel: i4b-L2-i4b_i_frame_queued_up: V(S) == ((V(A) + k) & 127)! > Jan 31 12:35:17 gold /kernel: i4b-L2-i4b_i_frame_queued_up: state = ST_MULTIFR > Jan 31 12:35:17 gold /kernel: i4b-L2-i4b_print_l2var: unit0 V(R)=4, V(S)=3, V(A)=2,ACKP=0,PBSY=0,OBSY=0 > Jan 31 12:35:21 gold /kernel: i4b-L3-T313_timeout: CONN ACK not received, cr = 1 [etc ...] This is a known phenomenon. Some people report it happenes on their systems, i've seen it here too occasionally and Martin has severe problems with it and is working to try to debug and fix it. Due to the nature of the problem it seems that it will take a while to get it fixed. hellmuth -- Hellmuth Michaelis Tel +49 40 559747-70 HCS Hanseatischer Computerservice GmbH Fax +49 40 559747-77 Oldesloer Strasse 97-99 Mail hm [at] hcs.de 22457 Hamburg WWW http://www.hcs.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Sun Jan 31 05:53:18 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA00809 for freebsd-isdn-outgoing; Sun, 31 Jan 1999 05:53:18 -0800 (PST) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from server.amis.net (server.amis.net [195.10.52.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA00802 for ; Sun, 31 Jan 1999 05:53:15 -0800 (PST) (envelope-from blaz@gold.amis.net) Received: (from uucp@localhost) by server.amis.net (8.8.8/8.8.8) with UUCP id OAA25147 for freebsd-isdn@FreeBSD.ORG; Sun, 31 Jan 1999 14:53:10 +0100 (CET) Received: (qmail 915 invoked by uid 1000); 31 Jan 1999 13:50:21 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 31 Jan 1999 13:50:21 -0000 Date: Sun, 31 Jan 1999 14:50:20 +0100 (CET) From: Blaz Zupan To: Hellmuth Michaelis cc: freebsd-isdn@FreeBSD.ORG Subject: Re: Occasional failure with i4b 0.70 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > This is a known phenomenon. Some people report it happenes on their systems, > i've seen it here too occasionally and Martin has severe problems with it > and is working to try to debug and fix it. Ok, if there's anything I can do (or provide) to help fixing this, I'm available. Unfortunatelly I don't have enough knowledge of the i4b internals to dive into the source and start working on it myself. Keep up the good work. Best regards, Blaz Zupan, blaz@medinet.si, http://home.amis.net/blaz Medinet d.o.o., Linhartova 21, 2000 Maribor, Slovenia To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Sun Jan 31 09:10:55 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA21454 for freebsd-isdn-outgoing; Sun, 31 Jan 1999 09:10:55 -0800 (PST) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from mx1.dmz.fedex.com (mx1.dmz.fedex.com [199.81.194.37]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA21415; Sun, 31 Jan 1999 09:10:45 -0800 (PST) (envelope-from wam@mohawk.dpd.fedex.com) Received: from mx1.zmd.fedex.com (sendmail@mx1.zmd.fedex.com [199.82.159.10]) by mx1.dmz.fedex.com (8.9.1/8.9.1) with ESMTP id LAA26435; Sun, 31 Jan 1999 11:10:43 -0600 (CST) Received: from s07.sa.fedex.com (root@s07.sa.fedex.com [199.81.124.17]) by mx1.zmd.fedex.com (8.9.1/8.9.1) with ESMTP id LAA12570; Sun, 31 Jan 1999 11:10:43 -0600 (CST) Received: from mohawk.dpd.fedex.com (mohawk.dpd.fedex.com [199.81.74.121]) by s07.sa.fedex.com (8.9.1/8.9.1) with SMTP id LAA14694; Sun, 31 Jan 1999 11:10:21 -0600 (CST) Message-Id: <199901311710.LAA14694@s07.sa.fedex.com> To: hm@kts.org, archie@whistle.com (Archie Cobbs), phk@FreeBSD.ORG, isdn@FreeBSD.ORG Subject: Re: If they US contingent wants ISDN4BSD... In-reply-to: Message id Date: Sun, 31 Jan 1999 11:10:01 -0600 From: William McVey Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Archie Cobbs wrote: >> Or better yet, somebody should give him ssh access to a machine >> that's connected to a real ISDN line and has a Teles card in it... >> With $499 PC's for sale, that'd probably be cheaper :-) I believe I've made that offer. I'm unsure what is specifically meant by "real ISDN" line, but I've offered console access (via serial interface) to one my machines with a Sportster ISDN card in it connected to a (U interface?) isdn line. Hellmuth Michaelis wrote: >Take volume IP internet access charges and telephone costs ("hey, >please write down the panic output and press reset ....") into >account and you'll end up with something horrible expensive I can't speak to the IP access charges you would incur associated with such a development effort (more than $950?); however, I would imagine telephone costs should be minimal if we are talking about console access to a machine that is configured to break to the kernel debugger (and hence allow a warm boot) upon receiving a `break'. In the rare cases that a power-cycle is necessary, I have available device that can allow remote power control (for details, see the pow-r-switch device at http://www.blackbox.com/catalog/09switches/394.PDF) of the computer in question. >for that solution - phk's idea is much cheaper, easier and faster >(also, such a device is just needed for the development time, after > that it may go back to where it came from. Debugging should be > no problem with that $499 setup). I'll check with some of my telco acquaintancs to see if I can get an equivalent ISDN emulator loaner device. I'm not holding my breath. Since I would have no use for the device after the development is done, I can't justify to myself (nor to my wife) the cost of purchasing the device mentioned to get my ISDN working (not when the same money can buy me more than 2 years of cable modem access). This of course assumes I would have to buy the machine by myself... I wouldn't be opposed to contributing to a pool of money to fund this device. If a pool of money was collected to assist in the development of the US ISDN protocols, would that pool of money be better to put towards buying the ISDN emulation device, or towards a bounty/reward posted at the Free Software Bazaar* (ie a direct monetary contribution to the developer(s) who do the work)? >Not to talk about that the one in the US will probably not pick up >his phone anymore after 10 such calls at 3 o'clock in the morning >US time. In cases where remote access to a machine's serial console and power control is insufficient (lets say you need a new card put into the device), what kind of response time would you need? I would imagine it would be a very rare event when console access and remote power capabilities would be insufficient to support remote machine being worked on. I know for the machines I support in Europe and Asia, the combination of serial consoles and remote power management allows pretty much complete control of the machine, up to changing hardware configs. >Having written, bootstrapped and debugged the i4b stack, i am quite >shure that developing a US stack remotely with such a setup makes >no sense at all (for me). Well, I'm definitely in no position to argue that point. Please keep in mind my offer if you decide that you'd like to try doing the remote development option. -- William * http://visar.csustan.edu/bazaar/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Sun Jan 31 10:21:48 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA00202 for freebsd-isdn-outgoing; Sun, 31 Jan 1999 10:21:48 -0800 (PST) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from vespucci.advicom.net (vespucci.advicom.net [199.170.120.42]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA00183; Sun, 31 Jan 1999 10:21:40 -0800 (PST) (envelope-from avalon@vespucci.advicom.net) Received: from localhost (avalon@localhost) by vespucci.advicom.net (8.8.8/8.8.5) with ESMTP id MAA06755; Sun, 31 Jan 1999 12:21:14 -0600 (CST) X-Envelope-Recipient: isdn@FreeBSD.ORG Date: Sun, 31 Jan 1999 12:21:14 -0600 (CST) From: Avalon Books To: Hellmuth Michaelis cc: Archie Cobbs , phk@FreeBSD.ORG, isdn@FreeBSD.ORG Subject: Re: If they US contingent wants ISDN4BSD... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 31 Jan 1999, Hellmuth Michaelis wrote: > Either the stack moves to Hamburg or Hamburg moves to the stack > (or - even better - nothing moves and someone from the US does it). Spoken like a true European. And everyone wonders why Americans can't seem to get any help on this mailing list... In typical fashion, we North Americans are simply going to have to help ourselves. And that's fine with us--we're getting used to this "cold shoulder" attitude from our foriegn "counter-parts". But in the midst of your arrogant territorialism, try to remember who invented ISDN, ok? But closer to Home: I expect my North American FreeBSD Support Page(s) to be up and running within the next week or two, as I have already received enough data from my fellow North Americans to make the page worth posting. This page will be available to interested parties for the conceiveable future. I will be formally requesting that the FreeBSD core group start the "freebsd-us-isdn" mailing list. Time for us to take our toys and go home, kids--they don't want us here anymore. --R. Pelletier (EX-German) Sys Admin, House Galiagante We are a Micro$oft-free site P.S. Forgive me if I've clouded the issue with too many facts. Sorry. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Sun Jan 31 11:00:53 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA05075 for freebsd-isdn-outgoing; Sun, 31 Jan 1999 11:00:53 -0800 (PST) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA05067 for ; Sun, 31 Jan 1999 11:00:48 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.1/8.8.5) with ESMTP id TAA14750; Sun, 31 Jan 1999 19:58:26 +0100 (CET) To: Avalon Books cc: Hellmuth Michaelis , Archie Cobbs , isdn@FreeBSD.ORG Subject: Re: If they US contingent wants ISDN4BSD... In-reply-to: Your message of "Sun, 31 Jan 1999 12:21:14 CST." Date: Sun, 31 Jan 1999 19:58:25 +0100 Message-ID: <14748.917809105@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message , Aval on Books writes: > >On Sun, 31 Jan 1999, Hellmuth Michaelis wrote: > >> Either the stack moves to Hamburg or Hamburg moves to the stack >> (or - even better - nothing moves and someone from the US does it). > > Spoken like a true European. And everyone wonders why Americans can't >seem to get any help on this mailing list... > > In typical fashion, we North Americans are simply going to have to >help ourselves. And that's fine with us--we're getting used to this "cold >shoulder" attitude from our foriegn "counter-parts". Yes, in fact, that is exactly the situation. And there is nothing wrong with it! Hellmuth spent a LOT of his spare time already, you have the source which is the result of that, you have access to the hardware & the switch (neither of which Hellmuth has), what on earth makes you think you can ask Hellmuth (or anybody else!) to do it on your terms ??? It has nothing to do with Hellmuth being european, it has to do with the fact that he is a volounteer who have already put in more time and effort than you can possibly imagine, and then you come in like a spoiled brat and demand that he make it work for you too. I'm sorry Biff, we don't play that way around here! > I will be formally requesting that the FreeBSD core group start the >"freebsd-us-isdn" mailing list. There is no point in doing so, since the only purpose is to enforce a geographical split you perceive but which doesn't exist in reality. >P.S. Forgive me if I've clouded the issue with too many facts. Sorry. You most certainly havn't, and there doesn't seem to be any reason to fear that it will happen any time soon. Instead of replying: please switch to Linux and leave us alone. Poul-Henning, Spoken as a 386BSD/FreeBSD volounteer for longer than I care to remember. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Sun Jan 31 11:32:49 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA09558 for freebsd-isdn-outgoing; Sun, 31 Jan 1999 11:32:49 -0800 (PST) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from mail.ppp.net (mail.ppp.net [194.64.12.35]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA09534; Sun, 31 Jan 1999 11:32:29 -0800 (PST) (envelope-from ernie!bert.kts.org!hm@ppp.net) Received: from casparc.ppp.net (casparc2.ppp.net [194.64.12.42]) by mail.ppp.net (8.8.8/8.8.8) with SMTP id UAA32063; Sun, 31 Jan 1999 20:32:02 +0100 Received: from ernie by casparc.ppp.net with uucp (Smail3.1.28.1 #1) id m1072bB-002ZjcC; Sun, 31 Jan 99 20:32 MET Received: from bert.kts.org([194.55.156.2]) (3308 bytes) by ernie.kts.org via sendmail with P:smtp/R:smart_host/T:uux (sender: ) id for ; Sun, 31 Jan 1999 20:13:20 +0100 (CET) (Smail-3.2.0.103 1998-Oct-9 #3 built 1998-Dec-9) Received: from localhost (2862 bytes) by bert.kts.org via sendmail with P:stdio/R:smart_host/T:smtp (sender: ) (ident using unix) id for ; Sun, 31 Jan 1999 20:13:35 +0100 (CET) (Smail-3.2.0.103 1998-Oct-9 #4 built 1998-Dec-26) Message-Id: From: hm@kts.org (Hellmuth Michaelis) Subject: Re: If they US contingent wants ISDN4BSD... In-Reply-To: <199901311710.LAA14694@s07.sa.fedex.com> from William McVey at "Jan 31, 1999 11:10: 1 am" To: wam@sa.fedex.com (William McVey) Date: Sun, 31 Jan 1999 20:13:35 +0100 (CET) Cc: hm@kts.org, archie@whistle.com, phk@FreeBSD.ORG, isdn@FreeBSD.ORG Organization: Kitchen Table Systems Reply-To: hm@kts.org X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org William McVey wrote: > >Archie Cobbs wrote: > >> Or better yet, somebody should give him ssh access to a machine > >> that's connected to a real ISDN line and has a Teles card in it... > >> With $499 PC's for sale, that'd probably be cheaper :-) > > I believe I've made that offer. And i appreciate it very very much. > I'll check with some of my telco acquaintancs to see if I can get > an equivalent ISDN emulator loaner device. I'm not holding my > breath. Since I would have no use for the device after the > development is done, I can't justify to myself (nor to my wife) > the cost of purchasing the device mentioned to get my ISDN working > (not when the same money can buy me more than 2 years of cable > modem access). This of course assumes I would have to buy the > machine by myself... I wouldn't be opposed to contributing to a > pool of money to fund this device. If a pool of money was collected > to assist in the development of the US ISDN protocols, would that > pool of money be better to put towards buying the ISDN emulation > device, or towards a bounty/reward posted at the Free Software > Bazaar* (ie a direct monetary contribution to the developer(s) who > do the work)? By all means, it would be much better, if someone from the US with the support of all those from the US who want the US protocols going into i4b would start working on it and later supporting it. > >Having written, bootstrapped and debugged the i4b stack, i am quite > >shure that developing a US stack remotely with such a setup makes > >no sense at all (for me). > > Well, I'm definitely in no position to argue that point. To repeat it, i appreciate your offers very much, and i don't want to be ungrateful. Its just that i know what i went through when i did that locally. Really, i don't want to do that remotely. This is not to say that it can't be done remotely and in case someone will try to do it, she/he will get all the support from me i'm able to give (as will anyone from the US doing that in the US). hellmuth -- Hellmuth Michaelis hm@kts.org Hamburg, Europe We all live in a yellow subroutine, yellow subroutine, yellow subroutine ... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Sun Jan 31 12:18:47 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA15097 for freebsd-isdn-outgoing; Sun, 31 Jan 1999 12:18:47 -0800 (PST) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from mail.ppp.net (mail.ppp.net [194.64.12.35]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA15087; Sun, 31 Jan 1999 12:18:40 -0800 (PST) (envelope-from ernie!bert.kts.org!hm@ppp.net) Received: from casparc.ppp.net (casparc2.ppp.net [194.64.12.42]) by mail.ppp.net (8.8.8/8.8.8) with SMTP id VAA32243; Sun, 31 Jan 1999 21:02:02 +0100 Received: from ernie by casparc.ppp.net with uucp (Smail3.1.28.1 #1) id m10734D-002ZjcC; Sun, 31 Jan 99 21:02 MET Received: from bert.kts.org([194.55.156.2]) (2244 bytes) by ernie.kts.org via sendmail with P:smtp/R:smart_host/T:uux (sender: ) id for ; Sun, 31 Jan 1999 20:38:54 +0100 (CET) (Smail-3.2.0.103 1998-Oct-9 #3 built 1998-Dec-9) Received: from localhost (1798 bytes) by bert.kts.org via sendmail with P:stdio/R:smart_host/T:smtp (sender: ) (ident using unix) id for ; Sun, 31 Jan 1999 20:39:09 +0100 (CET) (Smail-3.2.0.103 1998-Oct-9 #4 built 1998-Dec-26) Message-Id: From: hm@kts.org (Hellmuth Michaelis) Subject: Re: If they US contingent wants ISDN4BSD... In-Reply-To: from Avalon Books at "Jan 31, 1999 12:21:14 pm" To: avalon@advicom.net (Avalon Books) Date: Sun, 31 Jan 1999 20:39:09 +0100 (CET) Cc: hm@kts.org, archie@whistle.com, phk@FreeBSD.ORG, isdn@FreeBSD.ORG Organization: Kitchen Table Systems Reply-To: hm@kts.org X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Avalon Books wrote: > On Sun, 31 Jan 1999, Hellmuth Michaelis wrote: > > > Either the stack moves to Hamburg or Hamburg moves to the stack > > (or - even better - nothing moves and someone from the US does it). > > Spoken like a true European. And everyone wonders why Americans can't > seem to get any help on this mailing list... I should have added a ";-)" to the end of the first part of the above quouted sentence from me, my fault. And in case you didn't noticed, i already offered to come over to the US for a week or two in case i get a place to sleep and access to an ISDN passive card using the Siemens chipset and an ISDN line. And i did _not_ mean "please pay me the flight and a hotel". Is this still not enough for you ? I'm sorry then, i don't have to give more than that. And for the rest of your mail: i have really no idea, how it can be that someone so completely misunderstands me like you are obviously doing. hellmuth -- Hellmuth Michaelis hm@kts.org Hamburg, Europe We all live in a yellow subroutine, yellow subroutine, yellow subroutine ... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Sun Jan 31 15:33:14 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA11128 for freebsd-isdn-outgoing; Sun, 31 Jan 1999 15:33:14 -0800 (PST) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from news-ma.rhein-neckar.de (news-ma.rhein-neckar.de [193.197.90.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA11119 for ; Sun, 31 Jan 1999 15:33:12 -0800 (PST) (envelope-from naddy@mips.rhein-neckar.de) Received: from mips.rhein-neckar.de (uucp@localhost) by news-ma.rhein-neckar.de (8.8.8/8.8.8) with bsmtp id AAA23375 for freebsd-isdn@freebsd.org; Mon, 1 Feb 1999 00:33:10 +0100 (CET) (envelope-from naddy@mips.rhein-neckar.de) Received: by mips.rhein-neckar.de id m1073y4-000WyrC (Debian Smail-3.2.0.101 1997-Dec-17 #2); Sun, 31 Jan 1999 21:59:44 +0100 (CET) From: naddy@mips.rhein-neckar.de (Christian Weisgerber) Subject: Re: If they US contingent wants ISDN4BSD... Date: 31 Jan 1999 21:59:40 +0100 Message-ID: <792g7s$4qo$1@mips.rhein-neckar.de> References: <199901302135.NAA10780@bubba.whistle.com> <199901311017.LAA03880@rumolt.teuto.de> To: freebsd-isdn@FreeBSD.ORG Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Martin Husemann wrote: > > Or better yet, somebody should give him ssh access to a machine > > that's connected to a real ISDN line and has a Teles card in it... > > That's exactly what has been offered. No, not a Teles card, but the > USR Sportster TA intern that is already supported by I4B. Hmm, I think it bears pointing out that the cards sold as "USRobotics Sportster" in North America and Europe, respectively, are entirely different products. -- Christian "naddy" Weisgerber naddy@mips.rhein-neckar.de >H Deutsche Transhumanismus-Mailingliste echo 'subscribe trans-de' | mail majordomo@lists.rhein-neckar.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Sun Jan 31 20:09:41 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA13789 for freebsd-isdn-outgoing; Sun, 31 Jan 1999 20:09:41 -0800 (PST) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA13768; Sun, 31 Jan 1999 20:09:31 -0800 (PST) (envelope-from archie@whistle.com) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id UAA19531; Sun, 31 Jan 1999 20:09:25 -0800 (PST) Received: from bubba.whistle.com( 207.76.205.7) by whistle.com via smap (V2.0) id xma019526; Sun, 31 Jan 99 20:09:13 -0800 Received: (from archie@localhost) by bubba.whistle.com (8.8.7/8.6.12) id UAA25204; Sun, 31 Jan 1999 20:09:13 -0800 (PST) From: Archie Cobbs Message-Id: <199902010409.UAA25204@bubba.whistle.com> Subject: Re: If they US contingent wants ISDN4BSD... In-Reply-To: from Hellmuth Michaelis at "Jan 31, 99 10:08:07 am" To: hm@kts.org Date: Sun, 31 Jan 1999 20:09:13 -0800 (PST) Cc: phk@FreeBSD.ORG, isdn@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hellmuth Michaelis writes: > > Or better yet, somebody should give him ssh access to a machine > > that's connected to a real ISDN line and has a Teles card in it... > > With $499 PC's for sale, that'd probably be cheaper :-) > > Take volume IP internet access charges and telephone costs ("hey, > please write down the panic output and press reset ....") into > account and you'll end up with something horrible expensive > for that solution - phk's idea is much cheaper, easier and faster > (also, such a device is just needed for the development time, after > that it may go back to where it came from. Debugging should be > no problem with that $499 setup). > > Not to talk about that the one in the US will probably not pick up > his phone anymore after 10 such calls at 3 o'clock in the morning > US time. > > Having written, bootstrapped and debugged the i4b stack, i am quite > shure that developing a US stack remotely with such a setup makes > no sense at all (for me). I guess you're right. Having that reset button sure is handy :-) But just for fun, I'd like to point out that once you got the hardware driver debugged and working as a netgraph node (i.e., just doing the Layer 1 part), then you could do all the Layer 2 and Layer 3 debugging in user space :-) -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Tue Feb 2 06:00:21 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA16179 for freebsd-isdn-outgoing; Tue, 2 Feb 1999 06:00:21 -0800 (PST) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from north.ml.org ([134.102.242.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA16167 for ; Tue, 2 Feb 1999 06:00:03 -0800 (PST) (envelope-from ac@clx.net) Received: from north.ml.org (pC19F4611.dip.t-online.de [193.159.70.17]) by north.ml.org (8.8.5/8.8.5) with SMTP id PAA21186 for ; Tue, 2 Feb 1999 15:25:00 +0100 (CET) Date: Tue, 2 Feb 1999 13:28:58 +0000 From: =?ISO-8859-1?B?QW5kcukgJiBDYXJvbGluZSA=?= =?ISO-8859-1?B??= X-Mailer: The Bat! (v1.18 Christmas Edition) UNREG Reply-To: =?ISO-8859-1?B?QW5kcukgJiBDYXJvbGluZSA=?= =?ISO-8859-1?B??= X-Priority: 3 (Normal) Message-ID: <7561.990202@clx.net> To: freebsd-isdn@FreeBSD.ORG Subject: MultilinkPPP with i4b Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi there, is there a way to do multilink/ppp with i4B? My Provider supports that. the other way mentioned in a w**dumb newsgroup is to install 1 device for each B-Channel and do it via tunneling? the advantage should be that i can use 2 different provider, but the machine has two dynamic IP adresses? Anyone heard of that? Liebe Grüße a&c --------------------------------------------------------------- andre & caroline / ac@clx.net / fon+fax:+49-(0)2012.47180.10195 --------------------------------------------------------------- Pleaze use PGP! To get our public key, write an email with the subject 'get pgpkey' (without the quotes:-) --------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Tue Feb 2 06:05:35 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA16803 for freebsd-isdn-outgoing; Tue, 2 Feb 1999 06:05:35 -0800 (PST) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from hcsext.hcs.de (hcsext.hcs.de [194.123.40.2]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id GAA16798 for ; Tue, 2 Feb 1999 06:05:33 -0800 (PST) (envelope-from hm@hcs.de) Received: from hcswork.hcs.de([192.76.124.5]) (1544 bytes) by hcsext.hcs.de via sendmail with P:smtp/R:inet_hosts/T:smtp (sender: ) id for ; Tue, 2 Feb 1999 15:05:31 +0100 (CET) (Smail-3.2.0.104 1998-Nov-20 #1 built 1998-Dec-11) Received: by hcswork.hcs.de (Smail3.1.29.0 #12) id m107gSI-0000ZmC; Tue, 2 Feb 99 15:05 MET Message-Id: From: hm@hcs.de (Hellmuth Michaelis) Subject: US ISDN Specs To: freebsd-isdn@FreeBSD.ORG (ISDN Mailinglist) Date: Tue, 2 Feb 1999 15:05:30 +0100 (MET) Reply-To: hm@hcs.de Organization: HCS Hanseatischer Computerservice GmbH X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As far as i know now, the most widely used ISDN in the US seems to be the so called "National ISDN". The protocol specification for this seems (!) to be AT&T Document 235-900-341 (current issue is 5): "National ISDN Basic Rate Interface Specification". Anyway, nobody i talked to at AT&T and Lucent could tell me if this contains everything needed to implement a stack and/or if this document contains the US equivalent of Q.921/Q.931. This document can be ordered from Lucent in the US, Tel 317/322-6416 or Fax 317/322-6699 and costs 460 US$ plus S+H. hellmuth -- Hellmuth Michaelis Tel +49 40 559747-70 HCS Hanseatischer Computerservice GmbH Fax +49 40 559747-77 Oldesloer Strasse 97-99 Mail hm [at] hcs.de 22457 Hamburg WWW http://www.hcs.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Wed Feb 3 15:19:30 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA14164 for freebsd-isdn-outgoing; Wed, 3 Feb 1999 15:19:30 -0800 (PST) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA14143 for ; Wed, 3 Feb 1999 15:19:23 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.1/8.8.5) with ESMTP id AAA26031 for ; Thu, 4 Feb 1999 00:18:46 +0100 (CET) To: isdn@FreeBSD.ORG Subject: I4B PPP users, please test... From: Poul-Henning Kamp Date: Thu, 04 Feb 1999 00:18:46 +0100 Message-ID: <26029.918083926@critter.freebsd.dk> Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm trying to get the sppp code to behave less erratically in various corner cases (loopbacks, leased lines and whatsnot). This patch should hopefully not make things worse for ISDN use of the sppp implementation, but to make sure before I commit it, I'd like to hear back from a few people first. Don't worry about the "b6" you will see in ifconfig, it means that the isppp driver is "SMART" about the flags now, and a minor patch to ifconfig will make it look smarter there too. Poul-Henning Index: i386/isa/if_ar.c =================================================================== RCS file: /home/ncvs/src/sys/i386/isa/if_ar.c,v retrieving revision 1.24 diff -u -r1.24 if_ar.c --- if_ar.c 1998/12/16 18:42:38 1.24 +++ if_ar.c 1999/02/03 23:14:25 @@ -600,13 +600,6 @@ TRC(printf("ar%d: arioctl.\n", ifp->if_unit);) - if(cmd == SIOCSIFFLAGS) { - if(ifp->if_flags & IFF_LINK2) - sp->pp_flags |= PP_CISCO; - else - sp->pp_flags &= ~PP_CISCO; - } - was_up = ifp->if_flags & IFF_RUNNING; error = sppp_ioctl(ifp, cmd, data); Index: i386/isa/if_cx.c =================================================================== RCS file: /home/ncvs/src/sys/i386/isa/if_cx.c,v retrieving revision 1.26 diff -u -r1.26 if_cx.c --- if_cx.c 1998/12/16 18:42:38 1.26 +++ if_cx.c 1999/02/03 23:15:21 @@ -827,10 +827,6 @@ if (! new.ext) { struct sppp *sp = (struct sppp*) c->ifp; - if (new.cisco) - sp->pp_flags |= PP_CISCO; - else - sp->pp_flags &= ~PP_CISCO; if (new.keepalive) sp->pp_flags |= PP_KEEPALIVE; else Index: i386/isa/if_sr.c =================================================================== RCS file: /home/ncvs/src/sys/i386/isa/if_sr.c,v retrieving revision 1.21 diff -u -r1.21 if_sr.c --- if_sr.c 1999/01/18 21:27:03 1.21 +++ if_sr.c 1999/02/03 23:15:32 @@ -1275,13 +1275,6 @@ ifp->if_flags &= ~IFF_LINK1; #endif - /* - * Next we can handle minor protocol point(s) - */ - if (ifp->if_flags & IFF_LINK2) - sp->pp_flags |= PP_CISCO; - else - sp->pp_flags &= ~PP_CISCO; } /* * Next, we'll allow the network service layer we've called process Index: net/if.c =================================================================== RCS file: /home/ncvs/src/sys/net/if.c,v retrieving revision 1.65 diff -u -r1.65 if.c --- if.c 1999/02/01 20:03:27 1.65 +++ if.c 1999/02/03 21:01:39 @@ -604,6 +604,13 @@ error = suser(p->p_ucred, &p->p_acflag); if (error) return (error); + ifr->ifr_flags &= ~IFF_CANTCHANGE; + if (ifp->if_flags & IFF_SMART) { + if (ifp->if_ioctl) + (void) (*ifp->if_ioctl)(ifp, cmd, data); + getmicrotime(&ifp->if_lastchange); + break; + } if (ifp->if_flags & IFF_UP && (ifr->ifr_flags & IFF_UP) == 0) { int s = splimp(); if_down(ifp); @@ -615,7 +622,7 @@ splx(s); } ifp->if_flags = (ifp->if_flags & IFF_CANTCHANGE) | - (ifr->ifr_flags &~ IFF_CANTCHANGE); + ifr->ifr_flags; if (ifp->if_ioctl) (void) (*ifp->if_ioctl)(ifp, cmd, data); getmicrotime(&ifp->if_lastchange); Index: net/if.h =================================================================== RCS file: /home/ncvs/src/sys/net/if.h,v retrieving revision 1.49 diff -u -r1.49 if.h --- if.h 1998/03/21 13:36:20 1.49 +++ if.h 1999/02/03 21:00:25 @@ -82,7 +82,7 @@ #define IFF_DEBUG 0x4 /* turn on debugging */ #define IFF_LOOPBACK 0x8 /* is a loopback net */ #define IFF_POINTOPOINT 0x10 /* interface is point-to-point link */ -/*#define IFF_NOTRAILERS 0x20 * obsolete: avoid use of trailers */ +#define IFF_SMART 0x20 /* smart interface, don't muck with flags */ #define IFF_RUNNING 0x40 /* resources allocated */ #define IFF_NOARP 0x80 /* no address resolution protocol */ #define IFF_PROMISC 0x100 /* receive all packets */ @@ -97,7 +97,7 @@ /* flags set internally only: */ #define IFF_CANTCHANGE \ - (IFF_BROADCAST|IFF_POINTOPOINT|IFF_RUNNING|IFF_OACTIVE|\ + (IFF_BROADCAST|IFF_POINTOPOINT|IFF_SMART|IFF_RUNNING|IFF_OACTIVE|\ IFF_SIMPLEX|IFF_MULTICAST|IFF_ALLMULTI) #define IFQ_MAXLEN 50 Index: net/if_sppp.h =================================================================== RCS file: /home/ncvs/src/sys/net/if_sppp.h,v retrieving revision 1.13 diff -u -r1.13 if_sppp.h --- if_sppp.h 1998/12/27 21:30:44 1.13 +++ if_sppp.h 1999/02/03 21:42:25 @@ -83,7 +83,8 @@ struct ifqueue pp_fastq; /* fast output queue */ struct ifqueue pp_cpq; /* PPP control protocol queue */ struct sppp *pp_next; /* next interface in keepalive list */ - u_int pp_flags; /* use Cisco protocol instead of PPP */ + u_short pp_mode; /* operating mode */ + u_short pp_flags; /* various bits */ u_short pp_alivecnt; /* keepalive packets counter */ u_short pp_loopcnt; /* loopback detection counter */ u_long pp_seq; /* local sequence number */ @@ -132,11 +133,13 @@ }; #define PP_KEEPALIVE 0x01 /* use keepalive protocol */ -#define PP_CISCO 0x02 /* use Cisco protocol instead of PPP */ - /* 0x04 was PP_TIMO */ #define PP_CALLIN 0x08 /* we are being called */ #define PP_NEEDAUTH 0x10 /* remote requested authentication */ +#define PPM_LEASED 0x00 +#define PPM_CISCO 0x01 +#define PPM_AUTO 0x02 +#define PPM_PASSIVE 0x03 #define PP_MTU 1500 /* default/minimal MRU */ #define PP_MAX_MRU 2048 /* maximal MRU we want to negotiate */ Index: net/if_spppsubr.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_spppsubr.c,v retrieving revision 1.52 diff -u -r1.52 if_spppsubr.c --- if_spppsubr.c 1998/12/27 21:30:44 1.52 +++ if_spppsubr.c 1999/02/03 22:50:49 @@ -134,6 +134,7 @@ #define IFF_PASSIVE IFF_LINK0 /* wait passively for connection */ #define IFF_AUTO IFF_LINK1 /* auto-dial on output */ +#define IFF_CISCO IFF_LINK2 /* cisco protocol */ #define PPP_ALLSTATIONS 0xff /* All-Stations broadcast address */ #define PPP_UI 0x03 /* Unnumbered Information */ @@ -466,7 +467,7 @@ case PPP_ALLSTATIONS: if (h->control != PPP_UI) goto invalid; - if (sp->pp_flags & PP_CISCO) { + if (sp->pp_mode == PPM_CISCO) { if (debug) log(LOG_DEBUG, SPP_FMT "PPP packet in Cisco mode " @@ -548,7 +549,7 @@ case CISCO_MULTICAST: case CISCO_UNICAST: /* Don't check the control field here (RFC 1547). */ - if (! (sp->pp_flags & PP_CISCO)) { + if (sp->pp_mode != PPM_CISCO) { if (debug) log(LOG_DEBUG, SPP_FMT "Cisco packet in PPP mode " @@ -711,7 +712,7 @@ * (albeit due to the implementation it's always enough) */ h = mtod (m, struct ppp_header*); - if (sp->pp_flags & PP_CISCO) { + if (sp->pp_mode == PPM_CISCO) { h->address = CISCO_UNICAST; /* unicast address */ h->control = 0; } else { @@ -722,7 +723,7 @@ switch (dst->sa_family) { #ifdef INET case AF_INET: /* Internet Protocol */ - if (sp->pp_flags & PP_CISCO) + if (sp->pp_mode == PPM_CISCO) h->protocol = htons (ETHERTYPE_IP); else { /* @@ -742,19 +743,19 @@ #endif #ifdef NS case AF_NS: /* Xerox NS Protocol */ - h->protocol = htons ((sp->pp_flags & PP_CISCO) ? + h->protocol = htons ((sp->pp_mode == PPM_CISCO) ? ETHERTYPE_NS : PPP_XNS); break; #endif #ifdef IPX case AF_IPX: /* Novell IPX Protocol */ - h->protocol = htons ((sp->pp_flags & PP_CISCO) ? + h->protocol = htons ((sp->pp_mode == PPM_CISCO) ? ETHERTYPE_IPX : PPP_IPX); break; #endif #ifdef ISO case AF_ISO: /* ISO OSI Protocol */ - if (sp->pp_flags & PP_CISCO) + if (sp->pp_mode == PPM_CISCO) goto nosupport; h->protocol = htons (PPP_ISO); break; @@ -806,7 +807,7 @@ spppq = sp; sp->pp_if.if_mtu = PP_MTU; - sp->pp_if.if_flags = IFF_POINTOPOINT | IFF_MULTICAST; + sp->pp_if.if_flags = IFF_POINTOPOINT | IFF_MULTICAST | IFF_SMART; sp->pp_if.if_type = IFT_PPP; sp->pp_if.if_output = sppp_output; #if 0 @@ -898,7 +899,7 @@ */ IF_DEQUEUE(&sp->pp_cpq, m); if (m == NULL && - (sppp_ncp_check(sp) || (sp->pp_flags & PP_CISCO) != 0)) { + (sppp_ncp_check(sp) || (sp->pp_mode == PPM_CISCO))) { IF_DEQUEUE(&sp->pp_fastq, m); if (m == NULL) IF_DEQUEUE (&sp->pp_if.if_snd, m); @@ -922,7 +923,7 @@ m = sp->pp_cpq.ifq_head; if (m == NULL && (sp->pp_phase == PHASE_NETWORK || - (sp->pp_flags & PP_CISCO) != 0)) + sp->pp_mode == PPM_CISCO)) if ((m = sp->pp_fastq.ifq_head) == NULL) m = sp->pp_if.if_snd.ifq_head; splx (s); @@ -937,7 +938,7 @@ { struct ifreq *ifr = (struct ifreq*) data; struct sppp *sp = (struct sppp*) ifp; - int s, rv, going_up, going_down, newmode; + int s, rv; s = splimp(); rv = 0; @@ -947,33 +948,56 @@ break; case SIOCSIFADDR: - if_up(ifp); - /* fall through... */ + break; case SIOCSIFFLAGS: - going_up = ifp->if_flags & IFF_UP && - (ifp->if_flags & IFF_RUNNING) == 0; - going_down = (ifp->if_flags & IFF_UP) == 0 && - ifp->if_flags & IFF_RUNNING; - newmode = ifp->if_flags & (IFF_AUTO | IFF_PASSIVE); - if (newmode == (IFF_AUTO | IFF_PASSIVE)) { - /* sanity */ - newmode = IFF_PASSIVE; - ifp->if_flags &= ~IFF_AUTO; - } - if (going_up || going_down) + printf("Flags %08x/%08x mode %d\n", + ifp->if_flags, ifr->ifr_flags, sp->pp_mode); + if (sp->pp_mode != PPM_CISCO) lcp.Close(sp); - if (going_up && newmode == 0) { - /* neither auto-dial nor passive */ - ifp->if_flags |= IFF_RUNNING; - if (!(sp->pp_flags & PP_CISCO)) - lcp.Open(sp); - } else if (going_down) { - sppp_flush(ifp); - ifp->if_flags &= ~IFF_RUNNING; + + ifp->if_flags &= ~(IFF_PASSIVE|IFF_AUTO|IFF_CISCO); + sp->pp_mode = PPM_LEASED; + if (ifr->ifr_flags & IFF_PASSIVE) { + sp->pp_mode = PPM_PASSIVE; + ifp->if_flags |= IFF_PASSIVE; + } else if (ifr->ifr_flags & IFF_AUTO) { + sp->pp_mode = PPM_AUTO; + ifp->if_flags |= IFF_AUTO; + } else if (ifr->ifr_flags & IFF_CISCO) { + sp->pp_mode = PPM_CISCO; + ifp->if_flags |= IFF_CISCO; } + printf("Flags %08x/%08x mode %d\n", + ifp->if_flags, ifr->ifr_flags, sp->pp_mode); + + if ((ifr->ifr_flags & IFF_UP) && (ifp->if_flags & IFF_UP)) { + if (sp->pp_mode == PPM_LEASED) + lcp.Open(sp); + } else if ((ifr->ifr_flags & IFF_UP) != + (ifp->if_flags & IFF_UP)) { + s = splimp(); + if (ifr->ifr_flags & IFF_UP) + if_route(ifp, IFF_UP, AF_UNSPEC); + else + if_unroute(ifp, IFF_UP, AF_UNSPEC); + splx(s); + if (!(ifr->ifr_flags & IFF_UP)) { + sppp_flush(ifp); + ifp->if_flags &= ~IFF_RUNNING; + } else if (sp->pp_mode == PPM_LEASED) { + lcp.Open(sp); + ifp->if_flags |= IFF_RUNNING; + } else if (sp->pp_mode == PPM_CISCO) { + ifp->if_flags |= IFF_RUNNING; + } + } + ifp->if_flags &= ~(IFF_UP|IFF_DEBUG); + ifp->if_flags |= ifr->ifr_flags & (IFF_UP|IFF_DEBUG); + printf("Flags %08x/%08x mode %d\n", + ifp->if_flags, ifr->ifr_flags, sp->pp_mode); break; #ifdef SIOCSIFMTU @@ -1511,13 +1535,12 @@ if (ntohl (*(long*)(h+1)) == sp->lcp.magic) { /* Line loopback mode detected. */ printf(SPP_FMT "loopback\n", SPP_ARGS(ifp)); - if_down (ifp); - sppp_qflush (&sp->pp_cpq); - - /* Shut down the PPP link. */ - /* XXX */ - lcp.Down(sp); - lcp.Up(sp); + if (sp->pp_mode == PPM_LEASED) { + lcp.Down(sp); + lcp.Up(sp); + } else if (sp->pp_mode != PPM_CISCO) { + lcp.Close(sp); + } break; } *(long*)(h+1) = htonl (sp->lcp.magic); @@ -1822,23 +1845,18 @@ { STDDCL; + log(LOG_INFO, SPP_FMT "Up event\n", SPP_ARGS(ifp)); /* * If this interface is passive or dial-on-demand, and we are * still in Initial state, it means we've got an incoming * call. Activate the interface. */ - if ((ifp->if_flags & (IFF_AUTO | IFF_PASSIVE)) != 0) { - if (debug) - log(LOG_DEBUG, - SPP_FMT "Up event", SPP_ARGS(ifp)); + if (sp->pp_mode == PPM_AUTO || sp->pp_mode == PPM_PASSIVE) { ifp->if_flags |= IFF_RUNNING; if (sp->state[IDX_LCP] == STATE_INITIAL) { - if (debug) - addlog("(incoming call)\n"); sp->pp_flags |= PP_CALLIN; lcp.Open(sp); - } else if (debug) - addlog("\n"); + } } sppp_up_event(&lcp, sp); @@ -1849,30 +1867,14 @@ { STDDCL; + log(LOG_INFO, SPP_FMT "Down event\n", SPP_ARGS(ifp)); + sppp_down_event(&lcp, sp); - /* - * If this is neither a dial-on-demand nor a passive - * interface, simulate an ``ifconfig down'' action, so the - * administrator can force a redial by another ``ifconfig - * up''. XXX For leased line operation, should we immediately - * try to reopen the connection here? - */ - if ((ifp->if_flags & (IFF_AUTO | IFF_PASSIVE)) == 0) { - log(LOG_INFO, - SPP_FMT "Down event, taking interface down.\n", - SPP_ARGS(ifp)); - if_down(ifp); - } else { - if (debug) - log(LOG_DEBUG, - SPP_FMT "Down event (carrier loss)\n", - SPP_ARGS(ifp)); - } - sp->pp_flags &= ~PP_CALLIN; - if (sp->state[IDX_LCP] != STATE_INITIAL) + if (sp->pp_mode == PPM_AUTO || sp->pp_mode == PPM_PASSIVE) { + sp->pp_flags &= ~PP_CALLIN; lcp.Close(sp); - ifp->if_flags &= ~IFF_RUNNING; + } } static void @@ -1892,7 +1894,14 @@ static void sppp_lcp_close(struct sppp *sp) { + STDDCL; + sppp_close_event(&lcp, sp); + if (sp->pp_mode == PPM_AUTO || sp->pp_mode == PPM_PASSIVE) { + if_down(ifp); + ifp->if_flags &= ~IFF_RUNNING; + sppp_qflush (&sp->pp_cpq); + } } static void @@ -2018,32 +2027,17 @@ } /* * Local and remote magics equal -- loopback? - */ - if (sp->pp_loopcnt >= MAXALIVECNT*5) { - printf (SPP_FMT "loopback\n", - SPP_ARGS(ifp)); - sp->pp_loopcnt = 0; - if (ifp->if_flags & IFF_UP) { - if_down(ifp); - sppp_qflush(&sp->pp_cpq); - /* XXX ? */ - lcp.Down(sp); - lcp.Up(sp); - } - } else if (debug) - addlog("[glitch] "); - ++sp->pp_loopcnt; - /* - * We negate our magic here, and NAK it. If - * we see it later in an NAK packet, we - * suggest a new one. + * Choose new magic and ignore this packet... */ - nmagic = ~sp->lcp.magic; - /* Gonna NAK it. */ - p[2] = nmagic >> 24; - p[3] = nmagic >> 16; - p[4] = nmagic >> 8; - p[5] = nmagic; + if (debug) + addlog("loopback ? \n"); +#if defined(__FreeBSD__) && __FreeBSD__ >= 3 + sp->lcp.magic = random(); +#else + sp->lcp.magic = time.tv_sec + time.tv_usec; +#endif + free (buf, M_TEMP); + return (0); break; case LCP_OPT_ASYNC_MAP: @@ -2221,7 +2215,7 @@ */ if (magic == ~sp->lcp.magic) { if (debug) - addlog("magic glitch "); + addlog("glitch "); #if defined(__FreeBSD__) && __FreeBSD__ >= 3 sp->lcp.magic = random(); #else @@ -3813,26 +3807,23 @@ continue; /* No keepalive in PPP mode if LCP not opened yet. */ - if (! (sp->pp_flags & PP_CISCO) && + if (sp->pp_mode != PPM_CISCO && sp->pp_phase < PHASE_AUTHENTICATE) continue; if (sp->pp_alivecnt == MAXALIVECNT) { /* No keepalive packets got. Stop the interface. */ - printf (SPP_FMT "down\n", SPP_ARGS(ifp)); - if_down (ifp); - sppp_qflush (&sp->pp_cpq); - if (! (sp->pp_flags & PP_CISCO)) { - /* XXX */ - /* Shut down the PPP link. */ + printf (SPP_FMT "no keepalives\n", SPP_ARGS(ifp)); + if (sp->pp_mode == PPM_LEASED) { lcp.Down(sp); - /* Initiate negotiation. XXX */ lcp.Up(sp); + } else if (sp->pp_mode != PPM_CISCO) { + lcp.Close(sp); } } if (sp->pp_alivecnt <= MAXALIVECNT) ++sp->pp_alivecnt; - if (sp->pp_flags & PP_CISCO) + if (sp->pp_mode == PPM_CISCO) sppp_cisco_send (sp, CISCO_KEEPALIVE_REQ, ++sp->pp_seq, sp->pp_rseq); else if (sp->pp_phase >= PHASE_AUTHENTICATE) { -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Thu Feb 4 17:18:24 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA26572 for freebsd-isdn-outgoing; Thu, 4 Feb 1999 17:18:24 -0800 (PST) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from emmi.physik.TU-Berlin.DE (emmi.physik.TU-Berlin.DE [130.149.160.103]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA26557 for ; Thu, 4 Feb 1999 17:18:16 -0800 (PST) (envelope-from jan@emmi.physik.TU-Berlin.DE) Received: from rosa.physik.TU-Berlin.DE (rosa.physik.TU-Berlin.DE [130.149.160.209]) by emmi.physik.TU-Berlin.DE (8.9.1/8.9.1) with ESMTP id CAA22733 for ; Fri, 5 Feb 1999 02:18:08 +0100 (CET) (envelope-from jan@emmi.physik.TU-Berlin.DE) From: Jan Riedinger Received: (from jan@localhost) by rosa.physik.TU-Berlin.DE (8.9.1/8.9.1) id CAA01982 for freebsd-isdn@freebsd.org; Fri, 5 Feb 1999 02:18:08 +0100 (CET) (envelope-from jan@mail.physik.TU-Berlin.DE) Message-Id: <199902050118.CAA01982@rosa.physik.TU-Berlin.DE> Subject: address negotiation fails To: freebsd-isdn@FreeBSD.ORG Date: Fri, 5 Feb 1999 02:18:08 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The address negotitiation doesn't work for me with ppp. My configuration of isp2: isp2: flags=2815 mtu 1500 inet 0.0.0.0 --> 0.0.0.1 netmask 0xff000000 If I initiate a call to my ISP (TU Berlin :-) ) I get the following debug output: Feb 5 01:41:39 brahms /kernel: isp2: lcp output Feb 5 01:41:39 brahms /kernel: isp2: lcp input(req-sent): Feb 5 01:41:39 brahms /kernel: isp2: lcp parse opts: auth-proto magic 0x11 [rej] 0x12 [rej] 0x13 [rej] send conf-rej Feb 5 01:41:39 brahms /kernel: isp2: lcp output Feb 5 01:41:39 brahms /kernel: isp2: lcp input(req-sent): Feb 5 01:41:39 brahms /kernel: isp2: lcp parse opts: auth-proto magic Feb 5 01:41:39 brahms /kernel: isp2: lcp parse opt values: auth-proto magic 0x8f1796dd send conf-ack Feb 5 01:41:39 brahms /kernel: isp2: lcp output Feb 5 01:41:40 brahms /kernel: isp2: lcp TO(ack-sent) rst_counter = 10 Feb 5 01:41:40 brahms /kernel: isp2: lcp output Feb 5 01:41:40 brahms /kernel: isp2: lcp input(ack-sent): Feb 5 01:41:40 brahms /kernel: isp2: lcp tlu Feb 5 01:41:40 brahms /kernel: isp2: phase authenticate Feb 5 01:41:40 brahms /kernel: isp2: pap output Feb 5 01:41:40 brahms /kernel: isp2: pap success Feb 5 01:41:40 brahms /kernel: isp2: phase network Feb 5 01:41:40 brahms /kernel: isp2: ipcp open(initial) Feb 5 01:41:40 brahms /kernel: isp2: ipcp up(starting) Feb 5 01:41:40 brahms /kernel: isp2: ipcp output Feb 5 01:41:40 brahms /kernel: isp2: ipcp input(req-sent): Feb 5 01:41:41 brahms /kernel: isp2: ipcp parse opts: compression [rej] address send conf-rej Feb 5 01:41:41 brahms /kernel: isp2: ipcp output Feb 5 01:41:41 brahms /kernel: isp2: ipcp input(req-sent): Feb 5 01:41:41 brahms /kernel: isp2: ipcp nak opts: address [wantaddr 130.149.145.38] [agree] Feb 5 01:41:41 brahms /kernel: isp2: ipcp output Feb 5 01:41:41 brahms /kernel: isp2: lcp output Feb 5 01:41:41 brahms /kernel: isp2: invalid input protocol ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^? What's going wrong at this state? Feb 5 01:41:41 brahms /kernel: isp2: ipcp input(req-sent): Feb 5 01:41:41 brahms /kernel: isp2: ipcp parse opts: address Feb 5 01:41:41 brahms /kernel: isp2: ipcp parse opt values: address 0.0.0.1 [ack] send conf-ack Feb 5 01:41:41 brahms /kernel: isp2: ipcp output Feb 5 01:41:41 brahms /kernel: isp2: ipcp input(ack-sent): Feb 5 01:41:41 brahms /kernel: isp2: ipcp tlu During the call I get isp2: flags=2855 mtu 1500 inet 130.149.145.38 --> 0.0.0.1 netmask 0xff000000 The IP address negotiation for my ISP failed! His address seems not to be transmitted. If I set a wrong address for his side, e. g. isp2: flags=2815 mtu 1500 inet 0.0.0.0 --> 10.0.0.1 netmask 0xff000000 the other side transmits the requested (from call to call changing) address: Feb 5 01:58:31 brahms /kernel: isp2: Up event Feb 5 01:58:31 brahms /kernel: isp2: lcp up(starting) Feb 5 01:58:31 brahms /kernel: isp2: lcp output Feb 5 01:58:31 brahms /kernel: isp2: lcp input(req-sent): Feb 5 01:58:31 brahms /kernel: isp2: lcp parse opts: auth-proto magic 0x11 [rej] 0x12 [rej] 0x13 [rej] send conf-rej Feb 5 01:58:31 brahms /kernel: isp2: lcp output Feb 5 01:58:31 brahms /kernel: isp2: lcp input(req-sent): Feb 5 01:58:31 brahms /kernel: isp2: lcp parse opts: auth-proto magic Feb 5 01:58:31 brahms /kernel: isp2: lcp parse opt values: auth-proto magic 0x19964efb send conf-ack Feb 5 01:58:31 brahms /kernel: isp2: lcp output Feb 5 01:58:32 brahms /kernel: isp2: lcp TO(ack-sent) rst_counter = 10 Feb 5 01:58:32 brahms /kernel: isp2: lcp output Feb 5 01:58:32 brahms /kernel: isp2: lcp input(ack-sent): Feb 5 01:58:32 brahms /kernel: isp2: lcp tlu Feb 5 01:58:32 brahms /kernel: isp2: phase authenticate Feb 5 01:58:32 brahms /kernel: isp2: pap output Feb 5 01:58:32 brahms /kernel: isp2: pap success Feb 5 01:58:32 brahms /kernel: isp2: phase network Feb 5 01:58:32 brahms /kernel: isp2: ipcp open(initial) Feb 5 01:58:32 brahms /kernel: isp2: ipcp up(starting) Feb 5 01:58:32 brahms /kernel: isp2: ipcp output Feb 5 01:58:32 brahms /kernel: isp2: ipcp input(req-sent): Feb 5 01:58:32 brahms /kernel: isp2: ipcp parse opts: compression [rej] address send conf-rej Feb 5 01:58:32 brahms /kernel: isp2: ipcp output Feb 5 01:58:32 brahms /kernel: isp2: ipcp input(req-sent): Feb 5 01:58:32 brahms /kernel: isp2: ipcp nak opts: address [wantaddr 130.149.145.53] [agree] Feb 5 01:58:32 brahms /kernel: isp2: ipcp output Feb 5 01:58:32 brahms /kernel: isp2: lcp output Feb 5 01:58:32 brahms /kernel: isp2: invalid input protocol Feb 5 01:58:32 brahms /kernel: isp2: ipcp input(req-sent): Feb 5 01:58:32 brahms /kernel: isp2: ipcp parse opts: address Feb 5 01:58:32 brahms /kernel: isp2: ipcp parse opt values: address 130.149.145.2 [not agreed] send conf-nak Feb 5 01:58:32 brahms /kernel: isp2: ipcp output Feb 5 01:58:32 brahms /kernel: isp2: ipcp input(req-sent): Feb 5 01:58:32 brahms /kernel: isp2: ipcp input(ack-rcvd): Feb 5 01:58:32 brahms /kernel: isp2: ipcp parse opts: address Feb 5 01:58:32 brahms /kernel: isp2: ipcp parse opt values: address 130.149.145.2 [not agreed] send conf-nak Feb 5 01:58:32 brahms /kernel: isp2: ipcp output Feb 5 01:58:32 brahms /kernel: isp2: ipcp input(ack-rcvd): Feb 5 01:58:32 brahms /kernel: isp2: ipcp parse opts: address . .repeating lines deletetd . Feb 5 01:58:33 brahms /kernel: isp2: ipcp parse opts: address Feb 5 01:58:33 brahms /kernel: isp2: ipcp parse opt values: address 130.149.145.2 [not agreed] send conf-nak Feb 5 01:58:33 brahms /kernel: isp2: ipcp output Feb 5 01:58:33 brahms /kernel: isp2: ipcp input(ack-rcvd): Feb 5 01:58:33 brahms /kernel: isp2: ipcp parse opts: address Feb 5 01:58:33 brahms /kernel: isp2: ipcp parse opt values: address 130.149.145.2 [not agreed] send conf-nak Feb 5 01:58:33 brahms /kernel: isp2: ipcp output Feb 5 01:58:33 brahms /kernel: isp2: ipcp input(ack-rcvd): Feb 5 01:58:33 brahms /kernel: isp2: ipcp send terminate-ack Feb 5 01:58:33 brahms /kernel: isp2: ipcp output Feb 5 01:58:33 brahms /kernel: isp2: lcp input(opened): Feb 5 01:58:33 brahms /kernel: isp2: phase terminate Feb 5 01:58:33 brahms /kernel: isp2: ipcp down(req-sent) Feb 5 01:58:33 brahms /kernel: isp2: ipcp close(starting) Feb 5 01:58:33 brahms /kernel: isp2: lcp send terminate-ack Feb 5 01:58:33 brahms /kernel: isp2: lcp output Feb 5 01:58:33 brahms /kernel: isp2: lcp down(stopping) Feb 5 01:58:33 brahms /kernel: isp2: Down event (carrier loss) Feb 5 01:58:33 brahms /kernel: isp2: lcp close(starting) Feb 5 01:58:33 brahms /kernel: isp2: phase dead What do I have to change to get the address negotiation working? Thank you very much in advance Jan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Fri Feb 5 01:57:10 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA23088 for freebsd-isdn-outgoing; Fri, 5 Feb 1999 01:57:10 -0800 (PST) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from ts1.schiele-ct.de (ts1.schiele-ct.de [193.141.27.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA23079 for ; Fri, 5 Feb 1999 01:57:08 -0800 (PST) (envelope-from bk@schiele-ct.de) Received: from schiele-ct.de (wizard.schiele-ct.de [193.141.27.36]) by ts1.schiele-ct.de (8.8.8/8.8.8) with ESMTP id KAA09759 for ; Fri, 5 Feb 1999 10:49:16 +0100 (CET) (envelope-from bk@schiele-ct.de) Message-ID: <36BAC06F.D6A7644A@schiele-ct.de> Date: Fri, 05 Feb 1999 10:57:03 +0100 From: Bernd =?iso-8859-1?Q?K=F6cke?= Organization: SCT Schiele Computertechnik X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: de MIME-Version: 1.0 To: freebsd-isdn@FreeBSD.ORG Subject: Problem with ELSA Quickstep 3000 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I've got a little problem with my ELSA Quickstep 3000. My system runs with FreeBSD 3.0-Release and i4b 0.7-beta. The Quickstepo 3000 is an ISA-PnP-Card with Modem Chipset. I read that there exists a driver for Linux and that it is the same as for the Quickstep 1000. So I started to compile a new kernel with the Quickstep 1000-Driver from the i4b-Package. But when I entered 'make', I got the following errormessage: ../../i4b/layer1/i4b_elsa_qs1i.c: In function 'isic_probe_Eqs1pi': ../../i4b/layer1/i4b_elsa_qs1i.c:404: structure has no member named 'sc_clearirq' The problem may be due to the fact that I have a Qickstep 3000 and not a 1000, but I think the kernel should compile and may show an error-message when I reboot the system. But I'm not very familar with FreeBSD. I started to work with UNIX and the first thing I need was to establish a network connection via ISDN. If anybody could tell me what I am doing wrong, I would be very grateful. Below I attached my kernel-config. Thanks, Bernd Koecke -- Bernd Koecke, eMail: bk@schiele-ct.de # # UNICORN -- Machine with AHx family disk # # For more information read the handbook part System Administration -> # Configuring the FreeBSD Kernel -> The Configuration File. # The handbook is available in /usr/share/doc/handbook or online as # latest version from the FreeBSD World Wide Web server # # # An exhaustive list of options and more detailed explanations of the # device lines is present in the ./LINT configuration file. If you are # in doubt as to the purpose or necessity of a line, check first in LINT. # machine "i386" cpu "I586_CPU" ident UNICORN maxusers 32 options "CPU_FASTER_5X86_FPU" options INET #InterNETworking options FFS #Berkeley Fast Filesystem options FFS_ROOT #FFS usable as root device [keep this!] options MFS #Memory Filesystem options MFS_ROOT #MFS usable as root device, "MFS" req'ed options NFS #Network Filesystem options NFS_ROOT #NFS usable as root device, "NFS" req'ed options MSDOSFS #MSDOS Filesystem options "CD9660" #ISO 9660 Filesystem options "CD9660_ROOT" #CD-ROM usable as root. "CD9660" req'ed options PROCFS #Process filesystem options "COMPAT_43" #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=15000 #Be pessimistic about Joe SCSI device options UCONSOLE #Allow users to grab the console options FAILSAFE #Be conservative options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options "MD5" # config kernel root on wd0 config kernel root on da0 controller isa0 controller pci0 controller pnp0 controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr disk fd0 at fdc0 drive 0 options "CMD640" # work around CMD640 chip deficiency controller ahc0 controller scbus0 device da0 device sa0 device pass0 device cd0 #Only need one of these, the code dynamically grows # syscons is the default console driver, resembling an SCO console device sc0 at isa? port "IO_KBD" conflicts tty irq 1 vector scintr # Enable this and PCVT_FREEBSD for pcvt vt220 compatible console driver #device vt0 at isa? port "IO_KBD" conflicts tty irq 1 vector pcrint #options XSERVER # support for X server #options FAT_CURSOR # start with block cursor # If you have a ThinkPAD, uncomment this along with the rest of the PCVT lines #options PCVT_SCANSET=2 # IBM keyboards are non-std device npx0 at isa? port "IO_NPX" irq 13 vector npxintr # ISDN options "ELSA_QS1ISA" device isic0 at isa? port ? net irq ? vector isicintr # ISDN Protocol Stack pseudo-device "i4bq921" pseudo-device "i4bq931" pseudo-device "i4b" pseudo-device "i4btrc" 4 pseudo-device "i4bctl" pseudo-device "i4brbch" 4 pseudo-device "i4btel" 2 pseudo-device "i4bipr" 4 options IPR_VJ pseudo-device "i4bisppp" 4 pseudo-device sppp 4 # ISDN End device sio0 at isa? port "IO_COM1" flags 0x10 tty irq 4 vector siointr device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr device lpt0 at isa? port? tty irq 7 vector lptintr pseudo-device loop pseudo-device ether pseudo-device sl 1 pseudo-device ppp 1 pseudo-device tun 1 pseudo-device pty 16 pseudo-device gzip # Exec gzipped a.out's # KTRACE enables the system-call tracing facility ktrace(2). # This adds 4 KB bloat to your kernel, and slightly increases # the costs of each syscall. options KTRACE #kernel tracing # This provides support for System V shared memory. # options SYSVSHM To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Fri Feb 5 02:19:17 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA25533 for freebsd-isdn-outgoing; Fri, 5 Feb 1999 02:19:17 -0800 (PST) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from falbala.informatik.uni-kiel.de (falbala.informatik.uni-kiel.de [134.245.252.14]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA25526 for ; Fri, 5 Feb 1999 02:19:14 -0800 (PST) (envelope-from mfi@techfak.uni-kiel.de) Received: from hope.techfak.uni-kiel.de (hope.techfak.uni-kiel.de [134.245.244.140]) by falbala.informatik.uni-kiel.de (8.9.1/8.9.1) with ESMTP id LAA17471 for ; Fri, 5 Feb 1999 11:19:47 +0100 (MET) Received: from taipan.techfak.uni-kiel.de (taipan [134.245.244.156]) by hope.techfak.uni-kiel.de (8.8.8/8.8.8) with SMTP id LAA08429 for ; Fri, 5 Feb 1999 11:18:50 +0100 (MET) Received: by taipan.techfak.uni-kiel.de (SMI-8.6/client-1.6-SunOS5) id LAA22901; Fri, 5 Feb 1999 11:18:50 +0100 Message-ID: <19990205111849.56549@taipan.techfak.uni-kiel.de> Date: Fri, 5 Feb 1999 11:18:49 +0100 From: Michael Firnau To: freebsd-isdn@FreeBSD.ORG Subject: spppcontrol dumps core ... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.79 Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, spppcontrol dumps core because the 'buf'-array is a bit too small: const char * authflags(u_short flags) { static char buf[10]; <--- should be 30 ? buf[0] = '\0'; if (flags & AUTHFLAG_NOCALLOUT) strcat(buf, " callin"); if (flags & AUTHFLAG_NORECHALLENGE) strcat(buf, " norechallenge"); return buf; Mike +------------------------------------------------------------------+ | Michael Firnau | Technische Fakultaet der CAU zu Kiel | | | Rechnerbetriebsgruppe Kaiserstr.2 | | Phone: +49 431 77572 107 | D-24143 Kiel Germany | | Fax: +49 431 77572 103 | http://www.techfak.uni-kiel.de/ | +------------------------------------------------------------------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Sat Feb 6 10:24:36 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA06992 for freebsd-isdn-outgoing; Sat, 6 Feb 1999 10:24:36 -0800 (PST) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from alvman.RoBIN.de (alvman.robin.de [193.174.7.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA06982 for ; Sat, 6 Feb 1999 10:24:31 -0800 (PST) (envelope-from ah@alvman.RoBIN.de) Received: from localhost (ah@localhost) by alvman.RoBIN.de (8.9.2/8.8.8) with ESMTP id TAA00467 for ; Sat, 6 Feb 1999 19:24:10 +0100 (CET) (envelope-from ah@alvman.RoBIN.de) Date: Sat, 6 Feb 1999 19:24:10 +0100 (CET) From: Andreas Haakh To: FreeBSD ISDN Mailinglist In-Reply-To: <19990205111849.56549@taipan.techfak.uni-kiel.de> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-785719567-918325450=:455" Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-785719567-918325450=:455 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Hello, I'm having trouble to configure device /dev/i4btel0 under FreeBSD 3.0-STABLE root@alvman:~$ isdntelctl -g isdntelctl: cannot open /dev/i4btel0: Input/output error root@alvman:~$ ls -l /dev/i4btel0 crw------- 1 root wheel 56, 0 Feb 6 12:09 /dev/i4btel0 The kernel is configured with all necessary devices. i4b works fine. Dials out as requested and answers incoming calls. I just can not configure this device. Any clues?? Andreas -- Andreas Haakh * Mollerstraße 7 * 64289 Darmstadt * ah@alvman.RoBIN.de --0-785719567-918325450=:455 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="dmsg.lst" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Output of dmesg Content-Disposition: attachment; filename="dmsg.lst" Q29weXJpZ2h0IChjKSAxOTkyLTE5OTkgRnJlZUJTRCBJbmMuDQpDb3B5cmln aHQgKGMpIDE5ODIsIDE5ODYsIDE5ODksIDE5OTEsIDE5OTMNCglUaGUgUmVn ZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLg0KRnJlZUJTRCAzLjAtU1RBQkxFICM0OiBTYXQgRmVi ICA2IDEzOjEyOjI3IENFVCAxOTk5DQogICAgcm9vdEBhbHZtYW4uUm9CSU4u ZGU6L3Vzci9zcmMvc3lzL2NvbXBpbGUvQUxWTUFODQpUaW1lY291bnRlciAi aTgyNTQiICBmcmVxdWVuY3kgMTE5MzE4MiBIeg0KQ1BVOiBQZW50aXVtL1A1 NUMgKDE2Ny4wNS1NSHogNTg2LWNsYXNzIENQVSkNCiAgT3JpZ2luID0gIkdl bnVpbmVJbnRlbCIgIElkID0gMHg1NDMgIFN0ZXBwaW5nPTMNCiAgRmVhdHVy ZXM9MHg4MDAxYmY8RlBVLFZNRSxERSxQU0UsVFNDLE1TUixNQ0UsQ1g4LE1N WD4NCnJlYWwgbWVtb3J5ICA9IDY3MTA4ODY0ICg2NTUzNksgYnl0ZXMpDQph dmFpbCBtZW1vcnkgPSA2MjMyNDczNiAoNjA4NjRLIGJ5dGVzKQ0KUHJlbG9h ZGVkIGVsZiBrZXJuZWwgImtlcm5lbCIgYXQgMHhmMDJkMzAwMC4NClByb2Jp bmcgZm9yIGRldmljZXMgb24gUENJIGJ1cyAwOg0KY2hpcDA6IDxJbnRlbCA4 MjQzOVRYIFN5c3RlbSBDb250cm9sbGVyIChNVFhDKT4gcmV2IDB4MDEgb24g cGNpMC4wLjANCmNoaXAxOiA8SW50ZWwgODIzNzFBQiBQQ0kgdG8gSVNBIGJy aWRnZT4gcmV2IDB4MDEgb24gcGNpMC43LjANCmNoaXAyOiA8SW50ZWwgODIz NzFBQiBQb3dlciBtYW5hZ2VtZW50IGNvbnRyb2xsZXI+IHJldiAweDAxIG9u IHBjaTAuNy4zDQphaGMwOiA8QWRhcHRlYyBhaWM3ODk1IFVsdHJhIFNDU0kg YWRhcHRlcj4gcmV2IDB4MDMgaW50IGEgaXJxIDExIG9uIHBjaTAuMTMuMA0K YWhjMDogYWljNzg5NSBXaWRlIENoYW5uZWwgQSwgU0NTSSBJZD03LCAyNTUg U0NCcw0KYWhjMTogPEFkYXB0ZWMgYWljNzg5NSBVbHRyYSBTQ1NJIGFkYXB0 ZXI+IHJldiAweDAzIGludCBiIGlycSAxMiBvbiBwY2kwLjEzLjENCmFoYzE6 IGFpYzc4OTUgV2lkZSBDaGFubmVsIEIsIFNDU0kgSWQ9NywgMjU1IFNDQnMN ClByb2JpbmcgZm9yIGRldmljZXMgb24gdGhlIElTQSBidXM6DQpzYzAgb24g aXNhDQpzYzA6IFZHQSBjb2xvciA8MTYgdmlydHVhbCBjb25zb2xlcywgZmxh Z3M9MHgwPg0KZWQwIGF0IDB4MzAwLTB4MzFmIGlycSAxMCBtYWRkciAweGQw MDAwIG1zaXplIDE2Mzg0IG9uIGlzYQ0KZWQwOiBhZGRyZXNzIDAwOjAwOmMw OjNiOmI5OmE3LCB0eXBlIFNNQzgyMTYvU01DODIxNkMgKDE2IGJpdCkgDQph dGtiZGMwIGF0IDB4NjAtMHg2ZiBvbiBtb3RoZXJib2FyZA0KYXRrYmQwIGly cSAxIG9uIGlzYQ0KcHNtMCBub3QgZm91bmQNCnNpbzAgYXQgMHgzZjgtMHgz ZmYgaXJxIDQgZmxhZ3MgMHgxMCBvbiBpc2ENCnNpbzA6IHR5cGUgMTY1NTBB DQpzaW8xIGF0IDB4MmY4LTB4MmZmIGlycSAzIG9uIGlzYQ0Kc2lvMTogdHlw ZSAxNjU1MEENCmxwdDAgYXQgMHgzNzgtMHgzN2YgaXJxIDcgb24gaXNhDQps cHQwOiBJbnRlcnJ1cHQtZHJpdmVuIHBvcnQNCmxwMDogVENQL0lQIGNhcGFi bGUgaW50ZXJmYWNlDQpmZGMwIGF0IDB4M2YwLTB4M2Y3IGlycSA2IGRycSAy IG9uIGlzYQ0KZmRjMDogRklGTyBlbmFibGVkLCA4IGJ5dGVzIHRocmVzaG9s ZA0KZmQwOiAxLjQ0TUIgMy41aW4NCmlzaWMwIGF0IDB4ZDgwIGlycSA5IGZs YWdzIDB4MyBvbiBpc2ENCmlzaWMwOiBUZWxlcyBTMC8xNi4zDQppc2ljMDog SVNBQyAyMDg1IFZlcnNpb24gQTEvQTIgb3IgMjA4Ni8yMTg2IFZlcnNpb24g MS4xIChJT00tMikgKEFkZHI9MHg5NjApDQppc2ljMDogSFNDWCA4MjUyNSBv ciAyMTUyNSBWZXJzaW9uIDIuMSAoQWRkckE9MHgxNjAsIEFkZHJCPTB4NTYw KQ0KdmdhMCBhdCAweDNiMC0weDNkZiBtYWRkciAweGEwMDAwIG1zaXplIDEz MTA3MiBvbiBpc2ENCm5weDAgb24gbW90aGVyYm9hcmQNCm5weDA6IElOVCAx NiBpbnRlcmZhY2UNCkludGVsIFBlbnRpdW0gZGV0ZWN0ZWQsIGluc3RhbGxp bmcgd29ya2Fyb3VuZCBmb3IgRjAwRiBidWcNCmk0YjogSVNETiBjYWxsIGNv bnRyb2wgZGV2aWNlIGF0dGFjaGVkDQppNGJpc3BwcDogNCBJU0ROIFN5bmNQ UFAgZGV2aWNlKHMpIGF0dGFjaGVkDQppNGJjdGw6IElTRE4gc3lzdGVtIGNv bnRyb2wgcG9ydCBhdHRhY2hlZA0KaTRiaXByOiA0IElQIG92ZXIgcmF3IEhE TEMgSVNETiBkZXZpY2UocykgYXR0YWNoZWQgKFZKIGhlYWRlciBjb21wcmVz c2lvbikNCmk0YnRlbDogMiBJU0ROIHRlbGVwaG9ueSBpbnRlcmZhY2UgZGV2 aWNlKHMpIGF0dGFjaGVkDQppNGJyYmNoOiA0IHJhdyBCIGNoYW5uZWwgYWNj ZXNzIGRldmljZShzKSBhdHRhY2hlZA0KaTRidHJjOiA0IElTRE4gdHJhY2Ug ZGV2aWNlKHMpIGF0dGFjaGVkDQpXYWl0aW5nIDEwIHNlY29uZHMgZm9yIFND U0kgZGV2aWNlcyB0byBzZXR0bGUNCmNoYW5naW5nIHJvb3QgZGV2aWNlIHRv IGRhMHMxYQ0KZGEwIGF0IGFoYzAgYnVzIDAgdGFyZ2V0IDAgbHVuIDANCmRh MDogPElCTSBEUEVTLTMxMDgwIFMzMVE+IEZpeGVkIERpcmVjdCBBY2Nlc3Mg U0NTSS0yIGRldmljZSANCmRhMDogMTAuME1CL3MgdHJhbnNmZXJzICgxMC4w TUh6LCBvZmZzZXQgMTUpLCBUYWdnZWQgUXVldWVpbmcgRW5hYmxlZA0KZGEw OiAxMDM0TUIgKDIxMTgxNDQgNTEyIGJ5dGUgc2VjdG9yczogMjU1SCA2M1Mv VCAxMzFDKQ0KZGExIGF0IGFoYzAgYnVzIDAgdGFyZ2V0IDEgbHVuIDANCmRh MTogPElCTSBEQ0FTLTM0MzMwIFM2NUE+IEZpeGVkIERpcmVjdCBBY2Nlc3Mg U0NTSS0yIGRldmljZSANCmRhMTogMTAuME1CL3MgdHJhbnNmZXJzICgxMC4w TUh6LCBvZmZzZXQgMTUpLCBUYWdnZWQgUXVldWVpbmcgRW5hYmxlZA0KZGEx OiA0MTM0TUIgKDg0NjcyMDAgNTEyIGJ5dGUgc2VjdG9yczogMjU1SCA2M1Mv VCA1MjdDKQ0KZGEyIGF0IGFoYzAgYnVzIDAgdGFyZ2V0IDUgbHVuIDANCmRh MjogPElPTUVHQSBaSVAgMTAwIEouMDM+IFJlbW92YWJsZSBEaXJlY3QgQWNj ZXNzIFNDU0ktMiBkZXZpY2UgDQpkYTI6IDMuMzAwTUIvcyB0cmFuc2ZlcnMN CmRhMjogOTZNQiAoMTk2NjA4IDUxMiBieXRlIHNlY3RvcnM6IDY0SCAzMlMv VCA5NkMpDQpJUCBwYWNrZXQgZmlsdGVyaW5nIGluaXRpYWxpemVkLCBkaXZl cnQgZGlzYWJsZWQsIHJ1bGUtYmFzZWQgZm9yd2FyZGluZyBkaXNhYmxlZCwg bG9nZ2luZyBkaXNhYmxlZA0KY2QwIGF0IGFoYzAgYnVzIDAgdGFyZ2V0IDYg bHVuIDANCmNkMDogPFRPU0hJQkEgQ0QtUk9NIFhNLTUzMDFUQSAwOTI1PiBS ZW1vdmFibGUgQ0QtUk9NIFNDU0ktMiBkZXZpY2UgDQpjZDA6IDQuMjM3TUIv cyB0cmFuc2ZlcnMgKDQuMjM3TUh6LCBvZmZzZXQgMTUpDQpjZDA6IGNkIHBy ZXNlbnQgWzEyNjE2MSB4IDIwNDggYnl0ZSByZWNvcmRzXQ0K --0-785719567-918325450=:455 Content-Type: APPLICATION/octet-stream; name="kernel.gz" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Kernel configuration Content-Disposition: attachment; filename="kernel.gz" H4sIAFqGvDYAA6Va63PbNhL/LP0VqNy5OB3rQUlxncylOVmSE9V6VZSddDp3 CkRCFsYkwRKgZWXuj79dgBIfku2mpw8JCewLi8Xub0GflE9IZ3g76oxJtUo+ soBF3CE+ddY8YKR8AtNXIiK+iBjhwUpEPlVcBCRi1CVqzciaBu5SiHsS0kgR eysV80nH9XnApYoMcfUXkES6IljxuzjiwZ3mvIoYu7R75JpFAfOQaA6jOyrD ecU9VkPmeVYVl4Q+UO7RpYdWkXoso7pc04jVXeHU93RguAg8XAiVIMOjiklF HlgkUfYqEn7OkM8i8lzymbuMfGZLIlkEpKj8nzez4bu1UuG7en2z2dQShtpk 9rH+i/ZRJyDscU1jqfgDIx4snYgVESEuAowNXONBlykwm7lAHHo0oGYaKNEM EOOyB+4gf8AkrjKMmGSBwjUiRa0+HIznxMm5aKVdNFiRrYgJuADlAL0r4qWC dRMlNG8YR6GQDH0SMIdJydUWNVOt7Yw4a+bcg7BIanWoqIZLK/04cN8lIXL2 QKyaRay3b9/WG1bdahOr8c5qELom/ceQ/FguJ4FTKlV46+K8UnbCGJ4H8Lzo Tm/27+3C+5vC+/nuHfYiUKWSUQ/SH2PYFVlqNcvlk8S7pdKoM/+06I9uhp15 v1Q6seMwFBCLEKzk8eJnwvzY064q7zkG4/68BKSDQLEInjciuoewTAmurmyc v2TRPfPYllxRcAsGo9QBniNczCYTkHYCjySWOibB7ZEQareff9wzFsIucPnD v1PWkdExYhAa26PCR6nw0VPCz0gF5ipwIP98xdyUd2ykj5nCxR0VP07Fj58R Pz4mfmT3JnayAHw8qqDS7b09P29U0NP2hODzc3TaGCTu9qqzyahgUI3sxB0Y M51NusaWaSQwtvWhONQyGU0780W7pXUIP4SoQAUbrtYEE0C71iJ/XPf7UzL/ NLCze2V37cGi1x92fn9vNeCHoUFCPEU+nHXImHQpYkV+FYwgaeK8lP+mOxnb kyGGZ8fzxIboOMazeRfRpT6gcKql8DI8V53B0O5c9XUc6mlISBQTTEau3Z+B 6KvBR6Ba4rZVHcJcrkSUEt0O7JvOcJGhPXngMqYeeYqjcjvC06vzLiZbNFnq BAMWU0cBr7clUmFOw7A+kpIgiSgBAnBp9ybDL3lAIdK5ksxbnZHNmmFRUVBt tmTJdHqOTGFZgnC6hRP5DiTADyoJvEhSpejlakBapJ4I/S94EA7XfxaLBTxL yK1VRl7JOg7U66/IL2T0+3V/Nu4PIZvtEvLuNxh3hze9/sK4ZXE1GPb1+AkZ BI4Xu8nqkvUk6yiXzWpLJfNe0scFlu3ShnaZgBXdQ9wGxB5NE6Yz7YiAPSoC B1Ln6YAxF6J4n8eAGEMYaqjvM4VleBR7iichDcnMFMqUoTMddBeDSYHpFIdf k0F9ArZMNKneLdAP6R99jYrBCgZGumfk1GUrCookkWuxCV6/SxWMIQe/b2r5 QewvYXegYMCYzJBc3tjv2wWSZSwlyxKhSe+tAtVgQnA8SwdFZ/a+2S7QjedS +1xFwvNYVOISHH2SGWB6JDMQOryRY1m5TqNEobJJ+oHo6lAZTBZXPasCUSkI j/4k58SFf5tll8v7EjBoeuSDcSzqjf2MVZixssWo0h31ztuQ806ITrw0EjGU fzMKVZaHkBxW3OEscLa5VWyO2vg5a6PVLp8YKzbGvk3Wvv2UVZhCA/OKrGOK mhlFb1JpzUSadaioVZjKeaIzh+2FrewHOo3rVyIzxXnQ62OoFFkW9rwzH3RL Jz0RvII6JDBHUERRZHg9AuU6t5ZK1AEfQGUBKaZgpFOb1X7qyhNhuCWnrHZX I0O7ajUbr/GUdoiElAJ2AcCApIT20GCbYDGp823iL0lOAyc6A5SzxH+c1+A4 ECDjldlGtWdOY5YHUsGpg3NmTJK13A6AvHwEg+xcAIOaPAGXYWOfj9Nx0LVC C2lGdz4XJ76F/CMwL4GVOi0DTo59tF0nYVKFzMl0itIIc5fwdPZzecQchRgF cayHwDpGNMNQTKgaiQeVloSu8GNnTVaxtm+nJzHGiMw5w2RiFJSPUuo+FI7D B+JQX4fnhwLlJu+spfqrnGv6Vyl58XA2HltwoPcHxsrlG+lAYMOCdgGpS8Pu RWZfQiqzhBjTJ5PAS7K0gN5lF5JnCUyAquRuA+pzR+f1uwhqc0aeWbs24EM5 cySKPgH7G6n9b3T2s1J633GfZbAK2wV94RGOZktzZOyQz1IRqu6XmLh2kiVg FEBnBkVsl4JGrg5DHJja9Sb0VQClckfHSMjrgPx2fdkjSm33jtJ0KRlMmXWl npT+kelm6uqHuyPRA4fP446SuBgJTZ5cw15AvxjUzX8AbKCrLIeSxa6oJqIM oWbZSkR62PzhEpPavAOHJs1CLsK+0F962EojzOhO9vAx9XPOeBCd5GF9ptGF 0+7tfHE16/cR+uK5DZ0H6I5Vs4nu36PjvOp0Ix9UXsE+iX8BnHnbn+lqn033 X5KOOpPvrwCOd29m9mSmiRVeIWg0vvQEdKNOHAHuAdOT7nYNroNUBzkwuJ92 emckDsBQncbMqjwBDtEC0HkRM224jhVYrOmrM+q1B+xuZ2z354hzQNHlaB9n 0qA0EVSlctNdD8LHw+AaT7+Y8GiV9X3AkIZKhPvln2J2NZl1d5mSGPEayPcR GfoNzIWJ8BJUWdyx0sqjgH3h+FkATDvuAw0cSA1TsYHkOaIBvWPoAoyeabfb mfXI6bQ76g46r3f6cwfVgaU10m0EqGQiBcc/5MetdDyNKy6OoBRorQCm7Ay1 Gvvz0s4yHkEdwAiwY0fdyuQJLpp78sQTObZWyvYmx9Z6lq2dsr1NV+WFhfSY nvif0bGTyAVnQ4hxH2fprnC6McOWCHqdKJaIgMJILBlUW0AtPwVC/QQxGa7p kin+jeluCGTsroeCpDfneAuxooASIKAV98x9jRZkQn6JeWPFH5kLlZPM+N1a QVxuNC4KQ0axk1xTpfk4a0ABBgXLRAZ0U2yFEcfCRo3YDM2IYNn6DsyqwWHX RyRpc2o7VxL6uI8SSEPp8+oxTF/8DFEYpM+Rlz6r7HOG/iHKPGfGN8v0+dHb 10ZoUhvkSEECLyYFiXDhMx+GXWzR9zKO8DUvjvNdZPnQk39LX/gCX0r5mKf8 sCP6kHr7eSNSQu95wjdPGOsFzkveQWCQMnz7617JefPbS155gs+RLzigUEoB n4aFIYbQtFhxvZJVGArD8GDsISgMqDg4ZFTbknV+UNKxvy6qvfvGQ6wz/Ufm EHwJ4XzSmojVK40YruezTrcPiBrzloEA5hqrimCPqIg6WPMhWXAPL3DvcYSd Nl/X9nc1LhSuNrm+xBqKOUFg6Yz21xBY+aWHKQSwI4dGhFHdqyfgUip9H80o QHjEIqC1lpZ2Yx4sILl8SezZNyaQcB64C4Zn637yTeCW6Bt6l/j6wrOWXseU Svbv9q39aZQpzXqkXxwZ2R9Rl/4a8HUZQsKCzPmK5Hycc97+AndKnXumr3CB o0ZgAuXQDZb4BCJ47I562j808/niIbl6+zOGhp0Z56AC8xVDd4JJLa8Zu9JG LGn98NafRb6+00c9Pn3kfuynhChCwpAHdYUBnCWX0yvieNhaapfeRdSXJIoD vbBaIaR2biDtzH11aJZrZsrgsxNyY18ewwMIOOI13pcUBsWxwVhicj5Bebi1 ejlCA7ANM7UK4g1C3+GrbVLGuIi44mz/mSO5GgUJBlFK/TEEOmkMyKXhElhu 0cPJhw9dMZfME5uaCbQN9zwUAUXOWdPgDsIqIV3FKo6wjJ3sU0jyi33ZOBjD HuBgENHAweA6Xh4OAvw8HPShRTscXvMjmu4YFk1tbP5uEnZr0etf3nw8MgHg +nJi93FbycDujdsI4CX06PiNA7/+tJcE20qMXZzXEC49k6dQ+h3o+AdAZnPE jpIMpBuQ7ppDaKlkXwCZAshQLIUWX78mprx6pY/J169mNfBqvlhp3HE5mX/C fcFbrgD25QcNiMcAo6fBlHTRFLzVreZ+mmbO8NjajfoFfqUac8fZQl1oXIB7 dj6ozPvDhd1YXFT2kA9Xk5aIXJXLVD8DTa28HuscFXUhBSr+qF1VtRtZ3ZDV D3Vb508pT+oTFLAX7GgW7ai1SPlQz6JVKb+kaCf6bSK69bJtRWta5hPm7Yh0 LFw9Pl3Bof32A+5W1gMws+hYLywfr0WKKtpaxY09E9DOcwdWjcQS05aO0HnH oOAgqw3IF/Z8UEkR2TF1zfOLA3U/a3WD+TXhjxYZcScSWcEwMfhivSC39fYi i06SALrQkiGSq0ci+ciuAuXREFq0FtNn/fghi/Hw63khSqf/yAnuzuZfUPL3 Ce1BKRyzGD9cJzH/UfwrK7Y3Gy/GHyffJdRmrrekMWztZ8jJdshYLobsfm94 2bnpz77P0m1AIcncw/rP29NPORt/H3egt77+Lnn9od0hv8XcubcVCzHNNKDS gvROVjRSLX6zLRj+LunT7uDJ+HhCM7Ac0wzDaZyaQE00YId/TMlOD55iQ/Xs YV4Ymr9xpi1jScfRIOkZS2wF+MGnQUDmPKBV193d7qVYYNcewvyRA55vnpKq R6aRUMIBKbYCtHNQUhL9+OcQv9XeNi1SJx7dQlQ2ofZlS6Spjj0NJBDU4p+P ILwr4KwK8PwJciraAhDZSkW2/h+RrUSkEdVOROHFFjToO4kalhpPo/DnJFZS FyUItOAbPY8foD2Uaqo94jZXGK5dl3GqLwVzSxKBt32d1wmYBLWqyKmU2k+J 3m04wojNWphryKL1iSRHeZWjcvRnFkd/3weREd2Qy52HjwqKls66ksCm45Zp DAv5OlyLYHt8WczbiUiq9u7WJiNiMCUCn9GkT71hV7vxqDgeRtpLSZNCbn8l a0bxbglvXCP8gwL8kAwNg2O+pIN04CG8vsr89cp0trj99Slj5DZwyHSamHRo iY4RLqHbRUuKTSv0wDAKssv/A8nKLeQaJgAA --0-785719567-918325450=:455-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Sat Feb 6 17:03:32 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA16342 for freebsd-isdn-outgoing; Sat, 6 Feb 1999 17:03:32 -0800 (PST) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from uni-sb.de (uni-sb.de [134.96.252.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA16329 for ; Sat, 6 Feb 1999 17:03:20 -0800 (PST) (envelope-from rock@wurzelausix.CS.Uni-SB.DE) Received: from cs.uni-sb.de (cs.uni-sb.de [134.96.252.31]) by uni-sb.de (8.9.2/1999010400) with ESMTP id CAA04338 for ; Sun, 7 Feb 1999 02:03:15 +0100 (CET) Received: from wurzelausix.cs.uni-sb.de (wurzelausix.cs.uni-sb.de [134.96.247.1]) by cs.uni-sb.de (8.9.2/1999010400) with ESMTP id CAA25784 for ; Sun, 7 Feb 1999 02:03:15 +0100 (CET) Received: (from rock@localhost) by wurzelausix.cs.uni-sb.de (8.9.1/wjp/19980821) id CAA27831 for isdn@freebsd.org; Sun, 7 Feb 1999 02:03:14 +0100 (CET) Date: Sun, 7 Feb 1999 02:03:14 +0100 (CET) From: "D. Rock" Message-Id: <199902070103.CAA27831@wurzelausix.cs.uni-sb.de> To: isdn@FreeBSD.ORG Subject: sppp connection problems Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I sometimes have problems using i4b for dialing out. There seems to be a problem in the sppp handshake. Stopping and restarting isdnd, taking isp0 down and up again, nothing does help. The only solution I found is a reboot. I have turned on debugging on isp0 and up to the "phase network" seems to be ok, but then the connection is dropped. For a successful connection, the next message appearing is a "ipcp open(initial)", but in this case it is a "ipcp open(stopped)" instead. I have this problem with two different providers, so it seems a problem on the FreeBSD sppp site. Daniel P.S. I usually drop my connection manually with "ifconfig isp0 down". I don't know if this makes any problems under some circumstances. Here is the debug output of isp0: isp0: lcp open(initial) isp0: phase establish i4b: unit 0, assigned TEI = 124 = 0x7c isp0: Up event isp0: lcp up(starting) isp0: lcp output isp0: lcp input(req-sent): isp0: lcp parse opts: mru auth-proto 0x13 [rej] send conf-rej isp0: lcp output isp0: lcp input(req-sent): isp0: lcp input(ack-rcvd): isp0: lcp parse opts: mru auth-proto isp0: lcp parse opt values: mru 1524 auth-proto send conf-ack isp0: lcp output isp0: lcp tlu isp0: phase authenticate isp0: pap output isp0: pap success isp0: phase network isp0: ipcp open(stopped) isp0: lcp close(opened) isp0: phase terminate isp0: lcp output isp0: lcp input(closing): isp0: phase dead isp0: lcp down(closed) isp0: Down event (carrier loss) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Sat Feb 6 21:33:16 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA07786 for freebsd-isdn-outgoing; Sat, 6 Feb 1999 21:33:16 -0800 (PST) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from emmi.physik.TU-Berlin.DE (emmi.physik.TU-Berlin.DE [130.149.160.103]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA07768 for ; Sat, 6 Feb 1999 21:33:12 -0800 (PST) (envelope-from jan@emmi.physik.TU-Berlin.DE) Received: from rosa.physik.TU-Berlin.DE (rosa.physik.TU-Berlin.DE [130.149.160.209]) by emmi.physik.TU-Berlin.DE (8.9.1/8.9.1) with ESMTP id GAA20274 for ; Sun, 7 Feb 1999 06:33:02 +0100 (CET) (envelope-from jan@emmi.physik.TU-Berlin.DE) From: Jan Riedinger Received: (from jan@localhost) by rosa.physik.TU-Berlin.DE (8.9.1/8.9.1) id GAA12539 for freebsd-isdn@freebsd.org; Sun, 7 Feb 1999 06:33:01 +0100 (CET) (envelope-from jan@mail.physik.TU-Berlin.DE) Message-Id: <199902070533.GAA12539@rosa.physik.TU-Berlin.DE> Subject: Address negotiation problem solved To: freebsd-isdn@FreeBSD.ORG Date: Sun, 7 Feb 1999 06:33:01 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Because of a reply from Juergen Haecker to mailing I have now a working PPP setup. Against the first impression the address negotiation works. I didn't try to change the default route to the new configured interface, because of the output form ifconfig and because of the isdnd log output. isp2: flags=2815 mtu 1500 inet 0.0.0.0 --> 0.0.0.1 netmask 0xff000000 Feb 5 01:41:41 brahms /kernel: isp2: ipcp parse opt values: address 0.0.0.1 [ack] send conf-ack Feb 5 01:41:41 brahms /kernel: isp2: ipcp output Feb 5 01:41:41 brahms /kernel: isp2: ipcp input(ack-sent): I think both should be changed. I further think Gary should mention in the FAQ in the section "B. How to figure out the ISP's IP address that it isn't normaly necessary to do it because of the auto address negotiation. Jan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message