The problem is pretty much related right now which is why he referred you to my ticket but under normal circumstances your DAHDI card initialization should not depend on the Sangoma Wanpipe drivers initalization…
My Sangoma card needs both to work but in a system which doesn’t have Sangoma hardware your DAHDI card initialization should not depend on proper (or improper!) Sangoma Wanpipe driver intialization and right now it looks like it is the case…
I believe this whole setup predates Schmooze becoming Sangoma so Andrew, Bryan, Rob, etc…are only trying to make right something they had more than likely no say in how it was initially setted up…
I don’t think the current problem is related to this and your Digium derivative card seems to behave pretty much like the real hardware (unless later proven otherwise )…
Right now I would not suggest that someone who has DAHDI hardware of any kind update unless (s)he is OK with having some possible downtime and knows how to revert things to get her/his system back to working order…
I hope no-one thinks I’m being difficult. I really appreciate all the work and support that everyone is putting in to give me and the whole community a free pbx system. I am really grateful of this. In return, what I am trying to do is provide as much information as possible to aid fault finding, so that everyone can benefit from a fully debugged system.
LOL…
It would appear that you misunderstood my comment…
It was not targeted towards your comments but my own…
I think it’s pretty apparent that I find the way I think it works (based on everyone’s experiences) convoluted to say the least…
While all the people I named now work for the manufacturer of my DAHDI card I know that it was not always the case and they are just trying to fix something they were not the ones to break in the first place…
I said the comment to which I think you replied because I didn’t to appear, myself, difficult…
That doesn’t mean that I don’t have an opinion on how things should be done I also understand why things don’t always go smoothly…
It is a Sangoma telephony card hardware specific driver… It can actually do more than DAHDI but with FreePBX/Asterisk it’s a driver we must load in addition to DAHDI…
We use it with cards such as these:
I don’t think there is much risk if you don’t have any DAHDI hardware but as the MTA gals/guys say “Your server, your rules”…
(At one point in time I was really into mail servers (ie MTAs)…)
@chaser In order to assist you we need some additional information, such as who manufactures your card, what model is it, etc. Note if it’s not a Sangoma card, wanpipe shouldn’t be affecting this. Also to try to help can you tell me what the output of dahdi_cfg -vvvv and asterisk -rx "dahdi show status".
@Marbled There is a method to the madness with regards to the wanpipe kernel driver as you have to remember that our cards have other uses than just working with Asterisk and Dahdi. Also when you have time to try running yum upgrade on your system, as looking over everything, things should be resolved.
Actually, that’s not what I was commenting about… It’s the fact that it looks like it’s the Wanpipe driver stuff which starts DAHDI for the other non-Sangoma cards… Right now it looks like having working Wanpipe drivers breaks things for others and vice versa…
When the Wanpipe driver had problems things started working for people it did not before…
As for the card having other uses besides DAHDI, please look at this post
which is about 4-5 posts above this one.
I said the following in that post
It can actually do more than DAHDI but with FreePBX/Asterisk it’s a driver we must load in addition to DAHDI…
I was referring here to the Wanpipe driver so I am well aware that the fact that the card can do a loooooot more than what we use it for…
I understood long ago that DAHDI is just one of the ways to talk to the card, just one more API…
As for running yum upgrade I already did it several minutes ago (15-20 I would say, I didn’t check the time), I am testing if everything seems OK now. I also removed the modification I had done and described in the ticket to see if it was still needed and it still is…
I’m unsure as to what your problem is, exactly? If it’s the Exception in Module Admin, you need to upgrade Framework to 14.0.1.12 or higher. If it’s NOT that, can you be specific about what problem you’re having, please?
Ok, I seem to have some sort of timing related issue…
The fix I described in the ticket worked for a few tries and now no longer wants to…
If I had to guess I would say timing has something to do with it…
(So I will have to revert the fix and which will cause a timeout at boot and slow down my system boot time by about 4-5 minutes…)
I don’t know exactly how things work but my guess is that DAHDI is not initialized properly each time…
To debug thingx I use a phone which tells me to check the phone line when it doesn’t see line voltage…
When I reboot the system it stops having line voltage and complains but eventually tells me it’s OK when, I believe, the Wanpipe drivers have initialized the card…
However now, with the fix in place, I never get a dial tone…
If I had to guess I would think it’s either when the DAHDI drivers start or when Asterisk starts that I get a dial tone and I never get it with the fix in place…
Now I doubt Asterisk is to blame since, except for the missing DAHDI channels, everything works A-OK so my bets would be on DAHDI…
Bryan, does that make sense and is there anything you can suggest besides reverting the fix and slowing down my machine boot time tremendously?
OK, doing a fwconsole restart fixes things for me when I get that no dial tone problem which makes my problem a lot more similar to what the others are seeing…
Doing a lsdahdi when I have no dial tone gives this:
An fwconsole restart stops Dahdi then starts it again. When Dahdi is started in fwconsole on boot the system is telling us it’s already started when it isnt. You check check this after a reboot by running status against the Dahdi systems process then echo $?
Note that this card has worked flawlessly in my FreePBX13 system, and works in my FreePBX14 system if I manully start DADHi after a reboot. Also, others with genuine Digium hardware are reporting similar issues, so I don’t think its the card:
With the slightly older (and from what I understand, broken) wanpipe driver installed (7.0.20-9.sng7), everything boots fine, and I get the following:
[root@freepbx ~]# yum list kmod-wanpipe.x86_64 wanpipe.x86_64
Loaded plugins: fastestmirror, kmod, versionlock
Loading mirror speeds from cached hostfile
Installed Packages
kmod-wanpipe.x86_64 7.0.20-9.sng7 @sng-pkgs
wanpipe.x86_64 7.0.20-9.sng7 @sng-pkgs
Available Packages
kmod-wanpipe.x86_64 7.0.20.13-1.sng7 sng-pkgs
wanpipe.x86_64 7.0.20.13-1.sng7 sng-pkgs
[root@freepbx ~]# dahdi_cfg -vvvv
DAHDI Tools Version - 2.11.1
DAHDI Version: 2.11.1
Echo Canceller(s): OSLEC
Configuration
======================
Channel map:
Channel 01: FXS Kewlstart (Default) (Echo Canceler: oslec) (Slaves: 01)
Channel 02: FXO Kewlstart (Default) (Echo Canceler: oslec) (Slaves: 02)
Channel 03: FXO Kewlstart (Default) (Echo Canceler: oslec) (Slaves: 03)
Channel 04: FXS Kewlstart (Default) (Echo Canceler: oslec) (Slaves: 04)
4 channels to configure.
Setting echocan for channel 1 to oslec
Setting echocan for channel 2 to oslec
Setting echocan for channel 3 to oslec
Setting echocan for channel 4 to oslec
[root@freepbx ~]# asterisk -rx "dahdi show status"
Description Alarms IRQ bpviol CRC Fra Codi Options LBO
Wildcard TDM400P REV I Board 5 OK 0 0 0 CAS Unk 0 db (CSU)/0-133 feet (DSX-1)
[root@freepbx ~]#
If I then upgrade to the latest wanpipe driver, I get the following:
[root@freepbx ~]# yum list kmod-wanpipe.x86_64 wanpipe.x86_64
Loaded plugins: fastestmirror, kmod, versionlock
Loading mirror speeds from cached hostfile
Installed Packages
kmod-wanpipe.x86_64 7.0.20.13-1.sng7 @sng-pkgs
wanpipe.x86_64 7.0.20.13-1.sng7 @sng-pkgs
[root@freepbx ~]# dahdi_cfg -vvvv
DAHDI Tools Version - 2.11.1
DAHDI Version: 2.11.1
Echo Canceller(s):
Configuration
======================
Channel map:
Channel 01: FXS Kewlstart (Default) (Echo Canceler: oslec) (Slaves: 01)
Channel 02: FXO Kewlstart (Default) (Echo Canceler: oslec) (Slaves: 02)
Channel 03: FXO Kewlstart (Default) (Echo Canceler: oslec) (Slaves: 03)
Channel 04: FXS Kewlstart (Default) (Echo Canceler: oslec) (Slaves: 04)
4 channels to configure.
DAHDI_CHANCONFIG failed on channel 1: Invalid argument (22)
Selected signaling not supported
Possible causes:
FXS signaling is being used on a FXS interface (use a FXO signaling variant)
RBS signaling is being used on a E1 CCS span
Signaling is being assigned to channel 16 of an E1 CAS span
[root@freepbx ~]# asterisk -rx "dahdi show status"
Description Alarms IRQ bpviol CRC Fra Codi Options LBO
[root@freepbx ~]#
Edit: The latest kmod-wanpipe.x86_64 has just disappeared from the repo, so I can’t upgrade any longer!
Edit 2: Repo now fixed, so I’ve updated the post to show the results with the latest wanpipe.
@GameGamer43 - Now that the repo is working again, I’ve updated post 77 to show the output with both the previous and current wanpipe driver. As I’ve said before, DAHDi loads with the previous wanpipe driver, but doesn’t load with the newest, or those before the previous.
)…