fbrcapi und Auto-Reconnect (Error handling)

jpawlowski

Neuer User
Mitglied seit
10 Nov 2005
Beiträge
48
Punkte für Reaktionen
0
Punkte
0
Hallo zusammen,

ich möchte gerne meine Fritzbox 7390 an eine (unter ESXi 4.1 virtualisierten) Gemeinschaft 3.1-rc3 Anlage (mit Asterisk 1.4, basierend auf 32-Bit Debian Squeeze) anbinden. Dabei ist die genaue Konstellation wie folgt:

Code:
PSTN --- FB7390 --- IPsecVPN --{--}-- Vyatta-GW --- Gemeinschaft3.1-rc3 (mit fbrcapi 0.5)

Soweit funktioniert auch alles recht ordentlich.
Leider scheint die fbrcapi nicht mit einer 24h Trennung des VPN Tunnels zurecht zu kommen (bedingt durch die nächtliche Unterbrechung der DSL-Verbindung). Anrufe werden danach nicht mehr auf der CAPI-Anbindung signalisiert. Logge ich mich auf der Asterisk Maschine ein und schaue mittels capiinfo nach dem Status, dann dauert die Abfrage sehr lange, schließlich kommen folgende (unvollständige Ausgaben):

Code:
root@comgate:~# capiinfo 
Number of Controllers : 1
Controller 1:
Manufacturer: AVM Berlin
CAPI Version: 2.0
Manufacturer Version: 0.0-03  (0.3)
Serial Number: 0004711
BChannels: 2
Global Options: 0x00000039
   internal controller supported
   DTMF supported
   Supplementary Services supported
   channel allocation supported (leased lines)
B1 protocols support: 0x80003c0b
   64 kbit/s with HDLC framing
   64 kbit/s bit-transparent operation
   V.110 synconous operation with HDLC framing
B2 protocols support: 0x00000003
   ISO 7776 (X.75 SLP)
   Transparent
B3 protocols support: 0x00000081
   Transparent
   Modem

  0001
  0200
  39000000
  0b3c0080
  03000000
  81000000
  00000000 00000000 00000000 00000000 00000000 00000000
  01000001 00020000 00000000 00000000 00000000
FAC REQ - No additional information (0xfff2)
root@comgate:~# capiinfo Timeout, server not responding.

Die virtuelle Maschine hängt danach und benötigt einen manuellen Neustart. Danach funktioniert alles wieder einwandfrei (ohne die Fritzbox anzufassen, dort liegt also vermutlich kein Fehler vor; capiinfo läuft schnell und problemlos durch) - bis zu nächsten Trennung... gleiches Verhalten vermute ich auch, wenn die Netzwerkverbindung außerhalb der normalen Trennung kurzzeitig nicht Verfügbar ist.

Laut Changelog von fbrcapi auf http://fbrcapi.v3v.de/fbrcapi.html soll die Fehlertoleranz ja verbessert worden sein:

...

v0.1:
...
auto reconnect
...

So ganz rund scheint es aber noch nicht zu sein.
Weiß jemand wo ich hier ansetzen könnte?
Ein morgentlicher (automatisierter) Reboot der Asterisk-Kiste (bzw. entladen und neu laden des Kernel-Moduls) ist es jedenfalls nicht :)

Danke + Gruß
Julian
 
Zuletzt bearbeitet:
Ich bin jetzt zumindest bei der Fehleranalyse einen Schritt weiter.

Die Debug-Ausgabe in /var/log/kern.log zeigt ziemlich genau, was dazu führt, dass eine Kernel-Panic entsteht.
Wenn ich die Netzwerkverbindung unterbreche und schließlich nach dessen Wiederherstellung ein capiinfo ausführe, dann entsteht die Bildschirmausgabe wie oben bereits gezeigt. Das fbrcapi Modul gibt dabei folgende Debug-Meldungen aus:

Code:
Oct 30 12:39:05 comgate kernel: [161165.779537] fbrcapi: fbrc_register_appl(session e0ec4264 ctrl e0ec62bc appl 1 rp df92ca8c)
Oct 30 12:39:05 comgate kernel: [161165.779726] fbrcapi: fbrc_application_add(session e0ec4264 app de4ef150 applid 65535 kapplid 1)
Oct 30 12:39:10 comgate kernel: [161170.778738] fbrcapi: fbrc_application_del(session e0ec4264 app de4ef150 applid 65535 kapplid 1)
Oct 30 12:39:10 comgate kernel: [161170.778927] fbrcapi: fbrc_register_appl(session e0ec4264 ctrl e0ec6440 appl 1 rp df92ca8c)
Oct 30 12:39:10 comgate kernel: [161170.779099] fbrcapi: fbrc_application_add(session e0ec4264 app de4ef150 applid 65535 kapplid 1)
Oct 30 12:39:10 comgate kernel: [161170.779310] fbrcapi: Error: kernel_sendmsg returned -104
Oct 30 12:39:10 comgate kernel: [161170.779433] fbrcapi: Stopping kthread(session e0ec4264)
Oct 30 12:39:10 comgate kernel: [161170.779537] fbrcapi: fbrc_recv_message(e0ec4264): thread stopped
Oct 30 12:39:15 comgate kernel: [161175.778430] fbrcapi: fbrc_application_del(session e0ec4264 app de4ef150 applid 65535 kapplid 1)
Oct 30 12:39:15 comgate kernel: [161175.778642] fbrcapi: fbrc_register_appl(session e0ec4264 ctrl e0ec65c4 appl 1 rp df92ca8c)
Oct 30 12:39:15 comgate kernel: [161175.778825] fbrcapi: Connecting to :0 ...
Oct 30 12:39:15 comgate kernel: [161175.778973] fbrcapi: Error: unable to connect (-111)
Oct 30 12:39:15 comgate kernel: [161175.779079] fbrcapi: fbrc_register_appl(session e0ec4264 ctrl e0ec6748 appl 1 rp df92ca8c)
Oct 30 12:39:15 comgate kernel: [161175.779256] fbrcapi: Connecting to :0 ...
Oct 30 12:39:15 comgate kernel: [161175.779357] fbrcapi: Error: unable to connect (-111)
Oct 30 12:39:15 comgate kernel: [161175.779453] fbrcapi: fbrc_register_appl(session e0ec4264 ctrl e0ec68cc appl 1 rp df92ca8c)
Oct 30 12:39:15 comgate kernel: [161175.779624] fbrcapi: Connecting to :0 ...
Oct 30 12:39:15 comgate kernel: [161175.779718] fbrcapi: Error: unable to connect (-111)
Oct 30 12:39:15 comgate kernel: [161175.780179] fbrcapi: fbrc_release_appl(session e0ec4264 ctrl e0ec62bc appl 1)
Oct 30 12:39:15 comgate kernel: [161175.780342] fbrcapi: fbrc_release_appl(session e0ec4264 ctrl e0ec6440 appl 1)
Oct 30 12:39:15 comgate kernel: [161175.780504] fbrcapi: fbrc_release_appl(session e0ec4264 ctrl e0ec65c4 appl 1)
Oct 30 12:39:15 comgate kernel: [161175.780665] fbrcapi: fbrc_release_appl(session e0ec4264 ctrl e0ec6748 appl 1)
Oct 30 12:39:15 comgate kernel: [161175.780826] fbrcapi: fbrc_release_appl(session e0ec4264 ctrl e0ec68cc appl 1)

Man sieht also hier sehr gut, dass ein Auto-Reconnect offenbar erst dann ausgeführt wird, wenn die Verbindung von Host-Seite wieder benutzt werden soll. Warum es hier fehl schlägt, ist mir ein Rätsel. Entlade ich das Modul und lade es anschließend wieder neu, dann kommt eine Verbindung problemlos zu Stande!

Das "Auto-Reconnect on Demand" hat zudem natürlich den Nachteil, dass eingehende Anrufe solange nicht signalisiert werden können, bis vom Host eine CAPI-Aktion ausgeführt wird (mal angenommen es entstünde dabei keine Kernel-Panic :)). Das ist unschön in mehrfacher Hinsicht :-/

Ich sehe ein paar Dinge, die im Verhalten verbessert werden sollten - leider bin ich jedoch kein Programmierer und finde mich in dem Quellcode nicht zurecht :-/

- Automatische Erkennung, ob eine Socket-Verbindung noch lebt oder nicht
- davon ableitend entsprechende Maßnahmen, die Verbindung periodisch neu aufzubauen
- gleichzeitig umgehend die CAPI-Ports bei kcapi löschen, um eine Kernel-Panic zu verhindern, falls CAPI-Befehle während der Zeit ausgeführt werden sollen (sofern aktive Programme wie chan_capi, die auf die CAPI zugreifen, das zulassen)
- alternativ: Die Antworten einer Fritzbox simulieren, bis die echte wieder erreichbar ist (mit allen B-Kanälen belegt, damit nix raus gehen kann; D-Kanal ggf. ähnlich handhaben)
- und natürlich: das Auto-Reconnect fixen (ansonsten würde ja jetzt zumindest keine Panic enstehen, wenn die Verbindung erfolgreich wieder aufgebaut würde :-D)
 
fbrcapi probleme

Hallo,

ich habe aehnliche Probleme. Seit ca. 2 Wochen setze ich einen Asterisk mit chan_capi per fbrcapi und einer FritzBox! 5050 ein. Funktioniert prinzipiell.

Nach Laufzeit ~1Tag "klemmt" aber die CAPI. Ich sehe auch das Verhalten, dass capiinfo dann ewig braucht. Die Heilung bringt bei mir aber dann schon capiinit. Danach liefert capiinfo dann sofort wieder Output.

Allerdings muss ich danach auch den Asterisk neu starten, ich habe noch keinen Weg gefunden, die Capi im Asterisk zu resetten.

Der Asterisk Host laeuft nativ mit 32bit Debian Sid.

Ich hatte auch schon versucht, das fbrcapi Modul mal mit debug=4 zu starten. Dann ist leider das System nicht mehr benutzbar, die load geht ueber 4 bei einer Singleprozessormaschine. Telefonieren kann man dann auch nur abgehackt.

Allerdings tappe ich noch komplett im dunkeln, was bei mir das Problem ausloest. Fritzbox und Asterisk haengen direkt am gleichen Switch. Mittlerweile auch exklusiv in einem eigenen VLAN. Netzseitig kann das nicht mehr wackeln.

Ratlos,

Martin
 
Wie währe es denn mit einem skript das Zeugs zu entladen und dann wieder laden evtl per cron job alle

oder über die rclocal

nur mal so ein ansatz
 
Ach du grosse Guete!

Ich habe eben mal spasseshalber auf der Asterisk Kiste die Internetverbindung unterbrochen und dann wieder hergestellt. Prompt krieg ich beim Aufruf von capiinfo ne Panic.

Hier nun der Trace:

<code>
[1054810.517386] fbrcapi: Error: kernel_sendmsg returned -104
[1054810.974847] skb_over_panic: text:f83fc0a8 len:2745 put:1375 head:f60e0000 data:f60e0022 tail:0xf60e0adb end:0xf60e0620 dev:br0
[1054810.978831] ------------[ cut here ]------------
[1054810.978831] kernel BUG at /build/buildd-linux-2.6_2.6.32-29-i386-Of6Yt1/linux-2.6-2.6.32/debian/build/source_i386_none/net/core/skbuff.c:127!
[1054810.978831] invalid opcode: 0000 [#1] SMP
[1054810.978831] last sysfs file: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:00/PNP0C09:00/PNP0C0A:00/power_supply/BAT0/status
[1054810.978831] Modules linked in: dahdi_transcode dahdi tcp_diag fbrcapi cls_fw sch_htb pppoe pppox tun inet_diag deflate zlib_deflate ctr twofish twofish_common camellia ipt_REJECT ipt_LOG xt_state xt_multiport serpent iptable_filter ipt_MASQUERADE iptable_nat blowfish nf_nat nf_conntrack_ipv4 cast5 des_generic nf_conntrack cbc nf_defrag_ipv4 xt_DSCP xt_length aes_i586 xt_dscp xt_TCPMSS aes_generic xt_tcpmss xcbc xt_tcpudp rmd160 xt_MARK iptable_mangle sha256_generic ip_tables ebt_ip sha1_generic ebtable_filter hmac ebtables x_tables crypto_null af_key nfsd exportfs nfs lockd fscache nfs_acl auth_rpcgss sunrpc ppp_generic slhc 8021q garp bridge stp capi capifs kernelcapi tp_smapi thinkpad_ec acpi_cpufreq arc4 ecb pcmcia ath5k mac80211 ath snd_intel8x0 yenta_socket snd_intel8x0m rsrc_nonstatic snd_ac97_codec cfg80211 ac97_bus thinkpad_acpi usb_storage pcmcia_core snd_pcm snd_seq snd_timer rfkill mcs7830 shpchp snd_seq_device usbnet snd parport_pc psmouse mii battery ac nvram cdc_acm processor parport irda serio_raw soundcore evdev crc_ccitt snd_page_alloc i2c_i801 rng_core pci_hotplug ext3 jbd mbcache dm_mod raid1 md_mod sd_mod crc_t10dif uhci_hcd i915 drm_kms_helper ata_generic drm i2c_algo_bit i2c_core sdhci_pci ehci_hcd ata_piix sdhci libata mmc_core video thermal button e1000 led_class usbcore scsi_mod nls_base thermal_sys output [last unloaded: scsi_wait_scan]
[1054810.978831]
[1054810.978831] Pid: 0, comm: swapper Not tainted (2.6.32-5-686 #1) 2371LBG
[1054810.978831] EIP: 0060:[<c11d1ed4>] EFLAGS: 00010086 CPU: 0
[1054810.978831] EIP is at skb_put+0x5d/0x67
[1054810.978831] EAX: 0000008a EBX: f60e0adb ECX: c1359dc0 EDX: c1327e79
[1054810.978831] ESI: 0000055f EDI: f6518800 EBP: f6758560 ESP: c1359dbc
[1054810.978831] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[1054810.978831] Process swapper (pid: 0, ti=c1358000 task=c1386ba0 task.ti=c1358000)
[1054810.978831] Stack:
[1054810.978831] c1327e79 f83fc0a8 00000ab9 0000055f f60e0000 f60e0022 f60e0adb f60e0620
[1054810.978831] <0> f6721000 00000000 72620001 f83fc0a8 f6758540 f6f4d000 f6518800 00000000
[1054810.978831] <0> 00000000 f7d68bb9 f6f4d0f8 f6f4d000 f6f4d0e8 f7ed3c5c f6518800 f65d2f60
[1054810.978831] Call Trace:
[1054810.978831] [<f83fc0a8>] ? rx_complete+0x22/0x131 [usbnet]
[1054810.978831] [<f83fc0a8>] ? rx_complete+0x22/0x131 [usbnet]
[1054810.978831] [<f7d68bb9>] ? usb_hcd_giveback_urb+0x60/0x8f [usbcore]
[1054810.978831] [<f7ed3c5c>] ? ehci_urb_done+0x61/0x6d [ehci_hcd]
[1054810.978831] [<f7ed3d08>] ? qh_completions+0xa0/0x400 [ehci_hcd]
[1054810.978831] [<f7ed57c8>] ? ehci_work+0x7c/0x6f3 [ehci_hcd]
[1054810.978831] [<c104677c>] ? hrtimer_get_next_event+0x8c/0xa0
[1054810.978831] [<c103b1f6>] ? get_next_timer_interrupt+0x16f/0x1da
[1054810.978831] [<c1007569>] ? sched_clock+0x5/0x7
[1054810.978831] [<f7ed87a1>] ? ehci_irq+0x171/0x1c4 [ehci_hcd]
[1054810.978831] [<f7d6887b>] ? usb_hcd_irq+0x32/0x71 [usbcore]
[1054810.978831] [<c106c12d>] ? handle_IRQ_event+0x4e/0x101
[1054810.978831] [<c106d5d3>] ? handle_fasteoi_irq+0x66/0x97
[1054810.978831] [<c1004dd7>] ? handle_irq+0x17/0x1b
[1054810.978831] [<c1004659>] ? do_IRQ+0x38/0x89
[1054810.978831] [<c10037f0>] ? common_interrupt+0x30/0x38
[1054810.978831] [<f828c24b>] ? acpi_idle_enter_simple+0x117/0x151 [processor]
[1054810.978831] [<f828bf72>] ? acpi_idle_enter_bm+0xda/0x29c [processor]
[1054810.978831] [<c11c6471>] ? cpuidle_idle_call+0x68/0xbb
[1054810.978831] [<c1002388>] ? cpu_idle+0x89/0xa5
[1054810.978831] [<c13bd7fc>] ? start_kernel+0x318/0x31d
[1054810.978831] Code: 85 d2 0f 45 c2 50 ff b1 a4 00 00 00 53 ff b1 ac 00 00 00 ff b1 a8 00 00 00 56 ff 71 50 ff 74 24 24 68 79 7e 32 c1 e8 9f a0 09 00 <0f> 0b 83 c4 24 eb fe 5b 5e c3 55 89 c5 57 56 53 83 ec 24 89 54
[1054810.978831] EIP: [<c11d1ed4>] skb_put+0x5d/0x67 SS:ESP 0068:c1359dbc
[1054810.978831] ---[ end trace 9c984f825129cf0a ]---
[1054810.978831] Kernel panic - not syncing: Fatal exception in interrupt
[1054810.978831] Pid: 0, comm: swapper Tainted: G D 2.6.32-5-686 #1
[1054810.978831] Call Trace:
[1054810.978831] [<c126bec5>] ? panic+0x38/0xe6
[1054810.978831] [<c126e4d1>] ? oops_end+0x91/0x9d
[1054810.978831] [<c1004121>] ? do_invalid_op+0x0/0x75
[1054810.978831] [<c100418d>] ? do_invalid_op+0x6c/0x75
[1054810.978831] [<c11d1ed4>] ? skb_put+0x5d/0x67
[1054810.978831] [<c11ad5e8>] ? serial8250_console_write+0x0/0xe9
[1054810.978831] [<c1047146>] ? up+0x9/0x2a
[1054810.978831] [<c10308a5>] ? release_console_sem+0x174/0x1a2
[1054810.978831] [<c126dbc3>] ? error_code+0x73/0x78
[1054810.978831] [<c11d1ed4>] ? skb_put+0x5d/0x67
[1054810.978831] [<f83fc0a8>] ? rx_complete+0x22/0x131 [usbnet]
[1054810.978831] [<f83fc0a8>] ? rx_complete+0x22/0x131 [usbnet]
[1054810.978831] [<f7d68bb9>] ? usb_hcd_giveback_urb+0x60/0x8f [usbcore]
[1054810.978831] [<f7ed3c5c>] ? ehci_urb_done+0x61/0x6d [ehci_hcd]
[1054810.978831] [<f7ed3d08>] ? qh_completions+0xa0/0x400 [ehci_hcd]
[1054810.978831] [<f7ed57c8>] ? ehci_work+0x7c/0x6f3 [ehci_hcd]
[1054810.978831] [<c104677c>] ? hrtimer_get_next_event+0x8c/0xa0
[1054810.978831] [<c103b1f6>] ? get_next_timer_interrupt+0x16f/0x1da
[1054810.978831] [<c1007569>] ? sched_clock+0x5/0x7
[1054810.978831] [<f7ed87a1>] ? ehci_irq+0x171/0x1c4 [ehci_hcd]
[1054810.978831] [<f7d6887b>] ? usb_hcd_irq+0x32/0x71 [usbcore]
[1054810.978831] [<c106c12d>] ? handle_IRQ_event+0x4e/0x101
[1054810.978831] [<c106d5d3>] ? handle_fasteoi_irq+0x66/0x97
[1054810.978831] [<c1004dd7>] ? handle_irq+0x17/0x1b
[1054810.978831] [<c1004659>] ? do_IRQ+0x38/0x89
[1054810.978831] [<c10037f0>] ? common_interrupt+0x30/0x38
[1054810.978831] [<f828c24b>] ? acpi_idle_enter_simple+0x117/0x151 [processor]
[1054810.978831] [<f828bf72>] ? acpi_idle_enter_bm+0xda/0x29c [processor]
[1054810.978831] [<c11c6471>] ? cpuidle_idle_call+0x68/0xbb
[1054810.978831] [<c1002388>] ? cpu_idle+0x89/0xa5
[1054810.978831] [<c13bd7fc>] ? start_kernel+0x318/0x31d
[1054810.978831] [drm:drm_fb_helper_panic] *ERROR* panic occurred, switching back to text console
</code>
 
Zuletzt bearbeitet:
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.