Neuer Bristuff 1y
- Ersteller kombjuder
- Erstellt am
Mensch, jetzt hab ich das nächste Problem.
Bevor ich jetzt meinen alten Kernel mit dem neuen Compiler neubaue, habe ich mir gedacht, lieber gleich ein update auf den aktuellen Kernel 2.6.19 machen. Gesagt, getan, läuft einwandfrei.
Nun, jetzt kompiliert aber zaptel aus dem bristuff-installer nicht mehr:
CC [M] /root/bristuff-0.3.0-PRE-1w/zaptel-1.2.10/zaptel.o
In Datei, eingefügt von /root/bristuff-0.3.0-PRE-1w/zaptel-1.2.10/zaptel.c:40:
/root/bristuff-0.3.0-PRE-1w/zaptel-1.2.10/zconfig.h:9:26: linux/config.h: Datei oder Verzeichnis nicht gefunden
die /use/src/linux/lncludes/linux/config.h gibt es im 2.6.19er Kernel aber nicht mehr!
Die ganzen Inkompatibilitäten gehen mir langsam richtig auf den Wecker. Entweder die Programme sind veraltet und zaptel kompiliert nicht oder zu neu und es kompiliert ebenfalls nicht
Bevor ich jetzt meinen alten Kernel mit dem neuen Compiler neubaue, habe ich mir gedacht, lieber gleich ein update auf den aktuellen Kernel 2.6.19 machen. Gesagt, getan, läuft einwandfrei.
Nun, jetzt kompiliert aber zaptel aus dem bristuff-installer nicht mehr:
CC [M] /root/bristuff-0.3.0-PRE-1w/zaptel-1.2.10/zaptel.o
In Datei, eingefügt von /root/bristuff-0.3.0-PRE-1w/zaptel-1.2.10/zaptel.c:40:
/root/bristuff-0.3.0-PRE-1w/zaptel-1.2.10/zconfig.h:9:26: linux/config.h: Datei oder Verzeichnis nicht gefunden
die /use/src/linux/lncludes/linux/config.h gibt es im 2.6.19er Kernel aber nicht mehr!
Die ganzen Inkompatibilitäten gehen mir langsam richtig auf den Wecker. Entweder die Programme sind veraltet und zaptel kompiliert nicht oder zu neu und es kompiliert ebenfalls nicht
ähm, wo soll ich ./configure machen? In dem zaptel-Verzeichnis, welches der bristuff-installer holt und versucht zu kompilieren, gibt es kein configure.
Bin schon wieder ein Schritt weiter:
habe einfach ein config.h symlink auf autoconf.h in includes/linux/ erstellt. Nun kompiliert er auch eine lange Zeit, bricht dann aber später wieder ab bei:
Hat denn noch niemand versucht bristuff mit einem 2.6.19er Kernel zu bauen?
Bin schon wieder ein Schritt weiter:
habe einfach ein config.h symlink auf autoconf.h in includes/linux/ erstellt. Nun kompiliert er auch eine lange Zeit, bricht dann aber später wieder ab bei:
Code:
CC [M] /root/bristuff-0.3.0-PRE-1w/zaptel-1.2.10/xpp/card_fxo.o
In file included from /root/bristuff-0.3.0-PRE-1w/zaptel-1.2.10/xpp/xpd.h:26,
from /root/bristuff-0.3.0-PRE-1w/zaptel-1.2.10/xpp/card_fxo.c:28:
/root/bristuff-0.3.0-PRE-1w/zaptel-1.2.10/xpp/xdefs.h:93: error: conflicting types for `bool'
include/linux/types.h:36: error: previous declaration of `bool'
make[3]: *** [/root/bristuff-0.3.0-PRE-1w/zaptel-1.2.10/xpp/card_fxo.o] Fehler 1
make[2]: *** [/root/bristuff-0.3.0-PRE-1w/zaptel-1.2.10/xpp] Fehler 2
make[1]: *** [_module_/root/bristuff-0.3.0-PRE-1w/zaptel-1.2.10] Fehler 2
make[1]: Leaving directory `/usr/src/linux-2.6.19.1'
make: *** [linux26] Fehler 2Hat denn noch niemand versucht bristuff mit einem 2.6.19er Kernel zu bauen?
Netview
IPPF-Promi
- Mitglied seit
- 1 Apr 2004
- Beiträge
- 3,366
- Punkte für Reaktionen
- 0
- Punkte
- 36
Ich würde dir auch eher aus Stabilitätsgründen zu dem 2.6.16.x Kernel raten, der speziell in diese Richtung gepflegt wird (siehe hier: http://www.golem.de/0608/47187.html )
Danke für den Tipp. Auf meiner Workstation nutze ich auch 2.6.16 (aber nur aus zufall). Hätte ich das vorher gewusst, hätte ich meinen Server auch nur auf 2.6.16 upgedated.
Aber jetzt habe ich zaptel kompiliert bekommen und nun läuft die w vorerst wieder (inklusive florz-patch). Hoffe nun von den buffer overflows verschont zu bleiben. Wird sich nun zeigen.
Ach ja, was ich gemacht habe um den Fehler zu korrigieren ist hier beschrieben. habe in der
xpp/xdefs.h einfach die Zeile
typedef int bool;
ersetzt durch
typedef int _Bool;
Bringt haufenweise Warnungen (hoffe ich nutze/brauche dieses card_fxo nicht). Was ich da genau gemacht habe, weiss ich nicht, aber es kompiliert zumindest durch und scheint zu laufen
NACHTRAG: Nun, rund 3 Stunden später wieder die Buffer Overflows, trotz gleicher Compiler
Ich werde jetzt die p noch mal neubauen und schauen, ob's damit wieder okay ist.
NACHTRAG2: Die p läuft nun schon über einen halben Tag fehlerfrei. Also zwischen der p und der w muss sich was am zaphfc-Treiber geändert haben, dass auf meinem System für die Overflows verantwortlich ist.
Aber jetzt habe ich zaptel kompiliert bekommen und nun läuft die w vorerst wieder (inklusive florz-patch). Hoffe nun von den buffer overflows verschont zu bleiben. Wird sich nun zeigen.
Ach ja, was ich gemacht habe um den Fehler zu korrigieren ist hier beschrieben. habe in der
xpp/xdefs.h einfach die Zeile
typedef int bool;
ersetzt durch
typedef int _Bool;
Bringt haufenweise Warnungen (hoffe ich nutze/brauche dieses card_fxo nicht). Was ich da genau gemacht habe, weiss ich nicht, aber es kompiliert zumindest durch und scheint zu laufen
NACHTRAG: Nun, rund 3 Stunden später wieder die Buffer Overflows, trotz gleicher Compiler
Ich werde jetzt die p noch mal neubauen und schauen, ob's damit wieder okay ist.
NACHTRAG2: Die p läuft nun schon über einen halben Tag fehlerfrei. Also zwischen der p und der w muss sich was am zaphfc-Treiber geändert haben, dass auf meinem System für die Overflows verantwortlich ist.
Zuletzt bearbeitet:
- Mitglied seit
- 2 Nov 2004
- Beiträge
- 3,086
- Punkte für Reaktionen
- 0
- Punkte
- 0
Hallo,
da ich gerade einen Server neu aufsetzen musste, habe ich mal folgendes versucht:
Statt zaptel 1.2.10 wie im Bristuff vorgesehen, habe ich in die install.sh die 1.2.11 eingetragen.
Hat beim Auspacken gehakt, anscheinend ist das hinterlegte file beschädigt. Ich habe desshalb den Link auf den digium-Server geändert, dann gings.
Kompilierung incl. Florz ist problemlos durchgelaufen. Patch hat nur einige geänderte Zeilennummer angemerkt.
.
da ich gerade einen Server neu aufsetzen musste, habe ich mal folgendes versucht:
Statt zaptel 1.2.10 wie im Bristuff vorgesehen, habe ich in die install.sh die 1.2.11 eingetragen.
Hat beim Auspacken gehakt, anscheinend ist das hinterlegte file beschädigt. Ich habe desshalb den Link auf den digium-Server geändert, dann gings.
Kompilierung incl. Florz ist problemlos durchgelaufen. Patch hat nur einige geänderte Zeilennummer angemerkt.
.
Netview
IPPF-Promi
- Mitglied seit
- 1 Apr 2004
- Beiträge
- 3,366
- Punkte für Reaktionen
- 0
- Punkte
- 36
zaphfc 1w ist sowieso identisch mit 1v (md5) und hat beim kompilieren keinen Bezug zur zaptel-Version bzw. Bibliotheken. Lediglich im zaptel-package haben sich dann wohl einige offsets verschoben (deshalb die patch-Meldungen). Du hättest dir daher das Kompilieren von zaphfc (ink. florz-patch) sparen können ;-)
- Mitglied seit
- 2 Nov 2004
- Beiträge
- 3,086
- Punkte für Reaktionen
- 0
- Punkte
- 0
Netview schrieb:
Du hast den Text nicht ganz gelesen:
Weil ich einen neuen Server aufsetzen musste ...
Ich hätte mir bei einem der laufenden nicht die Mühe gemacht. Ging eigentlich nur um die Aussage, man könne auch den neusten zaptel verwenden.
hm, die p läuft nun wieder fehlerfrei, die w nicht
Dabei ist der einzige Unterschied beim zaphfc-modul:
`--> diff bristuff-0.3.0-PRE-1p/zaphfc/zaphfc.c bristuff-0.3.0-PRE-1w/zaphfc/zaphfc.c
29a30,33
> #ifdef LINUX26
> #include <linux/moduleparam.h>
> #endif
>
Ich habe diese drei Zeilen nun auch mal in der p eingebaut und werde beobachten, was passiert. Ich vermute der buffer overflow Fehler liegt gar nicht am zaphfc-Modul selbst, sondern an asterisk, zaptel oder ähnliches aus dem w-installer
NACHTRAG:
Erstaunlich! Fehler wieder aufgetreten! Es liegt wohl an diesen drei Zeilen!
Werde nun wohl noch mal 1w installieren und die drei Zeilen rausnehmen.
NACHTRAG2:
Ich steig jetzt nicht mehr durch. Habe gestern Nacht nochmal die 1w installiert (hab auch mal die zaptel 1.2.11 quelle eingetragen, natürlich von ftp.dignum.com) und die besagten Zeilen rausgelöscht: Der Overflow-Fehler tritt immer noch auf...
Bin jetzt wieder auf 1p und werde da nun auch bleiben. Läuft wieder ein tag stabil. Hatte gestern auch mal gcc 4.1 probiert und damit asterisk und kernel gebaut. Gleicher Fehler.
An die, bei denen die 1w fehlerfrei läuft: Welchen Compiler/Kernel nutzt ihr?
Dabei ist der einzige Unterschied beim zaphfc-modul:
`--> diff bristuff-0.3.0-PRE-1p/zaphfc/zaphfc.c bristuff-0.3.0-PRE-1w/zaphfc/zaphfc.c
29a30,33
> #ifdef LINUX26
> #include <linux/moduleparam.h>
> #endif
>
Ich habe diese drei Zeilen nun auch mal in der p eingebaut und werde beobachten, was passiert. Ich vermute der buffer overflow Fehler liegt gar nicht am zaphfc-Modul selbst, sondern an asterisk, zaptel oder ähnliches aus dem w-installer
NACHTRAG:
Erstaunlich! Fehler wieder aufgetreten! Es liegt wohl an diesen drei Zeilen!
Werde nun wohl noch mal 1w installieren und die drei Zeilen rausnehmen.
NACHTRAG2:
Ich steig jetzt nicht mehr durch. Habe gestern Nacht nochmal die 1w installiert (hab auch mal die zaptel 1.2.11 quelle eingetragen, natürlich von ftp.dignum.com) und die besagten Zeilen rausgelöscht: Der Overflow-Fehler tritt immer noch auf...
Bin jetzt wieder auf 1p und werde da nun auch bleiben. Läuft wieder ein tag stabil. Hatte gestern auch mal gcc 4.1 probiert und damit asterisk und kernel gebaut. Gleicher Fehler.
An die, bei denen die 1w fehlerfrei läuft: Welchen Compiler/Kernel nutzt ihr?
Zuletzt bearbeitet:
- Mitglied seit
- 2 Nov 2004
- Beiträge
- 3,086
- Punkte für Reaktionen
- 0
- Punkte
- 0
Hallo,
es gibt mal wieder was neues:
0.3.0-PRE-1x
- added software hdlc option for cwain driver ("modprobe cwain hw_hdlc=0")
- added hardware audio bridging to cwain driver ("modprobe cwain dacs=1")
- updated to asterisk 1.2.14
- fixes for ztgsm/chan_zap ("..unable to dial in state..")
Für Zaptel wird die V 1.2.10 verwendet. Wenn man download.sh auf 1.2.12 ändert wird fehlerfrei mit der aktuellen zaptel kompiliert.
es gibt mal wieder was neues:
0.3.0-PRE-1x
- added software hdlc option for cwain driver ("modprobe cwain hw_hdlc=0")
- added hardware audio bridging to cwain driver ("modprobe cwain dacs=1")
- updated to asterisk 1.2.14
- fixes for ztgsm/chan_zap ("..unable to dial in state..")
Für Zaptel wird die V 1.2.10 verwendet. Wenn man download.sh auf 1.2.12 ändert wird fehlerfrei mit der aktuellen zaptel kompiliert.
... das sollte ohne Meldungen funktionieren - ebenso beim aktuellen Bristuff.kombjuder schrieb:
Gruss
Walter
- Mitglied seit
- 2 Nov 2004
- Beiträge
- 3,086
- Punkte für Reaktionen
- 0
- Punkte
- 0
Das ist neu:
0.3.0-PRE-1y
- res_watchdog, fixed bug that prevented correct heartbeat to be generated
- fixed app_dial option "R"
- added "hdlcnet" option to cwain ("modprobe cwain hdlcnet=1").
This option bundles timeslots 1-31 into a single zaptel channel and performs
hardware HDLC encoding/decoding on the data. The result is a high performance
(with almost no noticable CPU usage) hdlc network device which can be used
with different wan protocols (e.g. cisco hdlc, ppp) on E1 leased lines.
- several cwain synchronization fixes
- hardware bridging "dacs=1" is default now for cwain
- extended cwain error reporting ("zap show status") on the asterisk cli
- ztgsm, fixed audio and signalling problems which occured in heavily loaded
environments (e.g. a multitude of zaptel cards lagging each others IRQs).
Tested on a P4 with 2 PRIs, 6 BRIs and 4 GSM channels.
- chan_zap/libgsmat, fixed ${HANGUPCAUSE} value for calls to busy subscribers
- added support for Junghanns.NET octoBRI PCI ISDN (version 2.0) and
Junghanns.NET duoBRI PCI ISDN in qozap.
Florz-Patch läuft.
0.3.0-PRE-1y
- res_watchdog, fixed bug that prevented correct heartbeat to be generated
- fixed app_dial option "R"
- added "hdlcnet" option to cwain ("modprobe cwain hdlcnet=1").
This option bundles timeslots 1-31 into a single zaptel channel and performs
hardware HDLC encoding/decoding on the data. The result is a high performance
(with almost no noticable CPU usage) hdlc network device which can be used
with different wan protocols (e.g. cisco hdlc, ppp) on E1 leased lines.
- several cwain synchronization fixes
- hardware bridging "dacs=1" is default now for cwain
- extended cwain error reporting ("zap show status") on the asterisk cli
- ztgsm, fixed audio and signalling problems which occured in heavily loaded
environments (e.g. a multitude of zaptel cards lagging each others IRQs).
Tested on a P4 with 2 PRIs, 6 BRIs and 4 GSM channels.
- chan_zap/libgsmat, fixed ${HANGUPCAUSE} value for calls to busy subscribers
- added support for Junghanns.NET octoBRI PCI ISDN (version 2.0) and
Junghanns.NET duoBRI PCI ISDN in qozap.
Florz-Patch läuft.
Netview schrieb:
... genau, ich hatte mich schon gewundert ueber Deine "Hochzeit". Der zaptel-Patch passt gar nicht zur 1.2.12 - Version.
Gruss
Walter
Netview
IPPF-Promi
- Mitglied seit
- 1 Apr 2004
- Beiträge
- 3,366
- Punkte für Reaktionen
- 0
- Punkte
- 36
Er passt zu zaptel 1.2.12 (war bereits in der 0.3.0-PRE-1x so!)
Aufwärts ab 1.2.13 geht's nimmer!
siehe hier: http://www.ip-phone-forum.de/showpost.php?p=782042&postcount=31
Aufwärts ab 1.2.13 geht's nimmer!
siehe hier: http://www.ip-phone-forum.de/showpost.php?p=782042&postcount=31
Netview schrieb:
Ich habe beim Patchen unzählige Hunks bekommen, beim Versuch 1.2.12 (via Anpassung der download.sh) zu nutzen. - "Es" funktionierte danach zwar scheinbar alles, aber das wird daran gelegen haben, dass nicht alle relavanten Zaptel-Funktionen gebraucht werden.
Gruss
Walter
Netview
IPPF-Promi
- Mitglied seit
- 1 Apr 2004
- Beiträge
- 3,366
- Punkte für Reaktionen
- 0
- Punkte
- 36
Hunks sind ja nichts schlimmes. Sie weissen lediglich darauf hin, dass die offsets nicht stimmen, jedoch das patch-Programm (scheinbar) die richtige Stelle gefunden hat (wenn man es genau nimmt kann man dies ja nochmals kontrollieren). Ich habe imho damit noch keine negativien Erfahrungen gemacht!
Neueste Beiträge
-
[Frage] Freepbx mit Telekom und Aufzeichnung
- Letzte: duffy6
-
[Sammlung] Aktuelle Konditionen für Vertragsverlängerung
- Letzte: RollinCHK
-
[Frage] 5590 Fiber und 1200AX - Wlan Frage- Letzte: Jstessi
-
5690 Pro Datenraten Problem 5ghz und 6ghz
- Letzte: Jstessi
-
[Sammlung] AVM-Gateway-kompatible Zigbee-Geräte
- Letzte: feikel67
-
Fritzbox als rustdesk-server?- Letzte: NDiIPP
