Guten Tag,
bekomme ich die Fritz!Card PCI V2.0 problemlos unter openSUSE 10.1
installiert? Gibt es dabei irgendwas besonderes zu beachten und ist in der
Distribution ein vernünftiges Programm zum versenden und empfangen von
Faxen enthalten??
Stephan
Hallo Liste !
Ich versuche einen BlueFRITZ USB-Stick (Bluetooth)
(mit Bluetooth-Headset) an meinem PC
(SuSE 10, AMD 64 Bit) zu betreiben.
Der Stick wird unter YAST-Hardware-Informationen
erkannt, aber ohne Icon auf dem KDE-Desktop.
Normale USB-Sticks dagegen vollständig.
Bei YAST-Hardware ist Bluetooth vorhanden,
versucht aber nach anclicken jedesmal
bluez-utils zu installieren.
Was mache ich falsch und weiss jemand Rat?
In den mailinglisten habe ich nur gefunden, dass
bluetooth in Version 10.0 voll integriert sein soll.
Die AVM-beschreibung hilft mir auch nicht weiter...
Herzlichen Dank inzwischen
Rabis
Hallo!
Ich hab hier Probleme mit einer Fritz!Card Classic (allerdings hab ich es zwischenzeitl auch mit einer PCI versucht). Beide Karten funktionieren mit dem Rechner, solange ich sie an einem T-Com Anschluss betreibe. Sobald ich sie jedoch an die Arcor Starterbox hänge (meine Eltern haben seit neuestem einen Arcor Anschluss) geht gar nichts mehr.
D.h. im Einzelnen:
- das Telefon, das über eine TK an dem anderen S0 Anschluss hängt, funktioniert nicht mehr,
- die Karte wird zwar vom Treiber erkannt + eingebunden, ich bekomme jedoch keinerlei Signale von ihr (z.B. isdnlog).
Woran kann das liegen? Allmählich nervt es. Also nochmal: ich hab den Rechner abgebaut, zur neuen Wohnung transportiert und angeschlossen... vorher gings - jetzt nicht mehr.
Wir reden über kernel 2.6.16.9, mit dem akt. AVM Treiber (ich sitze grade nicht am Rechner und darf mich auch noch über die *besch..schreckliche* Internetanbindung via Arcor aufregen, die auch nicht wirklich funktioniert)
Danke Euch!
cu,
Stefan
PS: ich kann versuchen, benötigte Logs zu beschaffen, jedoch ist die Internetanbindung eine Qual...manchmal geht es und dann wieder überhaupt nicht (leider ist die 2. Variante derzeit *sehr* häufig anzutreffen)
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
On Wed, Aug 23, 2006 at 02:56:52AM +0200, Gregor Howey wrote:
> Karsten Keil schrieb:
> > On Mon, Aug 21, 2006 at 12:37:19PM +0200, Gregor Howey wrote:
> >
> >> Hallo,
> >>
> >>> On Thu, Aug 17, 2006 at 01:05:05PM +0200, Gregor Howey wrote:
> >>>
> >>>> Hallo,
> >>>> Ich habe eine AVM C4 Karte an einem ptp (Anlagenanschluß)
> >>>> angeschlossen, an dem ich nur die Durchwahlinformationen (000-999)
> >>>> erhalte.
> >>>>
> >>>> System ist SuSE Linux 9.0
> >>>>
> >>>>
> >>> Welche capisuite Version (rpm -q capisuite oder capisuite -h)
> >>>
> >> Die Capisuite hat die Version 0.4.3
> >>
> >>
> >
> > Die konnte definitiv noch kein DDI, das war erst ab 0.4.4 drin.
> >
> Das klingt nicht schön :( da ich wegen anderer Sachen auf der Suse 9er
> bleiben muss (Ursprünglich lief das System mit SuSe 10.0).
> Was brauche ich um ne Capisuite >= 0.4.4 auf der Suse 9.0 zum Laufen zu
> bekommen (lassen sich die sourcen compilieren oder braucht es updates?).
Ja mit ein paar Anpassungen im spec File, ich habe mal Pakete für 32 Bit
gebaut unter (bzw. mirrors):
ftp://ftp.suse.com/pub/people/kkeil/testing/9.0/i586/capisuite-0.4.5-52.i58…
Soure RPM steht auch dort.
--
Karsten Keil
SuSE Labs
ISDN development
> Ich habe ein Problem mit Linux PS's die über eine ISDN Leitungen im Ausland (GB,PL,...) angebunden sind. Die CLI wird bei diversen Providern nicht zur Verfügung gestellt.
>
> Welche Möglichkeit existiert, die CLI Prüfung im capiplugin zu umgehen und bei jedem eingehenden Datenruf die feste cbnumber zurückzurufen.
>
> debug
> sync
> noauth
> name 1388
> demand
> connect ''
> idle 120
> ipparam XXX
> plugin capiplugin.so
> number XXX
> cli XXX
> coso local
> protocol hdlc
> ipcp-accept-local
> ipcp-accept-remote
> /dev/null
>
> Kernel: 2.4.29
> pppd version 2.4.1
> capiplugin: $Revision: 1.20 $
>
>
Hallo,
Ich habe eine AVM C4 Karte an einem ptp (Anlagenanschluß)
angeschlossen, an dem ich nur die Durchwahlinformationen (000-999)
erhalte.
System ist SuSE Linux 9.0
Eine Anwahl mit Blockwahl funktioniert einwandfrei, wenn ich jedoch
manuell wähle bekomme ich am Telefon die gesprochene Meldung "Dienst
oder Dienstmerkmal nicht möglich" es sieht so aus, als würde
capisuite nach der ersten Ziffer den Anruf annehmen.
Auszug aus der capisuite.conf:
DDI_length="3"
DDI_base_length="0"
DDI_stop_numbers=""
Wo steckt der Fehler?
Hallo,
gibt es die Möglichkeit über die Fritzbox (Fritz!Box Fon WLAN 7170) zu Faxen?
Mit Windows soll es ja klappen, gibt es da auch schon etwas für Linux?
Danke für Eure Hinweise. ;o)
--
Mit freundlichen Grüßen
Stefan Blinkmann
-Don´t send HTML Coded Mails !-
Hallo,
ich beabsichtige das Anrufbeantwortersystem VOCP mit Hilfe von vgetty und
einer Fritz ISDN PCI 2.0 zu betreiben.
Habe SuSE 10.1 mit i4l / capi4linux 2006.4.25-4 und capisuite 0.4.5-19 sowie
die Capi Treiber von http://opensuse.fltronic.de/ für den Kernel 2.6.16-21.
Fogendes Problem: Nach Annahme des Anrufs und eingehender DTMF-Töne reagiert
VOCP nicht. Habe hier mal den vgetty-log:
08/17 20:27:00 yI7 Linux ISDN: OK
08/17 20:27:00 yI7 voice command: 'AT+FCLASS=8' -> 'OK'
08/17 20:27:00 yI7 vgetty: AT+FCLASS=8
08/17 20:27:00 yI7 Linux ISDN: OK
08/17 20:27:00 yI7 voice command: 'AT' -> 'OK'
08/17 20:27:00 yI7 vgetty: AT
08/17 20:27:00 yI7 Linux ISDN: OK
08/17 20:27:00 yI7 vgetty: queued event RESET_WATCHDOG at position 0001
08/17 20:27:00 yI7 voice command: 'ATS20?' -> '0|1|2|3|4'
08/17 20:27:01 yI7 vgetty: ATS20?
08/17 20:27:01 yI7 vgetty: unqueued event RESET_WATCHDOG at position 0001
08/17 20:27:01 yI7 vgetty: voice_handle_event got event RESET_WATCHDOG with
data <_>
08/17 20:27:01 yI7 Linux ISDN: 1
08/17 20:27:01 yI7 voice command: 'ATA' -> 'VCON'
08/17 20:27:01 yI7 vgetty: ATA
08/17 20:27:01 yI7 Linux ISDN: OK
08/17 20:27:01 yI7 Linux ISDN: VCON
08/17 20:27:01 yI7 vgetty: queued event RESET_WATCHDOG at position 0002
08/17 20:27:01 yI7 voice command: 'AT+VLS=2' -> 'VCON|OK|NO CARRIER'
08/17 20:27:01 yI7 vgetty: AT+VLS=2
08/17 20:27:01 yI7 vgetty: unqueued event RESET_WATCHDOG at position 0002
08/17 20:27:01 yI7 vgetty: voice_handle_event got event RESET_WATCHDOG with
data <_>
08/17 20:27:01 yI7 Linux ISDN: OK
08/17 20:27:01 yI7 vgetty: Executing shell script /usr/local/vocp/bin/vocp.pl
with shell /usr/bin/perl
08/17 20:27:01 yI7 vgetty: opening pipes
08/17 20:27:01 yI7 vgetty: forking shell
08/17 20:27:01 yI7 vgetty(0): HELLO SHELL
08/17 20:27:01 yI7 vgetty: Got pipe signal
08/17 20:27:01 yI7 vgetty: queued event SIGNAL_SIGPIPE at position 0003
08/17 20:27:01 yI7 vgetty: unqueued event SIGNAL_SIGPIPE at position 0003
08/17 20:27:01 yI7 vgetty: voice_handle_event got event SIGNAL_SIGPIPE with
data <_>
08/17 20:27:01 yI7 shell(1): HELLO VOICE PROGRAM
08/17 20:27:01 yI7 vgetty(1): READY
08/17 20:27:01 yI7 vgetty: initialized communication
08/17 20:27:01 yI7 vgetty: Got pipe signal
08/17 20:27:01 yI7 vgetty: queued event SIGNAL_SIGPIPE at position 0004
08/17 20:27:01 yI7 vgetty: unqueued event SIGNAL_SIGPIPE at position 0004
08/17 20:27:01 yI7 vgetty: voice_handle_event got event SIGNAL_SIGPIPE with
data <_>
08/17 20:27:01 yI7 shell(1): DEVICE DIALUP_LINE
08/17 20:27:01 yI7 vgetty: queued event RESET_WATCHDOG at position 0005
08/17 20:27:01 yI7 voice command: 'AT+VLS=2' -> 'VCON|OK|NO CARRIER'
08/17 20:27:01 yI7 vgetty: AT+VLS=2
08/17 20:27:01 yI7 vgetty: unqueued event RESET_WATCHDOG at position 0005
08/17 20:27:01 yI7 vgetty: voice_handle_event got event RESET_WATCHDOG with
data <x>
08/17 20:27:01 yI7 Linux ISDN: OK
08/17 20:27:01 yI7 vgetty(1): READY
08/17 20:27:01 yI7 vgetty: Got pipe signal
08/17 20:27:01 yI7 vgetty: queued event SIGNAL_SIGPIPE at position 0006
08/17 20:27:01 yI7 vgetty: unqueued event SIGNAL_SIGPIPE at position 0006
08/17 20:27:01 yI7 vgetty: voice_handle_event got event SIGNAL_SIGPIPE with
data <_>
08/17 20:27:01 yI7 shell(1): AUTOSTOP ON
08/17 20:27:01 yI7 vgetty(1): READY
08/17 20:27:02 yI7 vgetty: Got pipe signal
08/17 20:27:02 yI7 vgetty: queued event SIGNAL_SIGPIPE at position 0007
08/17 20:27:02 yI7 vgetty: unqueued event SIGNAL_SIGPIPE at position 0007
08/17 20:27:02 yI7 vgetty: voice_handle_event got event SIGNAL_SIGPIPE with
data <_>
08/17 20:27:02 yI7 shell(1): ENABLE EVENTS
08/17 20:27:02 yI7 vgetty(1): READY
08/17 20:27:02 yI7 vgetty: Got pipe signal
08/17 20:27:02 yI7 vgetty: queued event SIGNAL_SIGPIPE at position 0008
08/17 20:27:02 yI7 vgetty: unqueued event SIGNAL_SIGPIPE at position 0008
08/17 20:27:02 yI7 vgetty: voice_handle_event got event SIGNAL_SIGPIPE with
data <_>
08/17 20:27:02 yI7 shell(1): PLAY /var/spool/voice/messages/root.rmd
08/17 20:27:02 yI7 vgetty(1): PLAYING
08/17 20:27:02 yI7 playing voice file /var/spool/voice/messages/root.rmd
08/17 20:27:02 yI7 vgetty: raw modem data header found
08/17 20:27:02 yI7 vgetty: modem type ISDN4Linux found
08/17 20:27:02 yI7 vgetty: compression method 0x0006, speed 8000, bits 8
08/17 20:27:02 yI7 vgetty: queued event RESET_WATCHDOG at position 0009
08/17 20:27:02 yI7 voice command: 'AT+VSM=6' -> 'OK'
08/17 20:27:02 yI7 vgetty: AT+VSM=6
08/17 20:27:02 yI7 vgetty: unqueued event RESET_WATCHDOG at position 0009
08/17 20:27:02 yI7 vgetty: voice_handle_event got event RESET_WATCHDOG with
data <x>
08/17 20:27:02 yI7 Linux ISDN: OK
08/17 20:27:02 yI7 vgetty: queued event RESET_WATCHDOG at position 0010
08/17 20:27:02 yI7 vgetty: unqueued event RESET_WATCHDOG at position 0010
08/17 20:27:02 yI7 vgetty: voice_handle_event got event RESET_WATCHDOG with
data <x>
08/17 20:27:02 yI7 voice command: 'AT' -> 'OK'
08/17 20:27:02 yI7 vgetty: AT
08/17 20:27:02 yI7 Linux ISDN: OK
08/17 20:27:02 yI7 tio_set_flow_control( HARD XON_OUT )
08/17 20:27:02 yI7 voice command: 'AT+VTX' -> 'CONNECT|NO ANSWER'
08/17 20:27:02 yI7 vgetty: AT+VTX
08/17 20:27:02 yI7 Linux ISDN: CONNECT
08/17 20:27:03 yI7 Linux ISDN: <DLE> <_>
08/17 20:27:03 yI7 vgetty: Unknown code <DLE> <_>
08/17 20:27:04 yI7 Linux ISDN: <DLE> <_>
08/17 20:27:04 yI7 vgetty: Unknown code <DLE> <_>
08/17 20:27:05 yI7 vgetty: <VOICE DATA 29825 bytes>
08/17 20:27:05 yI7 vgetty: queued event RESET_WATCHDOG at position 0011
08/17 20:27:05 yI7 vgetty: unqueued event RESET_WATCHDOG at position 0011
08/17 20:27:05 yI7 vgetty: voice_handle_event got event RESET_WATCHDOG with
data <x>
08/17 20:27:05 yI7 vgetty: <STOP PLAY>
08/17 20:27:05 yI7 voice command: '' -> 'OK|VCON'
08/17 20:27:05 yI7 Linux ISDN: VCON
08/17 20:27:05 yI7 vgetty(1): READY
08/17 20:27:05 yI7 vgetty: Got pipe signal
08/17 20:27:05 yI7 vgetty: queued event SIGNAL_SIGPIPE at position 0012
08/17 20:27:05 yI7 vgetty: unqueued event SIGNAL_SIGPIPE at position 0012
08/17 20:27:05 yI7 vgetty: voice_handle_event got event SIGNAL_SIGPIPE with
data <_>
08/17 20:27:05 yI7 shell(1): WAIT 3
08/17 20:27:05 yI7 vgetty(1): WAITING
08/17 20:27:05 yI7 vgetty: queued event RESET_WATCHDOG at position 0013
08/17 20:27:05 yI7 vgetty: unqueued event RESET_WATCHDOG at position 0013
08/17 20:27:05 yI7 vgetty: voice_handle_event got event RESET_WATCHDOG with
data <_>
08/17 20:27:05 yI7 vgetty: queued event RESET_WATCHDOG at position 0014
08/17 20:27:05 yI7 vgetty: unqueued event RESET_WATCHDOG at position 0014
08/17 20:27:05 yI7 vgetty: voice_handle_event got event RESET_WATCHDOG with
data <_>
08/17 20:27:09 yI7 vgetty(1): READY
08/17 20:27:09 yI7 vgetty: Got pipe signal
08/17 20:27:09 yI7 vgetty: queued event SIGNAL_SIGPIPE at position 0015
08/17 20:27:09 yI7 vgetty: unqueued event SIGNAL_SIGPIPE at position 0015
08/17 20:27:09 yI7 vgetty: voice_handle_event got event SIGNAL_SIGPIPE with
data <_>
08/17 20:27:09 yI7 shell(1): PLAY /var/spool/voice/messages/system/error.rmd
08/17 20:27:09 yI7 vgetty(1): PLAYING
08/17 20:27:09 yI7 playing voice
file /var/spool/voice/messages/system/error.rmd
08/17 20:27:09 yI7 vgetty: raw modem data header found
08/17 20:27:09 yI7 vgetty: modem type ISDN4Linux found
08/17 20:27:09 yI7 vgetty: compression method 0x0006, speed 8000, bits 8
08/17 20:27:09 yI7 vgetty: queued event RESET_WATCHDOG at position 0016
08/17 20:27:09 yI7 voice command: 'AT+VSM=6' -> 'OK'
08/17 20:27:09 yI7 vgetty: AT+VSM=6
08/17 20:27:09 yI7 vgetty: unqueued event RESET_WATCHDOG at position 0016
08/17 20:27:09 yI7 vgetty: voice_handle_event got event RESET_WATCHDOG with
data <_>
08/17 20:27:09 yI7 Linux ISDN: OK
08/17 20:27:09 yI7 vgetty: queued event RESET_WATCHDOG at position 0017
08/17 20:27:09 yI7 vgetty: unqueued event RESET_WATCHDOG at position 0017
08/17 20:27:09 yI7 vgetty: voice_handle_event got event RESET_WATCHDOG with
data <_>
08/17 20:27:09 yI7 voice command: 'AT' -> 'OK'
08/17 20:27:09 yI7 vgetty: AT
08/17 20:27:09 yI7 Linux ISDN: OK
08/17 20:27:09 yI7 tio_set_flow_control( HARD XON_OUT )
08/17 20:27:09 yI7 voice command: 'AT+VTX' -> 'CONNECT|NO ANSWER'
08/17 20:27:09 yI7 vgetty: AT+VTX
08/17 20:27:09 yI7 Linux ISDN: CONNECT
08/17 20:27:09 yI7 Linux ISDN: <DLE> <_>
08/17 20:27:09 yI7 vgetty: Unknown code <DLE> <_>
08/17 20:27:09 yI7 Linux ISDN: <DLE> <_>
08/17 20:27:09 yI7 vgetty: Unknown code <DLE> <_>
08/17 20:27:09 yI7 vgetty: <VOICE DATA 10176 bytes>
Die Zeilen "Linux ISDN: <DLE> <_>" sind das eigentliche Problem, da müssten
eigentlich die Ziffern der gedrückten Tasten auftauchen. Da vgetty also nur
"Unkonw code <DLE> <_>" bekommt, kann VOCP natürlich auch auf nichts
reagieren.
Allerdings zeigt "tail -f /var/log/messages | grep dtmf" folgendes:
Aug 17 20:27:03 r2d2 kernel: dtmf: tt='1'
Aug 17 20:27:04 r2d2 kernel: dtmf: tt='2'
Aug 17 20:27:09 r2d2 kernel: dtmf: tt='3'
Aug 17 20:27:09 r2d2 kernel: dtmf: tt='4'
Also genau die Zifferntasten, die ich gedrückt habe.
Ein kurz aufgerufener vboxgetty zeigte beim Empfang von DTMF-Sequenzen
folgendes:
17-Aug 13:14:28 <E> Illeagal "<DLE>" shielded code "[0xFF]" (ignored)...
Habe dann das Terminalprogramm "minicom" gestartet und folgende AT-Sequenzen
im Dialog für das ISDN-Device eingegeben:
AT S7=45 S0=0 L1 V1 &c1 E1 Q0
OK
atz
OK
at&b512
OK
at&eXXXXXX
OK
at+fclass=8
OK
ats18=5
OK
ats13=20
OK
at+vls=2
OK
RING
CALLER NUMBER: XXXXXXXX
ata
VCON
at+vls=2
OK
at+vls=0
OK
at+vls=2
OK
at+vsm=6
OK
at+vtx
CONNECT
....
NO CARRIER
Die zweitletzte Zeile zeigt eben auch nur je einen Punkt pro ankommenden
DTMF-Ton, das sollte eigentlich so aussehen:
.1.2.3.4
/var/log/messages zeigte es wieder korrekt.
Ich weiß an dieser Stelle nicht mehr weiter, welches Programm sorgt für die
DTMF-Erkennung bzw. Weiterleitung vom Kernel?
Muss noch irgendein Register über den AT-Befehlssatz geändert werden?
Wo finde ich die komplette AT-Befehlssatz-Beschreibung für i4l?
Oder ist das ganze ein Bug?
Um jede Hilfe wäre ich sehr dankbar.
Übrigens: Auf einem anderen System mit SuSE 9.2 und Kernel 2.6.11 sowie einer
alten Fritz ISDN PCI funktioniert das ganze mit den o.g. Befehlssequenzen
problemlos.
Klaus Nitsche
Hallo Liste,
es kommt manchmal vor das capisuite 0.4.5 (SuSE 10.1) keine Faxe versenden
kann mit dem Ergebnis: "job fax-XX.sff: result was 34d8,0. Diese Meldung
weist auf "incompatible destination" hin.
Nach wiederholter Nachfrage bei dem Empfänger, ob das Faxgerät bzw. die
ISDN-Anlage auch richtig konfiguriert wurde und die Faxnummer korrekt ist
(langsam wird das peinlich :-)) wird mir immer gesagt das deren TK-Anlage und
das Faxgerät richtig konfiguriert sind und die Faxnummern auch korrekt sind.
Ständiger Zusatz: Schließlich hat das ein Fachman bei uns Installiert!
Ich habe selber schon mehrfach Netzwerke aufgebaut, wo ich mit Fachleuten
(Fachidioten) aus der Telekommunikations-Branche zusammen kam. Ein Fachman
sollte doch zumindest in der Lage sein eine Telefonanlage richtig zu
konfigurieren. Es häufen sich die Fälle, in denen es leider nicht so ist,
oder werden dort auch zu viele ungelernte Kräfte wegen der Kosten
eingestellt?
Da ich das Fax beruflich Nutze, suche ich nach einer Lösung des Problems,
dessen ich mir sicher bin das es mehrere Leute haben.
MfG
Gerhard Lüken
--
------------------------------------------
gerhard lueken | webentwickler | lueken(a)penguins-home.de
Wie kann ich den ISDN-Provider über die Shell konfigurieren, ohne YaST. Mit
isdnctrl kann ich nur das Interface konfigurieren (oder?). Hintergrund ist,
das die Konfiguration gescriptet werden soll.
Till Elsner
_________________________________
Henkel KGaA
CC Communication Data
Phone: +49-211-797-9150
E-Mail: till.elsner(a)henkel.de
Internet: http://www.Henkel.com
