Dual zaptel cards channel order randomly changes on reboot?

[blanchae]

I am having two problems:

1. Random order of channel assignments on reboot
2. Asterisk doesn't recognize zaptel cards

1. Random order of channel assignments on reboot

I have a TE100P (PCI slot 1 - IRQ 5) and a TDM400P (PCI Slot 2 - IRQ 9) in a PC. Whenever I reboot - the channel order randomly changes. First the TE100P card is assigned channels 1 - 24 and the TDM400P 25 - 28. Next reboot, the TE100P card is assigned channels 5-28 and the TDM400P 1-4.

I've manually set the IRQs for the PCI slots, giving priority to the TE100p. I've update-scripts, update-fixes, update-source, stop gracefully, shutdown -r now, I've tried blacklisting the zaptel modules in /etc/modprobe.d/blacklist as detailed:

Edit /etc/modprobe.d/blacklist and add the following lines to the bottom of the file:
# Do not load zaptel modules let the Zaptel init script do it
blacklist pciradio
blacklist tor2
blacklist torisa
blacklist wcfxo
blacklist wct1xxp
blacklist wctdm
blacklist wcte11xp
blacklist wcusb
blacklist ztd-eth
blacklist ztd-ethmf
blacklist ztd-loc
blacklist wct4xxp
blacklist wctc4xxp
blacklist wctdm24xxp
blacklist wcte12xp
blacklist wcfxs
blacklist wctdm8xxp
blacklist wct2xxp


which lead to the next problem:

2. Asterisk doesn't recognize zaptel cards

I've removed the blacklist and the same problem after rebooting. I've done each of the following using the blacklist and not. Everything from the linux side seems to be okay.

Genzaptelconf runs, "registers" cards and ends with
"no such command 'zap show'. Asterisk help shows no zap commands.

ztcfg -vv works, zttool works

/etc/zaptel.conf shows the correct order that I want with TE100p using ch 1-24 and the TDM400 using 25-28.

/etc/asterisk/zapata.conf has the includes at the end:
#include zapata-auto.conf
#include zapata_additional.conf

/etc/asterisk/zapata-auto.conf has the correct info for the cards

/etc/asterisk/zapata_additional.conf has a test extension that was made earlier.

 

[blanchae]

Blacklist fails to load /dev/zap/ctl

After rebooting with a blacklist, zttool reports that it can't find /dev/zap/ctl and doesn't work. genzaptelconf flashes an error message for 1/2 second than restarts everything and creates the /dev/zap/ctl. After that, the file is there and still the zap commands don't show up in Asterisk CLI.

Ends up that the blacklist stops /dev/zap/ctl from being created and the first time you reboot, the zaptel channels fail. So blacklisting doesn't work for correcting the random channel assignments.

 

[blanchae]

From the Asterisk CLI> module reload chan_zap.so loads the channels correctly but still no zap commands.

 

[blanchae]

Zap channels back

I was moving the digium cards to different pci slots and subesquently the fxs channels were changing (which is what I'm trying to solve!). I took a look at /var/log/asterisk/full and looked at the error messages.

One error message pops up that there is no manager_additional.conf file and a warning that in the future, the module won't load. Need to put an empty file there to prevent future problems


Asterisk kept looking for channel 1 for trunking or something, so I deleted all my zaptel trunks and channels from the extensions (crude but it's not a production machine). Finally that seemed to clear up and a reboot brought up the zap commands. Unfortunately, I had to run genzaptelconf again and the channels randomly flipped again! Aaaaaaaaaaaaaaaaah!

Back to trying to get some sort of steady reliable configuration when rebooting with two digium cards. Back to square one....

 

[darmock]

One word of caution. If you are using asterisk 1.4.22 and zaptel 1.4.12.1 DON'T!

There have been problems reported because of digium deciding we all have to go to dahdi and the current version of asterisk has a few missing pieces which affect zaptel I am afraid.

I would downgrade your asterisk to 1.4.21.2. I am just working on releasing a downgrade from 1.4.22 back to 1.4.21.2 just because of this problem. Aside from some non digium cards it seems to have an effect on some genuine digium stuff which stops working... pretty cool isn't it?

Tom

 

[blanchae]

Thanks for the heads-up. I've been banging my head against the wall for a week now.

 

[darmock]

I am still working on protecting people who use our distro from digium. Update-source is being modified to provide warning about using it on the 1.4 tree unless it is on a non production box. This has been a real pain in the ass is all I can say and for what?

Oh well the new load and other files won't be out till sometime later this week.

Tom

 

[james]

The issue here is not your version it is based on a fundamental misunderstanding of how all the pieces go together.

Your issue was random load order due to the kernel loading your modules for you.

You added the moduled to the black list and told the kernel "Don't do that" okay now no one is loading the modules. If you have the zaptel init script loading zaptel for you you have to tell the init script what it should load. To tell the init script what to laod you have to add the proper module lines in /etc/sysconfig/zaptel . After that the zaptel init script will iterate through the modules and load what it is told.

 

[jsmith]

One word of caution. If you are using asterisk 1.4.22 and zaptel 1.4.12.1 DON'T!

I'm not sure what problems you're experiencing, but I've used Asterisk 1.4.22 with Zaptel 1.4.12.1 dozens of times without issue. Can you give me any more details on what's not working? Have you opened a bug on the Digium bug tracker by chance? To be completely honest, this is the first report I've heard of that not working.

If you're able and willing to share details of what's not working for you, I'm able and willing to help get the problem solved (whether on company time or on my own time).

-Jared

 

[jroper]

Hi

This sounds familiar.

Humour me for a moment.

Go into /etc/asterisk/zapata.conf and remove the lines #include zapata-channels.conf and the line #include zapata-addtional.conf and finally, #include zapata-auto.conf. Keep a note of them so you can put them back later.

Reboot

Then rasterisk to go into the asterisk CLI, if I'm right zap show channels should work at this point and only return the psuedo channel.

If it does, we've solved the problem, if it does not, then put it all back how it was, and take up Jareds offer to help who knows more about it that I do.

If Psuedo is shown, then go into FreePBX and delete every single zap extension and every zap trunk and do a reload with the orange bar at the top.

Then back into /etc/asterisk/zapata.conf, and put back #include zapata-additional.conf and '#include zapata-channels.conf.

reboot.

Do genzatelconf -sdvM and check your channels are created.

Back into rasterisk, and do zap show channels, at this point you should now be showing all the channels as they should be.

Take a note of the list of channel numbers and whether they are FSX or FXO and remake all your extensions and trunks accordingly in FreePBX.

Then you have to hope that your cards do not start swapping about.

The problem is caused by having an zap extension with a channel number that in fact has become an FXO port, or a trunk channel number that has become an fxs port.

Joe

 

[darmock]

I'm not sure what problems you're experiencing, but I've used Asterisk 1.4.22 with Zaptel 1.4.12.1 dozens of times without issue. Can you give me any more details on what's not working? Have you opened a bug on the Digium bug tracker by chance? To be completely honest, this is the first report I've heard of that not working.

If you're able and willing to share details of what's not working for you, I'm able and willing to help get the problem solved (whether on company time or on my own time).

-Jared

And I wager you are using recent Genuine Digium TDM cards. Works fine with most of the digium cards some problems with the older TDM cards as outlined elsewhere.

http://pbxinaflash.com/community/threads/asterisk-1-4-22-and-older-zaptel-hardware.2459/?t=2459

For example I have a genuine Digium TDM2400 card. (Found one in the parts box and decided to see if the problem actually existed as per the other thread) Dropped in the latest 1.4 asterisk and zaptel does not work as per the other thread. downgraded back to the previous release of Asterisk and it worked worked just fine. I have any number of donated cards that work great with the older versions of asterisk and the final version of zaptel.

Of course none of the mainstream 3rd party cards are happy with Dahdi and I don't envision us releasing dahdi into our userbase until it works with all of the common 3rd party cards.

Another case in point is the A400P card from openvox. this is a one to one drop in replacement for the TDM400.... there are a number of problems with it under the current version of asterisk/zaptel. Doesn't work well under Dahdi. Went back to the older version of Asterisk 1.4.21.2 works great. I am in close contact with Openvox over this as I suspect that making any 3rd party cards work under Asterisk is low on Digium's priority list. Perhaps I am wrong about that however

So here is the quandry.... Make our users update to something that causes problems with some cards or keep things stable until something better comes along.

Generally we test asterisk/zaptel/dahdi on donated fxo/fxs cards. One of the manufacturers has been generous to us and has provided one of each card they make. Others have been donated by our loyal userbase.



Tom

 

[jmullinix]

Jared,

With me, I upgraded a hosed up Trixbox to PIAF last week. This unit has a genuine Digium TDM2400 with 8-FXO ports (2 modules). The default PIAF load was Zaptel 1.4.12.1 and Asterisk 1.4.22. I could get the channels to show using the zap show channels command but they would not answer a ringing line and when you called out on them you got all circuits busy. As soon as I recompiled Asterisk back to 1.4.21.2, everything went to work swimmingly. This is a production box, but I will check with my customer to see if I can allow you in if you need to look around. The box is currently running PIAF 1.3, Asterisk 1.4.21.2 and Zaptel 1.4.12.1.

 

[blanchae]

I'll give that a try. I've talked to the guy who developed genzaptelconf and he's explained the problem with Centos randomly loading modules and how they are addressing it with Dahdi. I'll try the blacklist method again and adding the proper module lines in /etc/sysconfig/zaptel

The post that I read over at Tribox wasn't clear that there was anything to add to the init script. Didn't find anything over here either.

Thanks

 

[blanchae]

I booted from my PiaF on a USB flash drive at home and checked /etc/sysconfig/zaptel and it looks like the modules are already being loaded there by default. So with the blacklist, it should of worked, I'll try it again first thing in the morning back at work.

 

[blanchae]

It appears to be a problem with udev and it's parallel loading of both drivers at once. Depending on what's going happening, one or the other zaptel cards can load first. After looking at the udev tutorial, I should be able to make udev rules specific to each card and control the loading of the drivers. More reading to do - won't get to it until back at work next week.

The good side is that I'm learning way more than I ever wanted to know...

 

[blanchae]

zaptel init.d question

For etc/sysconfig/zaptel, does "TELEPHONY = NO" have to be changed to YES to use the zaptel init.d script?

 

[kenn10]

Mine has TELEPHONY = YES. That might be your issue....