From owner-freebsd-isdn Sun Jul 12 01:25:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA22805 for freebsd-isdn-outgoing; Sun, 12 Jul 1998 01:25:27 -0700 (PDT) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from hcshh.hcs.de (hcshh.hcs.de [194.123.40.1]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id BAA22799 for ; Sun, 12 Jul 1998 01:25:24 -0700 (PDT) (envelope-from hm@hcs.de) Received: from hcswork.hcs.de([192.76.124.5]) (3533 bytes) by hcshh.hcs.de via sendmail with P:smtp/R:inet_hosts/T:smtp (sender: ) id for ; Sun, 12 Jul 1998 10:25:08 +0200 (METDST) (Smail-3.2.0.101 1997-Dec-17 #2 built 1998-Jun-26) Received: by hcswork.hcs.de (Smail3.1.29.0 #12) id m0yvHTg-0000dRC; Sun, 12 Jul 98 10:27 METDST Message-Id: From: hm@hcs.de (Hellmuth Michaelis) Subject: Re: aocd seems to work pretty well ... In-Reply-To: <19980711182725.A4601@klemm.gtn.com> from Andreas Klemm at "Jul 11, 98 06:27:25 pm" To: andreas@klemm.gtn.com (Andreas Klemm) Date: Sun, 12 Jul 1998 10:27:24 +0200 (METDST) 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 Andreas Klemm: > > Without rates file and this configuration in isdnd.rc: > > # ratesfile = /etc/isdn/isdnd.rates # name & location of rates file > > unitlength = 90 > > unitlengthsrc = aocd > > > > I get this result: > > > > Jul 11 16:06:35 titan /kernel: isppp0: phase establish > > Jul 11 16:06:35 titan isdnd[17141]: CHD 00015 GTN rate 60 sec/unit (aocd, default) > > ^^^^^^^^^^^^^^^^^^^^^^^^^ [...] > > Jul 11 16:08:32 titan isdnd[17141]: CHD 00015 GTN charging: 1 units, 115 seconds > > ^^^^^^^^^^^^^^^^^^^^ > Hmm, or not ??? > > Jul 11 18:24:53 titan isdnd[17141]: CHD 00023 GTN rate 60 sec/unit (aocd, > default) [...] > Jul 11 18:25:49 titan isdnd[17141]: CHD 00023 GTN charging: 1 units, 55 seconds > ^^^^^^^^^ > Jul 11 18:25:49 titan isdnd[17141]: CHD 00023 GTN accounting: in 30488, out 6034 > > disconnected too early ... No, not quite. For the shorthold mode to work correctly, one needs to measure the time between 2 charging units. After this time is known, a hangup is done dependent on the idle timeout earlyhangup-seconds before the next charging unit occurs. As soon as a call to a remote site succeeds, you get the first charging unit, but you don't know the length between two units yet. In this situation a guess is made. In case you configured "aocd", the rates file is queried and the length of the first unit is got from the rates data- base, if one is accesible. In your case, no rate database is available so this time is fetched from a compiled in default (= 60 secs). So there are several things to notice here: - in case you configure "unitlengthsrc = aocd" its recommended to have a valid rates database installed to get the length of the first unit. - i don't know why your call lasts 115 secs and then 55 secs for the second case (the second is correct, the unitlength is 60 secs and i think your earlyhangup time is 5 secs, so if the idletimeout is within your configured limit, the call lasts 55 secs.) The 115 secs seems to be a bug (diffs are as usual welcome :-) although it is within the limit of the _real_ unit time length because otherwise you were more than one unit charged at the end of the call. - there should be another config value introduced which specifies from which source to get the time of the first unit in case of aocd. hellmuth -- Hellmuth Michaelis Tel +49 40 559747-70 HCS Hanseatischer Computerservice GmbH Fax +49 40 559747-77 Oldesloer Strasse 97-99 Mail hm@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 Jul 12 02:22:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA01884 for freebsd-isdn-outgoing; Sun, 12 Jul 1998 02:22:48 -0700 (PDT) (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 CAA01829 for ; Sun, 12 Jul 1998 02:22:36 -0700 (PDT) (envelope-from martin@rumolt.teuto.de) Received: from rumolt.teuto.de (root@rumolt.teuto.de [194.77.23.161]) by linteuto.teuto.de (8.8.7/8.8.7) with ESMTP id LAA17201; Sun, 12 Jul 1998 11:17:22 +0200 Received: (from martin@localhost) by rumolt.teuto.de (8.8.8/8.8.7) id LAA02855; Sun, 12 Jul 1998 11:04:53 +0200 (MEST) From: Martin Husemann Message-Id: <199807120904.LAA02855@rumolt.teuto.de> Subject: Re: fallback-IP-addr for dyn. dials. Is there any use for it ? To: malte@webmore.com Date: Sun, 12 Jul 1998 11:04:52 +0200 (MEST) Cc: hm@hcs.de, freebsd-isdn@FreeBSD.ORG, hohmuth@innocent.com In-Reply-To: from "Malte Lance" at Jul 11, 98 06:08:11 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 Uhh, sorry, > I found it just annoying to add this 0.0.0.0-"trigger-rule" into my > firewall-file and i did not for sure knew what implications such a rule > would have. And i found it much neater to just add "dynlip" to the > 'spppcontrol'-call instead of configuring the sppp-device with a magic > 0.0.0.0 number. Yes, 0.0.0.0 is magical for routing and that's ok, but > why config a device with 0.0.0.0 ??? Have to admit I'm still running this other software on that router (where I can assign any address and get dynamic ip address assignement on both sides of the link) :-( Yes, you are right. The 0.0.0.0 and 0.0.0.1 hack are realy ugly hacks and have to go. I talked to Gary about this right after they came in and he basically agreed, but wanted to keep our sppp as close as possible to the standard sppp in the FreeBSD tree. The flag in sppcontrol is the right way to go. We need "we-have-dynamic-ip" and "they-have-dynamic-ip" flags. So now: let's either break our incompatibility with the standard sppp even more or move the standard sppp to a clean solution (or do the former right now and the later as soon as possible). Martin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Sun Jul 12 03:19:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA09221 for freebsd-isdn-outgoing; Sun, 12 Jul 1998 03:19:25 -0700 (PDT) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from cyclone.degnet.baynet.de (cyclone.degnet.baynet.de [194.95.214.129]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id DAA09214 for ; Sun, 12 Jul 1998 03:19:22 -0700 (PDT) (envelope-from malte@webmore.com) Received: from neuron.webmore.com (unverified [194.95.214.184]) by cyclone.degnet.baynet.de (EMWAC SMTPRS 0.83) with SMTP id ; Sun, 12 Jul 1998 12:21:06 +0200 Received: (from malte@webmore.com) by neuron.webmore.com (8.8.8/8.8.8) id MAA00598; Sun, 12 Jul 1998 12:18:02 +0200 (CEST) Message-ID: X-Mailer: XFMail 1.2 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199807120904.LAA02855@rumolt.teuto.de> Date: Sun, 12 Jul 1998 12:18:02 +0200 (CEST) Reply-To: malte@webmore.com From: Malte Lance To: Martin Husemann Subject: Re: fallback-IP-addr for dyn. dials. Is there any use for it ? Cc: hohmuth@innocent.com, freebsd-isdn@FreeBSD.ORG, hm@hcs.de Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 12-Jul-98 Martin Husemann wrote: > Uhh, sorry, > >> I found it just annoying to add this 0.0.0.0-"trigger-rule" into my >> firewall-file and i did not for sure knew what implications such a rule >> would have. And i found it much neater to just add "dynlip" to the >> 'spppcontrol'-call instead of configuring the sppp-device with a magic >> 0.0.0.0 number. Yes, 0.0.0.0 is magical for routing and that's ok, but >> why config a device with 0.0.0.0 ??? > > Have to admit I'm still running this other software on that router (where > I can assign any address and get dynamic ip address assignement on both > sides of the link) :-( Hä ??? > Yes, you are right. The 0.0.0.0 and 0.0.0.1 hack are realy ugly hacks > and have to go. I talked to Gary about this right after they came in > and he basically agreed, but wanted to keep our sppp as close as possible > to the standard sppp in the FreeBSD tree. Hm ... there is not much in the standard-sppp to conform to. The code is just a basic ground for - attaching and detaching the devices (sppp_attach, sppp_detach) - input and output via lower-layer (sppp_input, sppp_output) - input, output and work-functionality for cp (sppp_lcp_input, sppp_cp_send) - ioctl-handling (sppp_ioctl) Joerg Wunsch made a major rewrite of this code and did a good job as he mostly injected new functionality (and mainly not changed the existing code). The problem i saw in the standard-sppp-code is, that the code is missing basic low-level features like 1. routing (no routing-code at all) 2. buffering of outgoing packets with a temporary wrong IP-addr (no code at all) 3. aliasing (no code at all) Explanation of 2.: Assume i configured my sppp-device with 0.0.0.0 for dynamic local IP-addr assignment and dynamic dial-out. Then i set a default-route via "-interface isppp0". When an outbound packet arrives, it will be sent via sppp. When the connection is down at that time, the Open-function of lcp is called and the dial-out is started, while the outbound-packet is enqueued with the src-IP-addr of 0.0.0.0 and therefor there will be no response for that packet. This case is acceptable for DNS-queries, since named boosts several packets in short periods out. But for HTTP-queries, where the timeout- value is rather high, it is extrem annoying for some user when there is no fast response (even no "something unreachable"). Sometimes, the timeout is that long, that sppp closes the connection in the meantime (that's the worst case). Correct code for routing would have the side-effect of stopping the natd-whining on this list. If the sppp-development is taken serious, routing and aliasing MUST be there. Rewriting of src-IP-addr for dynamiclly assigned local IP-addr'es may be a bonus. My personal suggestion would be to port user-ppp or kernel-ppp to work with i4b and inject the cisco and other parts of standard-sppp into this code, since the question of inventing the wheel several times always stands. Malte. > > The flag in sppcontrol is the right way to go. We need "we-have-dynamic-ip" > and "they-have-dynamic-ip" flags. > > So now: let's either break our incompatibility with the standard sppp even > more or move the standard sppp to a clean solution (or do the former right > now and the later as soon as possible). > > > Martin > ---------------------------------- E-Mail: Malte Lance Date: 12-Jul-98 Time: 11:36:18 ---------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Mon Jul 13 19:03:44 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA28862 for freebsd-isdn-outgoing; Mon, 13 Jul 1998 19:03:44 -0700 (PDT) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from harvey.aball.de (root@harvey.aball.de [194.77.82.26]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id TAA28852 for ; Mon, 13 Jul 1998 19:03:40 -0700 (PDT) (envelope-from alice.turbocat.de!dave@harvey.aball.de) Received: by harvey.aball.de (Smail3.1.28.1 #11) id m0yvuQz-000IytC; Tue, 14 Jul 98 04:03 MET DST Received: from cat.turbocat.de (cat.turbocat.de [194.77.82.49]) by alice.turbocat.de (8.8.8/8.7.3) with ESMTP id BAA12016; Tue, 14 Jul 1998 01:44:46 +0200 (CEST) Received: (from dave@localhost) by cat.turbocat.de (8.8.5/8.7.3) id BAA03680; Tue, 14 Jul 1998 01:44:48 +0200 (MET DST) Message-Id: <199807132344.BAA03680@cat.turbocat.de> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 4.2mach v148) Received: by NeXT.Mailer (1.148) From: David Wetzel Date: Tue, 14 Jul 98 01:44:46 +0200 To: hm@hcs.de Subject: Re: new isdn4bsd alpha available for download cc: freebsd-isdn@FreeBSD.ORG (ISDN Mailinglist) References: Organisation: Turbocat's Development http://www.turbocat.de/ Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > From: hm@hcs.de (Hellmuth Michaelis) > Hi, > > a new isdn4bsd alpha (i4b-00.63-alpha-100798.tgz) has been made available > on the isdn4bsd ftp site. > cc -g -O2 -Werror -Wall -Wmissing-prototypes -Wstrict-prototypes -I. -I../../../../arch -I../../../.. -nostdinc -DEXEC_AOUT -DEXEC_SCRIPT -DI486_CPU -DI586_CPU -DVM86 -DXSERVER -DKTRACE -DSYSVMSG -DSYSVSEM -DSYSVSHM -DSHMMAXPGS="0x400" -DCOMPAT_NOMID -DCOMPAT_10 -DCOMPAT_11 -DCOMPAT_12 -DCOMPAT_43 -DTCP_COMPAT_42 -DFFS -DMFS -DNFSSERVER -DFIFO -DGATEWAY -DINET -DMROUTING -DCCITT -DLLC -DHDLC -DNMBCLUSTERS="0x800" -DTEL_S0_16 -DIPR_VJ -DMAXUSERS=64 -D_KERNEL -Di386 -c ../../../../i4b/driver/i4b_ipr.c ../../../../i4b/driver/i4b_ipr.c: In function `i4biprioctl': ../../../../i4b/driver/i4b_ipr.c:493: structure has no member named `if_unit' *** Error code 1 Any ideas? uname -a NetBSD alice 1.3 NetBSD 1.3 (ALICE) #1: Sun Jun 14 20:13:12 CEST 1998 root@alice:/usr/src/sys/arch/i386/compile/ALICE i386 --- _ _ _(_)(_)_ David Wetzel, Turbocat's Development, (_) __ (_) Buchhorster Strasse, D-16567 Muehlenbeck/Berlin, FRG, _/ \_ Fax +49 33056 82835 NeXTmail dave@turbocat.de (______) http://www.turbocat.de/ DEVELOPMENT * CONSULTING * ADMINISTRATION WATCH OUT FOR TURBOFAX for OPENSTEP! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Tue Jul 14 06:31:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA02368 for freebsd-isdn-outgoing; Tue, 14 Jul 1998 06:31:25 -0700 (PDT) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from gilberto.physik.RWTH-Aachen.DE (gilberto.physik.rwth-aachen.de [137.226.30.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA02363 for ; Tue, 14 Jul 1998 06:31:12 -0700 (PDT) (envelope-from kuku@gilberto.physik.RWTH-Aachen.DE) Received: (from kuku@localhost) by gilberto.physik.RWTH-Aachen.DE (8.8.8/8.8.7) id PAA17253 for freebsd-isdn@freebsd.org; Tue, 14 Jul 1998 15:30:48 +0200 (MEST) (envelope-from kuku) Date: Tue, 14 Jul 1998 15:30:48 +0200 (MEST) From: Christoph Kukulies Message-Id: <199807141330.PAA17253@gilberto.physik.RWTH-Aachen.DE> To: freebsd-isdn@FreeBSD.ORG Subject: isdnd.rc - cannot dial in Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Environment: i4b-100798, FreeBSD-2.2.6 I thought I would be able to migrate my bisdnd environment without asking a question but though I can dialout fine to every remote site I had established under bisdn I still have configuration difficulties with dialing in (raw ip). And though I studied the isdnd.rc(5) page quite thoroughly I cannot withhold coming up with a question: On vtty6 I can see incoming call from 2405419245 but it doesn't seem to get answered or recognized at all. Below is my isdnd.rc: #------------------------------------------------------------------------------ # # example of a configuration file for the isdn daemon # --------------------------------------------------- # # $Id: isdnd.rc,v 1.7 1998/07/09 12:12:58 hm Exp $ # # last edit-date: [Thu Jul 9 14:14:54 1998] # # NOTICE: # ======= # This configuration file is an EXAMPLE only and MUST be edited # carefully to get the desired results! # # Please read the "isdnd.rc" manual page (execute "man isdnd.rc") # for reference ! # #------------------------------------------------------------------------------ #============================================================================== # SYSTEM section: isdnd global configuration parameters #============================================================================== system # accounting # ---------- acctall = on # generate info for everything acctfile = /var/log/isdnd.acct # name & location of accounting file useacctfile = yes # generate accouting info to file # monitor # ------- monitor-allowed = yes # global switch: monitor on/off monitor-port = 451 # default monitor TCP port # Monitor rights are granted due to the most specific host/net spec, i.e. in # the example below host 192.168.1.2 will have the rights specified on that # line, even so it belongs to net 192.168.1.0/24 as well. # # A monitor specification may either be: # # - the name of a local (UNIX-domain) socket; this MUST start with a "/" #monitor = "/var/run/isdn-monitor" #monitor-access = fullcmd #monitor-access = channelstate, logevents #monitor-access = callin, callout ## ## - a dotted-quad host spec #monitor = "192.168.1.119" #monitor-access = restrictedcmd, channelstate, callin, callout ## ## - a dotted-quad net spec with "/len" (CIDR-style) netmask spec #monitor = "192.168.1.0/24" #monitor-access = restrictedcmd, channelstate, callin, callout ## ## - a resolveable host name #monitor = "rumolt" #monitor-access = restrictedcmd, channelstate, callin, callout ## ## - a resolveable net name with "/len" netmask (s.a.) appended #monitor = "up-vision-net/24" #monitor-access = restrictedcmd, channelstate, callin, callout # # ratesfile # --------- ratesfile = /etc/isdn/isdnd.rates # name & location of rates file # regular expression pattern matching # ----------------------------------- #regexpr = "connected.*KTS" # look for matches in log messages #regprog = connectKTS # execute program when match is found # realtime priority section # ------------------------- rtprio = 25 # modify isdnd's process priority #============================================================================== # entry section: IP over ISDN #============================================================================== entry name = rwth # name for reference. This name will # be used in the logfile to identfy # this entry. # the network or telephone device # the data traffic should be routed to: usrdevicename = ipr # ipr, isppp, tel, rbch usrdeviceunit = 0 # unit number # the ISDN controller number to be # used for this entry: isdncontroller = 0 # contoller to use or -1 to use any isdnchannel = -1 # channel (1/2) to use or 0 or -1 for any # incoming only, outgoing only or both: direction = inout # in, out, inout # numbers used to verify a DIAL IN: local-phone-incoming = 4190006 # my number # numbers used at DIAL OUT time: local-phone-dialout = 4190006 # this is my number remote-phone-dialout = 44129870 # i call this remote number # in case i have several remote # telephone numbers specified, this # is used to specify which one is # used next on dial fail or retry: remdial-handling = first # first, last or next # what happenes if someone dials in: dialin-reaction = accept # reject, ignore, answer, callback # normal dialout or do i call back: dialout-type = normal # normal / calledback callbackwait = 1 # no of secs to wait before calling back # type of protocol on the B-channel: # hdlc must be specified for IP (the # ipr and isppp drivers), raw must be # specified for telephone answering b1protocol = hdlc # hdlc, raw # shorthold mode and idle time # configuration: ratetype = 0 # ratesfile entry to use unitlength = 90 # unitlength to assume unitlengthsrc = rate # none, rate, cmdl, conf, aocd idletime-incoming = 120 # incoming call idle timeout idletime-outgoing = 60 # outgoing call idle timeout earlyhangup = 5 # time to hangup before an expected # next charging unit will occur # retry and recovery parameters dialretries = 3 # # of dial retries dialrandincr = off # random dial increment time recoverytime = 5 # time to wait between 2 dial tries usedown = off # set i/f down downtries = 5 # retry cycles before set down downtime = 30 # time to be in down before going up ##========================================================================== entry name = kuku-home # name for reference. This name will # be used in the logfile to identfy # this entry. # the network or telephone device # the data traffic should be routed to: usrdevicename = ipr # ipr, isppp, tel, rbch usrdeviceunit = 1 # unit number # the ISDN controller number to be # used for this entry: isdncontroller = 0 # contoller to use or -1 to use any isdnchannel = -1 # channel (1/2) to use or 0 or -1 for any # incoming only, outgoing only or both: direction = inout # in, out, inout # numbers used to verify a DIAL IN: local-phone-incoming = 4190006 # my number # numbers used at DIAL OUT time: local-phone-dialout = 4190006 # this is my number remote-phone-dialout = 02405419245 # i call this remote number remote-phone-incoming = 2405419245 # anyone can call in # in case i have several remote # telephone numbers specified, this # is used to specify which one is # used next on dial fail or retry: remdial-handling = first # first, last or next # what happenes if someone dials in: dialin-reaction = accept # reject, ignore, answer, callback # normal dialout or do i call back: dialout-type = normal # normal / calledback callbackwait = 1 # no of secs to wait before calling back # type of protocol on the B-channel: # hdlc must be specified for IP (the # ipr and isppp drivers), raw must be # specified for telephone answering b1protocol = hdlc # hdlc, raw # shorthold mode and idle time # configuration: ratetype = 0 # ratesfile entry to use unitlength = 90 # unitlength to assume unitlengthsrc = rate # none, rate, cmdl, conf, aocd idletime-incoming = 120 # incoming call idle timeout idletime-outgoing = 60 # outgoing call idle timeout earlyhangup = 5 # time to hangup before an expected # next charging unit will occur # retry and recovery parameters dialretries = 3 # # of dial retries dialrandincr = off # random dial increment time recoverytime = 5 # time to wait between 2 dial tries usedown = off # set i/f down downtries = 5 # retry cycles before set down downtime = 30 # time to be in down before going up #============================================================================== # entry section: answering machine example #============================================================================== entry name = I4BTEL # name for reference usrdevicename = tel # ipr, tel, rbch usrdeviceunit = 0 # unit number isdncontroller = 0 # contoller to use or -1 to use any isdnchannel = -1 # channel (1/2) to use or 0 or -1 for any # numbers used to verify at DIAL IN local-phone-incoming = 4190006 # this is my number remote-phone-incoming = * # anyone can call in dialin-reaction = answer # accept, reject, ignore, answer answerprog = answer # program to run b1protocol = raw # hdlc, raw idletime-incoming = 10 # 5 seconds idle timeout #======================================================================= # entry section: PPP example #====================================================================== entry name = I4BPPP usrdevicename = isppp usrdeviceunit = 0 isdncontroller = 0 isdnchannel = -1 local-phone-incoming = 1234 remote-phone-incoming = 5678 local-phone-dialout = 1234 remote-phone-dialout = 5678 remdial-handling = first dialin-reaction = accept dialout-type = normal b1protocol = hdlc idletime-incoming = 240 idletime-outgoing = 30 ratetype = 0 unitlength = 90 unitlengthsrc = rate dialretries = 3 dialrandincr = on recoverytime = 25 usedown = off downtries = 2 downtime = 30 # EOF ######################################################################### The problem seems to be: I can dialout through entry kuku-home but I cannot dial in from kuku-home to ipr1. Here is /etc/rc.isdn: #!/bin/sh # -- from rc.bisdn -- if [ $1 != "restart" ] ; then sysctl -w net.inet.ip.forwarding=1 # config isdn interface 0,1 echo 'configuring ISDN/IP-interface ipr0 ...' ifconfig ipr0 inet 137.226.144.17 137.226.144.1 netmask 255.255.255.255 ifconfig ipr1 inet 192.168.1.119 192.168.0.1 netmask 255.255.255.255 ifconfig ipr0 ifconfig ipr1 route add -net default 137.226.144.1 route add -net 192.168.0.0 192.168.1.119 netstat -rn #--------------------------------------------------------------------------- # # /etc/rc.isdn - isdn4bsd EXAMPLE startup script # ---------------------------------------------- # # $Id: rc.isdn,v 1.3 1998/07/09 12:19:02 hm Exp $ # # NOTICE: # ======= # This startup script file is an EXAMPLE only and MUST be edited # ============================================================== # carefully to get the desired results !!!! # ========================================= # # last edit-date: [Thu Jul 9 13:40:15 1998] # # accepts argument "restart" to kill and restart the isdnd or # argument "stop" to kill isdnd. # #--------------------------------------------------------------------------- fi # rotate isdnd's logfile at startup ? rotate_log=NO #rotate_log=YES # start isdntrace in background run_isdntrace=NO #run_isdntrace=YES # flags for isdntrace #isdntraceflags="" isdntraceflags="-i" # trace logfile for isdntrace isdntracefile=/var/tmp/isdn.trace # enable verbose debugging messages in isdnd do_isdnddebug=NO #do_isdnddebug=YES # debugging level debuglevel="-d0" #debuglevel="-d0xf9 -dn" # output device for fullscreen mode, this device must have no getty running ! out_dev=/dev/ttyv6 # terminal type for fullscreen mode (this is for the pcvt VT220 emulator) out_typ=cons25 # restart daemon ? restart=0 # check for restart or stop arguments if [ $# -eq 1 ] then if [ $1 = restart ] then restart=1 kill `cat /var/run/isdnd.pid` elif [ $1 = stop ] then echo 'terminating the isdn4bsd ISDN management daemon ...' kill `cat /var/run/isdnd.pid` exit 0 fi fi # rotate log file if [ X${rotate_log} = X"YES" ] then if [ -f /var/log/isdnd.log ] then echo "rotating /var/log/isdnd.log file ..." cd /var/log if [ -f isdnd.log4 ] ; then mv -f isdnd.log4 isdnd.log5 ; fi if [ -f isdnd.log3 ] ; then mv -f isdnd.log3 isdnd.log4 ; fi if [ -f isdnd.log2 ] ; then mv -f isdnd.log2 isdnd.log3 ; fi if [ -f isdnd.log1 ] ; then mv -f isdnd.log1 isdnd.log2 ; fi if [ -f isdnd.log0 ] ; then mv -f isdnd.log0 isdnd.log1 ; fi cp -pf isdnd.log isdnd.log0 cat /dev/null > isdnd.log fi fi # start the isdn daemon if [ -x /usr/local/bin/isdnd ] then if [ $restart -eq 1 ] then echo 'restarting the isdn4bsd ISDN management daemon ...' else echo 'starting the isdn4bsd ISDN management daemon ...' fi if [ X${do_isdnddebug} = X"YES" ] then /usr/local/bin/isdnd ${debuglevel} -b -f -r $out_dev -t $out_typ else /usr/local/bin/isdnd -b -f -r $out_dev -t $out_typ fi fi # start the isdntrace utility if [ X${run_isdntrace} = X"YES" ] then if [ -x /usr/local/bin/isdntrace -a $restart -eq 0 ] then echo 'starting the isdn4bsd ISDN tracing facility ...' nohup /usr/local/bin/isdntrace ${isdntraceflags} -f{isdntracefile} >/dev/null 2>&1 & fi fi # EOF A helping tip appreciated. Thanks. -- Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Tue Jul 14 11:02:12 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA11657 for freebsd-isdn-outgoing; Tue, 14 Jul 1998 11:02:12 -0700 (PDT) (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 LAA11592 for ; Tue, 14 Jul 1998 11:02:06 -0700 (PDT) (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 UAA21733; Tue, 14 Jul 1998 20:01:59 +0200 Received: from ernie by casparc.ppp.net with uucp (Smail3.1.28.1 #1) id m0yw9Oq-002ZjZC; Tue, 14 Jul 98 20:02 MET DST Received: from bert.kts.org(really [194.55.156.2]) by ernie.kts.org via sendmail with smtp id for ; Tue, 14 Jul 1998 18:57:19 +0200 (CEST) (Smail-3.2.0.91 1997-Jan-14 #3 built 1998-Feb-14) Received: by bert.kts.org via sendmail with stdio id for freebsd-isdn@FreeBSD.ORG; Tue, 14 Jul 1998 18:51:55 +0200 (CEST) (Smail-3.2.0.94 1997-Apr-22 #1 built 1998-Jun-6) Message-Id: From: hm@kts.org (Hellmuth Michaelis) Subject: Re: new isdn4bsd alpha available for download In-Reply-To: <199807132344.BAA03680@cat.turbocat.de> from David Wetzel at "Jul 14, 98 01:44:46 am" To: dave@turbocat.de (David Wetzel) Date: Tue, 14 Jul 1998 18:51:55 +0200 (CEST) Cc: hm@hcs.de, freebsd-isdn@FreeBSD.ORG Organization: Kitchen Table Systems Reply-To: hm@kts.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 David Wetzel wrote: > ../../../../i4b/driver/i4b_ipr.c: In function `i4biprioctl': > ../../../../i4b/driver/i4b_ipr.c:493: structure has no member named `if_unit' > *** Error code 1 > > Any ideas? Yes. This part of the code is FreeBSD specific, i forgot to add the NetBSD specific part. Diffs are as usual welcome! hellmuth -- Hellmuth Michaelis hm@kts.org Hamburg, Europe A duck is like a bicycle because they both have two wheels except the duck (terry@cs.weber.edu) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Tue Jul 14 11:02:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA11684 for freebsd-isdn-outgoing; Tue, 14 Jul 1998 11:02:18 -0700 (PDT) (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 LAA11653 for ; Tue, 14 Jul 1998 11:02:10 -0700 (PDT) (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 UAA21737; Tue, 14 Jul 1998 20:02:00 +0200 Received: from ernie by casparc.ppp.net with uucp (Smail3.1.28.1 #1) id m0yw9Os-002ZjZC; Tue, 14 Jul 98 20:02 MET DST Received: from bert.kts.org(really [194.55.156.2]) by ernie.kts.org via sendmail with smtp id for ; Tue, 14 Jul 1998 18:51:31 +0200 (CEST) (Smail-3.2.0.91 1997-Jan-14 #3 built 1998-Feb-14) Received: by bert.kts.org via sendmail with stdio id for freebsd-isdn@FreeBSD.ORG; Tue, 14 Jul 1998 18:46:07 +0200 (CEST) (Smail-3.2.0.94 1997-Apr-22 #1 built 1998-Jun-6) Message-Id: From: hm@kts.org (Hellmuth Michaelis) Subject: Re: isdnd.rc - cannot dial in In-Reply-To: <199807141330.PAA17253@gilberto.physik.RWTH-Aachen.DE> from Christoph Kukulies at "Jul 14, 98 03:30:48 pm" To: kuku@gilberto.physik.RWTH-Aachen.DE (Christoph Kukulies) Date: Tue, 14 Jul 1998 18:46:07 +0200 (CEST) Cc: freebsd-isdn@FreeBSD.ORG Organization: Kitchen Table Systems Reply-To: hm@kts.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 Christoph Kukulies wrote: > On vtty6 I can see incoming call from 2405419245 > but it doesn't seem to get answered or recognized at all. It would be helpful to see an isdntrace output of this. > #======================================================================= > # entry section: PPP example > #====================================================================== > entry > name = I4BPPP > usrdevicename = isppp And please, remove _everything_ from the example config file you don't need at your local site ! hellmuth -- Hellmuth Michaelis hm@kts.org Hamburg, Europe A duck is like a bicycle because they both have two wheels except the duck (terry@cs.weber.edu) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Tue Jul 14 11:42:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA19766 for freebsd-isdn-outgoing; Tue, 14 Jul 1998 11:42:50 -0700 (PDT) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from gilberto.physik.RWTH-Aachen.DE (gilberto.physik.rwth-aachen.de [137.226.30.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA19686 for ; Tue, 14 Jul 1998 11:42:25 -0700 (PDT) (envelope-from kuku@gilberto.physik.RWTH-Aachen.DE) Received: (from kuku@localhost) by gilberto.physik.RWTH-Aachen.DE (8.8.8/8.8.7) id UAA21778; Tue, 14 Jul 1998 20:42:29 +0200 (MEST) (envelope-from kuku) Message-ID: <19980714204228.A21739@gil.physik.rwth-aachen.de> Date: Tue, 14 Jul 1998 20:42:28 +0200 From: Christoph Kukulies To: hm@kts.org, Christoph Kukulies Cc: freebsd-isdn@FreeBSD.ORG Subject: Re: isdnd.rc - cannot dial in References: <199807141330.PAA17253@gilberto.physik.RWTH-Aachen.DE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91 In-Reply-To: ; from Hellmuth Michaelis on Tue, Jul 14, 1998 at 06:46:07PM +0200 Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Jul 14, 1998 at 06:46:07PM +0200, Hellmuth Michaelis wrote: > Christoph Kukulies wrote: > > > On vtty6 I can see incoming call from 2405419245 > > but it doesn't seem to get answered or recognized at all. > > It would be helpful to see an isdntrace output of this. Yikes, it works! While I was trying to produce an isdn.trace file it suddenly magically worked. Maybe rebooting was the cure. It seemed that restarting isdnd wasn't sufficient when applying changes to the /etc/isdn/isdnd.rc file. > > > #======================================================================= > > # entry section: PPP example > > #====================================================================== > > entry > > name = I4BPPP > > usrdevicename = isppp > > And please, remove _everything_ from the example config file you don't > need at your local site ! Hmm. I thought entries that aren't triggered (remote-phone-incoming=5678) can't do any harm. OK, for the future I will remind :-) > > hellmuth > -- > Hellmuth Michaelis hm@kts.org Hamburg, Europe > A duck is like a bicycle because they both have two wheels except the duck > (terry@cs.weber.edu) -- Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Wed Jul 15 06:58:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA20373 for freebsd-isdn-outgoing; Wed, 15 Jul 1998 06:58:28 -0700 (PDT) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from gilberto.physik.RWTH-Aachen.DE (gilberto.physik.rwth-aachen.de [137.226.30.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA20361 for ; Wed, 15 Jul 1998 06:58:25 -0700 (PDT) (envelope-from kuku@gilberto.physik.RWTH-Aachen.DE) Received: (from kuku@localhost) by gilberto.physik.RWTH-Aachen.DE (8.8.8/8.8.7) id PAA25368 for freebsd-isdn@freebsd.org; Wed, 15 Jul 1998 15:58:25 +0200 (MEST) (envelope-from kuku) Date: Wed, 15 Jul 1998 15:58:25 +0200 (MEST) From: Christoph Kukulies Message-Id: <199807151358.PAA25368@gilberto.physik.RWTH-Aachen.DE> To: freebsd-isdn@FreeBSD.ORG Subject: bug in /etc/rc.isdn Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org From the i4b-100798 dist (I didn't examine earlier ones) ~/etc/rc.isdn: # start the isdntrace utility if [ X${run_isdntrace} = X"YES" ] then if [ -x /usr/local/bin/isdntrace -a $restart -eq 0 ] then echo 'starting the isdn4bsd ISDN tracing facility ...' nohup /usr/local/bin/isdntrace ${isdntraceflags} -f{isdntracefil -------------------------^ $ missing e} >/dev/null 2>&1 & fi fi -- Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Wed Jul 15 07:33:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA25083 for freebsd-isdn-outgoing; Wed, 15 Jul 1998 07:33:55 -0700 (PDT) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from gilberto.physik.RWTH-Aachen.DE (gilberto.physik.rwth-aachen.de [137.226.30.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA25072 for ; Wed, 15 Jul 1998 07:33:35 -0700 (PDT) (envelope-from kuku@gilberto.physik.RWTH-Aachen.DE) Received: (from kuku@localhost) by gilberto.physik.RWTH-Aachen.DE (8.8.8/8.8.7) id QAA25483 for freebsd-isdn@freebsd.org; Wed, 15 Jul 1998 16:33:12 +0200 (MEST) (envelope-from kuku) Date: Wed, 15 Jul 1998 16:33:12 +0200 (MEST) From: Christoph Kukulies Message-Id: <199807151433.QAA25483@gilberto.physik.RWTH-Aachen.DE> To: freebsd-isdn@FreeBSD.ORG Subject: natd/firewall issues Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org After re-establishing the setup I had running under 2.2.5/bisdnd, especially the firewall/natd settings I found that I cannot route through ipr0 when the same natd/firewall rules are applied I had under 2.2.5/bisdnd. Are there any caveats to know about when using i4b with natd? /etc/rc.firewall /sbin/ipfw -f flush #/sbin/ipfw add divert natd all from any to any via ipr0 /sbin/ipfw add pass all from any to any If I uncomment the ipr0 line, I cannot route out packets in conjunction with: /etc/rc.local: natd -n ipr0 sh /etc/rc.firewall kernel CONFIG: # machine "i386" cpu "I486_CPU" ident MONKAVMIFB maxusers 64 options MATH_EMULATE #Support for x87 emulation options INET #InterNETworking options FFS #Berkeley Fast Filesystem options NFS #Network Filesystem options MSDOSFS #MSDOS Filesystem options "CD9660" #ISO 9660 Filesystem options PROCFS #Process filesystem options "COMPAT_43" #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=15 #Be pessimistic about Joe SCSI device #options BOUNCE_BUFFERS #include support for DMA bounce buffers 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 SYSVSHM options SHMMAXPGS=4096 options "SHMMAX=(SHMMAXPGS*PAGE_SIZE+1)" options IPDIVERT options IPFIREWALL options IPFIREWALL_VERBOSE config kernel root on wd0 controller isa0 controller pci0 controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr disk fd0 at fdc0 drive 0 controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr disk wd0 at wdc0 drive 0 options ATAPI #Enable ATAPI support for IDE bus options ATAPI_STATIC #Don't do it as an LKM device wcd0 #IDE CD-ROM # A single entry for any of these controllers (ncr, ahb, ahc, amd) is # sufficient for any number of installed devices. # # Note: The dpt driver is present in this release but was left disabled # due to its relatively late entry (it's almost certainly benign to enable # it but we didn't want to risk any chance of destabilizing 2.2.6). To # enable DPT support, uncomment the dpt0 controller entry and the two # options DPTOPT and DPT_MEASURE_PERFORMANCE entries below. controller ncr0 controller scbus0 device sd0 device od0 #See LINT for possible `od' options. device st0 device cd0 #Only need one of these, the code dynamically grows device wt0 at isa? port 0x300 bio irq 5 drq 1 vector wtintr device scd0 at isa? port 0x230 bio # syscons is the default console driver, resembling an SCO console device sc0 at isa? port "IO_KBD" tty irq 1 vector scintr # Mandatory, don't remove device npx0 at isa? port "IO_NPX" flags 0x1 irq 13 vector npxintr # device sio0 at isa? port "IO_COM1" 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 device le0 at isa? port 0x200 net irq 10 iomem 0xd0000 vector le_intr # # Copyright (c) 1997, 1998 Hellmuth Michaelis. All rights reserved. # # Redistribution and use in source and binary forms, with or without # modification, are permitted provided that the following conditions # are met: # # 1. Redistributions of source code must retain the above copyright # notice, this list of conditions and the following disclaimer. # 2. Redistributions in binary form must reproduce the above copyright # notice, this list of conditions and the following disclaimer in the # documentation and/or other materials provided with the distribution. # 3. Neither the name of the author nor the names of any co-contributors # may be used to endorse or promote products derived from this software # without specific prior written permission. # 4. Altered versions must be plainly marked as such, and must not be # misrepresented as being the original software and/or documentation. # # THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND # ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE # IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE # ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE # FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL # DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS # OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) # HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT # LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY # OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF # SUCH DAMAGE. # #--------------------------------------------------------------------------- # # i4b FreeBSD kernel configuration # -------------------------------- # # last edit-date: [Fri Jun 19 10:44:03 1998] # # $Id: CONFIG,v 1.14 1998/06/19 09:26:07 hm Exp $ # # -hm cvs # -hm PPP # -hm hardware options patch from Gary # #--------------------------------------------------------------------------- # # i4b passive ISDN cards support (isic - I4b Siemens Isdn Chipset driver) # note that the ``options'' and ``device'' lines must BOTH be defined ! # Teles S0/8 or Niccy 1008 # AVM A1 or AVM Fritz!Card options "AVM_A1" device isic0 at isa? port 0x340 net irq 5 flags 0x08 vector isicintr # i4b passive cards D channel handling # Q.921 pseudo-device "i4bq921" # Q.931 pseudo-device "i4bq931" # common passive and active layer 4 # layer 4 pseudo-device "i4b" # userland driver to do ISDN tracing (for passive cards oly) pseudo-device "i4btrc" 4 # userland driver to control the whole thing pseudo-device "i4bctl" # userland driver for access to raw B channel pseudo-device "i4brbch" 4 # userland driver for telephony pseudo-device "i4btel" 2 # network driver for IP over raw HDLC ISDN pseudo-device "i4bipr" 4 # enable VJ header compression detection for ipr i/f options IPR_VJ # network driver for sync PPP over ISDN pseudo-device "i4bisppp" 4 pseudo-device sppp 4 pseudo-device loop pseudo-device ether pseudo-device log pseudo-device bpfilter 4 pseudo-device sl 1 pseudo-device ppp 1 pseudo-device vn 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 -- Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Wed Jul 15 12:02:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA02453 for freebsd-isdn-outgoing; Wed, 15 Jul 1998 12:02:30 -0700 (PDT) (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 MAA02441 for ; Wed, 15 Jul 1998 12:02:20 -0700 (PDT) (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 VAA09048; Wed, 15 Jul 1998 21:02:00 +0200 Received: from ernie by casparc.ppp.net with uucp (Smail3.1.28.1 #1) id m0ywWoV-002ZjZC; Wed, 15 Jul 98 21:02 MET DST Received: from bert.kts.org(really [194.55.156.2]) by ernie.kts.org via sendmail with smtp id for ; Wed, 15 Jul 1998 19:51:51 +0200 (CEST) (Smail-3.2.0.91 1997-Jan-14 #3 built 1998-Feb-14) Received: by bert.kts.org via sendmail with stdio id for freebsd-isdn@FreeBSD.ORG; Wed, 15 Jul 1998 19:46:30 +0200 (CEST) (Smail-3.2.0.94 1997-Apr-22 #1 built 1998-Jun-6) Message-Id: From: hm@kts.org (Hellmuth Michaelis) Subject: Re: natd/firewall issues In-Reply-To: <199807151433.QAA25483@gilberto.physik.RWTH-Aachen.DE> from Christoph Kukulies at "Jul 15, 98 04:33:12 pm" To: kuku@gilberto.physik.RWTH-Aachen.DE (Christoph Kukulies) Date: Wed, 15 Jul 1998 19:46:30 +0200 (CEST) Cc: freebsd-isdn@FreeBSD.ORG Organization: Kitchen Table Systems Reply-To: hm@kts.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 Christoph Kukulies wrote: > After re-establishing the setup I had running under 2.2.5/bisdnd, > especially the firewall/natd settings I found that I cannot route > through ipr0 when the same natd/firewall rules are applied I had > under 2.2.5/bisdnd. I'm not using ipfirewall (and no natd at all), but ipfilter everywhere and i didn't had to change anything except the interface names when i did the transitions from bisdn to i4b in my configurations, so i have no idea what went wrong. hellmuth -- Hellmuth Michaelis hm@kts.org Hamburg, Europe A duck is like a bicycle because they both have two wheels except the duck (terry@cs.weber.edu) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Wed Jul 15 15:31:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA27262 for freebsd-isdn-outgoing; Wed, 15 Jul 1998 15:31:05 -0700 (PDT) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from gw-nl1.philips.com (gw-nl1.philips.com [192.68.44.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA27250 for ; Wed, 15 Jul 1998 15:31:01 -0700 (PDT) (envelope-from tafkam@linda.mpn.cp.philips.com) Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl1.philips.com with ESMTP id AAA10157; Thu, 16 Jul 1998 00:30:41 +0200 (MEST) (envelope-from tafkam@linda.mpn.cp.philips.com) Received: from linda.mpn.cp.philips.com (linda.mpn.cp.philips.com [130.139.64.52]) by smtprelay-nl1.philips.com (8.8.5/8.6.10-1.2.2m-970826) with ESMTP id AAA22166; Thu, 16 Jul 1998 00:30:41 +0200 (MET DST) Received: (from tafkam@localhost) by linda.mpn.cp.philips.com (8.8.7/8.8.7) id AAA01742; Thu, 16 Jul 1998 00:28:36 +0200 (CEST) (envelope-from Eilko.Bos@nl.origin-it.com) From: Eilko Bos Message-Id: <199807152228.AAA01742@linda.mpn.cp.philips.com> Subject: Re: natd/firewall issues In-Reply-To: <199807151433.QAA25483@gilberto.physik.RWTH-Aachen.DE> from Christoph Kukulies at "Jul 15, 98 04:33:12 pm" To: kuku@gilberto.physik.RWTH-Aachen.DE (Christoph Kukulies) Date: Thu, 16 Jul 1998 00:28:36 +0200 (CEST) Cc: freebsd-isdn@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (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 > > After re-establishing the setup I had running under 2.2.5/bisdnd, > especially the firewall/natd settings I found that I cannot route > through ipr0 when the same natd/firewall rules are applied I had > under 2.2.5/bisdnd. > > Are there any caveats to know about when using i4b with natd? > > /etc/rc.firewall > /sbin/ipfw -f flush > #/sbin/ipfw add divert natd all from any to any via ipr0 > /sbin/ipfw add pass all from any to any > > If I uncomment the ipr0 line, I cannot route out packets > in conjunction with: > > /etc/rc.local: > I run freebsd 2.2.5 / i4b-00.60-alpha-070598 (eeeeehrm...) read the natd manual well. I've thrown away the rc.firewall and do the next: ---- ./dialin.sh ---- #! /bin/sh xterm -T Isdn -n Isdnd -e /usr/local/bin/isdnd -F -d0x71 & ifconfig isppp0 inet 0.0.0.0 123.134.71.100 netmask 0xffffff00 ifconfig isppp0 down route add default 123.134.71.100 spppcontrol isppp0 myauthproto=pap myauthname=authname myauthsecret=123445 ifconfig isppp0 up natd -n isppp0 # /sbin/ipfw -f flush /sbin/ipfw add divert natd all from any to any via isppp0 /sbin/ipfw add pass all from any to any And that works fine. Don't do the flush since that one seems to kill isppp0 As said, you need to read the manpage of natd, because you need to do some settings in rc.conf as well. If things start to complain about a missing rc.firewall, just touch it, that will work. Good luck. Cheers, Eilko. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Thu Jul 16 01:08:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA05705 for freebsd-isdn-outgoing; Thu, 16 Jul 1998 01:08:39 -0700 (PDT) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from gilberto.physik.RWTH-Aachen.DE (gilberto.physik.rwth-aachen.de [137.226.30.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA05624 for ; Thu, 16 Jul 1998 01:08:36 -0700 (PDT) (envelope-from kuku@gilberto.physik.RWTH-Aachen.DE) Received: (from kuku@localhost) by gilberto.physik.RWTH-Aachen.DE (8.8.8/8.8.7) id KAA29139; Thu, 16 Jul 1998 10:08:30 +0200 (MEST) (envelope-from kuku) Message-ID: <19980716100830.A29108@gil.physik.rwth-aachen.de> Date: Thu, 16 Jul 1998 10:08:30 +0200 From: Christoph Kukulies To: Eilko Bos , Christoph Kukulies Cc: freebsd-isdn@FreeBSD.ORG Subject: Re: natd/firewall issues References: <199807151433.QAA25483@gilberto.physik.RWTH-Aachen.DE> <199807152228.AAA01742@linda.mpn.cp.philips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91 In-Reply-To: <199807152228.AAA01742@linda.mpn.cp.philips.com>; from Eilko Bos on Thu, Jul 16, 1998 at 12:28:36AM +0200 Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Jul 16, 1998 at 12:28:36AM +0200, Eilko Bos wrote: > > > > After re-establishing the setup I had running under 2.2.5/bisdnd, > > especially the firewall/natd settings I found that I cannot route > > through ipr0 when the same natd/firewall rules are applied I had > > under 2.2.5/bisdnd. > > > > Are there any caveats to know about when using i4b with natd? > > > > /etc/rc.firewall > > /sbin/ipfw -f flush > > #/sbin/ipfw add divert natd all from any to any via ipr0 > > /sbin/ipfw add pass all from any to any > > > > If I uncomment the ipr0 line, I cannot route out packets > > in conjunction with: > > > > /etc/rc.local: > > > > > I run freebsd 2.2.5 / i4b-00.60-alpha-070598 (eeeeehrm...) > > read the natd manual well. > I've thrown away the rc.firewall and do the next: > > ---- ./dialin.sh ---- > #! /bin/sh > xterm -T Isdn -n Isdnd -e /usr/local/bin/isdnd -F -d0x71 & > ifconfig isppp0 inet 0.0.0.0 123.134.71.100 netmask 0xffffff00 > ifconfig isppp0 down > route add default 123.134.71.100 > spppcontrol isppp0 myauthproto=pap myauthname=authname myauthsecret=123445 > ifconfig isppp0 up > natd -n isppp0 > # /sbin/ipfw -f flush > /sbin/ipfw add divert natd all from any to any via isppp0 > /sbin/ipfw add pass all from any to any > > And that works fine. Don't do the flush since that one seems to kill isppp0 That's exactly what I have (my rc.firewall is just the last three lines above). Despite of the fact that you are only using it for dialing in via isppp0 while mine is active permanently for ipr0. So I see no difference between your settings and mine. Just that it doesn't seem to work for ipr0 in hdlc mode. But I will try harder, it's just that it didn't working right off from the start :-) > > As said, you need to read the manpage of natd, because you need to do some > settings in rc.conf as well. If things start to complain about a missing Aside from having firewall=YES I din't have anything that could affect natd and, as I said, things worked with these settings before. I'll inform the list when things turn out to the better. > rc.firewall, just touch it, that will work. > > Good luck. > > Cheers, > Eilko. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-isdn" in the body of the message -- --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Thu Jul 16 02:19:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA14416 for freebsd-isdn-outgoing; Thu, 16 Jul 1998 02:19:40 -0700 (PDT) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from gilberto.physik.RWTH-Aachen.DE (gilberto.physik.rwth-aachen.de [137.226.30.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA14411 for ; Thu, 16 Jul 1998 02:19:36 -0700 (PDT) (envelope-from kuku@gilberto.physik.RWTH-Aachen.DE) Received: (from kuku@localhost) by gilberto.physik.RWTH-Aachen.DE (8.8.8/8.8.7) id LAA29396 for freebsd-isdn@freebsd.org; Thu, 16 Jul 1998 11:19:36 +0200 (MEST) (envelope-from kuku) Date: Thu, 16 Jul 1998 11:19:36 +0200 (MEST) From: Christoph Kukulies Message-Id: <199807160919.LAA29396@gilberto.physik.RWTH-Aachen.DE> To: freebsd-isdn@FreeBSD.ORG Subject: i4b coexistence with NT on same S0 bus Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Suddenly, since I installed i4b I'm conflicting with other services which are using the S0 bus. This used to work smoothly under bisdn. Now it seems that a number which is not in the entry section of /etc/isdn/isdnd.rc is being accepted and then rejected. I'm not sure if it's because of the I4BTEL service is configured to allow anyone call in. OTOH the opposite site is not requesting the TEL service. This trace is showing the unwanted reaction of i4b: =========== isdntrace controller #0 =========== started Wed Jul 15 16:10:27 1998 -- NT->TE - unit:0 ---------------- time:15.07 16:11:01.34 --------------------- I430: INFO2 (Pending Activation, from NT) -- NT->TE - unit:0 ---------------- time:15.07 16:11:01.36 --------------------- I430: INFO4 (Activated, Priority = 8/9, from NT) -- NT->TE - unit:0 - frame:000001 - time:15.07 16:11:01.40 - length:40 --------- Dump:000 02 ff 03 ... Q921: SAP=0 (Call Control), C, TEI=127, U-Frame: UI PF 0 Dump:003 08 01 01 05 a1 04 02 88 90 18 01 89 6c 0d 21 81 ............l.!. Dump:019 33 35 31 38 37 33 34 31 32 33 34 70 08 c1 34 31 35187341234p..41 Dump:035 39 31 32 33 36 91236 Q931: pd=Q.931/I.451, cr=0x01 (from origination), message=SETUP: [sending complete] [bearer capability: cap=unrestricted digital information std=CCITT rate=64 kbit/s mode=circuit] [channel id: channel=B-1 (exclusive)] [calling party number: 35187341234 (type=national, plan=ISDN, presentation allowed, screening user provided: verified & passed)] [called party number: 4191236 (type=subscriber, plan=ISDN)] -- TE->NT - unit:0 - frame:000002 - time:15.07 16:11:01.40 - length:8 ---------- Dump:000 fc ff 03 0f 5a b9 01 ff ....Z... Q921: SAP=63 (TEI-Management), C, TEI=127, Ri=0xb95a, IdRequest, Ai=127 -- NT->TE - unit:0 - frame:000003 - time:15.07 16:11:01.42 - length:8 ---------- Dump:000 fe ff 03 0f 5a b9 02 ed ....Z... Q921: SAP=63 (TEI-Management), C, TEI=127, Ri=0xb95a, IdAssign, Ai=118 -- TE->NT - unit:0 - frame:000004 - time:15.07 16:11:01.42 - length:3 ---------- Dump:000 00 ed 7f ... Q921: SAP=0 (Call Control), C, TEI=118, U-Frame: SABME PF 1 -- NT->TE - unit:0 - frame:000005 - time:15.07 16:11:01.43 - length:3 ---------- Dump:000 00 ed 73 ..s Q921: SAP=0 (Call Control), R, TEI=118, U-Frame: UA PF 1 -- TE->NT - unit:0 - frame:000006 - time:15.07 16:11:01.43 - length:8 ---------- Dump:000 00 ed 00 00 .... Q921: SAP=0 (Call Control), C, TEI=118, I-Frame: N(S) 0 N(R) 0 P 0 Dump:004 08 01 81 07 .... Q931: pd=Q.931/I.451, cr=0x01 (from destination), message=CONNECT: -- NT->TE - unit:0 - frame:000007 - time:15.07 16:11:01.44 - length:3 ---------- Dump:000 00 b5 73 ..s Q921: SAP=0 (Call Control), R, TEI=90, U-Frame: UA PF 1 -- NT->TE - unit:0 - frame:000008 - time:15.07 16:11:01.45 - length:4 ---------- Dump:000 00 ed 01 02 .... Q921: SAP=0 (Call Control), R, TEI=118, S-Frame: RR N(R) 1 PF 0 -- NT->TE - unit:0 - frame:000009 - time:15.07 16:11:01.46 - length:4 ---------- Dump:000 00 b5 01 02 .... Q921: SAP=0 (Call Control), R, TEI=90, S-Frame: RR N(R) 1 PF 0 -- NT->TE - unit:0 - frame:000010 - time:15.07 16:11:01.48 - length:4 ---------- Dump:000 00 b5 01 04 .... Q921: SAP=0 (Call Control), R, TEI=90, S-Frame: RR N(R) 2 PF 0 -- NT->TE - unit:0 - frame:000011 - time:15.07 16:11:01.58 - length:12 --------- Dump:000 02 b5 00 04 .... Q921: SAP=0 (Call Control), C, TEI=90, I-Frame: N(S) 0 N(R) 2 P 0 Dump:004 08 01 01 4d 08 02 82 9a ...M.... Q931: pd=Q.931/I.451, cr=0x01 (from origination), message=RELEASE: [cause: 26: Non-selected user clearing (Q.850) (location=public network serving local user, std=CCITT)] -- NT->TE - unit:0 - frame:000012 - time:15.07 16:11:01.58 - length:8 ---------- Dump:000 02 ed 00 02 .... Q921: SAP=0 (Call Control), C, TEI=118, I-Frame: N(S) 0 N(R) 1 P 0 Dump:004 08 01 01 0f .... Q931: pd=Q.931/I.451, cr=0x01 (from origination), message=CONNECT ACKNOWLEDGE: -- TE->NT - unit:0 - frame:000013 - time:15.07 16:11:01.58 - length:4 ---------- Dump:000 02 ed 01 02 .... Q921: SAP=0 (Call Control), R, TEI=118, S-Frame: RR N(R) 1 PF 0 -- NT->TE - unit:0 - frame:000014 - time:15.07 16:11:01.60 - length:15 --------- Dump:000 02 b5 02 04 .... Q921: SAP=0 (Call Control), C, TEI=90, I-Frame: N(S) 1 N(R) 2 P 0 Dump:004 08 01 01 7d 08 02 82 e5 14 01 13 ...}....... Q931: pd=Q.931/I.451, cr=0x01 (from origination), message=STATUS: [cause: 101: Message not compatible with call state (Q.850) (location=public network serving local user, std=CCITT)] [call state: Std=CCITT, State=Release request] -- NT->TE - unit:0 - frame:000015 - time:15.07 16:11:01.60 - length:4 ---------- Dump:000 00 b5 01 06 .... Q921: SAP=0 (Call Control), R, TEI=90, S-Frame: RR N(R) 3 PF 0 -- NT->TE - unit:0 - frame:000016 - time:15.07 16:11:01.62 - length:4 ---------- Dump:000 00 b5 01 08 .... Q921: SAP=0 (Call Control), R, TEI=90, S-Frame: RR N(R) 4 PF 0 -- NT->TE - unit:0 - frame:000017 - time:15.07 16:11:11.40 - length:4 ---------- Dump:000 02 ed 01 03 .... Q921: SAP=0 (Call Control), C, TEI=118, S-Frame: RR N(R) 1 PF 1 -- TE->NT - unit:0 - frame:000018 - time:15.07 16:11:11.40 - length:4 ---------- Dump:000 02 ed 01 03 .... Q921: SAP=0 (Call Control), R, TEI=118, S-Frame: RR N(R) 1 PF 1 -- NT->TE - unit:0 - frame:000019 - time:15.07 16:11:11.41 - length:4 ---------- Dump:000 02 b5 01 09 .... Q921: SAP=0 (Call Control), C, TEI=90, S-Frame: RR N(R) 4 PF 1 -- NT->TE - unit:0 - frame:000020 - time:15.07 16:11:16.61 - length:3 ---------- Dump:000 00 b5 73 ..s Q921: SAP=0 (Call Control), R, TEI=90, U-Frame: UA PF 1 -- NT->TE - unit:0 - frame:000021 - time:15.07 16:11:21.40 - length:4 ---------- Dump:000 02 ed 01 03 .... Q921: SAP=0 (Call Control), C, TEI=118, S-Frame: RR N(R) 1 PF 1 -- TE->NT - unit:0 - frame:000022 - time:15.07 16:11:21.40 - length:4 ---------- Dump:000 02 ed 01 03 .... Q921: SAP=0 (Call Control), R, TEI=118, S-Frame: RR N(R) 1 PF 1 -- NT->TE - unit:0 - frame:000023 - time:15.07 16:11:31.40 - length:4 ---------- Dump:000 02 ed 01 03 .... Q921: SAP=0 (Call Control), C, TEI=118, S-Frame: RR N(R) 1 PF 1 -- TE->NT - unit:0 - frame:000024 - time:15.07 16:11:31.40 - length:4 ---------- Dump:000 02 ed 01 03 .... Q921: SAP=0 (Call Control), R, TEI=118, S-Frame: RR N(R) 1 PF 1 -- NT->TE - unit:0 - frame:000025 - time:15.07 16:11:36.15 - length:12 --------- Dump:000 02 ed 02 02 .... Q921: SAP=0 (Call Control), C, TEI=118, I-Frame: N(S) 1 N(R) 1 P 0 Dump:004 08 01 01 45 08 02 80 90 ...E.... Q931: pd=Q.931/I.451, cr=0x01 (from origination), message=DISCONNECT: [cause: 16: Normal call clearing (Q.850) (location=user, std=CCITT)] -- TE->NT - unit:0 - frame:000026 - time:15.07 16:11:36.15 - length:8 ---------- Dump:000 00 ed 02 04 .... Q921: SAP=0 (Call Control), C, TEI=118, I-Frame: N(S) 1 N(R) 2 P 0 Dump:004 08 01 81 4d ...M Q931: pd=Q.931/I.451, cr=0x01 (from destination), message=RELEASE: -- NT->TE - unit:0 - frame:000027 - time:15.07 16:11:36.16 - length:4 ---------- Dump:000 00 ed 01 04 .... Q921: SAP=0 (Call Control), R, TEI=118, S-Frame: RR N(R) 2 PF 0 -- NT->TE - unit:0 - frame:000028 - time:15.07 16:11:36.26 - length:8 ---------- Dump:000 02 ed 04 04 .... Q921: SAP=0 (Call Control), C, TEI=118, I-Frame: N(S) 2 N(R) 2 P 0 Dump:004 08 01 01 5a ...Z Q931: pd=Q.931/I.451, cr=0x01 (from origination), message=RELEASE COMPLETE: -- TE->NT - unit:0 - frame:000029 - time:15.07 16:11:36.26 - length:4 ---------- Dump:000 02 ed 01 06 .... Q921: SAP=0 (Call Control), R, TEI=118, S-Frame: RR N(R) 3 PF 0 -- NT->TE - unit:0 - frame:000030 - time:15.07 16:11:45.40 - length:4 ---------- Dump:000 02 ed 01 05 .... Q921: SAP=0 (Call Control), C, TEI=118, S-Frame: RR N(R) 2 PF 1 -- TE->NT - unit:0 - frame:000031 - time:15.07 16:11:45.40 - length:4 ---------- Dump:000 02 ed 01 07 .... Q921: SAP=0 (Call Control), R, TEI=118, S-Frame: RR N(R) 3 PF 1 -- NT->TE - unit:0 - frame:000032 - time:15.07 16:11:47.96 - length:40 --------- Dump:000 02 ff 03 ... Q921: SAP=0 (Call Control), C, TEI=127, U-Frame: UI PF 0 Dump:003 08 01 01 05 a1 04 02 88 90 18 01 89 6c 0d 21 81 ............l.!. Dump:019 33 35 31 38 37 33 34 31 32 33 34 70 08 c1 34 31 35187341234p..41 Dump:035 39 31 32 33 36 91236 Q931: pd=Q.931/I.451, cr=0x01 (from origination), message=SETUP: [sending complete] [bearer capability: cap=unrestricted digital information std=CCITT rate=64 kbit/s mode=circuit] [channel id: channel=B-1 (exclusive)] [calling party number: 35187341234 (type=national, plan=ISDN, presentation allowed, screening user provided: verified & passed)] [called party number: 4191236 (type=subscriber, plan=ISDN)] -- TE->NT - unit:0 - frame:000033 - time:15.07 16:11:47.96 - length:8 ---------- Dump:000 00 ed 04 06 .... Q921: SAP=0 (Call Control), C, TEI=118, I-Frame: N(S) 2 N(R) 3 P 0 Dump:004 08 01 81 07 .... Q931: pd=Q.931/I.451, cr=0x01 (from destination), message=CONNECT: -- NT->TE - unit:0 - frame:000034 - time:15.07 16:11:47.97 - length:3 ---------- Dump:000 00 b5 73 ..s Q921: SAP=0 (Call Control), R, TEI=90, U-Frame: UA PF 1 -- NT->TE - unit:0 - frame:000035 - time:15.07 16:11:47.98 - length:4 ---------- Dump:000 00 ed 01 06 .... Q921: SAP=0 (Call Control), R, TEI=118, S-Frame: RR N(R) 3 PF 0 -- NT->TE - unit:0 - frame:000036 - time:15.07 16:11:48.00 - length:4 ---------- Dump:000 00 b5 01 02 .... Q921: SAP=0 (Call Control), R, TEI=90, S-Frame: RR N(R) 1 PF 0 -- NT->TE - unit:0 - frame:000037 - time:15.07 16:11:48.02 - length:4 ---------- Dump:000 00 b5 01 04 .... Q921: SAP=0 (Call Control), R, TEI=90, S-Frame: RR N(R) 2 PF 0 -- NT->TE - unit:0 - frame:000038 - time:15.07 16:11:48.09 - length:8 ---------- Dump:000 02 ed 06 06 .... Q921: SAP=0 (Call Control), C, TEI=118, I-Frame: N(S) 3 N(R) 3 P 0 Dump:004 08 01 01 0f .... Q931: pd=Q.931/I.451, cr=0x01 (from origination), message=CONNECT ACKNOWLEDGE: -- TE->NT - unit:0 - frame:000039 - time:15.07 16:11:48.09 - length:4 ---------- Dump:000 02 ed 01 08 .... Q921: SAP=0 (Call Control), R, TEI=118, S-Frame: RR N(R) 4 PF 0 -- NT->TE - unit:0 - frame:000040 - time:15.07 16:11:48.11 - length:12 --------- Dump:000 02 b5 00 04 .... Q921: SAP=0 (Call Control), C, TEI=90, I-Frame: N(S) 0 N(R) 2 P 0 Dump:004 08 01 01 4d 08 02 82 d1 ...M.... Q931: pd=Q.931/I.451, cr=0x01 (from origination), message=RELEASE: [cause: 81: Invalid call reference value (Q.850) (location=public network serving local user, std=CCITT)] -- NT->TE - unit:0 - frame:000041 - time:15.07 16:11:48.13 - length:15 --------- Dump:000 02 b5 02 04 .... Q921: SAP=0 (Call Control), C, TEI=90, I-Frame: N(S) 1 N(R) 2 P 0 Dump:004 08 01 01 7d 08 02 82 e5 14 01 13 ...}....... Q931: pd=Q.931/I.451, cr=0x01 (from origination), message=STATUS: [cause: 101: Message not compatible with call state (Q.850) (location=public network serving local user, std=CCITT)] [call state: Std=CCITT, State=Release request] -- NT->TE - unit:0 - frame:000042 - time:15.07 16:11:48.13 - length:4 ---------- Dump:000 00 b5 01 06 .... Q921: SAP=0 (Call Control), R, TEI=90, S-Frame: RR N(R) 3 PF 0 -- NT->TE - unit:0 - frame:000043 - time:15.07 16:11:48.15 - length:4 ---------- Dump:000 00 b5 01 08 .... Q921: SAP=0 (Call Control), R, TEI=90, S-Frame: RR N(R) 4 PF 0 -- NT->TE - unit:0 - frame:000044 - time:15.07 16:11:57.40 - length:4 ---------- Dump:000 02 ed 01 07 .... Q921: SAP=0 (Call Control), C, TEI=118, S-Frame: RR N(R) 3 PF 1 -- TE->NT - unit:0 - frame:000045 - time:15.07 16:11:57.40 - length:4 ---------- Dump:000 02 ed 01 09 .... Q921: SAP=0 (Call Control), R, TEI=118, S-Frame: RR N(R) 4 PF 1 -- NT->TE - unit:0 - frame:000046 - time:15.07 16:11:57.40 - length:4 ---------- Dump:000 02 b5 01 09 .... Q921: SAP=0 (Call Control), C, TEI=90, S-Frame: RR N(R) 4 PF 1 -- NT->TE - unit:0 - frame:000047 - time:15.07 16:12:03.14 - length:3 ---------- Dump:000 00 b5 73 ..s Q921: SAP=0 (Call Control), R, TEI=90, U-Frame: UA PF 1 -- NT->TE - unit:0 - frame:000048 - time:15.07 16:12:07.40 - length:4 ---------- Dump:000 02 ed 01 07 .... Q921: SAP=0 (Call Control), C, TEI=118, S-Frame: RR N(R) 3 PF 1 -- TE->NT - unit:0 - frame:000049 - time:15.07 16:12:07.40 - length:4 ---------- Dump:000 02 ed 01 09 .... Q921: SAP=0 (Call Control), R, TEI=118, S-Frame: RR N(R) 4 PF 1 -- NT->TE - unit:0 - frame:000050 - time:15.07 16:12:17.40 - length:4 ---------- Dump:000 02 ed 01 07 .... Q921: SAP=0 (Call Control), C, TEI=118, S-Frame: RR N(R) 3 PF 1 -- TE->NT - unit:0 - frame:000051 - time:15.07 16:12:17.40 - length:4 ---------- Dump:000 02 ed 01 09 .... Q921: SAP=0 (Call Control), R, TEI=118, S-Frame: RR N(R) 4 PF 1 -- NT->TE - unit:0 - frame:000052 - time:15.07 16:12:22.56 - length:12 --------- Dump:000 02 ed 08 06 .... Q921: SAP=0 (Call Control), C, TEI=118, I-Frame: N(S) 4 N(R) 3 P 0 Dump:004 08 01 01 45 08 02 80 90 ...E.... Q931: pd=Q.931/I.451, cr=0x01 (from origination), message=DISCONNECT: [cause: 16: Normal call clearing (Q.850) (location=user, std=CCITT)] -- TE->NT - unit:0 - frame:000053 - time:15.07 16:12:22.56 - length:8 ---------- Dump:000 00 ed 06 0a .... Q921: SAP=0 (Call Control), C, TEI=118, I-Frame: N(S) 3 N(R) 5 P 0 Dump:004 08 01 81 4d ...M Q931: pd=Q.931/I.451, cr=0x01 (from destination), message=RELEASE: -- NT->TE - unit:0 - frame:000054 - time:15.07 16:12:22.58 - length:4 ---------- Dump:000 00 ed 01 08 .... Q921: SAP=0 (Call Control), R, TEI=118, S-Frame: RR N(R) 4 PF 0 -- NT->TE - unit:0 - frame:000055 - time:15.07 16:12:22.64 - length:8 ---------- Dump:000 02 ed 0a 08 .... Q921: SAP=0 (Call Control), C, TEI=118, I-Frame: N(S) 5 N(R) 4 P 0 Dump:004 08 01 01 5a ...Z Q931: pd=Q.931/I.451, cr=0x01 (from origination), message=RELEASE COMPLETE: -- TE->NT - unit:0 - frame:000056 - time:15.07 16:12:22.64 - length:4 ---------- Dump:000 02 ed 01 0c .... Q921: SAP=0 (Call Control), R, TEI=118, S-Frame: RR N(R) 6 PF 0 -- NT->TE - unit:0 - frame:000057 - time:15.07 16:12:32.40 - length:4 ---------- Dump:000 02 ed 01 09 .... Q921: SAP=0 (Call Control), C, TEI=118, S-Frame: RR N(R) 4 PF 1 -- TE->NT - unit:0 - frame:000058 - time:15.07 16:12:32.40 - length:4 ---------- Dump:000 02 ed 01 0d .... Q921: SAP=0 (Call Control), R, TEI=118, S-Frame: RR N(R) 6 PF 1 -- NT->TE - unit:0 - frame:000059 - time:15.07 16:12:42.40 - length:4 ---------- Dump:000 02 ed 01 09 .... Q921: SAP=0 (Call Control), C, TEI=118, S-Frame: RR N(R) 4 PF 1 -- TE->NT - unit:0 - frame:000060 - time:15.07 16:12:42.40 - length:4 ---------- Dump:000 02 ed 01 0d .... Q921: SAP=0 (Call Control), R, TEI=118, S-Frame: RR N(R) 6 PF 1 -- NT->TE - unit:0 - frame:000061 - time:15.07 16:12:52.40 - length:4 ---------- Dump:000 02 ed 01 09 .... Q921: SAP=0 (Call Control), C, TEI=118, S-Frame: RR N(R) 4 PF 1 -- TE->NT - unit:0 - frame:000062 - time:15.07 16:12:52.40 - length:4 ---------- Dump:000 02 ed 01 0d .... Q921: SAP=0 (Call Control), R, TEI=118, S-Frame: RR N(R) 6 PF 1 -- NT->TE - unit:0 - frame:000063 - time:15.07 16:13:02.40 - length:4 ---------- Dump:000 02 ed 01 09 .... Q921: SAP=0 (Call Control), C, TEI=118, S-Frame: RR N(R) 4 PF 1 -- TE->NT - unit:0 - frame:000064 - time:15.07 16:13:02.40 - length:4 ---------- Dump:000 02 ed 01 0d .... Q921: SAP=0 (Call Control), R, TEI=118, S-Frame: RR N(R) 6 PF 1 -- NT->TE - unit:0 - frame:000065 - time:15.07 16:13:12.40 - length:4 ---------- Dump:000 02 ed 01 09 .... Q921: SAP=0 (Call Control), C, TEI=118, S-Frame: RR N(R) 4 PF 1 -- TE->NT - unit:0 - frame:000066 - time:15.07 16:13:12.40 - length:4 ---------- Dump:000 02 ed 01 0d .... Q921: SAP=0 (Call Control), R, TEI=118, S-Frame: RR N(R) 6 PF 1 -- NT->TE - unit:0 - frame:000067 - time:15.07 16:13:22.40 - length:4 ---------- Dump:000 02 ed 01 09 .... Q921: SAP=0 (Call Control), C, TEI=118, S-Frame: RR N(R) 4 PF 1 -- TE->NT - unit:0 - frame:000068 - time:15.07 16:13:22.40 - length:4 ---------- Dump:000 02 ed 01 0d .... Q921: SAP=0 (Call Control), R, TEI=118, S-Frame: RR N(R) 6 PF 1 -- NT->TE - unit:0 - frame:000069 - time:15.07 16:13:32.40 - length:4 ---------- Dump:000 02 ed 01 09 .... Q921: SAP=0 (Call Control), C, TEI=118, S-Frame: RR N(R) 4 PF 1 -- TE->NT - unit:0 - frame:000070 - time:15.07 16:13:32.40 - length:4 ---------- Dump:000 02 ed 01 0d .... Q921: SAP=0 (Call Control), R, TEI=118, S-Frame: RR N(R) 6 PF 1 -- NT->TE - unit:0 - frame:000071 - time:15.07 16:13:42.40 - length:4 ---------- Dump:000 02 ed 01 09 .... Q921: SAP=0 (Call Control), C, TEI=118, S-Frame: RR N(R) 4 PF 1 -- TE->NT - unit:0 - frame:000072 - time:15.07 16:13:42.40 - length:4 ---------- Dump:000 02 ed 01 0d .... Q921: SAP=0 (Call Control), R, TEI=118, S-Frame: RR N(R) 6 PF 1 -- NT->TE - unit:0 - frame:000073 - time:15.07 16:13:52.40 - length:4 ---------- Dump:000 02 ed 01 09 .... Q921: SAP=0 (Call Control), C, TEI=118, S-Frame: RR N(R) 4 PF 1 -- TE->NT - unit:0 - frame:000074 - time:15.07 16:13:52.40 - length:4 ---------- Dump:000 02 ed 01 0d .... Q921: SAP=0 (Call Control), R, TEI=118, S-Frame: RR N(R) 6 PF 1 -- NT->TE - unit:0 - frame:000075 - time:15.07 16:14:02.40 - length:4 ---------- Dump:000 02 ed 01 09 .... Q921: SAP=0 (Call Control), C, TEI=118, S-Frame: RR N(R) 4 PF 1 -- TE->NT - unit:0 - frame:000076 - time:15.07 16:14:02.40 - length:4 ---------- Dump:000 02 ed 01 0d .... Q921: SAP=0 (Call Control), R, TEI=118, S-Frame: RR N(R) 6 PF 1 -- NT->TE - unit:0 - frame:000077 - time:15.07 16:14:12.40 - length:4 ---------- Dump:000 02 ed 01 09 .... Q921: SAP=0 (Call Control), C, TEI=118, S-Frame: RR N(R) 4 PF 1 -- TE->NT - unit:0 - frame:000078 - time:15.07 16:14:12.40 - length:4 ---------- Dump:000 02 ed 01 0d .... Q921: SAP=0 (Call Control), R, TEI=118, S-Frame: RR N(R) 6 PF 1 -- NT->TE - unit:0 - frame:000079 - time:15.07 16:14:22.40 - length:4 ---------- Dump:000 02 ed 01 09 .... Q921: SAP=0 (Call Control), C, TEI=118, S-Frame: RR N(R) 4 PF 1 -- TE->NT - unit:0 - frame:000080 - time:15.07 16:14:22.40 - length:4 ---------- Dump:000 02 ed 01 0d .... Q921: SAP=0 (Call Control), R, TEI=118, S-Frame: RR N(R) 6 PF 1 -- NT->TE - unit:0 - frame:000081 - time:15.07 16:14:32.40 - length:4 ---------- Dump:000 02 ed 01 09 .... Q921: SAP=0 (Call Control), C, TEI=118, S-Frame: RR N(R) 4 PF 1 -- TE->NT - unit:0 - frame:000082 - time:15.07 16:14:32.40 - length:4 ---------- Dump:000 02 ed 01 0d .... Q921: SAP=0 (Call Control), R, TEI=118, S-Frame: RR N(R) 6 PF 1 -- NT->TE - unit:0 - frame:000083 - time:15.07 16:14:42.40 - length:4 ---------- Dump:000 02 ed 01 09 .... Q921: SAP=0 (Call Control), C, TEI=118, S-Frame: RR N(R) 4 PF 1 -- TE->NT - unit:0 - frame:000084 - time:15.07 16:14:42.40 - length:4 ---------- Dump:000 02 ed 01 0d .... Q921: SAP=0 (Call Control), R, TEI=118, S-Frame: RR N(R) 6 PF 1 -- NT->TE - unit:0 - frame:000085 - time:15.07 16:14:52.40 - length:4 ---------- Dump:000 02 ed 01 09 .... Q921: SAP=0 (Call Control), C, TEI=118, S-Frame: RR N(R) 4 PF 1 -- TE->NT - unit:0 - frame:000086 - time:15.07 16:14:52.40 - length:4 ---------- Dump:000 02 ed 01 0d .... Q921: SAP=0 (Call Control), R, TEI=118, S-Frame: RR N(R) 6 PF 1 -- NT->TE - unit:0 - frame:000087 - time:15.07 16:15:02.40 - length:4 ---------- Dump:000 02 ed 01 09 .... Q921: SAP=0 (Call Control), C, TEI=118, S-Frame: RR N(R) 4 PF 1 -- TE->NT - unit:0 - frame:000088 - time:15.07 16:15:02.40 - length:4 ---------- Dump:000 02 ed 01 0d .... Q921: SAP=0 (Call Control), R, TEI=118, S-Frame: RR N(R) 6 PF 1 -- NT->TE - unit:0 - frame:000089 - time:15.07 16:15:12.40 - length:4 ---------- Dump:000 02 ed 01 09 .... Q921: SAP=0 (Call Control), C, TEI=118, S-Frame: RR N(R) 4 PF 1 -- TE->NT - unit:0 - frame:000090 - time:15.07 16:15:12.40 - length:4 ---------- Dump:000 02 ed 01 0d .... Q921: SAP=0 (Call Control), R, TEI=118, S-Frame: RR N(R) 6 PF 1 -- NT->TE - unit:0 - frame:000091 - time:15.07 16:15:22.40 - length:4 ---------- Dump:000 02 ed 01 09 .... Q921: SAP=0 (Call Control), C, TEI=118, S-Frame: RR N(R) 4 PF 1 -- TE->NT - unit:0 - frame:000092 - time:15.07 16:15:22.40 - length:4 ---------- Dump:000 02 ed 01 0d .... Q921: SAP=0 (Call Control), R, TEI=118, S-Frame: RR N(R) 6 PF 1 -- NT->TE - unit:0 - frame:000093 - time:15.07 16:15:32.40 - length:4 ---------- Dump:000 02 ed 01 09 .... Q921: SAP=0 (Call Control), C, TEI=118, S-Frame: RR N(R) 4 PF 1 -- TE->NT - unit:0 - frame:000094 - time:15.07 16:15:32.40 - length:4 ---------- Dump:000 02 ed 01 0d .... Q921: SAP=0 (Call Control), R, TEI=118, S-Frame: RR N(R) 6 PF 1 -- NT->TE - unit:0 - frame:000095 - time:15.07 16:15:42.40 - length:4 ---------- Dump:000 02 ed 01 09 .... Q921: SAP=0 (Call Control), C, TEI=118, S-Frame: RR N(R) 4 PF 1 -- TE->NT - unit:0 - frame:000096 - time:15.07 16:15:42.40 - length:4 ---------- Dump:000 02 ed 01 0d .... Q921: SAP=0 (Call Control), R, TEI=118, S-Frame: RR N(R) 6 PF 1 -- NT->TE - unit:0 - frame:000097 - time:15.07 16:15:52.40 - length:4 ---------- Dump:000 02 ed 01 09 .... Q921: SAP=0 (Call Control), C, TEI=118, S-Frame: RR N(R) 4 PF 1 -- TE->NT - unit:0 - frame:000098 - time:15.07 16:15:52.40 - length:4 ---------- Dump:000 02 ed 01 0d .... Q921: SAP=0 (Call Control), R, TEI=118, S-Frame: RR N(R) 6 PF 1 -- NT->TE - unit:0 - frame:000099 - time:15.07 16:16:02.40 - length:4 ---------- Dump:000 02 ed 01 09 .... Q921: SAP=0 (Call Control), C, TEI=118, S-Frame: RR N(R) 4 PF 1 -- TE->NT - unit:0 - frame:000100 - time:15.07 16:16:02.40 - length:4 ---------- Dump:000 02 ed 01 0d .... Q921: SAP=0 (Call Control), R, TEI=118, S-Frame: RR N(R) 6 PF 1 -- NT->TE - unit:0 - frame:000101 - time:15.07 16:16:12.40 - length:4 ---------- Dump:000 02 ed 01 09 .... Q921: SAP=0 (Call Control), C, TEI=118, S-Frame: RR N(R) 4 PF 1 -- TE->NT - unit:0 - frame:000102 - time:15.07 16:16:12.40 - length:4 ---------- Dump:000 02 ed 01 0d .... Q921: SAP=0 (Call Control), R, TEI=118, S-Frame: RR N(R) 6 PF 1 -- NT->TE - unit:0 - frame:000103 - time:15.07 16:16:22.40 - length:4 ---------- Dump:000 02 ed 01 09 .... Q921: SAP=0 (Call Control), C, TEI=118, S-Frame: RR N(R) 4 PF 1 -- TE->NT - unit:0 - frame:000104 - time:15.07 16:16:22.40 - length:4 ---------- Dump:000 02 ed 01 0d .... Q921: SAP=0 (Call Control), R, TEI=118, S-Frame: RR N(R) 6 PF 1 -- NT->TE - unit:0 - frame:000105 - time:15.07 16:16:32.39 - length:4 ---------- Dump:000 02 ed 01 09 .... Q921: SAP=0 (Call Control), C, TEI=118, S-Frame: RR N(R) 4 PF 1 -- TE->NT - unit:0 - frame:000106 - time:15.07 16:16:32.39 - length:4 ---------- Dump:000 02 ed 01 0d .... Q921: SAP=0 (Call Control), R, TEI=118, S-Frame: RR N(R) 6 PF 1 -- NT->TE - unit:0 - frame:000107 - time:15.07 16:16:42.40 - length:4 ---------- Dump:000 02 ed 01 09 .... Q921: SAP=0 (Call Control), C, TEI=118, S-Frame: RR N(R) 4 PF 1 -- TE->NT - unit:0 - frame:000108 - time:15.07 16:16:42.40 - length:4 ---------- Dump:000 02 ed 01 0d .... Q921: SAP=0 (Call Control), R, TEI=118, S-Frame: RR N(R) 6 PF 1 -- NT->TE - unit:0 - frame:000109 - time:15.07 16:16:52.40 - length:4 ---------- Dump:000 02 ed 01 09 .... Q921: SAP=0 (Call Control), C, TEI=118, S-Frame: RR N(R) 4 PF 1 -- TE->NT - unit:0 - frame:000110 - time:15.07 16:16:52.40 - length:4 ---------- Dump:000 02 ed 01 0d .... Q921: SAP=0 (Call Control), R, TEI=118, S-Frame: RR N(R) 6 PF 1 -- NT->TE - unit:0 - frame:000111 - time:15.07 16:17:02.40 - length:4 ---------- Dump:000 02 ed 01 09 .... Q921: SAP=0 (Call Control), C, TEI=118, S-Frame: RR N(R) 4 PF 1 -- TE->NT - unit:0 - frame:000112 - time:15.07 16:17:02.40 - length:4 ---------- Dump:000 02 ed 01 0d .... Q921: SAP=0 (Call Control), R, TEI=118, S-Frame: RR N(R) 6 PF 1 -- NT->TE - unit:0 - frame:000113 - time:15.07 16:17:12.40 - length:4 ---------- Dump:000 02 ed 01 09 .... Q921: SAP=0 (Call Control), C, TEI=118, S-Frame: RR N(R) 4 PF 1 -- TE->NT - unit:0 - frame:000114 - time:15.07 16:17:12.40 - length:4 ---------- Dump:000 02 ed 01 0d .... Q921: SAP=0 (Call Control), R, TEI=118, S-Frame: RR N(R) 6 PF 1 -- Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Thu Jul 16 02:50:02 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA17412 for freebsd-isdn-outgoing; Thu, 16 Jul 1998 02:50:02 -0700 (PDT) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from gilberto.physik.RWTH-Aachen.DE (gilberto.physik.rwth-aachen.de [137.226.30.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA17354 for ; Thu, 16 Jul 1998 02:49:57 -0700 (PDT) (envelope-from kuku@gilberto.physik.RWTH-Aachen.DE) Received: (from kuku@localhost) by gilberto.physik.RWTH-Aachen.DE (8.8.8/8.8.7) id LAA29546 for freebsd-isdn@freebsd.org; Thu, 16 Jul 1998 11:49:53 +0200 (MEST) (envelope-from kuku) Date: Thu, 16 Jul 1998 11:49:53 +0200 (MEST) From: Christoph Kukulies Message-Id: <199807160949.LAA29546@gilberto.physik.RWTH-Aachen.DE> To: freebsd-isdn@FreeBSD.ORG Subject: incoming alert - what does it mean? Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In the log on vty6 (isdnd full screen log) I'm seeing 16.07.98 11:42:35 CHD 00001 rwth rate 90 sec/unit (rate) 16.07.98 11:42:35 CHD 00001 rwth dialing from 4191236 to 441291234 16.07.98 11:42:35 CHD 00001 rwth outgoing call proceeding (ctl 0, ch 0) 16.07.98 11:42:35 CHD 00001 rwth incoming alert <<<<<<<<<<<<<<< 16.07.98 11:42:35 CHD 00001 rwth outgoing call active (ctl 0, ch 0) What does this 'incoming alert' mean? -- Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Thu Jul 16 06:52:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA12735 for freebsd-isdn-outgoing; Thu, 16 Jul 1998 06:52:59 -0700 (PDT) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from hcshh.hcs.de (hcshh.hcs.de [194.123.40.1]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id GAA12724 for ; Thu, 16 Jul 1998 06:52:54 -0700 (PDT) (envelope-from hm@hcs.de) Received: from hcswork.hcs.de([192.76.124.5]) (1545 bytes) by hcshh.hcs.de via sendmail with P:smtp/R:inet_hosts/T:smtp (sender: ) id for ; Thu, 16 Jul 1998 15:52:26 +0200 (METDST) (Smail-3.2.0.101 1997-Dec-17 #2 built 1998-Jun-26) Received: by hcswork.hcs.de (Smail3.1.29.0 #12) id m0ywoUd-0000aoC; Thu, 16 Jul 98 15:54 METDST Message-Id: From: hm@hcs.de (Hellmuth Michaelis) Subject: Re: incoming alert - what does it mean? In-Reply-To: <199807160949.LAA29546@gilberto.physik.RWTH-Aachen.DE> from Christoph Kukulies at "Jul 16, 98 11:49:53 am" To: kuku@gilberto.physik.RWTH-Aachen.DE (Christoph Kukulies) Date: Thu, 16 Jul 1998 15:54:42 +0200 (METDST) 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 Christoph Kukulies: > 16.07.98 11:42:35 CHD 00001 rwth outgoing call proceeding (ctl 0, ch 0) > 16.07.98 11:42:35 CHD 00001 rwth incoming alert <<<<<<<<<<<<<<< > 16.07.98 11:42:35 CHD 00001 rwth outgoing call active (ctl 0, ch 0) > > What does this 'incoming alert' mean? It "rings" at the remote end. hellmuth -- Hellmuth Michaelis Tel +49 40 559747-70 HCS Hanseatischer Computerservice GmbH Fax +49 40 559747-77 Oldesloer Strasse 97-99 Mail hm@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 Thu Jul 16 07:25:12 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA16653 for freebsd-isdn-outgoing; Thu, 16 Jul 1998 07:25:12 -0700 (PDT) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from hcshh.hcs.de (hcshh.hcs.de [194.123.40.1]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id HAA16635 for ; Thu, 16 Jul 1998 07:25:07 -0700 (PDT) (envelope-from hm@hcs.de) Received: from hcswork.hcs.de([192.76.124.5]) (12313 bytes) by hcshh.hcs.de via sendmail with P:smtp/R:inet_hosts/T:smtp (sender: ) id for ; Thu, 16 Jul 1998 16:24:40 +0200 (METDST) (Smail-3.2.0.101 1997-Dec-17 #2 built 1998-Jun-26) Received: by hcswork.hcs.de (Smail3.1.29.0 #12) id m0ywozl-0000dfC; Thu, 16 Jul 98 16:26 METDST Message-Id: From: hm@hcs.de (Hellmuth Michaelis) Subject: Re: i4b coexistence with NT on same S0 bus In-Reply-To: <199807160919.LAA29396@gilberto.physik.RWTH-Aachen.DE> from Christoph Kukulies at "Jul 16, 98 11:19:36 am" To: kuku@gilberto.physik.RWTH-Aachen.DE (Christoph Kukulies) Date: Thu, 16 Jul 1998 16:26:52 +0200 (METDST) 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 Christoph Kukulies: [this is a long mail .... -hm] > Suddenly, since I installed i4b I'm conflicting with other services > which are using the S0 bus. This used to work smoothly under bisdn. > > Now it seems that a number which is not in the entry section of > /etc/isdn/isdnd.rc is being accepted and then rejected. > > I'm not sure if it's because of the I4BTEL service is configured > to allow anyone call in. OTOH the opposite site is not requesting the > TEL service. > > This trace is showing the unwanted reaction of i4b: Hmm, lets see: > -- NT->TE - unit:0 - frame:000001 - time:15.07 16:11:01.40 - length:40 --------- > Dump:000 02 ff 03 ... > Q921: SAP=0 (Call Control), C, TEI=127, U-Frame: UI PF 0 > Dump:003 08 01 01 05 a1 04 02 88 90 18 01 89 6c 0d 21 81 ............l.!. > Dump:019 33 35 31 38 37 33 34 31 32 33 34 70 08 c1 34 31 35187341234p..41 > Dump:035 39 31 32 33 36 91236 > Q931: pd=Q.931/I.451, cr=0x01 (from origination), message=SETUP: > [sending complete] > [bearer capability: > cap=unrestricted digital information > std=CCITT > rate=64 kbit/s > mode=circuit] > [channel id: channel=B-1 (exclusive)] > [calling party number: 35187341234 (type=national, plan=ISDN, > presentation allowed, screening user provided: verified & passed)] > [called party number: 4191236 (type=subscriber, plan=ISDN)] An incoming call comes in. From: 35187341234 To: 4191236 Service: data transfer (not telephony!) > -- TE->NT - unit:0 - frame:000002 - time:15.07 16:11:01.40 - length:8 ---------- > Dump:000 fc ff 03 0f 5a b9 01 ff ....Z... > Q921: SAP=63 (TEI-Management), C, TEI=127, Ri=0xb95a, IdRequest, Ai=127 > > -- NT->TE - unit:0 - frame:000003 - time:15.07 16:11:01.42 - length:8 ---------- > Dump:000 fe ff 03 0f 5a b9 02 ed ....Z... > Q921: SAP=63 (TEI-Management), C, TEI=127, Ri=0xb95a, IdAssign, Ai=118 the isdn4bsd machine requests a TEI and gets one, it got TEI 118. > -- TE->NT - unit:0 - frame:000006 - time:15.07 16:11:01.43 - length:8 ---------- > Dump:000 00 ed 00 00 .... > Q921: SAP=0 (Call Control), C, TEI=118, I-Frame: N(S) 0 N(R) 0 P 0 > Dump:004 08 01 81 07 .... > Q931: pd=Q.931/I.451, cr=0x01 (from destination), message=CONNECT: the isdn4bsd machine accepts the call. In order to do this, there must be an entry matching: From: 35187341234 To: 4191236 Service: data transfer (not telephony!) > -- NT->TE - unit:0 - frame:000007 - time:15.07 16:11:01.44 - length:3 ---------- > Dump:000 00 b5 73 ..s > Q921: SAP=0 (Call Control), R, TEI=90, U-Frame: UA PF 1 This seems to be your NT machine, it has TEI 90. > -- NT->TE - unit:0 - frame:000011 - time:15.07 16:11:01.58 - length:12 --------- > Dump:000 02 b5 00 04 .... > Q921: SAP=0 (Call Control), C, TEI=90, I-Frame: N(S) 0 N(R) 2 P 0 > Dump:004 08 01 01 4d 08 02 82 9a ...M.... > Q931: pd=Q.931/I.451, cr=0x01 (from origination), message=RELEASE: > [cause: 26: Non-selected user clearing (Q.850) > (location=public network serving local user, std=CCITT)] And the NT gets a RELEASE from the exchange with cause = 26. Cause 26 is: "This cause indicates that the user has not been awarded the incoming call". Quite normal..... > -- NT->TE - unit:0 - frame:000012 - time:15.07 16:11:01.58 - length:8 ---------- > Dump:000 02 ed 00 02 .... > Q921: SAP=0 (Call Control), C, TEI=118, I-Frame: N(S) 0 N(R) 1 P 0 > Dump:004 08 01 01 0f .... > Q931: pd=Q.931/I.451, cr=0x01 (from origination), message=CONNECT ACKNOWLEDGE: Because i4b (with the better OS !! :-)) has gotten the call! > -- NT->TE - unit:0 - frame:000014 - time:15.07 16:11:01.60 - length:15 --------- > Dump:000 02 b5 02 04 .... > Q921: SAP=0 (Call Control), C, TEI=90, I-Frame: N(S) 1 N(R) 2 P 0 > Dump:004 08 01 01 7d 08 02 82 e5 14 01 13 ...}....... > Q931: pd=Q.931/I.451, cr=0x01 (from origination), message=STATUS: > [cause: 101: Message not compatible with call state (Q.850) > (location=public network serving local user, std=CCITT)] > [call state: Std=CCITT, State=Release request] Then the NT machine does something bad (not that unusual): a protocol violation. > -- NT->TE - unit:0 - frame:000025 - time:15.07 16:11:36.15 - length:12 --------- > Dump:000 02 ed 02 02 .... > Q921: SAP=0 (Call Control), C, TEI=118, I-Frame: N(S) 1 N(R) 1 P 0 > Dump:004 08 01 01 45 08 02 80 90 ...E.... > Q931: pd=Q.931/I.451, cr=0x01 (from origination), message=DISCONNECT: > [cause: 16: Normal call clearing (Q.850) > (location=user, std=CCITT)] > > -- TE->NT - unit:0 - frame:000026 - time:15.07 16:11:36.15 - length:8 ---------- > Dump:000 00 ed 02 04 .... > Q921: SAP=0 (Call Control), C, TEI=118, I-Frame: N(S) 1 N(R) 2 P 0 > Dump:004 08 01 81 4d ...M > Q931: pd=Q.931/I.451, cr=0x01 (from destination), message=RELEASE: > > -- NT->TE - unit:0 - frame:000027 - time:15.07 16:11:36.16 - length:4 ---------- > Dump:000 00 ed 01 04 .... > Q921: SAP=0 (Call Control), R, TEI=118, S-Frame: RR N(R) 2 PF 0 > > -- NT->TE - unit:0 - frame:000028 - time:15.07 16:11:36.26 - length:8 ---------- > Dump:000 02 ed 04 04 .... > Q921: SAP=0 (Call Control), C, TEI=118, I-Frame: N(S) 2 N(R) 2 P 0 > Dump:004 08 01 01 5a ...Z > Q931: pd=Q.931/I.451, cr=0x01 (from origination), message=RELEASE COMPLETE: After some time the remote side disconnects from the i4b side. Then, the very same remote calls in again: > -- NT->TE - unit:0 - frame:000032 - time:15.07 16:11:47.96 - length:40 --------- > Dump:000 02 ff 03 ... > Q921: SAP=0 (Call Control), C, TEI=127, U-Frame: UI PF 0 > Dump:003 08 01 01 05 a1 04 02 88 90 18 01 89 6c 0d 21 81 ............l.!. > Dump:019 33 35 31 38 37 33 34 31 32 33 34 70 08 c1 34 31 35187341234p..41 > Dump:035 39 31 32 33 36 91236 > Q931: pd=Q.931/I.451, cr=0x01 (from origination), message=SETUP: > [sending complete] > [bearer capability: > cap=unrestricted digital information > std=CCITT > rate=64 kbit/s > mode=circuit] > [channel id: channel=B-1 (exclusive)] > [calling party number: 35187341234 (type=national, plan=ISDN, > presentation allowed, screening user provided: verified & passed)] > [called party number: 4191236 (type=subscriber, plan=ISDN)] > > -- TE->NT - unit:0 - frame:000033 - time:15.07 16:11:47.96 - length:8 ---------- > Dump:000 00 ed 04 06 .... > Q921: SAP=0 (Call Control), C, TEI=118, I-Frame: N(S) 2 N(R) 3 P 0 > Dump:004 08 01 81 07 .... > Q931: pd=Q.931/I.451, cr=0x01 (from destination), message=CONNECT: The i4b machine wants to get the call ... > -- NT->TE - unit:0 - frame:000038 - time:15.07 16:11:48.09 - length:8 ---------- > Dump:000 02 ed 06 06 .... > Q921: SAP=0 (Call Control), C, TEI=118, I-Frame: N(S) 3 N(R) 3 P 0 > Dump:004 08 01 01 0f .... > Q931: pd=Q.931/I.451, cr=0x01 (from origination), message=CONNECT ACKNOWLEDGE: and gets it again! > -- NT->TE - unit:0 - frame:000040 - time:15.07 16:11:48.11 - length:12 --------- > Dump:000 02 b5 00 04 .... > Q921: SAP=0 (Call Control), C, TEI=90, I-Frame: N(S) 0 N(R) 2 P 0 > Dump:004 08 01 01 4d 08 02 82 d1 ...M.... > Q931: pd=Q.931/I.451, cr=0x01 (from origination), message=RELEASE: > [cause: 81: Invalid call reference value (Q.850) > (location=public network serving local user, std=CCITT)] > > -- NT->TE - unit:0 - frame:000041 - time:15.07 16:11:48.13 - length:15 --------- > Dump:000 02 b5 02 04 .... > Q921: SAP=0 (Call Control), C, TEI=90, I-Frame: N(S) 1 N(R) 2 P 0 > Dump:004 08 01 01 7d 08 02 82 e5 14 01 13 ...}....... > Q931: pd=Q.931/I.451, cr=0x01 (from origination), message=STATUS: > [cause: 101: Message not compatible with call state (Q.850) > (location=public network serving local user, std=CCITT)] > [call state: Std=CCITT, State=Release request] And the NT machine did something nasty again. After some time the remote machine disconnects again from the i4b machine > -- NT->TE - unit:0 - frame:000052 - time:15.07 16:12:22.56 - length:12 --------- > Dump:000 02 ed 08 06 .... > Q921: SAP=0 (Call Control), C, TEI=118, I-Frame: N(S) 4 N(R) 3 P 0 > Dump:004 08 01 01 45 08 02 80 90 ...E.... > Q931: pd=Q.931/I.451, cr=0x01 (from origination), message=DISCONNECT: > [cause: 16: Normal call clearing (Q.850) > (location=user, std=CCITT)] > > -- TE->NT - unit:0 - frame:000053 - time:15.07 16:12:22.56 - length:8 ---------- > Dump:000 00 ed 06 0a .... > Q921: SAP=0 (Call Control), C, TEI=118, I-Frame: N(S) 3 N(R) 5 P 0 > Dump:004 08 01 81 4d ...M > Q931: pd=Q.931/I.451, cr=0x01 (from destination), message=RELEASE: > > -- NT->TE - unit:0 - frame:000054 - time:15.07 16:12:22.58 - length:4 ---------- > Dump:000 00 ed 01 08 .... > Q921: SAP=0 (Call Control), R, TEI=118, S-Frame: RR N(R) 4 PF 0 > > -- NT->TE - unit:0 - frame:000055 - time:15.07 16:12:22.64 - length:8 ---------- > Dump:000 02 ed 0a 08 .... > Q921: SAP=0 (Call Control), C, TEI=118, I-Frame: N(S) 5 N(R) 4 P 0 > Dump:004 08 01 01 5a ...Z > Q931: pd=Q.931/I.451, cr=0x01 (from origination), message=RELEASE COMPLETE: And thats it. There is nothing strange going on. It seems that the NT _and_ the i4b machine have some identical configuration and want _both_ to take that incoming call. When 2 devices compete for an incoming call, the fastest one sending the CONNECT message gets the call. This seems to be your situation - the i4b machine is faster. This might have been different with bisdn, because that was slower than i4b. hellmuth -- Hellmuth Michaelis Tel +49 40 559747-70 HCS Hanseatischer Computerservice GmbH Fax +49 40 559747-77 Oldesloer Strasse 97-99 Mail hm@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 Thu Jul 16 10:20:43 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA12674 for freebsd-isdn-outgoing; Thu, 16 Jul 1998 10:20:43 -0700 (PDT) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from gilberto.physik.RWTH-Aachen.DE (gilberto.physik.rwth-aachen.de [137.226.30.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA12653 for ; Thu, 16 Jul 1998 10:20:37 -0700 (PDT) (envelope-from kuku@gilberto.physik.RWTH-Aachen.DE) Received: (from kuku@localhost) by gilberto.physik.RWTH-Aachen.DE (8.8.8/8.8.7) id TAA01589 for freebsd-isdn@freebsd.org; Thu, 16 Jul 1998 19:20:43 +0200 (MEST) (envelope-from kuku) Date: Thu, 16 Jul 1998 19:20:43 +0200 (MEST) From: Christoph Kukulies Message-Id: <199807161720.TAA01589@gilberto.physik.RWTH-Aachen.DE> To: freebsd-isdn@FreeBSD.ORG Subject: could i4b influence sound? Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org My sound applications (midi) are choppy and expose periodical pauses. This is with the native FreeBSD sound driver as well as with the OSS/FreeBSD lkm (4Front Technologies). -- Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Thu Jul 16 11:56:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA26695 for freebsd-isdn-outgoing; Thu, 16 Jul 1998 11:56:20 -0700 (PDT) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from hcshh.hcs.de (hcshh.hcs.de [194.123.40.1]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id LAA26690 for ; Thu, 16 Jul 1998 11:56:18 -0700 (PDT) (envelope-from hm@hcs.de) Received: from hcswork.hcs.de([192.76.124.5]) (1476 bytes) by hcshh.hcs.de via sendmail with P:smtp/R:inet_hosts/T:smtp (sender: ) id for ; Thu, 16 Jul 1998 20:55:40 +0200 (METDST) (Smail-3.2.0.101 1997-Dec-17 #2 built 1998-Jun-26) Received: by hcswork.hcs.de (Smail3.1.29.0 #12) id m0ywtE6-0000dzC; Thu, 16 Jul 98 20:57 METDST Message-Id: From: hm@hcs.de (Hellmuth Michaelis) Subject: Re: i4b coexistence with NT on same S0 bus In-Reply-To: <19980716164530.A677@gil.physik.rwth-aachen.de> from Christoph Kukulies at "Jul 16, 98 04:45:30 pm" To: kuku@gilberto.physik.RWTH-Aachen.DE (Christoph Kukulies) Date: Thu, 16 Jul 1998 20:57:57 +0200 (METDST) Cc: freebsd-isdn@FreeBSD.ORG (ISDN Mailinglist) 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 Christoph Kukulies: > My problem solved such that I had a missing entry remote-phone-incoming > in my entry so that the calling number was accepted by the entry: This is a fat bug in isdnd, which has just been fixed ;-) hellmuth -- Hellmuth Michaelis Tel +49 40 559747-70 HCS Hanseatischer Computerservice GmbH Fax +49 40 559747-77 Oldesloer Strasse 97-99 Mail hm@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 Thu Jul 16 11:59:11 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA27141 for freebsd-isdn-outgoing; Thu, 16 Jul 1998 11:59:11 -0700 (PDT) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from hcshh.hcs.de (hcshh.hcs.de [194.123.40.1]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id LAA27123 for ; Thu, 16 Jul 1998 11:59:08 -0700 (PDT) (envelope-from hm@hcs.de) Received: from hcswork.hcs.de([192.76.124.5]) (1485 bytes) by hcshh.hcs.de via sendmail with P:smtp/R:inet_hosts/T:smtp (sender: ) id for ; Thu, 16 Jul 1998 20:58:41 +0200 (METDST) (Smail-3.2.0.101 1997-Dec-17 #2 built 1998-Jun-26) Received: by hcswork.hcs.de (Smail3.1.29.0 #12) id m0ywtH1-0000dzC; Thu, 16 Jul 98 21:00 METDST Message-Id: From: hm@hcs.de (Hellmuth Michaelis) Subject: Re: could i4b influence sound? In-Reply-To: <199807161720.TAA01589@gilberto.physik.RWTH-Aachen.DE> from Christoph Kukulies at "Jul 16, 98 07:20:43 pm" To: kuku@gilberto.physik.RWTH-Aachen.DE (Christoph Kukulies) Date: Thu, 16 Jul 1998 21:00:59 +0200 (METDST) 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 Christoph Kukulies: > My sound applications (midi) are choppy and expose periodical pauses. It might be possible that i4b is the cause. Is an ISDN data transfer happening at this time ? Or does it happen all the time ? What type of card are you using ? hellmuth -- Hellmuth Michaelis Tel +49 40 559747-70 HCS Hanseatischer Computerservice GmbH Fax +49 40 559747-77 Oldesloer Strasse 97-99 Mail hm@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 Thu Jul 16 23:38:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA26077 for freebsd-isdn-outgoing; Thu, 16 Jul 1998 23:38:15 -0700 (PDT) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from gilberto.physik.RWTH-Aachen.DE (gilberto.physik.rwth-aachen.de [137.226.30.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA26070 for ; Thu, 16 Jul 1998 23:38:12 -0700 (PDT) (envelope-from kuku@gilberto.physik.RWTH-Aachen.DE) Received: (from kuku@localhost) by gilberto.physik.RWTH-Aachen.DE (8.8.8/8.8.7) id IAA04728; Fri, 17 Jul 1998 08:38:03 +0200 (MEST) (envelope-from kuku) Message-ID: <19980717083803.A4710@gil.physik.rwth-aachen.de> Date: Fri, 17 Jul 1998 08:38:03 +0200 From: Christoph Kukulies To: hm@hcs.de, Christoph Kukulies Cc: freebsd-isdn@FreeBSD.ORG Subject: Re: could i4b influence sound? References: <199807161720.TAA01589@gilberto.physik.RWTH-Aachen.DE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91 In-Reply-To: ; from Hellmuth Michaelis on Thu, Jul 16, 1998 at 09:00:59PM +0200 Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Jul 16, 1998 at 09:00:59PM +0200, Hellmuth Michaelis wrote: > >From the keyboard of Christoph Kukulies: > > > My sound applications (midi) are choppy and expose periodical pauses. > > It might be possible that i4b is the cause. Is an ISDN data transfer > happening at this time ? Or does it happen all the time ? What type of > card are you using ? No, I think the line was idle when this happens. It also doesn't seem to be correlated with the logs in /var/tmp/isdn.trace when I enable tracing which I first thought. Anyway, it seems to be happening at fixed time intervalls (that the sound stops playing). Well, the sound driver uses DMA and it's essential that the DMA done interrupt is being served with highest priority. > # AVM A1 or AVM Fritz!Card options "AVM_A1" device isic0 at isa? port 0x340 net irq 5 flags 0x08 vector isici ntr ##controller snd0 ##device gus0 at isa? port 0x220 irq 12 drq 1 flags 0x3 vector gusintr Whether I enable the FreeBSD-2.2.6 native sound driver in the kernel or use the OSS/FreeBSD (4front) driver lkm - I bought it spontaneously over the net yesterday (USD 20.00) - , it makes no difference. I'm in the course of building a generic kernel without i4b now an try to find out if i4b is related to that in any way. > hellmuth > -- > Hellmuth Michaelis Tel +49 40 559747-70 > HCS Hanseatischer Computerservice GmbH Fax +49 40 559747-77 > Oldesloer Strasse 97-99 Mail hm@hcs.de > 22457 Hamburg WWW http://www.hcs.de -- --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Fri Jul 17 01:17:07 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA04218 for freebsd-isdn-outgoing; Fri, 17 Jul 1998 01:17:07 -0700 (PDT) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from gilberto.physik.RWTH-Aachen.DE (gilberto.physik.rwth-aachen.de [137.226.30.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA04213 for ; Fri, 17 Jul 1998 01:16:57 -0700 (PDT) (envelope-from kuku@gilberto.physik.RWTH-Aachen.DE) Received: (from kuku@localhost) by gilberto.physik.RWTH-Aachen.DE (8.8.8/8.8.7) id KAA05084; Fri, 17 Jul 1998 10:16:43 +0200 (MEST) (envelope-from kuku) Message-ID: <19980717101643.B4996@gil.physik.rwth-aachen.de> Date: Fri, 17 Jul 1998 10:16:43 +0200 From: Christoph Kukulies To: hm@hcs.de, Christoph Kukulies Cc: ISDN Mailinglist Subject: Re: i4b coexistence with NT on same S0 bus References: <19980716164530.A677@gil.physik.rwth-aachen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91 In-Reply-To: ; from Hellmuth Michaelis on Thu, Jul 16, 1998 at 08:57:57PM +0200 Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Jul 16, 1998 at 08:57:57PM +0200, Hellmuth Michaelis wrote: > >From the keyboard of Christoph Kukulies: > > > My problem solved such that I had a missing entry remote-phone-incoming > > in my entry so that the calling number was accepted by the entry: > > This is a fat bug in isdnd, which has just been fixed ;-) You're welcome. I'm happy that you don't say: "Your fault when you remove this remote-phone-incoming from the isdnd.rc example entry". :-) > > hellmuth > -- > Hellmuth Michaelis Tel +49 40 559747-70 > HCS Hanseatischer Computerservice GmbH Fax +49 40 559747-77 > Oldesloer Strasse 97-99 Mail hm@hcs.de > 22457 Hamburg WWW http://www.hcs.de -- --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Fri Jul 17 04:52:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA19857 for freebsd-isdn-outgoing; Fri, 17 Jul 1998 04:52:28 -0700 (PDT) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from hcshh.hcs.de (hcshh.hcs.de [194.123.40.1]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id EAA19852 for ; Fri, 17 Jul 1998 04:52:26 -0700 (PDT) (envelope-from hm@hcs.de) Received: from hcswork.hcs.de([192.76.124.5]) (1554 bytes) by hcshh.hcs.de via sendmail with P:smtp/R:inet_hosts/T:smtp (sender: ) id for ; Fri, 17 Jul 1998 13:52:01 +0200 (METDST) (Smail-3.2.0.101 1997-Dec-17 #2 built 1998-Jun-26) Received: by hcswork.hcs.de (Smail3.1.29.0 #12) id m0yx95f-0000dZC; Fri, 17 Jul 98 13:54 METDST Message-Id: From: hm@hcs.de (Hellmuth Michaelis) Subject: Re: could i4b influence sound? In-Reply-To: <19980717083803.A4710@gil.physik.rwth-aachen.de> from Christoph Kukulies at "Jul 17, 98 08:38:03 am" To: kuku@gilberto.physik.RWTH-Aachen.DE (Christoph Kukulies) Date: Fri, 17 Jul 1998 13:54:19 +0200 (METDST) 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 Christoph Kukulies: > No, I think the line was idle when this happens. It also doesn't > seem to be correlated with the logs in /var/tmp/isdn.trace when I > enable tracing which I first thought. Anyway, it seems to be > happening at fixed time intervalls (that the sound stops playing). I have an idea and will look into this. hellmuth -- Hellmuth Michaelis Tel +49 40 559747-70 HCS Hanseatischer Computerservice GmbH Fax +49 40 559747-77 Oldesloer Strasse 97-99 Mail hm@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 Fri Jul 17 07:20:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA28469 for freebsd-isdn-outgoing; Fri, 17 Jul 1998 07:20:29 -0700 (PDT) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from gilberto.physik.RWTH-Aachen.DE (gilberto.physik.rwth-aachen.de [137.226.30.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA28418 for ; Fri, 17 Jul 1998 07:20:13 -0700 (PDT) (envelope-from kuku@gilberto.physik.RWTH-Aachen.DE) Received: (from kuku@localhost) by gilberto.physik.RWTH-Aachen.DE (8.8.8/8.8.7) id QAA06221 for freebsd-isdn@freebsd.org; Fri, 17 Jul 1998 16:20:02 +0200 (MEST) (envelope-from kuku) Date: Fri, 17 Jul 1998 16:20:02 +0200 (MEST) From: Christoph Kukulies Message-Id: <199807171420.QAA06221@gilberto.physik.RWTH-Aachen.DE> To: freebsd-isdn@FreeBSD.ORG Subject: sometimes ipr0 doesn't send packets - it seems Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I've been out for lunch. Left my machine at 12:35 after doing some ISDN activity. Everything worked fine. Maybe I played some sound/midi files after the line was timed out. I also don't want to lead you on the wrong trail (Holzweg) , Hellmuth, when I'm mentioning 'sound' here. Anyway, when I came back at 14:14 - long lunch time, eh? ;-) - I sat at the computer, typed the usual 'rlogin gil' in my xterm (which is aliased to an ssh, btw.) and nothing happened. The usual infamous 'jhs-beep' could be heard, vty6 was showing rwth: incoming alert, rwth: call active (ctl 0 , ch 0) etc. but no packets. Nothing. Not even a ping to the peer point possible. I let the line time out (connection time 4 minutes) - my various activities kept the shorthold timer from counting down - and rebooted. After that I could immediately login again to the remote site. The tracefile including all activities of today can be found at ftp://gil.physik.rwth-aachen.de/incoming/isdn.trace.gz (33405 bytes) -- Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Fri Jul 17 23:28:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA24820 for freebsd-isdn-outgoing; Fri, 17 Jul 1998 23:28:05 -0700 (PDT) (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 XAA24739 for ; Fri, 17 Jul 1998 23:28:00 -0700 (PDT) (envelope-from martin@rumolt.teuto.de) Received: from rumolt.teuto.de (root@rumolt.teuto.de [194.77.23.161]) by linteuto.teuto.de (8.8.7/8.8.7) with ESMTP id IAA14564; Sat, 18 Jul 1998 08:27:36 +0200 Received: (from martin@localhost) by rumolt.teuto.de (8.8.8/8.8.7) id HAA02134; Sat, 18 Jul 1998 07:40:41 +0200 (MEST) From: Martin Husemann Message-Id: <199807180540.HAA02134@rumolt.teuto.de> Subject: Re: sometimes ipr0 doesn't send packets - it seems To: kuku@gilberto.physik.RWTH-Aachen.DE (Christoph Kukulies) Date: Sat, 18 Jul 1998 07:40:41 +0200 (MEST) Cc: freebsd-isdn@FreeBSD.ORG In-Reply-To: <199807171420.QAA06221@gilberto.physik.RWTH-Aachen.DE> from "Christoph Kukulies" at Jul 17, 98 04:20:02 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 > The usual infamous 'jhs-beep' could be heard, vty6 was showing > rwth: incoming alert, rwth: call active (ctl 0 , ch 0) etc. > but no packets. Nothing. Not even a ping to the peer point > possible. Just FYI: I've seen this same thing happen randomly (not very often) with an old bisnd installation. When it happens, the b-channel interrupt handler is called with the card denying any need for a b-channel interrupt, so the handler does nothing and returns. (I've watched the interrupt handler with remote gdb.) A reboot did not always cure it, same for powercycling. I suspected broken hardware and replaced the card, but the effect happend again later once. (First card was a realy new (at that time) Teles S0/16.3, replacement was the quite old AVM A1 card you send me, Hellmuth. System was a 486.). Martin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message