Kommentarloser Absturz bei Faxeingang

[Bernd Wurst]

Hallo.

Ich nutze Capisuite schon lÀnger und hatte schon manchmal Probleme mit
dem FritzCard-BinÀrtreiber, aber so wie jetz twar es noch nie. ;-)

Also, seit etwa einer Woche kann mein Capisuite kein Fax mehr annehmen.
Wenn ein Fax reinkommt, wird das ordnungsgemÀß angenommen und als SFF
gespeichert. Beim EmpfÀnger wird die Übertragung als "Ok" eingestuft.
Die SFF-Datei kann danach problemlos nach TIFF und PDF konvertiert
werden.

Danach ist der Capisuite-Prozess aber weg, in der Logfile kein weiterer
Kommentar.
Die .txt-Datei mit den Infos wird *nicht* erstellt, daher glaube ich,
dass der Fehler noch vor dem Konvertieren auftritt.

Was ich zu dem Zeitpunkt getan habe, seit das Fax nicht mehr geht, war,
dass ich vom capisuite 0.4.4 auf 0.4.5 geupdated habe. Ein Downgrade
hat aber nichts geholfen.

Zum Test habe ich bereits die FritzCard USB durch eine FritzCard PCI
ersetzt, das hat aber nichts geÀndert (bis auf das Problem, dass dann
der PPPd nicht mehr per DSL einwÀhlen wollte) (!).

Kernel habe ich auch geÀndert und neu kompiliert (2.6.11 => 2.6.11.7),
kein Erfolg, Capi-Treiber-Module habe ich alle neu erstellt, ebenfalls
nichts geÀndert.

Jetzt bin ich mit meinem Latein am Ende. Anrufbeantworter funktioniert
einwandfrei.

Hat jemand ne Idee, wo ich da weiter suchen kann?
Im Anhang ein Ausschnitt der Log-Datei mit exzessiv-Logging. Danach ist
sofort Ende, ohne weitere Meldungen. In der capisuite.error wird nichts
geloggt ausser "Capisuite started".

cu, Bernd

[Jeroen Roovers]

I am seeing the exact same problems you are describing, when using a
2.6.11 and a 2.6.12-rc3 kernel, capi4k-utils 20041006-r5, isdn4k-utils
3.6_pre20041219-r1 (for what it's worth) and capisuite 0.4.5.

The answering machine and fax reception both work properly, but after
that capisuite stops without notice.

The last messages in capisuite.log are:

----------------------------------------------------------
Thu Apr 28 14:12:28 2005 Capi 0x81a96b0: <INFO_IND: Controller/PLCI
0x101, InfoN
umber 1e (ignoring)
Thu Apr 28 14:12:28 2005 Capi 0x81a96b0: >INFO_RESP ApplId 0x2, MsgNr
0x3e, Addr
ess 0x101
Thu Apr 28 14:12:28 2005 Capi 0x81a96b0: info: 0
Thu Apr 28 14:12:28 2005 Capi 0x81a96b0: **
Thu Apr 28 14:12:28 2005 Capi 0x81a96b0: *
Thu Apr 28 14:12:28 2005 Capi 0x81a96b0: <DISCONNECT_B3_IND NCCI 0x10101
Reason
0x3301
Thu Apr 28 14:12:28 2005 Connection 0x8221b08: stop_file_transmission
initiated
Thu Apr 28 14:12:28 2005 Connection 0x8221b08: stop_file_transmission
finished
Thu Apr 28 14:12:28 2005 Connection 0x8221b08: stop_file_reception finished
Thu Apr 28 14:12:28 2005 Capi 0x81a96b0: >DISCONNECT_B3_RESP ApplId 0x2
MsgNum 0
x3f NCCI 0x10101
Thu Apr 28 14:12:28 2005 Capi 0x81a96b0: info: 0
Thu Apr 28 14:12:28 2005 Capi 0x81a96b0: **
----------------------------------------------------------

In messages I find:

----------------------------------------------------------
Apr 28 13:56:58 henke capidrv-1: incoming call 595424274,1,1,595424045
Apr 28 13:56:58 henke capidrv-1: patching si2=1 to 0 for VBOX
Apr 28 13:56:58 henke isdn_net: call from 595424274 -> 0 595424045 ignored
Apr 28 13:56:58 henke isdn_tty: call from 595424274 -> 595424045 ignored
Apr 28 13:56:58 henke capidrv-1: incoming call 595424274,1,0,595424045
ignored
Apr 28 13:56:58 henke capilib_new_ncci: kcapi: appl 2 ncci 0x10101 up
Apr 28 13:57:14 henke kcapi: appl 2 ncci 0x10101 forced down
Apr 28 13:57:14 henke capilib_free_ncci: ncci 0x10101 not found
----------------------------------------------------------

Post by Bernd Wurst
Hallo.
Ich nutze Capisuite schon länger und hatte schon manchmal Probleme mit
dem FritzCard-Binärtreiber, aber so wie jetz twar es noch nie. ;-)
Also, seit etwa einer Woche kann mein Capisuite kein Fax mehr annehmen.
Wenn ein Fax reinkommt, wird das ordnungsgemäß angenommen und als SFF
gespeichert. Beim Empfänger wird die Übertragung als "Ok" eingestuft.
Die SFF-Datei kann danach problemlos nach TIFF und PDF konvertiert
werden.
Danach ist der Capisuite-Prozess aber weg, in der Logfile kein weiterer
Kommentar.
Die .txt-Datei mit den Infos wird *nicht* erstellt, daher glaube ich,
dass der Fehler noch vor dem Konvertieren auftritt.
Was ich zu dem Zeitpunkt getan habe, seit das Fax nicht mehr geht, war,
dass ich vom capisuite 0.4.4 auf 0.4.5 geupdated habe. Ein Downgrade
hat aber nichts geholfen.
Zum Test habe ich bereits die FritzCard USB durch eine FritzCard PCI
ersetzt, das hat aber nichts geändert (bis auf das Problem, dass dann
der PPPd nicht mehr per DSL einwählen wollte) (!).
Kernel habe ich auch geändert und neu kompiliert (2.6.11 => 2.6.11.7),
kein Erfolg, Capi-Treiber-Module habe ich alle neu erstellt, ebenfalls
nichts geändert.
Jetzt bin ich mit meinem Latein am Ende. Anrufbeantworter funktioniert
einwandfrei.
Hat jemand ne Idee, wo ich da weiter suchen kann?
Im Anhang ein Ausschnitt der Log-Datei mit exzessiv-Logging. Danach ist
sofort Ende, ohne weitere Meldungen. In der capisuite.error wird nichts
geloggt ausser "Capisuite started".
cu, Bernd

[Jeroen Roovers]

I also notice that I have never seen an e-mail from Capisuite yet. Maybe
it is not able to send e-mail to fax / answering machine users. I have
searched for the mail requirements for MailAndSave, and it's not
entirely clear to me how Capisuite does this.

For the moment I consider it entirely possible that: 1) Capisuite
doesn't succeed in sending e-mail and 2) doesn't have sanity checks for
this requirement. It's also possible that 3) the Gentoo ebuild doesn't
provide all the necessary files and sane defaults.

I have checked that I can send mail from root (Capisuite) to user
(Capisuite user receiving fax/voice). Could someone please point me in
the right direction as to the requirements for a local mail delivery system?

Post by Jeroen Roovers
I am seeing the exact same problems you are describing, when using a
2.6.11 and a 2.6.12-rc3 kernel, capi4k-utils 20041006-r5, isdn4k-utils
3.6_pre20041219-r1 (for what it's worth) and capisuite 0.4.5.
The answering machine and fax reception both work properly, but after
that capisuite stops without notice.
----------------------------------------------------------
Thu Apr 28 14:12:28 2005 Capi 0x81a96b0: <INFO_IND: Controller/PLCI
0x101, InfoN
umber 1e (ignoring)
Thu Apr 28 14:12:28 2005 Capi 0x81a96b0: >INFO_RESP ApplId 0x2, MsgNr
0x3e, Addr
ess 0x101
Thu Apr 28 14:12:28 2005 Capi 0x81a96b0: info: 0
Thu Apr 28 14:12:28 2005 Capi 0x81a96b0: **
Thu Apr 28 14:12:28 2005 Capi 0x81a96b0: *
Thu Apr 28 14:12:28 2005 Capi 0x81a96b0: <DISCONNECT_B3_IND NCCI 0x10101
Reason
0x3301
Thu Apr 28 14:12:28 2005 Connection 0x8221b08: stop_file_transmission
initiated
Thu Apr 28 14:12:28 2005 Connection 0x8221b08: stop_file_transmission
finished
Thu Apr 28 14:12:28 2005 Connection 0x8221b08: stop_file_reception finished
Thu Apr 28 14:12:28 2005 Capi 0x81a96b0: >DISCONNECT_B3_RESP ApplId 0x2
MsgNum 0
x3f NCCI 0x10101
Thu Apr 28 14:12:28 2005 Capi 0x81a96b0: info: 0
Thu Apr 28 14:12:28 2005 Capi 0x81a96b0: **
----------------------------------------------------------
----------------------------------------------------------
Apr 28 13:56:58 henke capidrv-1: incoming call 595424274,1,1,595424045
Apr 28 13:56:58 henke capidrv-1: patching si2=1 to 0 for VBOX
Apr 28 13:56:58 henke isdn_net: call from 595424274 -> 0 595424045 ignored
Apr 28 13:56:58 henke isdn_tty: call from 595424274 -> 595424045 ignored
Apr 28 13:56:58 henke capidrv-1: incoming call 595424274,1,0,595424045
ignored
Apr 28 13:56:58 henke capilib_new_ncci: kcapi: appl 2 ncci 0x10101 up
Apr 28 13:57:14 henke kcapi: appl 2 ncci 0x10101 forced down
Apr 28 13:57:14 henke capilib_free_ncci: ncci 0x10101 not found
----------------------------------------------------------

[Bernd Wurst]

Hallo.

Post by Jeroen Roovers
For the moment I consider it entirely possible that: 1) Capisuite
doesn't succeed in sending e-mail and 2) doesn't have sanity checks
for this requirement. It's also possible that 3) the Gentoo ebuild
doesn't provide all the necessary files and sane defaults.

It's number 1 because of number 2. ;-)

Ok, in particular:
Capisuite reads the config file and passes the (string-)value of the
user's *_email parameters to python's mail sending library without any
checks. But python's library expects a list of fully qualified
addresses. Also, if you have something that is not a valid address
(e.g. without domain part), mail sending can fail if your MTA is kind
of pedantic (Exim4 and Courier are, I heared of Postfix too).

The correct way is to specify a single, fully qualified address for the
*_email options. If you want to use multiple addresses, I wrote a patch
to correctly give python's library a list instead of a string. You can
find the patch in the (ok, german) message from 2005-04-07 17:37 CEST
written by me.

You will not see any problems when your mail server has lazy protocol
implementation, QMail for example did work for me but Courier doesn't.

cu, Bernd

[Jeroen Roovers]

Hi,


it's me again. If you rather write German, please feel free to do so. I
have no problems *reading* German. :)

I am currently recompiling/installing (Gentoo-speak: merging) glibc and
gcc in an attempt to root out the problem. Because capisuite doesn't
generate the .txt files in the users/*/* directories properly, it may be
looking for a codepage / character map that's missing from either glibc
or the libstdc++ library which comes with gcc and is used by Python.

Since I compiled glibc with only a couple of these codepages (through
the "userlocales" USE flag), Capisuite/Python may be failing to convert
the text it wants to write to the .txt files. Still, why it crashes
without any form of notice is beyond me. Any thoughts on this theory?


JeR

Post by Bernd Wurst
Hallo.

Post by Jeroen Roovers
For the moment I consider it entirely possible that: 1) Capisuite
doesn't succeed in sending e-mail and 2) doesn't have sanity checks
for this requirement. It's also possible that 3) the Gentoo ebuild
doesn't provide all the necessary files and sane defaults.

It's number 1 because of number 2. ;-)
Capisuite reads the config file and passes the (string-)value of the
user's *_email parameters to python's mail sending library without any
checks. But python's library expects a list of fully qualified
addresses. Also, if you have something that is not a valid address
(e.g. without domain part), mail sending can fail if your MTA is kind
of pedantic (Exim4 and Courier are, I heared of Postfix too).
The correct way is to specify a single, fully qualified address for the
*_email options. If you want to use multiple addresses, I wrote a patch
to correctly give python's library a list instead of a string. You can
find the patch in the (ok, german) message from 2005-04-07 17:37 CEST
written by me.
You will not see any problems when your mail server has lazy protocol
implementation, QMail for example did work for me but Courier doesn't.
cu, Bernd

[Bernd Wurst]

Hallo.

Post by Jeroen Roovers
Any thoughts on this theory?

Cool. ;-)
I also use gentoo and so this sounds possible. Though, I can't really
believe it, because Capisuite should only write characters in the
7-bit-ACSII space and every other app I know about does some kind of
fallback to an existing locale.

I don't have the ability to change much on the target system, so it
would be great if you keep me up-to-date with your experiences.

cu, Bernd

[Jeroen Roovers]

On the other hand, something like

iconv -f Latin1 -t CP437 <file>

doesn't complain about missing codepages at all. In fact 'iconv -l'
neatly lists an incredible lot of character maps. Still, Capisuite
doesn't write the .txt files it should. I'll try to investigate further.


JeR

Post by Bernd Wurst
Hallo.

Post by Jeroen Roovers
Any thoughts on this theory?

Cool. ;-)
I also use gentoo and so this sounds possible. Though, I can't really
believe it, because Capisuite should only write characters in the
7-bit-ACSII space and every other app I know about does some kind of
fallback to an existing locale.
I don't have the ability to change much on the target system, so it
would be great if you keep me up-to-date with your experiences.
cu, Bernd

[Jeroen Roovers]

Post by Bernd Wurst
I also use gentoo

Hmmm. I didn't notice that at first. Congratulations on your choice. :)

But what it means is, I guess it's time to file a bug report...
<clickity> It's number 90901. (
http://bugs.gentoo.org/show_bug.cgi?id=90901 )


Have a nice day,
JeR