Re: ISDN4BSD (HPS version) is going into ports

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: ISDN4BSD (HPS version) is going into ports

Andreas Longwitz
Hi,

I try to get ISDN4BSD from ports (rev 2349) with FreeBSD 8.3 working. My
first step is to run the daemon isdnd with isp0 interface for
connections to some isdn routers. Therfore I use option SPPP together
with the default options. ISDN hardware is Primux S0, everything worked
fine with my old configuration FreeBSD 6 Stable and ISDN4BSD rev 1641.

My first try was to load i4b on the running kernel, but I found
     kldload i4b  -->  kldunload i4b  --> crash  (very often)
     kldload i4b  -->  kldunload i4b  --> ifconfig --> crash (always)
     kldload i4b  -->  crash (somtimes, trap 10 or trap 12).
I can give any informations from the dumps.

Now I load i4b via loader.conf and don't try to unload, no crashes anymore.

I use interface isp0 with sppp and 'ifconfig isp0' with option link1.
Further I have
     isdnconfig -u 0 te_mode -p DRVR_DSS1_TE.
For outgoing calls everything looks fine, the isdn line is transparent
for the network users.

Incoming calls do not work yet. If I ping from the outside one packet
gets a response, four are missing, another packet gets a response, four
or five are missing, ... Every packet is a separate ISDN call.

On the console I see messages
   i4b-L3 dss1_decode_q931_cs0_ie_cd: IEI_BEARERCAP - Unsupported
          B-Sub-Protocol 0x00

But isdndecode shows correct bearer capability for the incoming SETUP:
L3 06 05 0------- Message type extension = 0
         -0000101 Message type = SETUP
 (0x05)
L3 07 A1 1------- Single octet Information element
         -0100001 Sending complete
L3 08 04 0------- Variable length Information element
         -0000100 IE = bearer capability
L3 09 02 00000010 IE Length = 2 bytes
L3 0A 88 1------- Extension Bit = 1                 (no extension, final
octet)
         -00----- Coding standard = CCITT
         ---01000 Capability = 0x08, unrestricted digital information

isdnd.log:
  CHD ev_incoming_from_i4b: Incoming call from '4514998058' to '4982872'
(cdid=00064)
  DBG cep_set_state: [ST_IDLE: entry is not active] -> [ST_INCOMING:
incoming call, waiting for user-response]
  CHD ev_incoming_from_i4b: 00064 CiscoNet is accepting incoming call
from 4514998058 to 4982872
  DBG sendm_connect_resp: accept
  DBG sendm_connect_resp: sent I4B_CONNECT_RESP
  DBG cep_set_state: [ST_INCOMING: incoming call, waiting for
     user-response] -> [ST_WAIT_CONNECT: incoming call, waiting for
     i4b-response]
  DBG handle_scrprs: 4514998058 - screening user provided, verified & i
     passed
  DBG handle_scrprs: 4514998058 - presentation allowed
  DBG response_to_user: sent I4B_RESPONSE_TO_USER [disconnected]

Further I see TEI REQUESTS and the NT-side offers them, but i4b does not
use them, the TEI REQUESTS are repeated.

Any ideas ?

Some more hints to the ports version of ISDN4BSD:
1. The option ING=on does not work for me, because kldload fails with
 KLD i4b.ko: depends on netgraph - not available or version mismatch
 I have netgraph static in the kernel.

2. The option TRACE is mandatory and therefore not an option. Without
 TRACE kldload fails with link_elf: symbol i4b_l1_trace_ind undefined.

3. I use the following minor patch for isdnd to keep the pidfile:
-- src/usr.sbin/i4b/isdnd/support.c.orig       2011-10-10
20:34:44.000000000 +0200
+++ src/usr.sbin/i4b/isdnd/support.c    2012-07-10 15:53:26.000000000 +0200
@@ -854,7 +854,7 @@
                case 0:                 /* child */
                        break;
                default:                /* parent */
-                       exit(0);
+                       _exit(0);
        }

ISDN4BSD in the ports is a great thing, even without working
kldload/kldunload.


Andreas Longwitz

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-isdn
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ISDN4BSD (HPS version) is going into ports

Hans Petter Selasky
On Wednesday 11 July 2012 19:07:42 Andreas Longwitz wrote:

> Hi,
>
> I try to get ISDN4BSD from ports (rev 2349) with FreeBSD 8.3 working. My
> first step is to run the daemon isdnd with isp0 interface for
> connections to some isdn routers. Therfore I use option SPPP together
> with the default options. ISDN hardware is Primux S0, everything worked
> fine with my old configuration FreeBSD 6 Stable and ISDN4BSD rev 1641.
>
> My first try was to load i4b on the running kernel, but I found
>      kldload i4b  -->  kldunload i4b  --> crash  (very often)
>      kldload i4b  -->  kldunload i4b  --> ifconfig --> crash (always)
>      kldload i4b  -->  crash (somtimes, trap 10 or trap 12).
> I can give any informations from the dumps.
>


Hi Andreas,

If you can collect the backtrace from these crashes, that would be nice. I
believe the SPPP functionality has not been tested for a while. I'm currently
using I4B mostly for voice.

--HPS

> Now I load i4b via loader.conf and don't try to unload, no crashes anymore.
>
> I use interface isp0 with sppp and 'ifconfig isp0' with option link1.
> Further I have
>      isdnconfig -u 0 te_mode -p DRVR_DSS1_TE.
> For outgoing calls everything looks fine, the isdn line is transparent
> for the network users.
>
> Incoming calls do not work yet. If I ping from the outside one packet
> gets a response, four are missing, another packet gets a response, four
> or five are missing, ... Every packet is a separate ISDN call.
>
> On the console I see messages
>    i4b-L3 dss1_decode_q931_cs0_ie_cd: IEI_BEARERCAP - Unsupported
>           B-Sub-Protocol 0x00
>
> But isdndecode shows correct bearer capability for the incoming SETUP:
> L3 06 05 0------- Message type extension = 0
>          -0000101 Message type = SETUP
>  (0x05)
> L3 07 A1 1------- Single octet Information element
>          -0100001 Sending complete
> L3 08 04 0------- Variable length Information element
>          -0000100 IE = bearer capability
> L3 09 02 00000010 IE Length = 2 bytes
> L3 0A 88 1------- Extension Bit = 1                 (no extension, final
> octet)
>          -00----- Coding standard = CCITT
>          ---01000 Capability = 0x08, unrestricted digital information
>
> isdnd.log:
>   CHD ev_incoming_from_i4b: Incoming call from '4514998058' to '4982872'
> (cdid=00064)
>   DBG cep_set_state: [ST_IDLE: entry is not active] -> [ST_INCOMING:
> incoming call, waiting for user-response]
>   CHD ev_incoming_from_i4b: 00064 CiscoNet is accepting incoming call
> from 4514998058 to 4982872
>   DBG sendm_connect_resp: accept
>   DBG sendm_connect_resp: sent I4B_CONNECT_RESP
>   DBG cep_set_state: [ST_INCOMING: incoming call, waiting for
>      user-response] -> [ST_WAIT_CONNECT: incoming call, waiting for
>      i4b-response]
>   DBG handle_scrprs: 4514998058 - screening user provided, verified & i
>      passed
>   DBG handle_scrprs: 4514998058 - presentation allowed
>   DBG response_to_user: sent I4B_RESPONSE_TO_USER [disconnected]
>
> Further I see TEI REQUESTS and the NT-side offers them, but i4b does not
> use them, the TEI REQUESTS are repeated.
>
> Any ideas ?
>
> Some more hints to the ports version of ISDN4BSD:
> 1. The option ING=on does not work for me, because kldload fails with
>  KLD i4b.ko: depends on netgraph - not available or version mismatch
>  I have netgraph static in the kernel.
>
> 2. The option TRACE is mandatory and therefore not an option. Without
>  TRACE kldload fails with link_elf: symbol i4b_l1_trace_ind undefined.
>
> 3. I use the following minor patch for isdnd to keep the pidfile:
> -- src/usr.sbin/i4b/isdnd/support.c.orig       2011-10-10
> 20:34:44.000000000 +0200
> +++ src/usr.sbin/i4b/isdnd/support.c    2012-07-10 15:53:26.000000000 +0200
> @@ -854,7 +854,7 @@
>                 case 0:                 /* child */
>                         break;
>                 default:                /* parent */
> -                       exit(0);
> +                       _exit(0);
>         }
>
> ISDN4BSD in the ports is a great thing, even without working
> kldload/kldunload.
>
>
> Andreas Longwitz
>
> _______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-isdn
> To unsubscribe, send any mail to "[hidden email]"
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-isdn
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ISDN4BSD (HPS version) is going into ports

Andreas Longwitz
Hi Hans

> If you can collect the backtrace from these crashes, that would be nice.

Three examples of backtraces follow, the others are similar. I use
minidumps and ddb with the line
   script kdb.enter.default=watchdog; call doadump; reset
in ddb.conf.

1. example: Default options + SPPP + RBCH, crash on kldload i4b, test PC
without isdn hardware:

kgdb /boot/kernel/kernel vmcore.3
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, ....
...
Unread portion of the kernel message buffer:
i4b: ISDN call control device attached
capi: CAPI call control device attached, v2.11
i4bisppp: 8 ISDN SyncPPP device(s) attached
i4bctl: ISDN system control port attached
i4brbch: 8 raw B channel access device(s) attached
i4btrc: 64 ISDN trace device(s) attached
Physical memory: 995 MB
Dumping 150 MB: 135 119 103 87 71 55 39 23 7

Reading symbols from /boot/kernel/firewire.ko...Reading symbols from
/boot/kernel/firewire.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/firewire.ko
Reading symbols from /boot/kernel/snd_ich.ko...Reading symbols from
/boot/kernel/snd_ich.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/snd_ich.ko
Reading symbols from /boot/kernel/sound.ko...Reading symbols from
/boot/kernel/sound.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/sound.ko
Reading symbols from /boot/kernel/dcons_crom.ko...Reading symbols from
/boot/kernel/dcons_crom.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/dcons_crom.ko
Reading symbols from /boot/kernel/acpi.ko...Reading symbols from
/boot/kernel/acpi.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/acpi.ko
Reading symbols from /boot/kernel/linux.ko...Reading symbols from
/boot/kernel/linux.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/linux.ko
Reading symbols from /usr/local/modules/fuse.ko...done.
Loaded symbols for /usr/local/modules/fuse.ko
Reading symbols from /boot/modules/i4b.ko...done.
Loaded symbols for /boot/modules/i4b.ko
#0  doadump () at pcpu.h:244
244     #endif /* !_MACHINE_PCPU_H_ */
Loading gdb init file /home/crash/.gdbinit ...
set height 100 ...
source gdb6 (and gdb6.i386) ...
source mygdb6 ...
Working directory /home/crash.

(kgdb) where
#0  doadump () at pcpu.h:244
#1  0xc04b3269 in db_fncall (dummy1=0, dummy2=0, dummy3=0,
dummy4=0xe734e890 "€è4ç")
    at /usr/src/sys/ddb/db_command.c:548
#2  0xc04b369f in db_command (last_cmdp=0xc09a917c, cmd_table=0x0,
dopager=0) at /usr/src/sys/ddb/db_command.c:445
#3  0xc04b3754 in db_command_script (command=0xc09aa04a "call doadump")
at /usr/src/sys/ddb/db_command.c:516
#4  0xc04b7680 in db_script_exec (scriptname=0xc090886e
"kdb.enter.default", warnifnotfound=Variable "warnifnotfound" is not
available.)    at /usr/src/sys/ddb/db_script.c:302
#5  0xc04b777b in db_script_kdbenter (eventname=0xc0946305 "unknown") at
/usr/src/sys/ddb/db_script.c:325
#6  0xc04b5708 in db_trap (type=10, code=0) at
/usr/src/sys/ddb/db_main.c:230
#7  0xc063abb8 in kdb_trap (type=10, code=0, tf=0xe734eadc) at
/usr/src/sys/kern/subr_kdb.c:654
#8  0xc08b85fe in trap (frame=0xe734eadc) at
/usr/src/sys/i386/i386/trap.c:710
#9  0xc089e96c in calltrap () at /usr/src/sys/i386/i386/exception.s:168
#10 0xc64df633 in ?? ()
Previous frame inner to this frame (corrupt stack?)i

2. example: crash on kldunload, server with isdn hardware
Relevant Information from messages:

Jul  5 08:58:44 <kern.crit> loserver kernel: pci6: <network, ISDN> at
device 1.0 (no driver attached)

Jul  9 21:20:39 <kern.crit> loserver kernel: KLD i4b.ko: depends on
netgraph - not available or version mismatch

Jul  9 21:37:44 <kern.crit> loserver kernel: bus_dmamem_alloc failed to
align memory properly.
Jul  9 21:37:44 <kern.crit> loserver kernel: ihfc0: <HFC-2BDS0 128K PCI
ISDN adapter> port 0xbc00-0xbc07 mem 0xff532000
-0xff5320ff irq 22 at device 1.0 on pci6
Jul  9 21:37:44 <kern.crit> loserver kernel: ihfc0: [ITHREAD]
Jul  9 21:37:44 <kern.crit> loserver kernel: ihfc0: Attaching I4B
controller 0.
Jul  9 21:37:44 <kern.crit> loserver kernel: ihfc0: Creating /dev/ihfc0.X.
Jul  9 21:37:44 <kern.crit> loserver kernel: capi: CAPI call control
device attached, v2.11
Jul  9 21:37:44 <kern.crit> loserver kernel: i4btel: 8 ISDN telephony
interface device(s) attached
Jul  9 21:37:44 <kern.crit> loserver kernel: i4bctl: ISDN system control
port attached
Jul  9 21:37:44 <kern.crit> loserver kernel: iloop0: I4B Loopback device
(attached)
Jul  9 21:37:44 <kern.crit> loserver kernel: i4b: Attaching I4B
controller 63.
Jul  9 21:37:44 <kern.crit> loserver kernel: i4bipr: 8 IP over raw HDLC
ISDN device(s) attached (VJ header compression)
Jul  9 21:37:44 <kern.crit> loserver kernel: i4b: ISDN call control
device attached
Jul  9 21:37:44 <kern.crit> loserver kernel: i4brbch: 8 raw B channel
access device(s) attached
Jul  9 21:37:44 <kern.crit> loserver kernel: i4btrc: 64 ISDN trace
device(s) attached

Information from vmcore by kgdb:
Unread portion of the kernel message buffer:
ihfc0: detached
pci6: <network, ISDN> at device 1.0 (no driver attached)
iloop0: I4B Loopback device (attached)
i4b: Attaching I4B controller 62.
kernel trap 12 with interrupts disabled

Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address   = 0xcd28f26c
fault code              = supervisor read, page not present
instruction pointer     = 0x20:0xc0624752
stack pointer           = 0x28:0xc5343c28
frame pointer           = 0x28:0xc5343c8c
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = resume, IOPL = 0
current process         = 11 (swi4: clock)

(kgdb) where
#0  doadump () at pcpu.h:244
#1  0xc04bc079 in db_fncall (dummy1=0, dummy2=0, dummy3=0,
dummy4=0xc5343918 ",94Å")
    at /usr/src/sys/ddb/db_command.c:548
#2  0xc04bc4af in db_command (last_cmdp=0xc0988e1c, cmd_table=0x0,
dopager=0) at /usr/src/sys/ddb/db_command.c:445
#3  0xc04bc564 in db_command_script (command=0xc0989cea "call doadump")
at /usr/src/sys/ddb/db_command.c:516
#4  0xc04c0490 in db_script_exec (scriptname=0xc08ec23f
"kdb.enter.default", warnifnotfound=Variable "warnifnotfound" is not
available.)    at /usr/src/sys/ddb/db_script.c:302
#5  0xc04c058b in db_script_kdbenter (eventname=0xc0927275 "unknown") at
/usr/src/sys/ddb/db_script.c:325
#6  0xc04be518 in db_trap (type=12, code=0) at
/usr/src/sys/ddb/db_main.c:230
#7  0xc0641308 in kdb_trap (type=12, code=0, tf=0xc5343be8) at
/usr/src/sys/kern/subr_kdb.c:654
#8  0xc089b17f in trap_fatal (frame=0xc5343be8, eva=3442012780) at
/usr/src/sys/i386/i386/trap.c:1000
#9  0xc089b235 in trap_pfault (frame=0xc5343be8, usermode=0,
eva=3442012780) at /usr/src/sys/i386/i386/trap.c:834
#10 0xc089bf93 in trap (frame=0xc5343be8) at
/usr/src/sys/i386/i386/trap.c:546
#11 0xc08824ec in calltrap () at /usr/src/sys/i386/i386/exception.s:168
#12 0xc0624752 in softclock (arg=0xc09a4360) at
/usr/src/sys/kern/kern_timeout.c:443
#13 0xc05e6d3b in intr_event_execute_handlers (p=0xc5544810,
ie=0xc5542680) at /usr/src/sys/kern/kern_intr.c:1219
#14 0xc05e83fb in ithread_loop (arg=0xc54f6930) at
/usr/src/sys/kern/kern_intr.c:1232
#15 0xc05e3b87 in fork_exit (callout=0xc05e8390 <ithread_loop>,
arg=0xc54f6930, frame=0xc5343d28)
    at /usr/src/sys/kern/kern_fork.c:876

3. example: the same server crashes after kldunload and an ifconfig
command, after output of the linei
  isp0: flags=a011<UP,POINTOPOINT,LINK1,MULTICAST> metric 0 mtu 1500

Unread portion of the kernel message buffer:

Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address   = 0xcc387630
fault code              = supervisor read, page not present
instruction pointer     = 0x20:0xcc387630
stack pointer           = 0x28:0xe810db20
frame pointer           = 0x28:0xe810dbe8
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 81670 (ifconfig)
Physical memory: 2030 MB
Dumping 249 MB: 234 218 202 186 170 154 138 122 106 90 74 58 42 26 10
...
(kgdb) where
#0  doadump () at pcpu.h:244
#1  0xc04bc079 in db_fncall (dummy1=0, dummy2=0, dummy3=0,
dummy4=0xe810d810 "$Ø\020è")
    at /usr/src/sys/ddb/db_command.c:548
#2  0xc04bc4af in db_command (last_cmdp=0xc0988e1c, cmd_table=0x0,
dopager=0) at /usr/src/sys/ddb/db_command.c:445
#3  0xc04bc564 in db_command_script (command=0xc0989cea "call doadump")
at /usr/src/sys/ddb/db_command.c:516
#4  0xc04c0490 in db_script_exec (scriptname=0xc08ec23f
"kdb.enter.default", warnifnotfound=Variable "warnifnotfound" is not
available.)    at /usr/src/sys/ddb/db_script.c:302
#5  0xc04c058b in db_script_kdbenter (eventname=0xc0927275 "unknown") at
/usr/src/sys/ddb/db_script.c:325
#6  0xc04be518 in db_trap (type=12, code=0) at
/usr/src/sys/ddb/db_main.c:230
#7  0xc0641308 in kdb_trap (type=12, code=0, tf=0xe810dae0) at
/usr/src/sys/kern/subr_kdb.c:654
#8  0xc089b17f in trap_fatal (frame=0xe810dae0, eva=3426252336) at
/usr/src/sys/i386/i386/trap.c:1000
#9  0xc089b4ae in trap_pfault (frame=0xe810dae0, usermode=0,
eva=3426252336) at /usr/src/sys/i386/i386/trap.c:922
#10 0xc089bf93 in trap (frame=0xe810dae0) at
/usr/src/sys/i386/i386/trap.c:546
#11 0xc08824ec in calltrap () at /usr/src/sys/i386/i386/exception.s:168
#12 0xcc387630 in ?? ()
Previous frame inner to this frame (corrupt stack?)

By the way, the output of kldxref in /boot/modules is
./i4b.ko
  interface ihfcpnp.1
  depends on usb.1 (1,1)
  depends on pci.1 (1,1)
  depends on isa.1 (1,1)
  module ihfcpnp_uhub
  depends on kernel.803500 (803500,899999)
  module ihfcpnp_pci
  depends on kernel.803500 (803500,899999)
  module ihfcpnp_isa
  depends on kernel.803500 (803500,899999)
  depends on ihfcpnp.1 (1,1)
  depends on usb.1 (1,1)
  module yealink_uhub
  depends on kernel.803500 (803500,899999)
  depends on sppp.1 (1,1)
  interface i4bisppp.1

Is that what you expect ? I would expect a line
  interface yealink.1
but probably I am wrong.

> I believe the SPPP functionality has not been tested for a while. I'm currently
> using I4B mostly for voice.

OK. I will try to check the sppp problem for incoming calls.

Andreas Longwitz

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-isdn
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ISDN4BSD (HPS version) is going into ports

Hans Petter Selasky
On Monday 16 July 2012 12:48:24 Andreas Longwitz wrote:

> Hi Hans
>
> > If you can collect the backtrace from these crashes, that would be nice.
>
> Three examples of backtraces follow, the others are similar. I use
> minidumps and ddb with the line
>    script kdb.enter.default=watchdog; call doadump; reset
> in ddb.conf.
>
> 1. example: Default options + SPPP + RBCH, crash on kldload i4b, test PC
> without isdn hardware:
>
> kgdb /boot/kernel/kernel vmcore.3
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, ....
> ...
Hi Andreas,

I cannot reproduce this crash over here. I think it is not a bug in I4B, but rather
some hardware generating spurious interrupts when probing! Loading I4B will cause a
re-probe of existing devices with no driver attached.


              ┌────────────────────────────────────────────────────────────────────┐
              │ Options for isdn4bsd-kmod 2.0.3                                    │  
              │ ┌────────────────────────────────────────────────────────────────┐ │  
              │ │         [ ] DEBUG    Build with debugging support              │ │  
              │ │         [*] HFC      Build HFC-XXX driver                      │ │  
              │ │         [ ] ING      Build ING driver                          │ │  
              │ │         [ ] IPR      Build IPR driver                          │ │  
              │ │         [ ] IPR_VJ   Build IPR driver with VJ support          │ │  
              │ │         [ ] LOOP     Build loopback test driver                │ │  
              │ │         [*] MAN      Intall manual pages                       │ │  
              │ │         [*] RBCH     Build RBCH driver                         │ │  
              │ │         [*] SPPP     Build SPPP driver                         │ │  
              │ │         [ ] TEL      Build TEL driver                          │ │  
              │ │         [*] TRACE    Build TRACE driver                        │ │  
              │ │         [*] YEALINK  Build YEALINK driver                      │ │  
              │ │                                                                │ │  
              │ │                                                                │ │  
              │ └────────────────────────────────────────────────────────────────┘ │  
              ├────────────────────────────────────────────────────────────────────┤  
              │                   <  OK  >          <Cancel>                       │  
              └────────────────────────────────────────────────────────────────────┘  
                                                                                     

kldload i4b

i4b: ISDN call control device attached
capi: CAPI call control device attached, v2.11
i4bisppp: 8 ISDN SyncPPP device(s) attached
i4bctl: ISDN system control port attached
i4brbch: 8 raw B channel access device(s) attached
i4btrc: 64 ISDN trace device(s) attached

>
> Is that what you expect ? I would expect a line
>   interface yealink.1
> but probably I am wrong.

The I4B module as a whole cannot be unloaded, it requires a reboot. Some parts of I4B supports unload, but others not.
A crash at this point is like expected. However it is possible in theory to split I4B into separate modules,
which can be loaded/unloaded, but not the core itself currently.

>
> > I believe the SPPP functionality has not been tested for a while. I'm
> > currently using I4B mostly for voice.
>

Thanks for testing!

--HPS

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-isdn
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ISDN4BSD (HPS version) is going into ports

Christopher Intemann-2
Just curious, but does this port also work with OpenBSD/current?
Thanks,
 Chris

On Mon, Jul 16, 2012 at 6:01 PM, Hans Petter Selasky <[hidden email]>wrote:

> On Monday 16 July 2012 12:48:24 Andreas Longwitz wrote:
> > Hi Hans
> >
> > > If you can collect the backtrace from these crashes, that would be
> nice.
> >
> > Three examples of backtraces follow, the others are similar. I use
> > minidumps and ddb with the line
> >    script kdb.enter.default=watchdog; call doadump; reset
> > in ddb.conf.
> >
> > 1. example: Default options + SPPP + RBCH, crash on kldload i4b, test PC
> > without isdn hardware:
> >
> > kgdb /boot/kernel/kernel vmcore.3
> > GNU gdb 6.1.1 [FreeBSD]
> > Copyright 2004 Free Software Foundation, Inc.
> > GDB is free software, ....
> > ...
>
> Hi Andreas,
>
> I cannot reproduce this crash over here. I think it is not a bug in I4B,
> but rather
> some hardware generating spurious interrupts when probing! Loading I4B
> will cause a
> re-probe of existing devices with no driver attached.
>
>
>
> ┌────────────────────────────────────────────────────────────────────┐
>               │ Options for isdn4bsd-kmod 2.0.3
>          │
>               │
> ┌────────────────────────────────────────────────────────────────┐ │
>               │ │         [ ] DEBUG    Build with debugging support
>        │ │
>               │ │         [*] HFC      Build HFC-XXX driver
>        │ │
>               │ │         [ ] ING      Build ING driver
>        │ │
>               │ │         [ ] IPR      Build IPR driver
>        │ │
>               │ │         [ ] IPR_VJ   Build IPR driver with VJ support
>        │ │
>               │ │         [ ] LOOP     Build loopback test driver
>        │ │
>               │ │         [*] MAN      Intall manual pages
>       │ │
>               │ │         [*] RBCH     Build RBCH driver
>       │ │
>               │ │         [*] SPPP     Build SPPP driver
>       │ │
>               │ │         [ ] TEL      Build TEL driver
>        │ │
>               │ │         [*] TRACE    Build TRACE driver
>        │ │
>               │ │         [*] YEALINK  Build YEALINK driver
>        │ │
>               │ │
>        │ │
>               │ │
>        │ │
>               │
> └────────────────────────────────────────────────────────────────┘ │
>
> ├────────────────────────────────────────────────────────────────────┤
>               │                   <  OK  >          <Cancel>
>         │
>
> └────────────────────────────────────────────────────────────────────┘
>
>
> kldload i4b
>
> i4b: ISDN call control device attached
> capi: CAPI call control device attached, v2.11
> i4bisppp: 8 ISDN SyncPPP device(s) attached
> i4bctl: ISDN system control port attached
> i4brbch: 8 raw B channel access device(s) attached
> i4btrc: 64 ISDN trace device(s) attached
>
> >
> > Is that what you expect ? I would expect a line
> >   interface yealink.1
> > but probably I am wrong.
>
> The I4B module as a whole cannot be unloaded, it requires a reboot. Some
> parts of I4B supports unload, but others not.
> A crash at this point is like expected. However it is possible in theory
> to split I4B into separate modules,
> which can be loaded/unloaded, but not the core itself currently.
>
> >
> > > I believe the SPPP functionality has not been tested for a while. I'm
> > > currently using I4B mostly for voice.
> >
>
> Thanks for testing!
>
> --HPS
>
> _______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-isdn
> To unsubscribe, send any mail to "[hidden email]"
>
>

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-isdn
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ISDN4BSD (HPS version) is going into ports

Hans Petter Selasky
On Tuesday 17 July 2012 10:00:34 Christopher Intemann wrote:
> Just curious, but does this port also work with OpenBSD/current?
> Thanks,
>  Chris

Only the user-land part. Not the kernel part.

--HPS
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-isdn
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ISDN4BSD (HPS version) is going into ports

Andreas Longwitz
In reply to this post by Hans Petter Selasky
Hi Hans,

>> 1. example: Default options + SPPP + RBCH, crash on kldload i4b, test PC
>> without isdn hardware:
>>
> I cannot reproduce this crash over here. I think it is not a bug in I4B, but rather
> some hardware generating spurious interrupts when probing! Loading I4B will cause a
> re-probe of existing devices with no driver attached.

OK, the re-probe of the existing devices is done by the kernel because a
DRIVER_MODULE is loaded via kldload, or did you some special programming
for this ?

> The I4B module as a whole cannot be unloaded, it requires a reboot. Some parts of I4B supports unload, but others not.
> A crash at this point is like expected. However it is possible in theory to split I4B into separate modules,
> which can be loaded/unloaded, but not the core itself currently.

So it seems a little bit safer to load i4b - or any other DRIVER_MODULE
- via loader.conf, because the re-probe must not be done.

> I believe the SPPP functionality has not been tested for a while.
In the meantime I found the reason for my troubles with i4b + sppp on
incoming calls:

There was a commit for if_spppsubr.c (Revision 1.222) with the text:
Use monotonic time_uptime instead of 'time_second' as timebase for timeouts.
After changing in i4b_global.h from
     #define SECOND                time_second
to   #define SECOND                time_uptime
the problem was gone.

One bagatelle is left: On every incoming call I see in /var/log/messages
kernel: i4b-L3 dss1_decode_q931_cs0_ie_cd: IEI_BEARERCAP - Unsupported
        B-Sub-Protocol 0x00
kernel: i4b: unit 0, assigned TEI = 253 = 0xfd (example),

but the incoming SETUP frame is ok. Can you give me a hint how to deal
with this ? In /etc/isdn/isdnd.rc I do not have any subaddress specific
parameters.

--
Andreas Longwitz

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-isdn
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ISDN4BSD (HPS version) is going into ports

Christopher Intemann-2
In reply to this post by Hans Petter Selasky
On Tue, Jul 17, 2012 at 1:20 PM, Hans Petter Selasky <[hidden email]>wrote:

> On Tuesday 17 July 2012 10:00:34 Christopher Intemann wrote:
> > Just curious, but does this port also work with OpenBSD/current?
> > Thanks,
> >  Chris
>
> Only the user-land part. Not the kernel part.
>
>
> Ah, ok, thanks for clarification!
I guess there is no OpenBSD Kernel module available any longer or is there
anybody still maintaining this branch?
Thanks,
 Chris
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-isdn
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ISDN4BSD (HPS version) is going into ports

Hans Petter Selasky
In reply to this post by Andreas Longwitz
On Thursday 19 July 2012 18:21:09 Andreas Longwitz wrote:
> Hi Hans,

Hi Andreas,

>
> >> 1. example: Default options + SPPP + RBCH, crash on kldload i4b, test PC
> >
> >> without isdn hardware:
> > I cannot reproduce this crash over here. I think it is not a bug in I4B,
> > but rather some hardware generating spurious interrupts when probing!
> > Loading I4B will cause a re-probe of existing devices with no driver
> > attached.
>
> OK, the re-probe of the existing devices is done by the kernel because a
> DRIVER_MODULE is loaded via kldload, or did you some special programming
> for this ?

No, this is done by generic PNP/PCI code when the module is loaded as far as
I'm aware.

>
> > The I4B module as a whole cannot be unloaded, it requires a reboot. Some
> > parts of I4B supports unload, but others not. A crash at this point is
> > like expected. However it is possible in theory to split I4B into
> > separate modules, which can be loaded/unloaded, but not the core itself
> > currently.
>
> So it seems a little bit safer to load i4b - or any other DRIVER_MODULE
> - via loader.conf, because the re-probe must not be done.

Right.

>
> > I believe the SPPP functionality has not been tested for a while.
>
> In the meantime I found the reason for my troubles with i4b + sppp on
> incoming calls:
>
> There was a commit for if_spppsubr.c (Revision 1.222) with the text:
> Use monotonic time_uptime instead of 'time_second' as timebase for
> timeouts. After changing in i4b_global.h from
>      #define SECOND                time_second
> to   #define SECOND                time_uptime
> the problem was gone.

I4B also uses SECOND for other purpose. I think your change is OK and have
committed it.

>
> One bagatelle is left: On every incoming call I see in /var/log/messages
> kernel: i4b-L3 dss1_decode_q931_cs0_ie_cd: IEI_BEARERCAP - Unsupported
>         B-Sub-Protocol 0x00
> kernel: i4b: unit 0, assigned TEI = 253 = 0xfd (example),

This warning can be ignored. I4B looks for a Voice type byte which is not
there and the safety wrapper returns zero. Try this patch:

Modified:
   trunk/i4b/src/sys/i4b/dss1/dss1_l3decoder.h
Log:
i4b: Silence warning when using HDLC.

Modified: trunk/i4b/src/sys/i4b/dss1/dss1_l3decoder.h
===================================================================
--- trunk/i4b/src/sys/i4b/dss1/dss1_l3decoder.h
+++ trunk/i4b/src/sys/i4b/dss1/dss1_l3decoder.h
@@ -177,8 +177,10 @@
              break;
 
            default:
-             NDBGL3(L3_P_ERR, "IEI_BEARERCAP - "
+             if (dss1_get_valid(buf,4)) {
+               NDBGL3(L3_P_ERR, "IEI_BEARERCAP - "
                     "Unsupported B-Sub-Protocol 0x%02x", temp);
+             }
              cd->channel_bsubprot = BSUBPROT_UNKNOWN;
            }
            break;


>
> but the incoming SETUP frame is ok. Can you give me a hint how to deal
> with this ? In /etc/isdn/isdnd.rc I do not have any subaddress specific
> parameters.

Subaddress is not matched unless specified.

I'll roll out a new tarball when time permits. Until further simply checkout
code via SVN and type "make package" in the i4b direction to get a new tarball
for ports.

After replacing the file in /usr/ports/distfiles, you type make makesum or
something like that to update the checksum file.

Thanks for testing!

--HPS
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-isdn
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ISDN4BSD (HPS version) is going into ports

Hans Petter Selasky
In reply to this post by Christopher Intemann-2
On Thursday 19 July 2012 18:40:23 Christopher Intemann wrote:
> On Tue, Jul 17, 2012 at 1:20 PM, Hans Petter Selasky
<[hidden email]>wrote:

> > On Tuesday 17 July 2012 10:00:34 Christopher Intemann wrote:
> > > Just curious, but does this port also work with OpenBSD/current?
> > > Thanks,
> > >
> > >  Chris
> >
> > Only the user-land part. Not the kernel part.
> >
> >
> > Ah, ok, thanks for clarification!
>

Hi,

> I guess there is no OpenBSD Kernel module available any longer or is there
> anybody still maintaining this branch?

Regarding my branch, I maintained a NetBSD version for a while, but that has
now been axed to simplify the internals of I4B.

--HPS
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-isdn
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ISDN4BSD (HPS version) is going into ports

Andreas Longwitz
In reply to this post by Hans Petter Selasky
Hi Hans,

>> One bagatelle is left: On every incoming call I see in /var/log/messages
>> kernel: i4b-L3 dss1_decode_q931_cs0_ie_cd: IEI_BEARERCAP - Unsupported
>>         B-Sub-Protocol 0x00
>> kernel: i4b: unit 0, assigned TEI = 253 = 0xfd (example),
>
> This warning can be ignored. I4B looks for a Voice type byte which is not
> there and the safety wrapper returns zero. Try this patch:
>
> Modified:
>    trunk/i4b/src/sys/i4b/dss1/dss1_l3decoder.h
> Log:
> i4b: Silence warning when using HDLC.
>
> Modified: trunk/i4b/src/sys/i4b/dss1/dss1_l3decoder.h
> ===================================================================
> --- trunk/i4b/src/sys/i4b/dss1/dss1_l3decoder.h
> +++ trunk/i4b/src/sys/i4b/dss1/dss1_l3decoder.h
> @@ -177,8 +177,10 @@
>               break;
>  
>             default:
> -             NDBGL3(L3_P_ERR, "IEI_BEARERCAP - "
> +             if (dss1_get_valid(buf,4)) {
> +               NDBGL3(L3_P_ERR, "IEI_BEARERCAP - "
>                      "Unsupported B-Sub-Protocol 0x%02x", temp);
> +             }
>               cd->channel_bsubprot = BSUBPROT_UNKNOWN;
>             }
>             break;
>
>
>> but the incoming SETUP frame is ok. Can you give me a hint how to deal
>> with this ? In /etc/isdn/isdnd.rc I do not have any subaddress specific
>> parameters.

OK, works as expected.
Further I use the patch from
http://lists.freebsd.org/pipermail/freebsd-current/2009-June/008787.html
to get rid of the "failed to align memory properly" message.

Regards,
Andreas Longwitz

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-isdn
To unsubscribe, send any mail to "[hidden email]"