I have a loaded module of avmfritz from mISDN, with everything that’s required for that, and /sys/class/mISDN/AVM.1/device/ shows that it is working. but capiinfo can’t find it, and states: > capi no installed - No such device or address (6) /etc/init.d/capi is started. capisuite, when I try to start it, also complains, that: > Can't start Capi abstraction. The given error message was: CapiError: Error in CAPI20_ISINSTALLED: CAPI not installed. occured in Capi::getCapiInfo() What does it mean with “CAPI not installled”? CAPI is obviously enabled in the kernel, or the avmfritz module would not load. Also lsmod shows capi is loaded, together with kernelcapi capifs, mISDN_core and mISDNipac. But /dev/capi/ is empty. /dev/capi20 exists. Package versions: sys-kernel/hardened-sources-2.6.32-r22 net-dialup/capi4k-utils-20050718-r5 Relevant configuration options: # egrep -i 'misdn|capi' /usr/src/linux/.config CONFIG_MISDN=m CONFIG_MISDN_DSP=m CONFIG_MISDN_L1OIP=m # mISDN hardware drivers # CONFIG_MISDN_HFCPCI is not set # CONFIG_MISDN_HFCMULTI is not set # CONFIG_MISDN_HFCUSB is not set CONFIG_MISDN_AVMFRITZ=m # CONFIG_MISDN_SPEEDFAX is not set # CONFIG_MISDN_INFINEON is not set # CONFIG_MISDN_W6692 is not set # CONFIG_MISDN_NETJET is not set CONFIG_MISDN_IPAC=m CONFIG_ISDN_CAPI=m CONFIG_CAPI_TRACE=y CONFIG_ISDN_CAPI_MIDDLEWARE=y CONFIG_ISDN_CAPI_CAPI20=m CONFIG_ISDN_CAPI_CAPIFS_BOOL=y CONFIG_ISDN_CAPI_CAPIFS=m # CAPI hardware drivers # CONFIG_CAPI_AVM is not set # CONFIG_CAPI_EICON is not set Reproducible: Always Steps to Reproduce: 1. Make sure you have the avmfritz module loaded, with everything required for it, and capi4k-utils installed. 2. Run capiinfo Actual Results: capi no installed - No such device or address (6) Expected Results: Show the avmfritz device in some way. I don’t get what it wants. Is the device node missing or what? P.S.: This is me moving from kernel 2.6.28 with the external fcpci module just now. (In case there are “leftovers”?)
Additional infos: /dev/capi is mounted: > capifs on /dev/capi type capifs (rw,mode=0666) dmesg states (dmesg | egrep -i 'misdn|capi|avm|fritz'): CAPI Subsystem Rev 1.1.2.8 capifs: Rev 1.1.2.3 capi20: Rev 1.1.2.7: started up with major 68 (middleware+capifs) mISDNipac module version 2.0 AVM Fritz PCI driver Rev. 2.1 mISDN: found adapter Fritz!Card PCI at 0000:01:08.0 AVM.1: AVM Fritz!CARD PCI config irq:18 base:0xD400 AVM 1 cards installed DEBUG grsec: mount of capifs to /dev/capi by /bin/mount[mount:4385] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/capiinit[capiinit:4373] uid/euid:0/0 gid/egid:0/0
OK, I think I found something: The logs contained this bit: Nov 20 14:02:53 [udevd-work] mknod(/dev/capi/0, 020660, (191,0) failed: Operation not permitted_ Nov 20 14:02:53 [udevd-work] mknod(/dev/capi/1, 020660, (191,1) failed: Operation not permitted_ Nov 20 14:02:53 [udevd-work] mknod(/dev/capi/2, 020660, (191,2) failed: Operation not permitted_ Nov 20 14:02:53 [udevd-work] mknod(/dev/capi/3, 020660, (191,3) failed: Operation not permitted_ Nov 20 14:02:53 [udevd-work] mknod(/dev/capi/4, 020660, (191,4) failed: Operation not permitted_ Nov 20 14:02:53 [udevd-work] mknod(/dev/capi/5, 020660, (191,5) failed: Operation not permitted_ Nov 20 14:02:53 [udevd-work] mknod(/dev/capi/6, 020660, (191,6) failed: Operation not permitted_ Nov 20 14:02:53 [udevd-work] mknod(/dev/capi/8, 020660, (191,8) failed: Operation not permitted_ Nov 20 14:02:53 [udevd-work] mknod(/dev/capi/7, 020660, (191,7) failed: Operation not permitted_ Nov 20 14:02:53 [udevd-work] mknod(/dev/capi/9, 020660, (191,9) failed: Operation not permitted_ Nov 20 14:02:53 [udevd-work] mknod(/dev/capi/11, 020660, (191,11) failed: Operation not permitted_ Nov 20 14:02:53 [udevd-work] mknod(/dev/capi/10, 020660, (191,10) failed: Operation not permitted_ Nov 20 14:02:53 [udevd-work] mknod(/dev/capi/22, 020660, (191,22) failed: Operation not permitted_ Nov 20 14:02:53 [udevd-work] mknod(/dev/capi/23, 020660, (191,23) failed: Operation not permitted_ Nov 20 14:02:53 [udevd-work] mknod(/dev/capi/24, 020660, (191,24) failed: Operation not permitted_ Nov 20 14:02:53 [udevd-work] mknod(/dev/capi/25, 020660, (191,25) failed: Operation not permitted_ Nov 20 14:02:53 [udevd-work] mknod(/dev/capi/31, 020660, (191,31) failed: Operation not permitted_ Nov 20 14:02:53 [udevd-work] mknod(/dev/capi/30, 020660, (191,30) failed: Operation not permitted_ Nov 20 14:02:53 [udevd-work] mknod(/dev/capi/20, 020660, (191,20) failed: Operation not permitted_ Nov 20 14:02:53 [udevd-work] mknod(/dev/capi/17, 020660, (191,17) failed: Operation not permitted_ Nov 20 14:02:53 [udevd-work] mknod(/dev/capi/19, 020660, (191,19) failed: Operation not permitted_ Nov 20 14:02:53 [udevd-work] mknod(/dev/capi/18, 020660, (191,18) failed: Operation not permitted_ Nov 20 14:02:53 [udevd-work] mknod(/dev/capi/27, 020660, (191,27) failed: Operation not permitted_ Nov 20 14:02:53 [udevd-work] mknod(/dev/capi/29, 020660, (191,29) failed: Operation not permitted_ Nov 20 14:02:53 [udevd-work] mknod(/dev/capi/28, 020660, (191,28) failed: Operation not permitted_ Nov 20 14:02:53 [udevd-work] mknod(/dev/capi/26, 020660, (191,26) failed: Operation not permitted_ Nov 20 14:02:53 [udevd-work] mknod(/dev/capi/12, 020660, (191,12) failed: Operation not permitted_ Nov 20 14:02:53 [udevd-work] mknod(/dev/capi/21, 020660, (191,21) failed: Operation not permitted_ Nov 20 14:02:53 [udevd-work] mknod(/dev/capi/13, 020660, (191,13) failed: Operation not permitted_ Nov 20 14:02:53 [udevd-work] mknod(/dev/capi/16, 020660, (191,16) failed: Operation not permitted_ Nov 20 14:02:53 [udevd-work] mknod(/dev/capi/14, 020660, (191,14) failed: Operation not permitted_ Nov 20 14:02:53 [udevd-work] mknod(/dev/capi/15, 020660, (191,15) failed: Operation not permitted_ Looks pretty obvious to me. But why in the world would udevd not be permitted to do that? I hope it’s not PAX or something. But there were no PAX messages…
Seems I’m by far the only one on the net, who has this exact problem. Nobody seems to have a solution though.
Unfortunately we have no access to such hardware to reproduce the problem :-(
I could supply you with such a card. (FritzCard PCI) But I can’t afford distant shipping, and I’d only do it if somebody actually needs this, as the card is special to me.
Haha. I just saw that I reported this bug a long time ago. If this bug only exists for me, please ignore it. I have moved on to XMPP/SIP with RTC. So if anybody else needs this for something important, write me a e-mail about it, and I may give away the card.
The trick is that it's probably an upstream issue. And upstream seems to be dead for a long time. So, even if you gave us access to this card, no matter how - physical one, ssh access to a machine with card installed or other, it's needed to become a new upstream for the whole package to fix this. And we are very sorry, but we have no manpower for doing this.
(In reply to Sergey Popov from comment #7) > no matter how I meant physically sending over the card, since I certainly won’t give anyone hardware access to my server. ^^ > And we are very sorry, but we have no manpower for doing this. Don’t worry. :) I’m thankful you even replied to this at all. :) I just wrote it as an offer to those other three CCs.
