[HowTo] Bezahlbares GSM-VoIP-Gateway auf Asterisk-Basis zum selber bauen

[PsychoMantis]

Da gibt es doch dieses char_conv.c, char_conv.h und chan_datacard.c.
Früher (bis Rev. 37) gab es nur chan_datacard.c als sourcen.
Warum hat der Entwickler ab Rev. 38 drei Dateien als sourcen gemacht?
Kann man nicht alles einfach bei einer Datei belassen?

 

[schufti]

naja, weil das bei C Programmierern so üblich ist, dass Hilfsroutinen ausgelagert werden?!

Das original Makefile berücksichtigt das soweit ich gesehen habe auch korrekt.

Mal sehen, wann ich dazukomme das mal auf meinem Server durch zu kompilieren.

schufti

 

[chrizzz]

Das wird der Entwickler wohl noch selbst nachholen, z.Zt wird die char_conv.c gar nicht verwendet, er hat nur die char_conv.h inkludiert, da stehen die Prototypen drin. Sobald ich das OpenWRT am Laufen habe, könnte ich das auch noch hinkriegen, aber bis dahin wird das wohl eh behoben sein... Alles ohne Gewähr, C ist lange her
Quick & Dirty wäre die Funktionen+Prototyp einfach in die chan_datacard.c zu kopieren.

Außerdem inkludiert er das char_conv.h in der chan_datacard.c nachdem er eine static-Funktion schreibt... Ob das geht???

#include <asterisk/manager.h>
#include <asterisk/io.h>

/*! Global jitterbuffer configuration - by default, jb is disabled */
static struct ast_jb_conf default_jbconf = {
	.flags = 0,
	.max_size = -1,
	.resync_threshold = -1,
	.impl = "",
	.target_extra = -1,
};
static struct ast_jb_conf global_jbconf;

[COLOR="Red"]#include "char_conv.h"[/COLOR]

EDIT: Hier nun Asterisk 1.6.2.6 als ipkg für openWRT Backfire + chan_datacard.so (KEIN SMS)

Es muss vor dem installieren mit "opkg install /pfad.zum.ipk" die /var/opkg-lists/packages angepasst werden, damit die MD5-SUM stimmt. Dort einfach unter dem Eintrag asterisk16 die folgende Summe eintragen: 5362a62f24eb607faae8b158fbd4c04c

Sobald es einen Fix für das SMS-Problem gibt, stell ich es online!

 

[schufti]

Hi chrizzz,

also ich gehe mal davon aus, dass es für den Entwickler so funktioniert und er _daran_ nichts ändern wird.

#include "char_conv.h" ist völlig ausreichend. Das biete sozusagen die Prototypen der Funktionen an, die dann dazugelinkt werden _wenn_ es im makefile so angegeben ist (so funktioniert das mit "libraries" in C üblicher weise).

Es führt also kein Weg daran vorbei, dass du entweder die char_conv.c in die chan_datacard.c integrierst (das aber dann bei jeder neuen Release) oder du kümmerst dich darum, dass dein makefile die char_conv entsprechend berücksichtigt...

schufti

 

[chrizzz]

ok, hab ich mir schon fast gedacht. Da die Sourcen ja im Asterisk/Channels-Ordner liegen, gibt es kein Makefile bzw. nur das des gesamten Package. Leider fehlt mir in dem Buildroot die iconv.h bzw. libiconv an der richtigen Stelle. Sie ist da, aber der Pfad ist falsch... Mal schaun

 

[chrizzz]

Hab jetzt die chan_datacard.c so angepasst, dass es auch ohne die zusätzlichen Files funktionert. Leider kann ich nicht testen, da meine Box par tout den Stick nicht erkennt. Hab schon alles mögliche probiert, ohci+uhci+ehci+usb-serial sind installiert, der Stick wird erkannt

root@OpenWRT:~# lsusb
[COLOR="Red"]Bus 002 Device 002: ID 12d1:1001 Huawei Technologies Co., Ltd. E620 USB Modem[/COLOR]
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
root@OpenWRT:~#

allerdings sollte er doch an dem 2.0 hub hängen? Wenn ich ohci entferne, wird mein log vollgeschrieben.. Hab auch schon per AT-Command den SD/Flash-Speicher deaktiviert, bringt auch nichts... Hat jemand ne Idee?

 

[PsychoMantis]

Ja, usb-serial-option oder wie das heißt. Das muss dazu. Ich habe immer nur das genommen (siehe Bild).
Ach ja, häng die angepasste chan_datacard.c im Beitrag über diesen bitte als Anhang an.
Nachtrag: Das von Fredjam beschriebene Problem, dass nach einer Zeit die UMTS-Sticks einfach verschwinden, konnte ich nun nachvollziehen. Bin mal gespannt, ob das Problem auch mit OpenWRT auftritt. Bin gerade dabei OpenWRT zu bauen.
Nachtrag: Ich kopiere mal eine Antwort auf eine PN hier rein, vielleicht kann es für den einen oder anderen nützlich sein:

Achso, das wusste ich nicht. Also das geht aufjedenfall zu kompilieren so auf meine Weise. Wenn man die von dir angepasste source nimmt, dann müsste es auf alle Fälle funktionieren.

Ich hatte damals etwas gekämpft, um es "auf meine Weise" zu kompilieren. Aus irgendeinem Grund hat er beim Kompilieren den ganzen Asterisk-Ordner gelöscht und aus den Asterisk-Sourcen neu entpackt (und da war das datacard-Zeugs natürlich nicht mehr im channel-Ordner dabei). Also hatte ich den Archiv mit den Asterisk-Sourcen genommen (ich spreche von der ca. 22MB großen Datei, die automatisch von digium runtergeladen wird) und direkt dort rein das datacard-zeug hinzugefügt. Im make-File habe ich dann die neue md5-Summe von diesem Archiv eingetragen, damit der OpenWRT-Builder annimmt, dass es sich bei den Sourcen um die original von digium runtergeladenen handelt. So ging das dann am einfachsten.
Ich hatte das aber auch mit einem anderem Weg geschafft: Mir einfach ein script geschrieben, der im Hintergrund läuft, und alle 0,5 Sekunden versucht die datacard-Sourcen in den channels-Ordner zu kopieren.
Egal wie man das macht, man muss einfach dafür sorgen, dass die datacard-sourcen beim Kompilieren von Asterisk im channels-Ordner liegen.
Sicher gibt es hierfür elegantere Wege als die beiden von mir beschriebenen, aber ich bin eben ein Linux-Noob und das war das einfachste, was mir eingefallen ist.

 

[schufti]

Hi Psychomantis,

ja, das Vorgehen ist ok, solange die neue * Komponente nur aus einer .c Datei besteht, oder alle externen Routinen schon im * vorhanden sind.

Im Fall von chan_datacard ab rev3x wird eine "library" verwendet, was das autom. makefile des * nicht erkennen kann. Daher muß man entweder das make vom * anpassen, oder das mit chan_datacard gelieferte aufrufen und chan_datacard getrennt nach * compilieren.

schufti

 

[chrizzz]

Ok, jetzt läuft es. Ich habe per at^diag die speicher-funktion deaktiviert und in der

/etc/modules.d/60-usb-serial

folgendes eingetragen:

usbserial vendor=0x12d1 product=0x1001 maxSize=4096

Die Werte hab ich von lsusb geraubt. So hab ich es die ganze Zeit probiert, aber mein (Mac OS)-Terminal hat einfach ein Zeichen zwischen den Zahlen eingefügt...

Mit dieser Methode sollte auch das disconnecten verschwunden sein. Bei mir läufts jetzt seit ca. 10 Stunden, vorher max. 2 Stunden. Ich will hier nicht mit nicht-funktionierenden .so's um mich werfen, sobald es funktioniert, lad ich sie hoch. So ganz einfach wie ich es mir vorgestellt habe, ist es nicht. Bei eingehender SMS kommt ein Fehler weil die Lib nicht gefunden wird (macht Sinn ). Leider kenn ich mich im Pinguin-C nicht aus und openWRT benutz ich auch erst seit ner Woche.


Für die perfekte Integration in openWRT müsste man das Paket so aufbauen, wie jetzt z.B. chan_local. Also im Endeffekt eine chan_datacard.ipk haben.

 

[PsychoMantis]

@ chrizzz
Welcher Befehl war das genau, um den Cardreader zu deaktivieren? Laut dieser Aussage "AT^U2DIAG=0".
Stimmt das? Wie gebe ich das in der Asterisk-CLI ein?

@ schufti
Die Idee mit einer einzelnen c-Datei gefällt mir eigentlich am besten. Verrätst du mir/uns wie man aus der Dateien chan_datacard.c, char_conv.c und char_conv.h eine einzelne chan_datacard.c macht?

Für die perfekte Integration in openWRT müsste man das Paket so aufbauen, wie jetzt z.B. chan_local. Also im Endeffekt eine chan_datacard.ipk haben.

Das ist meiner Meinung nach nicht so wichtig und kann warten. Ich selbst gehe einfach wie drei Posts weiter oben beschrieben vor und ändere zusätzlich einfach die Datei packages/net/asterisk-1.6.x/Makefile in dem ich einfach die rot markierten Sachen hinzufüge:

define Package/asterisk16/install
	$(INSTALL_DIR) $(1)/etc/asterisk
	for f in asterisk extensions features \
		indications logger manager modules \
		sip sip_notify rtp; do \
		$(CP) $(PKG_INSTALL_DIR)/etc/asterisk/$$$$f.conf $(1)/etc/asterisk/ ; \
	done
	$(INSTALL_DIR) $(1)/usr/lib/asterisk/modules
	for f in app_dial app_echo app_playback app_macro \
		chan_sip [color=red]chan_datacard[/color] codec_ulaw codec_gsm \
		format_gsm format_pcm format_wav format_wav_gsm \
		pbx_config \
		func_strings func_timeout func_callerid; do \
		$(CP) $(PKG_INSTALL_DIR)/usr/lib/asterisk/modules/$$$$f.so $(1)/usr/lib/asterisk/modules/ ; \
	done

 

[chrizzz]

AT^U2DIAG=0 ist richtig, das habe ich mit z.B. Hyperterminal aus Windows XP (mit installiertem Treiber!) über den automatisch erstellten (virtuellen) COM-Port eingehackt. Einfach ne niedrige Baud benutzen und z.B. AT (ENTER) senden, wenn dann ein OK zurückkommt, klappt alles und du kannst AT^U2DIAG=0 senden. Hier mal meine gepachte datacard.c. Libiconv muss, wie oben erwähnt, im Buildroot zur Verfügung stehen! Die iconv.h muß im include-Verzeichnis liegen, ich glaube unter

[br]/staging_dir/toolchain-gcc-bla/usr/include

. Vielleicht kannst du es ja mal bei dir testen?

EDIT: Die char_conv.h muss auch im channels-Verzeichnis liegen!
EDIT2: Weißt du sicher, aber du kannst Asterisk mit

make package/feeds/packages/asterisk-1.6.x-compile V=99

, danach liegt die ipkg im bin-Ordner. Während der Ausgabe siehst du auch die Warnings, die vom gcc geschmissen werden.

 

[Fredjam]

Hallo,

ich habe mich heute mal mit dem befehl AT^U2DIAG=0 auseinander gesetzt ... Da hier ja geschrieben worden ist, das dies die lösung für die disconnects sind...

Die infos habe ich gefunden.
http://www.dlink.ua/?e1550
einfach übersetzt heist das (google)

1. Stellen Sie sicher, dass Sie Hyper Terminal (Windows XP) installiert, verbinden Sie das Modem Huawei 1550.
   2. Verbinden Sie das Modem.
   3. Überprüfen Sie die Verbindung durch Eingabe von "AT", wenn alles korrekt ist, sollten Sie die Zeichenfolge "OK".
   4. Als nächstes wählen Sie den gewünschten Befehl aus:
          * AT^U2DIAG=0 Gerät WinModem
          * AT^U2DIAG=1 Gerät als Modem + CD-ROM
          * AT^U2DIAG=255 Gerät als Modem + CD-ROM + Card Reader
          * AT^U2DIAG=256 Gerät als Modem + Card Reader

Warnung Sie müssen Treiber für das Modem an den Computer wie möglich mit ZeroCD Start nicht mehr zu halten.
Betriebsschalter das Modem eignet sich für viele Modems Funktion ZeroCD.

Jetzt habe ich mit den werten mal ein wenig rumgespielt... das geht auch ohne win
screen /dev/ttyUSB0
dann einfach eintippen:

at

also antwort bekommt man wenn es alles funktionert ein OK

Jetzt werde ich die nächsten Tage schauen und prüfen ob sich was zeit...

noch was am rande.
ich habe mit den verschiedensten firmware parallel gearbeitet.
11.314.21.31.00
11.314.17.31.00
11.314.12.02.00
11.314.12.00.00

wobei die letzte firmware "11.314.12.00.00" nach einem Tag meinen Ganzen USB hub von 5 sticks gekickt hat...
das gleiche mit einen der befehle weiter oben...

AT^U2DIAG=0

und würder bekommst man ein OK.

 

[chrizzz]

Screen /dev/ttyUSB geht aber nicht, wenn es gar nicht erkannt wird.. Dann: Win+Treiber installieren! Hast mal die Chan_datacard kompiliert? Gruß

 

[Fredjam]

dumme frage, hast du screen installiert und auch den richtigen ttyUSB ausgewählt?

gibt mal bitte ein

ls -la /dev/ttyUSB*

 

[PsychoMantis]

Also bei mir funzt das mit dem screen. Einfach

opkg update
opkg install screen
screen /dev/ttyUSB0

 

[Fredjam]

Mal eine Frage,
was macht dieser befehl?

usbserial vendor=0x12d1 product=0x1001 maxSize=4096

 

[chrizzz]

Ok, ich hab mich falsch ausgedrückt.

Bei mir wurde das Modem nur als "Mass Storage Device" erkannt, nicht als USB Modem. Dadurch hatte ich natürlich auch keine /dev/ttyUSBx-Geräte (deshalb auch kein screen). Das gleiche passiert, wenn ihr das Modem in einen Win/Mac steckt, da werden beim ersten reinstecken nur die Treiber/Software installiert. Dann sendet der Treiber ein "modeswitch", damit das Gerät sich als Modem "anmeldet". Unter Linux gibt es dafür USB_modeswitch oder huaweiaktbbo. Das hat aber bei mir, warum auch immer, nicht funktioniert.

Ich habe nur usbcore, usb-uhci, usb-ohci, usb-ehci, usb-serial. Nicht den Treiber von Option. Vielleicht sorgt der für die automatische Anmeldung und die Probleme?

Für usb-serial muß man normalerweise unter /etc/modules.d/ einen Eintrag anlegen, der folgendes enthält:

usbserial vendor=0x12d1 product=0x1001 maxSize=4096

Danach(neustart) wurden bei mir die /dev/ttyUSBx-Geräte angezeigt und alles funktioniert perfekt.. Jetzt schon seit 2 oder 3 Tagen..

P.S.: Zur Info/Fehlersuche
lsusb zeigt das Modem bei mir jetzt als usb 1.1-gerät an:

Bus 002 Device 008: ID 12d1:1001 Huawei Technologies Co., Ltd. E620 USB Modem
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

root@OpenWRT_7:~# lsmod | grep usb
usbserial              21960  6 
usbcore                91760  6 usbserial,uhci_hcd,ohci_hcd,ehci_hcd,rtl8187
nls_base                4336  8 vfat,fat,ntfs,hfsplus,hfs,cifs,nls_utf8,usbcore

root@OpenWRT_7:~# ls -la /dev/ttyUSB*
crw-rw-rw-    1 root     root     188,   0 Apr 13 20:40 /dev/ttyUSB0
crw-rw-rw-    1 root     root     188,   1 Apr 14 20:51 /dev/ttyUSB1
crw-rw-rw-    1 root     root     188,   2 Apr 16 07:43 /dev/ttyUSB2

Kann mir jemand verraten, wie die udev-rules eingetragen werden? Hab folgendes gemacht:
In

/lib/udev/rules.d/10-datacard.rules
/*das eingetragen*/
SUBSYSTEMS=="usb", ATTRS{idProduct}=="1001", ATTRS{idVendor}=="12d1", SYMLINK+="ttyUSB_%b", KERNEL=="ttyUSB[0-9*]", MODE="0666", OWNER="root",GROUP="root"

funktioniert so aber nicht.

 

[schufti]

@psychomantis

ich gehe mal davon aus, dass du/ihr von den orig. asterisk sourcen kompiliert, dann

1) im asterisk source Verzeichnis: make distclean

2) chan_datacard.c, char_conv.h, char_conv.c ins channels Verzeichnis kopieren

3) das Makefile im channels Verzeichnis um folgene Zeile ergänzen:
(am besten unter der ähnlichen Zeile für chan_iax2)

$(if $(filter chan_datacard,$(EMBEDDED_MODS)),modules.link,chan_datacard.so): char_conv.o

4) ./configure (wichtig! sonst wird das neue Modul nicht gefunden und eingebunden)

5) make menuselect, make, make install (was auch immer) wie gewohnt durchführen

schufti

 

[Fredjam]

also die udev roulz habe ich nicht im lib ordner sondern im /etc/udev/rules.d/ ordner...

echo 'SUBSYSTEMS=="usb", SYMLINK+="ttyUSB_%b", KERNEL=="ttyUSB*", MODE="0666", OWNER="asterisk",GROUP="uucp"' >> /etc/udev/rules.d/92-datacard.rules

Mit den die du gepostet hast wirst du probleme bekommen wenn du über 9 ports kommst...
mit dem consolen befehl hast du die in deinem system... ^^

nach einem Neustart sieht das ganze dann so aus.

lrwxrwxrwx 1 root     root       7 15. Apr 09:22 /dev/ttyUSB_4-1.5.2:1.0 -> ttyUSB0
lrwxrwxrwx 1 root     root       7 15. Apr 09:22 /dev/ttyUSB_4-1.5.2:1.1 -> ttyUSB1
lrwxrwxrwx 1 root     root       7 15. Apr 09:22 /dev/ttyUSB_4-1.5.2:1.2 -> ttyUSB2
lrwxrwxrwx 1 root     root       7 15. Apr 05:53 /dev/ttyUSB_4-1.5.3:1.0 -> ttyUSB3
lrwxrwxrwx 1 root     root       7 15. Apr 05:53 /dev/ttyUSB_4-1.5.3:1.1 -> ttyUSB4
lrwxrwxrwx 1 root     root       7 15. Apr 05:53 /dev/ttyUSB_4-1.5.3:1.2 -> ttyUSB5
lrwxrwxrwx 1 root     root       7 16. Apr 01:38 /dev/ttyUSB_4-1.5.4:1.0 -> ttyUSB6
lrwxrwxrwx 1 root     root       7 16. Apr 01:38 /dev/ttyUSB_4-1.5.4:1.1 -> ttyUSB7
lrwxrwxrwx 1 root     root       7 16. Apr 01:38 /dev/ttyUSB_4-1.5.4:1.2 -> ttyUSB8
lrwxrwxrwx

in die datacard.conf
must du dann halt immer

audio=//dev/ttyUSB_4-1.5.2:1.1
data=/dev/ttyUSB_4-1.5.2:1.2

audio=/dev/ttyUSB_4-1.5.3:1.1
data=/dev/ttyUSB_4-1.5.3:1.2

audio=/dev/ttyUSB_4-1.5.4:1.1
data=/dev/ttyUSB_4-1.5.4:1.2

 

[sparkie]

Hallo Leute,

ist ja ein geniales Projekt hier. Meine Hardware ist das Intel D945GSEJT + HFC-S PCI.

Mit den Standard Paketen von Debian Squeeze laeuft hier bereits ein Asterisk mit der HFC im TE-Mode. Geplant ist jedoch der NT-Mode zum Anschluss meiner GIGASET-ISDN. DAHDI konnte ich dazu schon mal testweise zum NT-Mode ueberreden.

Mir ist schon klar, dass spaeter fuer GSM Betrieb das 'chan_datacard' manuell integriert werden muss.

Meine Frage:
Haltet ihr diese Vorgehensweise grundsaetzlich fuer sinnvoll oder gibt's einfachere Moeglichkeiten, um zu einem lauffaehigen GSM-Voip-ISDN-Gateway (mit ISDN im NT-Mode) auf obiger Hardware zu kommen?

- sparkie