* Jan Girlich schrieb:

ich habe alles gemacht, was in der i4l-Faq und Howto über die abc-Extensions drinsteht um Least Cost Routing zu aktivieren. Dennoch funktioniert es nicht.

Wer kann mir da helfen? (Leo?)

Ich habe Kernel 2.4.20 vanilla und nutze Gentoo 1.4_rc3.

Als erstes den Patch runtergeladen und eingespielt (http://i4l.mediatronix.de/isdn-20010926-channelbind.tgz). make menuconfig und dann den LCR-Support unter "abc-dw-extensions" ausgewählt. Ein "make dep && make clean bzImage modules modules_install" und den fertigen Kernel an die richtige Stelle geschoben. Isdnlog mit abclcr=4 und providerchange=/etc/isdn/provider in der Config-File ausgeführt. Das Skript provider läuft und gibt "0" zurück.

isdnlog muss neu übersetzt werden. Hierbei muss die Konstante CONFIG_ISDN_WITH_ABC_LCR_SUPPORT aus der Kernelkonfiguration gesetzt sein. Mangels entsprechenden Kernel(quellen) weiß ich nicht, ob dies automatisch der Fall ist. Auf jeden Fall wird hierdurch das Verhalten in ~/isdn4k-utils/isdnlog/isdnlog/processor.c o. ä. geändert. Hiernach sollte isdnlog echtes LCR betreiben, eine Bestätigung dafür ist mir bislang nicht aber bekannt, von daher wären Deine Ergebnisse in jedem Fall wissenswert. Sollte das Neuübersetzen zu Problemen führen, diese bitte hier schildern. Gruß Tobias -- Tobias Becker E-Mail tobiasb@talypso.de PGP 0xD06BB70D * Und erfahrene Menschen sagen, daß derjenige, der zu viel sieht und zu viel weiß, ähnlich wie der, der zu wenig sieht und zu wenig weiß, leicht vom richtigen Weg abkommt und untergeht. * Stefan Chwin *

* Jan Girlich schrieb:

Tobias Becker schrieb:

...

isdnlog muss neu übersetzt werden. Hierbei muss die Konstante CONFIG_ISDN_WITH_ABC_LCR_SUPPORT aus der Kernelkonfiguration gesetzt sein. Mangels entsprechenden Kernel(quellen) weiß ich nicht, ob dies automatisch der Fall ist. Auf jeden Fall wird hierdurch das Verhalten in ~/isdn4k-utils/isdnlog/isdnlog/processor.c o. ä. geändert.

Ja, ich habe mir die Stelle im Source-Code angesehen. Und die Konstante ist erst nach einspielen des Channelbind-Patches verfügbar und muss dann noch auf 'y' gesetzt werden.

Das ist innerhalb der Kernelquellen und hier in meinen Augen ein gutes Zeichen. Ich habe auf Anhieb keinen Mechanismus in den isdnlog-Quellen gesehen, der /usr/src/linux/.config beim Übersetzen mit einbindet und daher ein mögliches Problem gesehen. Aber soweit sind wir ja noch nicht.

Das Problem liegt ein wenig früher als ich dachte. Und zwar ist kein Hisax-Treiber mehr da, wenn man den Patch einspielt und den Kernel neu kompiliert. Dabei spielt es keine Rolle, ob man den Hisax als Modul oder fest in den Kernel mit einkompiliert. Er scheint einfach zu verschwinden. "modprobe: can't find module hisax" Und bei fest im Kernel kompiliertem Treiber ist nichts davon in dmesg zu finden.

Kernelpatches sind nicht mein Gewerk. Einfallen tut mir daher zum einen nur ein `depmod -a' oder insmod statt modprobe. Zum anderen sollte `locate hisax.o' Aufschluss darüber geben, ob das Modul erstellt und richtig installiert wurde.

Ist es ein Ausweg den capi-Treiber zu verwenden? Das werde ich im Verlaufe der nächsten Tage mal probieren, aber ich habe noch keinerlei Erfahrungen mit der Capi.

Soweit ich weiß, wurden die ABC-Erweiterung zuletzt im Kernel 2.0 offziell unterstützt, die CAPI gibt es erst ab 2.4. Sofern der Kernelpatch sie nicht ausdrücklich erwähnt, würde ich eher keinen Erfolg erwarten. Gruß Tobias -- Tobias Becker E-Mail tobiasb@talypso.de PGP 0xD06BB70D * Und erfahrene Menschen sagen, daß derjenige, der zu viel sieht und zu viel weiß, ähnlich wie der, der zu wenig sieht und zu wenig weiß, leicht vom richtigen Weg abkommt und untergeht. * Stefan Chwin *

Hallo, Jan Girlich schrieb:

Ich habe mir in der Zwischenzeit anders geholfen. Ich habe Kernel 2.4.20 vanilla eingespielt, alles korrekt übersetzt etc mit "make dep && make clean bzImage modules modules_install" und danach die Kernel-Sourcen gepatcht mit dem ISDN-Tree mit Channelbindings und einen neuen Kernel mit aktiviertem abc_lcr kompiliert. Danach einfach die Modules tec vom alten benutzt und den Vatr mit einer Soende audegootet.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Es war spät gestern... ;) Also noch mal Klartext. Ich habe den Kernel (2.2.40 vanilla) normal installiert ("make dep && make clean bzImage modules modules_install") und danach den ISDN-Tree mit Channelbinding eingespielt. Den Kernel daraus kompiliert ("make dep && make clean bzImage") und von diesem Kernel gestartet. Dann lief das HiSax-Modul ohne Probleme. Dann habe ich isdnlog neu kompiliert und festgestellt: es tut sich nichts. Daraufhin habe ich noch mal in dmesg reingeschaut und da ist keine Meldung von den abc-exensions zu finden. Sollte es aber laut Dokumentation (http://i4l.mediatronix.de/de-dwabc-extension-howto-4.htm). Daher komme ich nun zu dem Resultat, dass es nicht möglich ist LCR mit dem Kernel 2.4.20 zu betreiben. Gruß Jan

Tobias Becker schrieb:

* Jan Girlich schrieb:

...

Also noch mal Klartext. Ich habe den Kernel (2.2.40 vanilla) normal installiert ("make dep && make clean bzImage modules modules_install") und danach den ISDN-Tree mit Channelbinding eingespielt. Den Kernel daraus kompiliert ("make dep && make clean bzImage") und von diesem Kernel gestartet. Dann lief das HiSax-Modul ohne Probleme. Dann habe ich isdnlog neu kompiliert und festgestellt: es tut sich nichts. Daraufhin habe ich noch mal in dmesg reingeschaut und da ist keine Meldung von den abc-exensions zu finden. Sollte es aber laut Dokumentation (http://i4l.mediatronix.de/de-dwabc-extension-howto-4.htm).

Das HOWTO geht von einem Durchgang aus. Sofern noch nicht geschehen, wäre so ein neuer Versuch (Kernelquellen auspacken, ISDN-Tree auspacken und einspielen, erst dann make menuconfig usw.) überlegenswert.

Ist schon geschehen. Das war der Durchgang, den ich noch vor Anfang dieses Threads gemacht habe.

Unabhängig davon würde ich vermuten, dass nach dem Einspielen ein neues make menuconfig mit Auswahl der der ABC Extensions erforderlich ist, da std2kern diese Fähigkeit wohl nur bereitstellt, nicht aber aktiviert.

Richtig. Das ist im HowTo auch erläutert und so habe ich es auch gemacht.

Allerdings spricht http://i4l.mediatronix.de/ mit Datum vom 22.02.2003 davon, dass der abweichende ISDN-Tree nur bis Kernel 2.4.17 getestet wurde. In diesem Zusammenhang stellt sich die Frage, wie aktuell diese Quelltexte sind, und ob ihnen vielleicht wichtige Änderungen der neuesten Zeit fehlen. Dies könnte auch das fehlerhafte Übersetzungsverhalten (kein Modul hisax.o) verständlich erscheinen lassen.

Das ist genau der Punkt, bei dem ich inzwischen angelangt bin. Soweit ich verstanden habe ist das nicht nur ein Patch, sondern der ISDN-Tree des letzten Kernels, der Channelbinding unterstützte. Also schon relativ alter Code. Woran erkennst du übrigens das Datum der Seite? Ich nehme an, dass sie aus dem Jahre 2002 stammt.

In diesem Fall wären die notwendigen Änderungen gegenüber den Standardkernel manuell vorzunehmen. Vielleicht weiß ja der Webmaster von http://i4l.mediatronix.de/ noch etwas.

Genau dem werde ich morgen mal eine E-Mail schreiben. Der wird sicher noch etwas wissen. Soweit ich das sehe ist er ja auch der Autor der dw-abc-Extensions. (dw = Detlef Wengorz)

...

Daher komme ich nun zu dem Resultat, dass es nicht möglich ist LCR mit dem Kernel 2.4.20 zu betreiben.

Bis auf weiteres ist das der Stand der Dinge. Solltest Du noch zu einem Hisaxtreiber mit ABC Extensions kommen, lass es uns bitte wissen.

Ich werde mit dem Autor der Seiten auf i4l.mediatronix.de kontakt aufnehmen und hier kurz zusammenfassend erläutern wie der Sachverhalt aussieht. Gruß Jan

Jan Girlich wrote:

Das Projekt ist inzwischen seit 2 Jahren eingestellt worden, da

1. Linux diese Erweiterungen nie akzeptiert und in den Kernel aufgenommen hat 2. Die "ISDN-Quote", also die Verbreitung von ISDN, stark abnimmt und dementsprechend die Nachfrage nach solchen Techniken gering ist.

0. Da es Patente einer deutschen Firma gibt, die diese Art von LCR verhindern, sodaß es von Anfang an eher aussichtslos schien, das überhaupt durchzuziehen - AFAIK & IANAL.

Gruß Jan

leo