After running autoconf, I get this within /etc/dahdi/system.conf: # Digium Wildcard TE235 (VPMOCT064) (WCTE2/0/1) # Don't know how to configure this (type=digital-T1). # Please file a bug on bugs.gentoo.org and add jaco@uls.co.za as CC. # Digium Wildcard TE235 (VPMOCT064) (WCTE2/0/2) # Don't know how to configure this (type=digital-T1). # Please file a bug on bugs.gentoo.org and add jaco@uls.co.za as CC.
I actually fixed this issue by simply modifying /etc/modprobe.d/dahdi.conf: options wcte43x default_linemode=e1 Maybe autoconf can warn about this (eg. in a comment).
There is a difference between E1 and T1. With the card in t1 mode, can you please post me the output of cat /proc/dahdi/1 (assuming you only have this one card). In the meantime I've updated the init script to also generate an init warning on such cases. It won't give details, but it will alert visibly that there's an error. Would appreciate confirmation (since I don't have hardware on hand).
Hmm, I think I screwed things up a little. Here's what I did. Before changing from E1 to T1: # cat /proc/dahdi/1 Span 1: B4/0/1 "B4XXP (PCI) Card 0 Span 1" (MASTER) AMI/CCS 1 B4/0/1/1 Clear (In use) (EC: LASVEGAS2 - INACTIVE) 2 B4/0/1/2 Clear (In use) (EC: LASVEGAS2 - INACTIVE) 3 B4/0/1/3 Hardware-assisted HDLC (In use) (EC: LASVEGAS2 - INACTIVE) # lsmod | grep wcte wcte43x 77824 62 oct612x 188416 1 wcte43x dahdi 253952 225 wcb4xxp,oct612x,wcte43x # /etc/init.d/dahdi stop * Stopping DAHDI ... [ ok ] # /etc/init.d/asterisk stop * Signalling asterisk wrapper script to terminate ... [ ok ] * Stopping asterisk PBX gracefully ... [ ok ] # rmmod wcte43x # lsmod | grep wcte I now commented out everything in /etc/modprobe.d/dahdi.conf. # /etc/init.d/dahdi start * Starting DAHDI ... DAHDI_SPANCONFIG failed on span 5: No such device or address (6) [ !! ] # lsmod | grep wcte # modprobe wcte43x # lsmod | grep wcte wcte43x 77824 0 oct612x 188416 1 wcte43x dahdi 253952 15 wcb4xxp,oct612x,wcte43x # /etc/init.d/dahdi restart * Stopping DAHDI ... [ ok ] * Starting DAHDI ... DAHDI_SPANCONFIG failed on span 5: Invalid argument (22) [ !! ] # modprobe wcb4xxp # /etc/init.d/dahdi restart * Stopping DAHDI ... [ ok ] * Starting DAHDI ... DAHDI_SPANCONFIG failed on span 5: Invalid argument (22) [ !! ] # lsmod | grep wcb wcb4xxp 77824 0 dahdi 253952 15 wcb4xxp,oct612x,wcte43x # cat /proc/dahdi/1 Span 1: B4/0/1 "B4XXP (PCI) Card 0 Span 1" AMI/CCS 1 B4/0/1/1 (EC: LASVEGAS2 - INACTIVE) 2 B4/0/1/2 (EC: LASVEGAS2 - INACTIVE) 3 B4/0/1/3 (EC: LASVEGAS2 - INACTIVE) # cat /proc/dahdi/ (TAB) 1 2 3 4 5 6 # cat /proc/dahdi/2 Span 2: B4/0/2 "B4XXP (PCI) Card 0 Span 2" (MASTER) AMI/CCS 4 B4/0/2/1 (EC: LASVEGAS2 - INACTIVE) 5 B4/0/2/2 (EC: LASVEGAS2 - INACTIVE) 6 B4/0/2/3 (EC: LASVEGAS2 - INACTIVE) # cat /proc/dahdi/3 Span 3: B4/0/3 "B4XXP (PCI) Card 0 Span 3" AMI/CCS 7 B4/0/3/1 (EC: LASVEGAS2 - INACTIVE) 8 B4/0/3/2 (EC: LASVEGAS2 - INACTIVE) 9 B4/0/3/3 (EC: LASVEGAS2 - INACTIVE) # cat /proc/dahdi/4 Span 4: B4/0/4 "B4XXP (PCI) Card 0 Span 4" AMI/CCS 10 B4/0/4/1 (EC: LASVEGAS2 - INACTIVE) 11 B4/0/4/2 (EC: LASVEGAS2 - INACTIVE) 12 B4/0/4/3 (EC: LASVEGAS2 - INACTIVE) # cat /proc/dahdi/5 Span 5: WCTE2/0/1 "WCTE23X (PCI) Card 0 Span 1" 13 WCTE2/0/1/1 14 WCTE2/0/1/2 15 WCTE2/0/1/3 16 WCTE2/0/1/4 17 WCTE2/0/1/5 18 WCTE2/0/1/6 19 WCTE2/0/1/7 20 WCTE2/0/1/8 21 WCTE2/0/1/9 22 WCTE2/0/1/10 23 WCTE2/0/1/11 24 WCTE2/0/1/12 25 WCTE2/0/1/13 26 WCTE2/0/1/14 27 WCTE2/0/1/15 28 WCTE2/0/1/16 29 WCTE2/0/1/17 30 WCTE2/0/1/18 31 WCTE2/0/1/19 32 WCTE2/0/1/20 33 WCTE2/0/1/21 34 WCTE2/0/1/22 35 WCTE2/0/1/23 36 WCTE2/0/1/24 # cat /proc/dahdi/6 Span 6: WCTE2/0/2 "WCTE23X (PCI) Card 0 Span 2" 37 WCTE2/0/2/1 38 WCTE2/0/2/2 39 WCTE2/0/2/3 40 WCTE2/0/2/4 41 WCTE2/0/2/5 42 WCTE2/0/2/6 43 WCTE2/0/2/7 44 WCTE2/0/2/8 45 WCTE2/0/2/9 46 WCTE2/0/2/10 47 WCTE2/0/2/11 48 WCTE2/0/2/12 49 WCTE2/0/2/13 50 WCTE2/0/2/14 51 WCTE2/0/2/15 52 WCTE2/0/2/16 53 WCTE2/0/2/17 54 WCTE2/0/2/18 55 WCTE2/0/2/19 56 WCTE2/0/2/20 57 WCTE2/0/2/21 58 WCTE2/0/2/22 59 WCTE2/0/2/23 60 WCTE2/0/2/24 # /etc/init.d/dahdi restart * Stopping DAHDI ... [ ok ] * Starting DAHDI ... DAHDI_SPANCONFIG failed on span 5: Invalid argument (22) [ !! ] # rmmod wcte43x # rmmod wcb4xxp # modprobe wcb4xxp # modprobe wcte43x # /etc/init.d/dahdi restart * Stopping DAHDI ... [ ok ] * Starting DAHDI ... [ ok ] # /etc/init.d/asterisk restart * Starting asterisk PBX ... * Max open filedescriptors : 4096 * Starting asterisk as : asterisk:asterisk [ ok ] # # cat /proc/dahdi/5 Span 5: WCTE2/0/1 "WCTE23X (PCI) Card 0 Span 1" CCS/HDB3/CRC4 Timing slips: 3 13 WCTE2/0/1/1 Clear (In use) (EC: VPMOCT064 - INACTIVE) 14 WCTE2/0/1/2 Clear (In use) (EC: VPMOCT064 - INACTIVE) 15 WCTE2/0/1/3 Clear (In use) (EC: VPMOCT064 - INACTIVE) 16 WCTE2/0/1/4 Clear (In use) (EC: VPMOCT064 - INACTIVE) 17 WCTE2/0/1/5 Clear (In use) (EC: VPMOCT064 - INACTIVE) 18 WCTE2/0/1/6 Clear (In use) (EC: VPMOCT064 - INACTIVE) 19 WCTE2/0/1/7 Clear (In use) (EC: VPMOCT064 - INACTIVE) 20 WCTE2/0/1/8 Clear (In use) (EC: VPMOCT064 - INACTIVE) 21 WCTE2/0/1/9 Clear (In use) (EC: VPMOCT064 - INACTIVE) 22 WCTE2/0/1/10 Clear (In use) (EC: VPMOCT064 - INACTIVE) 23 WCTE2/0/1/11 Clear (In use) (EC: VPMOCT064 - INACTIVE) 24 WCTE2/0/1/12 Clear (In use) (EC: VPMOCT064 - INACTIVE) 25 WCTE2/0/1/13 Clear (In use) (EC: VPMOCT064 - INACTIVE) 26 WCTE2/0/1/14 Clear (In use) (EC: VPMOCT064 - INACTIVE) 27 WCTE2/0/1/15 Clear (In use) (EC: VPMOCT064 - INACTIVE) 28 WCTE2/0/1/16 HDLCFCS (In use) (EC: VPMOCT064 - INACTIVE) 29 WCTE2/0/1/17 Clear (In use) (EC: VPMOCT064 - INACTIVE) 30 WCTE2/0/1/18 Clear (In use) (EC: VPMOCT064 - INACTIVE) 31 WCTE2/0/1/19 Clear (In use) (EC: VPMOCT064 - INACTIVE) 32 WCTE2/0/1/20 Clear (In use) (EC: VPMOCT064 - INACTIVE) 33 WCTE2/0/1/21 Clear (In use) (EC: VPMOCT064 - INACTIVE) 34 WCTE2/0/1/22 Clear (In use) (EC: VPMOCT064 - INACTIVE) 35 WCTE2/0/1/23 Clear (In use) (EC: VPMOCT064 - INACTIVE) 36 WCTE2/0/1/24 Clear (In use) (EC: VPMOCT064 - INACTIVE) 37 WCTE2/0/1/25 Clear (In use) (EC: VPMOCT064 - INACTIVE) 38 WCTE2/0/1/26 Clear (In use) (EC: VPMOCT064 - INACTIVE) 39 WCTE2/0/1/27 Clear (In use) (EC: VPMOCT064 - INACTIVE) 40 WCTE2/0/1/28 Clear (In use) (EC: VPMOCT064 - INACTIVE) 41 WCTE2/0/1/29 Clear (In use) (EC: VPMOCT064 - INACTIVE) 42 WCTE2/0/1/30 Clear (In use) (EC: VPMOCT064 - INACTIVE) 43 WCTE2/0/1/31 Clear (In use) (EC: VPMOCT064 - INACTIVE) # cat /proc/dahdi/6 Span 6: WCTE2/0/2 "WCTE23X (PCI) Card 0 Span 2" CCS/HDB3/CRC4 RED 44 WCTE2/0/2/1 Clear (In use) (EC: VPMOCT064 - INACTIVE) 45 WCTE2/0/2/2 Clear (In use) (EC: VPMOCT064 - INACTIVE) 46 WCTE2/0/2/3 Clear (In use) (EC: VPMOCT064 - INACTIVE) 47 WCTE2/0/2/4 Clear (In use) (EC: VPMOCT064 - INACTIVE) 48 WCTE2/0/2/5 Clear (In use) (EC: VPMOCT064 - INACTIVE) 49 WCTE2/0/2/6 Clear (In use) (EC: VPMOCT064 - INACTIVE) 50 WCTE2/0/2/7 Clear (In use) (EC: VPMOCT064 - INACTIVE) 51 WCTE2/0/2/8 Clear (In use) (EC: VPMOCT064 - INACTIVE) 52 WCTE2/0/2/9 Clear (In use) (EC: VPMOCT064 - INACTIVE) 53 WCTE2/0/2/10 Clear (In use) (EC: VPMOCT064 - INACTIVE) 54 WCTE2/0/2/11 Clear (In use) (EC: VPMOCT064 - INACTIVE) 55 WCTE2/0/2/12 Clear (In use) (EC: VPMOCT064 - INACTIVE) 56 WCTE2/0/2/13 Clear (In use) (EC: VPMOCT064 - INACTIVE) 57 WCTE2/0/2/14 Clear (In use) (EC: VPMOCT064 - INACTIVE) 58 WCTE2/0/2/15 Clear (In use) (EC: VPMOCT064 - INACTIVE) 59 WCTE2/0/2/16 HDLCFCS (In use) (EC: VPMOCT064 - INACTIVE) 60 WCTE2/0/2/17 Clear (In use) (EC: VPMOCT064 - INACTIVE) 61 WCTE2/0/2/18 Clear (In use) (EC: VPMOCT064 - INACTIVE) 62 WCTE2/0/2/19 Clear (In use) (EC: VPMOCT064 - INACTIVE) 63 WCTE2/0/2/20 Clear (In use) (EC: VPMOCT064 - INACTIVE) 64 WCTE2/0/2/21 Clear (In use) (EC: VPMOCT064 - INACTIVE) 65 WCTE2/0/2/22 Clear (In use) (EC: VPMOCT064 - INACTIVE) 66 WCTE2/0/2/23 Clear (In use) (EC: VPMOCT064 - INACTIVE) 67 WCTE2/0/2/24 Clear (In use) (EC: VPMOCT064 - INACTIVE) 68 WCTE2/0/2/25 Clear (In use) (EC: VPMOCT064 - INACTIVE) 69 WCTE2/0/2/26 Clear (In use) (EC: VPMOCT064 - INACTIVE) 70 WCTE2/0/2/27 Clear (In use) (EC: VPMOCT064 - INACTIVE) 71 WCTE2/0/2/28 Clear (In use) (EC: VPMOCT064 - INACTIVE) 72 WCTE2/0/2/29 Clear (In use) (EC: VPMOCT064 - INACTIVE) 73 WCTE2/0/2/30 Clear (In use) (EC: VPMOCT064 - INACTIVE) 74 WCTE2/0/2/31 Clear (In use) (EC: VPMOCT064 - INACTIVE) # Hope that helps somehow. BTW, shouldn't the DAHDI init script unload/reload the kernel modules? I haven't restarted this system yet so I don't know if it's necessary to actually add, say, wcte43x to /etc/modprobe.d/dahdi.conf. In other words, I don't know if I need to have this: wcte43x options wcte43x default_linemode=e1 instead of just this: options wcte43x default_linemode=e1 If I need to add the module name too then maybe the init script or ebuild could warn the user about it (I can't reboot the system right now to test it myself). Thanks
Created attachment 788711 [details] dahdi-autoconf.init-3.1.0-r3 (In reply to Vieri from comment #3) > Hmm, I think I screwed things up a little. :). We all do. > Here's what I did. > Before changing from E1 to T1: > > # cat /proc/dahdi/1 > Span 1: B4/0/1 "B4XXP (PCI) Card 0 Span 1" (MASTER) AMI/CCS > > 1 B4/0/1/1 Clear (In use) (EC: LASVEGAS2 - INACTIVE) > 2 B4/0/1/2 Clear (In use) (EC: LASVEGAS2 - INACTIVE) > 3 B4/0/1/3 Hardware-assisted HDLC (In use) (EC: LASVEGAS2 - > INACTIVE) Ok, so that's the info from your BRI card, not useful here. > I now commented out everything in /etc/modprobe.d/dahdi.conf. OK. > # /etc/init.d/dahdi start > * Starting DAHDI ... > DAHDI_SPANCONFIG failed on span 5: No such device or address (6) > [ !! ] Yea, that's as you say because /etc/init.d/dahdi doesn't load the modules. This is a valid point, however, dahdi-autoconf DOES load them, and is part of it's purpose. If you prefer auto-loading of modules, you can edit /etc/modprobe.d/dahdi-blacklist and comment the specific lines. The *problem* with that is (and why we blacklist by default and rely on dahdi-autoconf to load) is that the load ordering cannot be guaranteed. So the span ordering can change (if you have more than one card). If I'm not mistaken, /etc/init.d/modules also has a way to pre-load modules on boot if you prefer that, looking at the init script you simply add a file to /etc/modules-load.d/ containing the list of modules (one per line) that should be loaded at startup. So no, I won't be adding this to /etc/init.d/dahdi unless someone can provide another good motivation why. > # lsmod | grep wcte > # modprobe wcte43x > # lsmod | grep wcte > wcte43x 77824 0 > oct612x 188416 1 wcte43x > dahdi 253952 15 wcb4xxp,oct612x,wcte43x Simpler way to achieve this, and regenerate the errors as well, is to just restart dahdi-autoconf (which should unload the modules during stop). > # /etc/init.d/dahdi restart > * Stopping DAHDI ... > [ ok ] > * Starting DAHDI ... > DAHDI_SPANCONFIG failed on span 5: Invalid argument (22) > [ !! ] This is because T1/E1 config in system.conf isn't right. Snipped a LOT of data. > Hope that helps somehow. It did. > BTW, shouldn't the DAHDI init script unload/reload the kernel modules? > I haven't restarted this system yet so I don't know if it's necessary to > actually add, say, wcte43x to /etc/modprobe.d/dahdi.conf. > In other words, I don't know if I need to have this: > > wcte43x > options wcte43x default_linemode=e1 This could work. Please see discussion above. Maybe I've got the whole thing wrong above, but based on reading of modprobe.d(5) what you have also won't work. > instead of just this: > > options wcte43x default_linemode=e1 If you need e1 mode, just put this in there, and use dahdi-autoconf (which orders the spans based on PCI IDs as per dahdi_hardware). I looked at the DAHDI provided genconf now too, and I can't recall the exact details I didn't use it, but not supporting E1 would have been a killer for us at the time, nor do I think the original versions we started with had the tool (or it didn't work remotely properly for us). > If I need to add the module name too then maybe the init script or ebuild > could warn the user about it (I can't reboot the system right now to test it > myself). Just trying to think *how*, basically I'd need to run dahdi_hardware looking for the second column of output ending with - and then fail, however, maybe you specifically don't want those modules loaded? So this isn't a workable solution. Use dahdi-autoconf :). I wrote it to work. Please test the updated version which I'll attach now. It is COMPLETELY untested since I do not have hardware at hand to test with. Have requested the team to check if maybe we still have SOMETHING in storage. Might also get a machine freeing up in such a way that I can run some rudementary testing on the hardware (it's a really old host so will want to move the card to somewhere with a newer install).
Thanks for all the work! Correct me if I'm wrong, but I think /etc/dahdi/system.conf and /etc/asterisk/dahdi-channels.conf are tightly related. I think /usr/sbin/dahdi_genconf creates both, so could /etc/init.d/dahdi-autoconf also generate both? Sure, there are values such as "contexts" that could be user-defined maybe in /etc/conf.d.
EDIT: dahdi-channels.conf being included by chan_dahdi.conf that is (if the user edits the latter file, of course).
(In reply to Vieri from comment #5) > Thanks for all the work! > > Correct me if I'm wrong, but I think /etc/dahdi/system.conf and > /etc/asterisk/dahdi-channels.conf are tightly related. > I think /usr/sbin/dahdi_genconf creates both, so could > /etc/init.d/dahdi-autoconf also generate both? > Sure, there are values such as "contexts" that could be user-defined maybe > in /etc/conf.d. They are ... however, dahdi-channels.conf (to be included from chan_dahdi.conf?) also contains information I have no way of inferencing. I highly doubt dahdi_genconf will be able to generate a completely functional chan_dahdi.conf, I also generally use users.conf for configuring dahdi channels though due to templating assistance, as such I believe that there are different ways of configuring this, if you have some "template" based solution that you'd like me to action (eg, generating a dahdi_auto_generated.conf into /etc/asterisk which we structure in a specific format) I'm happy to include that, but can we defer that to a next release please? (I do love the idea).
Ok, looking at this again, it seems there are two things which we can't infer clearly: channel grouping (in users.conf something like): [line](!) context=incoming ; default, this we override in some places. ... other DAHDI params, eg progzone=za tonezone=1 callprogress=no [group](line)(!) group=1 And then we inherit the appropriate groups in the individual channels: [dahdi-PRI-1](group) rxgain=?? txgain=?? dahdichan=1-15,17-31 signalling=pri_net So at least some of that can be generated, specifically the last section, but do we do so in users-dahdi-auto.conf or dahdi-auto.conf? (the reason we used users.conf was because some of the functionality in users.conf at the time for asterisk 1.6 wasn't available in chan_dahdi.conf, I cannot remember exactly what it was). What do we set for things like progzone? callprogress? How about usecallerid via FSK on FXS/FXO? What do we use for busydetect functions? Guessing we can use inheritance like above, and provide a way in /etc/conf.d/dahdi-autoconf to specify the group on a per tech type or span basis kind of thing? For example, let's say we have a 4-port PRI card, with 3 ports in CPE mode, and 1 in NET, there are 1 port going to the local telco, 1 port to a Premicell device, and the third port to another PBX with which we're slaving, and some application server attached to our NET port, now we'd need inheritance from four different groups to get this "just right". So unfortunately it gets very complicated, very quickly. And frankly, the asterisk side of the configuration is fairly easy to "get right" compared to system.conf on the dahdi-tools side (where you need to have some technical understanding). Still, you're welcome to NOT use dahdi-autoconf as per previous discussion, I provide it since we use it (less and less frequently mind you), or even just use it once-off to generate system.conf for you, the big trick is to arrange for the modules to be loaded (in the correct order) prior to starting /etc/init.d/dahdi.conf (which I believe you've been given solutions for above).
Yes, thanks for the explanation, but this goes beyond this bug report. Whatever you decide to do is fine with me. I just need to make sure my system reboots fine. I tried running the dahdi-autoconf script to generate /etc/dahdi/system.conf, and it's OK for me. So I guess I can put it in the default runlevel so it will load the modules on reboot. I will only need to leave options wcte43x default_linemode=e1 in /etc/modprobe.d/dahdi.conf. That should take care of reboots as dahdi-autoconf starts "before dahdi". As far as chan_dahdi.conf is concerned what I did was generate dahdi-channels.conf once with /usr/sbin/dahdi_genconf, renamed it to somethign else, customized it a bit then included it at the bottom of chan_dahdi.conf. If the channel info in the file included by chan_dahdi.conf and system.conf are consistent and don't change on reboot (and I believe there's no reason for that to happen) then I'm good to go. BTW thanks for providing the very convenient dahdi-autoconf script.
Hi, (In reply to Vieri from comment #9) > Yes, thanks for the explanation, but this goes beyond this bug report. > Whatever you decide to do is fine with me. I just need to make sure my > system reboots fine. Thank you for the feedback. Still nice to have these discussions sometimes, even if not always on the exact right forum. You're always welcome to join us on #gentoo-voip btw. PR updated with the changes as you indicate this works for you (on actual hardware, thank you for that). > I tried running the dahdi-autoconf script to generate > /etc/dahdi/system.conf, and it's OK for me. So I guess I can put it in the > default runlevel so it will load the modules on reboot. > I will only need to leave > > options wcte43x default_linemode=e1 Perfect. We deploy similar as a standard. Your linemode needs to match what your provider gives you. E1 does seem the more common except in NANP region for some reason, but I have no real way to confirm that as we've got no presense there, so things may have changed. > in /etc/modprobe.d/dahdi.conf. > > That should take care of reboots as dahdi-autoconf starts "before dahdi". Correct. > As far as chan_dahdi.conf is concerned what I did was generate > dahdi-channels.conf once with /usr/sbin/dahdi_genconf, renamed it to > somethign else, customized it a bit then included it at the bottom of > chan_dahdi.conf. For ISDN (as you have) this is perfect. We actually have code that finds the base channel numbers from /proc/dahdi/ and then links IDs in a way to that where possible, then based on user configuration (stored in SQL) generate users-dahdi.conf which is included into users.conf. That however goes WAY beyond what I can do in the init script :). If channels do end up switching around some reconfiguration is generally in order then though. > If the channel info in the file included by chan_dahdi.conf and system.conf > are consistent and don't change on reboot (and I believe there's no reason > for that to happen) then I'm good to go. As long as you don't physically move cards around in the host it won't. > BTW thanks for providing the very convenient dahdi-autoconf script. My pleasure.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=927a9ab6f7f379ad727928be6d7174cd62cce398 commit 927a9ab6f7f379ad727928be6d7174cd62cce398 Author: Jaco Kroon <jaco@uls.co.za> AuthorDate: 2022-06-15 13:06:51 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-06-30 21:46:42 +0000 net-misc/dahdi-tools: revbump to fix bugs. No major changes. Biggest was to add T1 support into dahdi-autoconf. Closes: https://bugs.gentoo.org/841428 Closes: https://bugs.gentoo.org/852779 Closes: https://bugs.gentoo.org/852785 Package-Manager: Portage-3.0.30, Repoman-3.0.3 Signed-off-by: Jaco Kroon <jaco@uls.co.za> Closes: https://github.com/gentoo/gentoo/pull/25852 Signed-off-by: Sam James <sam@gentoo.org> net-misc/dahdi-tools/dahdi-tools-3.1.0-r3.ebuild | 70 ++++++ .../dahdi-tools/files/dahdi-autoconf.init-3.1.0-r3 | 271 +++++++++++++++++++++ 2 files changed, 341 insertions(+)
