Please post patches and new ebuilds for zaptel/dahdi to this bug. Note: The name of this driver is zaptel up until 1.x versions. From 2.0 forward it will be called dahdi due to copyright issues with the name. http://blogs.digium.com/2008/05/19 Reproducible: Always Steps to Reproduce: Bug #224907 is a duplicate and can be closed.
Version bump to zaptel-1.4.11 in VoIP Overlay (r699). Features new USE flag echpec (support for commercial HPEC echo chanceller). Tested on amd64 only.
Revision zaptel-1.4.11-r1 in VoIP Overlay (r702). The HPEC echo chanceller is now enabled by the init script if present.
1. emerge net-misc/zaptel-1.4.11-r1 (and asterisk) 2. modprobe ztdummy 3. You will now have the /dev/zap/pseudo is created with permissions crw-rw---- 1 root dialout 196, 255 Jul 8 18:09 /dev/zap/pseudo Meetme and other technology which requires the "pseudo device" will now FAIL with the error "build_conf: Unable to open pseudo device". This is because the asterisk is running as user "asterisk" and this user does NOT have access to the /dev/zap/pseudo technology. Quick fix: Add asterisk to group dialout. Personally preferred fix: ebuild should create /dev/zap/pseudo be 0wned by root:asterisk Non-helpfull cries for help: http://forums.digium.com/viewtopic.php?p=65497
Zaptel is not exclusively used by Asterisk but also by other ebuilds such as CallWeaver, therefore any devices created by Zaptel should use generic users and groups - in this case root:dialout. IMHO using root:asterisk instead is not the way to go, better change the Howtos out there: > Quick fix: Add asterisk to group dialout. Sounds like a good and consisten solution to me. Any comments?
This will need to replace zaptel once kernel 2.6.26 is stabilized as zaptel doesn't support 2.6.26.
dahdi compiles on x86, can we please get the ~x86 keyword in there? Got it running successfully here on x86.
The devices installed by dahdi are owned by root:root. Thats not what asterisk wants i guess. Had to do a chown root:dialout and add group write access to those devices. No i am able to use dahdi as dummy device for app_meetme.
Created attachment 172077 [details] udev rules for dahdi The dahdi ebuild installs a bunch of nodes in /dev/dahdi, however, upon reboot these goes away (power failure), which is obviously no good. The attached file creates the appropriate files and sets the group to asterisk so that asterisk can actually gain access to the files. The default is for udev to create device nodes such as /dev/dahdi1 /dev/dahdictl etc ... just a missing / can cause a lot of trouble. My system works correctly with the attached file in /etc/udev/rules.d/
Hi, two more comments: 1. /etc/init.d/dahdi does NOT actually load the modules listed in /etc/dahdi/modules. Just misleading, I load them from /etc/modules.autoload.d/kernel-2.6 anyway. 2. /etc/init.d/dahdi should check for the existance of /etc/fxotune.vals and if it exists (presuming dahdi_cfg was successful) execute fxotune -s.
Please version bump for dahdi-2.1.0.4 (fixes kernel panic).
(In reply to comment #10) > Please version bump for dahdi-2.1.0.4 (fixes kernel panic). I'll do it this evening, sorry for the delay.
> I'll do it this evening, sorry for the delay. Argh, I can't to the version bump as I'm on the road this week and I forgot to take the svn password along. However, it compiles okay on my amd64. Can somebody else do the bump? (Otherwise I can do it - yet not before Sunday.) Thanks!
Version bump to dahdi 2.1.0.4 as of r796.
To confirm, the Svoop & Rambaldi ebuild from the overlay has made it into the main tree. As such, this bug is now resolved. Any comments/fixes for the in-tree ebuild go in a new bug please. Thank you for your contribution to the VoiP overlay and Gentoo Linux itself.
