bristuff-0.3.0-PRE-1s kompiliert nicht mit KERNEL 2.6.19.1

[RcRaCk2k]

Booahr Leute ich glaub ich häng!!!

Ich kann die zaphfc und zaptel Treiber unter Kernel 2.6.19.1 nicht kompilieren!

Hat jemand selbigen Fehler?

rm -f ztgsm.o *.ko *.mod.c *.mod.o .*o.cmd *~
rm -rf .tmp_versions
make -C /usr/src/linux-2.6 SUBDIRS=/usr/src/bristuff-0.3.0-PRE-1s/ztgsm ZAP=-I/usr/src/bristuff-0.3.0-PRE-1s/zaptel modules
make[1]: Entering directory `/usr/src/linux-2.6.19.1'
  CC [M]  /usr/src/bristuff-0.3.0-PRE-1s/ztgsm/ztgsm.o
In file included from /usr/src/bristuff-0.3.0-PRE-1s/zaptel/zaptel.h:34,
                 from /usr/src/bristuff-0.3.0-PRE-1s/ztgsm/ztgsm.c:17:
/usr/src/bristuff-0.3.0-PRE-1s/zaptel/zconfig.h:9:26: linux/config.h: No such file or directory
/usr/src/bristuff-0.3.0-PRE-1s/ztgsm/ztgsm.c: In function `ztgsm_findCards':
/usr/src/bristuff-0.3.0-PRE-1s/ztgsm/ztgsm.c:1070: warning: passing arg 2 of `request_irq' from incompatible pointer type
make[2]: *** [/usr/src/bristuff-0.3.0-PRE-1s/ztgsm/ztgsm.o] Error 1
make[1]: *** [_module_/usr/src/bristuff-0.3.0-PRE-1s/ztgsm] Error 2
make[1]: Leaving directory `/usr/src/linux-2.6.19.1'
make: *** [linux26] Error 2
make -C /usr/src/linux-2.6 SUBDIRS=/usr/src/bristuff-0.3.0-PRE-1s/ztgsm ZAP=-I/usr/src/bristuff-0.3.0-PRE-1s/zaptel modules
make[1]: Entering directory `/usr/src/linux-2.6.19.1'
  CC [M]  /usr/src/bristuff-0.3.0-PRE-1s/ztgsm/ztgsm.o
In file included from /usr/src/bristuff-0.3.0-PRE-1s/zaptel/zaptel.h:34,
                 from /usr/src/bristuff-0.3.0-PRE-1s/ztgsm/ztgsm.c:17:
/usr/src/bristuff-0.3.0-PRE-1s/zaptel/zconfig.h:9:26: linux/config.h: No such file or directory
/usr/src/bristuff-0.3.0-PRE-1s/ztgsm/ztgsm.c: In function `ztgsm_findCards':
/usr/src/bristuff-0.3.0-PRE-1s/ztgsm/ztgsm.c:1070: warning: passing arg 2 of `request_irq' from incompatible pointer type
make[2]: *** [/usr/src/bristuff-0.3.0-PRE-1s/ztgsm/ztgsm.o] Error 1
make[1]: *** [_module_/usr/src/bristuff-0.3.0-PRE-1s/ztgsm] Error 2
make[1]: Leaving directory `/usr/src/linux-2.6.19.1'
make: *** [linux26] Error 2

Das ist wahrlich nicht erfreulich!

./fs/dlm/config.h
./net/tipc/config.h
./include/config/x86/find/smp/config.h

Das sind die einzigsten config.h Dateien was ich finden kann. Die im Verzeichnis smp ist sogar leer.

Gibts schon BugFixes - Work-Arrounds?

Grüße
Michi.

 

[OttTheTormentor]

Hallo Michi,

die Datei /usr/include/linux/config.h ist schon länger ein 1-Zeiler für ein anderes Include:

#ifndef _LINUX_CONFIG_H
#define _LINUX_CONFIG_H
/* This file is no longer in use and kept only for backward compatibility.
 * autoconf.h is now included via -imacros on the commandline
 */
#include <linux/autoconf.h>

#endif

In 2.6.19.1 wurde config.h schliesslich entfernt. Als Workaround (bis der bristuff anpgepasst ist), kannst du eine config.h so wie oben gezeigt erstellen.

 

[RcRaCk2k]

Vielen Dank Aha daher weht also der Wind ;-) Hmm nunja nun habe ich mal meinen Asterisk mit mISDN gepaared, hatte dort auch zuerst den Fehler. Aber nach der Erstellung deiner erwähnten config.h File ging das kompilieren gleich wie von selbst ;-)

Sicherlich gehen da viele Meinungen auseinander, aber ich bin bis jetzt recht von mISDN überzeugt. Zudem die Handhabung der Config-Files in mISDN um einiges einfacher ist, als bei BRISTUFF.

Ich muss dazu auch sagen, dass der Asterisk 1.4 mit mISDN nun endlich gut , durch die Integration der chan_misdn Treiber zusammenarbeitet.

Grüße
Michi.

 

[Kermit23]

Beherrscht mISDN eigentlich auch den NT-Mode? Dann würde ich das auch mal probieren. Kriege ein akutelleres bristuff nicht ans Laufen (wegen buffe overflow fehler, die mein System lahmlegen)

 

[RcRaCk2k]

Ja beherrscht NT und TE...

Weiteres findest du auf dieser Page:
http://www.ip-phone-forum.de/showthread.php?p=755124#post755124

Am Besten, du verwendest Asterisk 1.4, denn der hat den chan_misdn schon mit integriert, und du hast keine Probleme beim Kompilieren des BeroNET Modules.

PS: Ich bin jetzt endgültig von BRISTUFF weg... Man muss immer warten, bis die neuesten Patches heraussen sind - das ist nervig. Man weiß auch nicht, ob es lang genug nen Maintainer für den BRI-STUFF geben wird. Und soweit bin ich jetzt eigentlich mit mISDN sehr zufrieden, nachdem vISDN ja jetzt so gut wie gestorben ist :-( schade eigentlich, denn einen nativen ISDN-Stack-Driver wie vISDN hätte UNIX schon nötig gehabt.

Grüße
Michael Rack

 

[Kermit23]

Danke für den Tipp!
Habe nun mISDN-1_0_4, mISDNuser-1_0_3 (brauche ich das überhaupt? Das zaphfc-Modul ist ja scheinbar aus mISDN-1_0_4, andere Module sind nicht geladen) und asterisk 1.4beta4 installiert. Nach einem bisschen rumkonfigurieren funktioniert es prima! Bin begeistert.
werde es nun mal Langzeit testen.
Theoretisch kann ich mir ja dann ja demnächst die binary-Versionen von Asterisk aus meiner Distri ziehen, wenn das chan_modul ja ab 1.4 dabei ist. Dann fällt das lästige und (zeit)aufwendige kompilieren auch weg...

 

[RcRaCk2k]

Das ist eine sehr gute Frage... Ich arbeite leider auch erst seit 2-3 Tagen mit mISDN ;-) Daher kann ich dir darüber keine Auskunft geben. Hab mir einfach die beiden Sourcen heruntergeladen und durchkompiliert.

Das einzigste was mich bei mISDN noch ein wenig in Verbindung mit Asterisk 1.4 stört ist das OVERLAP-Dial... Das geht bei mir irgendwie nicht. Er versucht immer gleich nach der ersten Zahl zu wählen. - Ist aber Thema für einen neuen Topic.

Grüße
Michael.

 

[Kermit23]

Ja, das Problem hatte ich auch zuerst.
mach ein 'misdn show config

Dort stand bei mir zuerst -> overlapdial: 0

Dann habe ich in der /etc/asterisk/misdn.conf
overlapdial=yes

dann geht es problemlos. Bei mir wird dann:
-> overlapdial: 4
angezeigt. Denke mal es sind 4 Sekunden. Vielleicht kann man den Wert auch irgendwie individuell ändern.

Die meisten Probleme hatte ich aber mit Namensänderungen durch die 1.4er Version. ${CALLERIDNUM} gab es z.B. nicht mehr und andere kleine Dinge...

Momentan macht mir Sipgate Probleme: Mal geht's mal nicht. Weiß aber nicht, ob das mit der 1.4er Version zusammenhängt. Im Moment kann ich mich scheinbar gar nicht mehr registrieren. Heute morgen hatte ich auch Probleme. Dann lief es mal eine Zeit, aber ich bekam laufen Meldungen wie
Really destroying SIP dialog '[email protected]' Method: REGISTER
Really destroying SIP dialog '[email protected]' Method: OPTIONS

(den Zahlensalat hab ich hier aus Sicherheitsgründen ein bisschen abgeändert)

 

[RcRaCk2k]

Sowas aber auch ;-) Hab ich doch echt vergessen, das overlapdial Commando einzuschalten... Dabei war ich mir doch zuerst soooo sicher, es eingetragen zu haben... Gut - so lernt man wieder dazu ;-) Vielen Dank.

Ja mit Sipgate hatte ich auch meine Probleme, hab aber noch nicht versucht diese wieder in den Griff zu bekommen.

Werde nun mal meinen SIP-Account einbinden, und kucken was er dann sagt.

Grüße
Michi.

 

[RcRaCk2k]

Hmm also bei mir gehts:
sipgate.de:5060 948***6 105 Registered Tue, 19 Dec 2006 20:05:40

Meine Config - vielleicht hilft sie dir ja:

register => 948***6:[email protected]/49865448***6

[authentication]

[sipgate-in]
type=peer
context=sip-sipgate
fromdomain=sipgate.de
host=sipgate.de

[49865448***6-out]
type=peer
username=948***6
secret=XXXXXX
fromuser=948***6
fromdomain=sipgate.de

nat hab ich global auf yes gestellt, da ich davor an meinem Linunx-Router den CONTRACK_SIP betreibe.

Grüße
Michi.

 

[Kermit23]

Scheint ein Problem bei Sipgate heute gewesen zu sein. Momentan geht's wieder fehlerfrei (habe nichts verändert).
nat habe ich auf no, da mein Server gleichzeit mein Router ist. Brauche deshalb auch nicht CONTRACK_SIP.
Aber was anderes? Welche UDP-Ports muss ich von aussen zu Asterisk zwingend durchlassen, damit sipgate (oder ähnliches) funktioniert. Habe damals einfach alle Ports durchgelassen, an welche Asterisk (damals) gelauscht hat laut netstat:
# Asterisk/Sipgate
iptables -A sperre -p UDP --dport 5060 -j ACCEPT
iptables -A sperre -p UDP --dport 5004 -j ACCEPT
iptables -A sperre -p UDP --dport 10000 -j ACCEPT
iptables -A sperre -p UDP --dport 8000:8019 -j ACCEPT

Brauch ich die alle oder stellen die gar ein Sicherheitsrisiko von aussen da (Asterisk ist ja ziemlich mächtig, da habe ich nicht so den Überblick). Ich weiss echt nicht mehr, wieso ich damals 8000:8019 geöffnet habe. Kommt mir etwas komisch vor. Würde vielleicht allein 5060 reichen. Mit dem Rest kann ich nicht viel anfangen.

Hm, war wohl schon lange her. Sind wohl noch ein paar dazu gekommen:

tcp        0      0 0.0.0.0:2000            0.0.0.0:*               LISTEN     31187/asterisk
udp        0      0 0.0.0.0:2727            0.0.0.0:*                          31187/asterisk
udp        0      0 0.0.0.0:4520            0.0.0.0:*                          31187/asterisk
udp        0      0 0.0.0.0:8002            0.0.0.0:*                          31187/asterisk
udp        0      0 0.0.0.0:8003            0.0.0.0:*                          31187/asterisk
udp        0      0 0.0.0.0:5060            0.0.0.0:*                          31187/asterisk
udp        0      0 0.0.0.0:8008            0.0.0.0:*                          31187/asterisk
udp        0      0 0.0.0.0:8009            0.0.0.0:*                          31187/asterisk
udp        0      0 0.0.0.0:8010            0.0.0.0:*                          31187/asterisk
udp        0      0 0.0.0.0:8011            0.0.0.0:*                          31187/asterisk
udp        0      0 0.0.0.0:8016            0.0.0.0:*                          31187/asterisk
udp        0      0 0.0.0.0:8017            0.0.0.0:*                          31187/asterisk
udp        0      0 0.0.0.0:4569            0.0.0.0:*                          31187/asterisk

Dafür sind andere weg...
Muss ich überhaupt irgendwas aufmachen, denn der Registrierungsprozess geht ja von mir aus? Nur kann ich dann noch angerufen werden?


Hm, kann nun zwar mit sipgate Rufe absetzen, aber nicht angerufen werden. Sipgäte löst einfach aus. Bei meinem Asterisk kommt überhaupt kein Ruf an.
Scheint aber heute ein allgemeines Problem bei Sipgate zu sein, von dem ich auch betroffen bin. Seht hier. Einen schlechteren Zeitpunkt hätte sich sipgate für die Probleme nicht aussuchen können

 

[RcRaCk2k]

Also es ist krass, welche Ports bei dir geöffnet sind ;-) Verwendest du den selben Asterisk wie ich? *gg* .... Scherz.

Folgende Ports sind wichtig:
UDP 5060 In/Outbound sowie default von Asterisk 10000-20000 für RTP nur Inbound wird benötigt, da outgoing immer der Port des anderen SIP-Gerätes ist.

5060 ist der SIGNAL-Port, das ist wie im ISDN mit dem D-Channel zu vergleichen. Die Port-Range 10000-20000 sind die Sprachkanäle - jeweils nur eingehend (Unter ISDN auch als B-Channel bekannt).

Somit sollte deine IP-Tables so aussehen:
iptables -A sperre -p UDP --dport 5060 -j ACCEPT
iptables -A sperre -p UDP --dport 10000:20000 -j ACCEPT

Die Port-Range für RTP (10000 bis 20000) entnimmst du bitte der /etc/asterisk/rtp.conf Datei.

 

[RcRaCk2k]

Achja, was ich noch sagen wollte. UDP ist ein verbindungsloses Protokoll, was viele Probleme mit sich trägt!

Stell dir mal eine REGISTER-Anfrage vor. Die Anfrage wandert von Links nach Rechts:
ASTERISK .... LINUX-GATEWAY .............. SIPGATE

Sipgate hat nun (DEFAULT) 180 Sekunden Zeit, auf deine Anfrage zu antworten, bevor deine Firewall den Ausgangs-Port wieder schließt und jegliche Antwort von sich abweißt.

Wenn du nun deinen Port 5060 nicht richtig freigegeben hast, in deiner IP-Tables, dann kann SIP-GATE dir auch keine Anrufe mehr zustellen, da die CONNTRACK (Verbindungs-Tabelle) keinen gültigen Eintrag mehr enthält, dass SIPGATE dir antworten darf.

Den Wert des Time-Outs kannst du so auslesen:
cat /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout_stream

Grüße
Michi

 

[Kermit23]

Ja, jetzt wird mir einiges wieder klar:
`--> cat /etc/asterisk/rtp.conf
rtpstart=8000
rtpend=8019

Weiß nicht, ob ich das mal vor langer Zeit eingestellt habe oder es schon so war. Jedenfalls würde ich ungern 10000 UDP-Ports einfach so freigeben, zumal ich in dem Bereich (10000-20000) noch andere UDP-Dienste laufen habe. Die alle umzulegen wäre etwas Aufwand...
Wie das (statusabhängige) filtern bei UDP vor sich geht, habe ich noch nie verstanden, eben weil es ja (zumindest bis einschließlich L4) verbindungslos ist. Wie können da überhaupt Antworten auf Anfragen erkannt werden. Gibt ja keine SYN/ACK Flags, Sequenznummer, etc. wie bei TCP... Aber das gehört hier nun wirklich nicht mehr hin.

Vielen Dank,
Kermit

 

[RcRaCk2k]

Das würd ich so nicht sagen, dass es hier nicht hingehört.. Sicherlich haben einige Leute Probleme, dass nach ein paar Minuten immer die SIP-Nachrichten nichtmehr ankommen.

Also UDP hat genauso Souce-IP, Source-Port sowie Destination-IP und Destination-Port.

Damit ein gesendetes UDP-Paket wieder beantwortet werden kann, gibt es unter UNIX das conntrack_udp Module. Dies merkt sich für eine gewisse Zeit, von welcher Source-IP und von Source-Port ein Paket ausging, und an welche Destination-IP und Port es gesendet wurde.

Wenn nun ein Antwort-Paket innerhalb des Time-Outs von der damaligen Destination-IP und Port and die damalig gemerkte Source-IP und Port eintrifft, leitet es die Antwort an den ausgehenden Host weiter.

Grafik:

Ein UDP-Paket verlässt unseren Router:
src_ip=85.187.9.76 src_port=63118 dst_ip=217.8.17.9 dst_port=5060

Ein Paket, das unseren Router wieder erreicht (ANTWORT)
src_ip=217.8.17.9 src_port=5060 dst_ip=85.187.9.76 dst_port=63118

Wenn du in den IP-Tables den Port 63118 für immer freigeben würdest (-j ACCEPT), dann würde conntrack_udp dieses EVENT nicht speichern müssen, da die Daten auf diesem Port eh immer passieren dürften.

Hoffe, ich konnte das ein wenig veranschaulichen.

Grüße
Michi.

 

[Kermit23]

Ja, jetzt ist's mir klar. Danke.
Dann geht das also nur über Timer. Eine Antwort auf eine UDP-Verbindung erwartet man i.d.R. ja auch innerhalb kürzester Zeit (i.d.R. natürlich auf den SRC-Port des Anfragers und dieser wird dann wohl einige Sekunden acceptet)

 

[RcRaCk2k]

Richtig ;-)