Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 29 Nov 2012 17:25:46 +0100
From:      Andreas Longwitz <longwitz@incore.de>
To:        Hans Petter Selasky <hselasky@c2i.net>
Cc:        freebsd-isdn@freebsd.org
Subject:   Re: ISDN4BSD (HPS version) is going into ports
Message-ID:  <50B78C8A.2040701@incore.de>
In-Reply-To: <201211241222.52897.hselasky@c2i.net>
References:  <509E87EF.9070607@incore.de> <201211151812.32616.hselasky@c2i.net> <50AF5B79.5050802@incore.de> <201211241222.52897.hselasky@c2i.net>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi,

> I've made a new release of ISDN4BSD, now version 2.0.6. I4B SVN has been 
> updated with new ports.

I tested all the last changes in version 2.0.6 of isdn4bsd-kmod and
isdn4-utils and everything worked as expected.

Thanks!

>> One thing is left: the handling of DISCONNECT including error codes like
>> "busy". We had some discussion about this in late 2010, I wrote
>>
>>> My understanding of the standard closing of a Q.931 connection is
>>>
>>>       --> DISCONNECT
>>>       <-- RELEASE
>>>       --> RELEASE_COMPLETE
>>>
>>> it is like closing a tcp socket (-> FIN; <- FIN+ACK; -> ACK). I have
>>> never seen an example that RELEASE and RELESE_COMPLETE is send in the
>>> same direction. Your method of finishing a Q.931 connection is correct
>>> but not standard: In the active case you send RELEASE_COMLETE, in the
>>> passive case you answer the incoming DISCONNECT with RELEASE_COMPLETE.
>> and your answer was that the statemachine in ISDN4BSD must be changed to
>> accomplish my requirement. If you have a patch for this, I would like to
>> test this.
> 
> I haven't had time to look into this one yet. I will see if I can find some 
> time to do this. Else keep in reminding me or if you want you can suggest a 
> patch. I think we already have a DISCONNECT state, where we can go instead of 
> release complete. I'm just not sure how that will interact with STATUS 
> enquiry, what state we get back.
> 
> Does the Q.931 define a maximum time before we can expect a RELEASE_COMPLETE? 

After sending out a DISCONNECT to the D-channel the timer T105 should be
started (default ist 30 sec). This is the information given in Table 9-2
of Recommendation Q.931 (05/98) free available for download at
www.itu.int/rec/T-REC-Q.931-199805-I/e.

> isdnconfig -u XXX status_enquiry_enable
> isdnconfig -u XXX status_enquiry_disable

Works perfect.

One more thing: I have some ISDN cards "AVM Fritz!Card version 2 PCI":

ihfc1@pci0:0:7:0:
  class=0x028000 card=0x0e001244 chip=0x0e001244 rev=0x02 hdr=0x00
  vendor     = 'AVM Audiovisuelles MKTG & Computer GmbH'
  device     = 'Fritz!PCI v2.0 ISDN Controller'
  class      = network
  bar   [10] = type Memory, range 32, base 0xfb145000, size 32, enabled
  bar   [14] = type I/O Port, range 32, base 0x54c0, size 32, enabled
  cap 01[40] = powerspec 2  supports D0 D2 D3  current D0

and know that these cards do not work with isdn4bsd at the moment mainly
because of missing information from AVM. At the moment these cards run
in servers or soekris devices with FreeBSD 6 Stable without any problem
for years now using the ifpi2 driver of FreeBSD 6 and the old isdnd:

ifpi2-0@pci0:14:0:
  class=0x028000 card=0x0e001244 chip=0x0e001244 rev=0x02 hdr=0x00
  vendor     = 'AVM AUDIOVISUELLES MKTG & Computer GmbH'
  device     = 'Fritz!PCI v2.0 ISDN Controller'
  class      = network

Because I would like to update all these boxes from FreeBSD 6 to FreeBSD
>= 8, I will try to get isdnd working with isdn4bsd-kmod/utils.

First step of analyze is done: I see in the isdntrace that several of
the incoming D-channel frames have an extra byte at the end of the frame:
       10101110 UNKNOWN single octet IE = 0xae
Further I see many single outgoing bytes on L3 level:
  L3 04 AE 10101110 Protocol = Other Layer 3 or X.25        (0xae)

On the other side of the ISDN-line all length are correct. Maybe there
is a "one byte length problem" in the D-channel communication between
the i4b driver and the card.


-- 
Andreas Longwitz




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50B78C8A.2040701>