Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 346179 - capiinit (capi4k-utils) can’t find working avmfritz (mISDN) card
Summary: capiinit (capi4k-utils) can’t find working avmfritz (mISDN) card
Status: RESOLVED CANTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Library (show other bugs)
Hardware: All Linux
: High normal with 1 vote (vote)
Assignee: Gentoo Dialup Developers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-20 14:24 UTC by Navid Zamani
Modified: 2014-06-28 19:13 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Navid Zamani 2010-11-20 14:24:23 UTC
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”?)
Comment 1 Navid Zamani 2010-11-20 14:36:05 UTC
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
Comment 2 Navid Zamani 2010-11-20 15:41:47 UTC
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…
Comment 3 Navid Zamani 2010-11-20 16:06:55 UTC
Seems I’m by far the only one on the net, who has this exact problem. Nobody seems to have a solution though.
Comment 4 Sergey Popov gentoo-dev 2014-06-28 07:20:44 UTC
Unfortunately we have no access to such hardware to reproduce the problem :-(
Comment 5 Navid Zamani 2014-06-28 11:36:38 UTC
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.
Comment 6 Navid Zamani 2014-06-28 11:38:46 UTC
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.
Comment 7 Sergey Popov gentoo-dev 2014-06-28 19:09:22 UTC
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.
Comment 8 Navid Zamani 2014-06-28 19:13:57 UTC
(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.