Zapata install errors

Hello,
I am trying to make the switch from zapata to dahdi and get this error whilst trying to install zaptel:

make[2]: Entering directory /usr/src/linux-headers-3.2.0-24-generic' CC [M] /home/ted/t1stuff/zaptel-1.4.12.1/kernel/pciradio.o In file included from /home/ted/t1stuff/zaptel-1.4.12.1/kernel/zaptel.h:39:0, from /home/ted/t1stuff/zaptel-1.4.12.1/kernel/pciradio.c:56: /home/ted/t1stuff/zaptel-1.4.12.1/kernel/zconfig.h:26:28: fatal error: linux/autoconf.h: No such file or directory compilation terminated. make[3]: *** [/home/ted/t1stuff/zaptel-1.4.12.1/kernel/pciradio.o] Error 1 make[2]: *** [_module_/home/ted/t1stuff/zaptel-1.4.12.1/kernel] Error 2 make[2]: Leaving directory/usr/src/linux-headers-3.2.0-24-generic’
make[1]: *** [modules] Error 2
make[1]: Leaving directory `/home/ted/t1stuff/zaptel-1.4.12.1’
make: *** [all] Error 2

Unfortunately installing dahdi is not a one stop for me as I do not use asterisk but my own telco code which relies
on the functions in zap.h, zaptel.h etc.

Where are these functions now?

For example whats the current equivlant of:

i = zap_sethook(chan, hook ? ZAP_ONHOOK : ZAP_OFFHOOK);

Any help would be appreciated. Im coming from 11 years ago on gentoo to Ubuntu 12.04 and need to figure out how to get my stuff working.

You’re trying to compile a very recent kernel against Zaptel. I think this will generally be very painful as Zaptel has not been changed to keep up-to-date with changes in the kernel interfaces for quite some time now.

For the vast majority of the ioctls, changing ZAP to DAHDI will suffice. See the dahdi_set_hook implementation in the chan_dahdi.

Hope this helps.

[quote=“sruffell”][quote]
make[2]: Entering directory `/usr/src/linux-headers-3.2.0-24-generic’
CC [M] /home/ted/t1stuff/zaptel-1.4.12.1/kernel/pciradio.o
In file included from /home/ted/t1stuff/zaptel-1.4.12.1/kernel/zaptel.h:39:0,
from /home/ted/t1stuff/zaptel-1.4.12.1/kernel/pciradio.c:56:
/home/ted/t1stuff/zaptel-1.4.12.1/kernel/zconfig.h:26:28: fatal error: linux/autoconf.h: No such file or directory
compilation terminated.
[/quote]

You’re trying to compile a very recent kernel against Zaptel. I think this will generally be very painful as Zaptel has not been changed to keep up-to-date with changes in the kernel interfaces for quite some time now.

For the vast majority of the ioctls, changing ZAP to DAHDI will suffice. See the dahdi_set_hook implementation in the chan_dahdi.

Hope this helps.[/quote]

This is great start thank you. Maybe I no longer need zap(ata|tel) after all. What .h file do I include for these new ioctls? which -lib to I link to?

Sorry im very new to this change. my stuff has been running for 11 years now and thought it might be time to get up to speed. lol.

In dahdi-linux when you run “make install” /usr/include/dahdi/user.h will be added to your system. This file contains the user-mode / kernel mode interface for DAHDI and is what you will want to include in your program.

There are no DAHDI specific libraries to link against. Only the default system interface that provides read / write / ioctl is needed.

[quote=“sruffell”][quote]
Maybe I no longer need zap(ata|tel) after all. What .h file do I include for these new ioctls? which -lib to I link to?
[/quote]

In dahdi-linux when you run “make install” /usr/include/dahdi/user.h will be added to your system. This file contains the user-mode / kernel mode interface for DAHDI and is what you will want to include in your program.

There are no DAHDI specific libraries to link against. Only the default system interface that provides read / write / ioctl is needed.[/quote]

Hmm. im on gentoo 12.04. It says dahdi-linux is up to date but I dont have that file:

Reading package lists… Done
Building dependency tree
Reading state information… Done
dahdi-linux is already the newest version.
dahdi-linux set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 27 not upgraded.
tghome/home/ted> ls /usr/include/dahdi
ls: cannot access /usr/include/dahdi: No such file or directory
tghome/home/ted>

I’m not familar with Gentoo. What if you just build it from source:

svn co http://svn.asterisk.org/svn/dahdi/linux/tags/2.6.1 dahdi-linux-2.6.1
cd dahdi-linux-2.6.1
make install
cd ..
svn co http://svn.asterisk.org/svn/dahdi/tools/tags/2.6.1 dahdi-tools-2.6.1
cd dahdi-tools-2.6.1
./configure && make && make install

[quote=“sruffell”]I’m not familar with Gentoo. What if you just build it from source:

svn co http://svn.asterisk.org/svn/dahdi/linux/tags/2.6.1 dahdi-linux-2.6.1 cd dahdi-linux-2.6.1 make install cd .. svn co http://svn.asterisk.org/svn/dahdi/tools/tags/2.6.1 dahdi-tools-2.6.1 cd dahdi-tools-2.6.1 ./configure && make && make install [/quote]

Sorry my bad. I meant Ubuntu 12.04. I built and installed from source and now have the proper includes. But it seems much more has changed. For example this function no longer works:

i = dahdi_getdtmf(chan, 1, NULL, ’ ', 2000, 8000, DAHDI_HOOKEXIT);

i find tons of stuff no longer here:

no getdtmf
no HOOKEXIT
no EVENT_RINGANSWER
no DTMFINT
no digitmode, makelink, breaklink, wink, clearlinks, recf, rec, start, dial, gains, and on and on

i see (for example) struct dahdi_gains in user.h but my code i guess is wrong now:

i = dahdi_gains(chan, rxgain, txgain);
t1_error(i, “error setting gains”);

warning: implicit declaration of function �dahdi_gains� [-Wimplicit-function-declaration]

hell, I cant even init the channel:
DAHDI *chan;

error: unknown type name �DAHDI

its funny. it was easier for me to switch from dialogic to zapata 11 years ago than it is for me to switch from zapata to dahdi. lol

I guess I’m confused about what you’re trying to do. There is not a “dahdi_getdtmf” function that’s installed generally as part of DAHDI. Most functions like that are implemented as part of chan_dahdi in Asterisk. DAHDI only provides kernel modules + a user to kernel interface. The functions you are describing I guess are provided in a third-party Zaptel library?

yep. they are all in zap.c. Heres the zapata tar:

dl.dropbox.com/u/61083309/extras/zapata.v1.9.tgz

This doesnt compile anymore however.

Ahh, that looks like the original library for Zaptel before Asterisk was a heavy user. It could take a bit of work to port that to DAHDI. However, much of what that library was intended to do is now done directly by Asterisk.

I think you’ll need to decide what would be better in your case:

a) stay on a platform and with a kernel supported by the library as is.
b) Port the library (both the side to the kernel and the side back to your application) to DAHDI.
or,
c) Implement your application via Asterisk.

Just out of curiosity, what prevents you from using Asterisk now?

Well, Ive spent years developing my telco application. It also has a great deal of customization for use at my company. Completely redoing it in Asterisk is problably not something Im going to be willing to do.

These are all my unique zapata functions. If I can find some way to make new functions that do the same thing with DAHDI then im Golden. There really arent that many. Is there maybe a doc that outlines all the dahdi lib functions and how to use them? (i tried to change ‘zap’ to ‘dahdi’ to see if it would compile… it didnts :wink:

chan = dahdi_open(channel, 0);
i = dahdi_close(chan);
i = dahdi_sethook(chan, hook ? DAHDI_ONHOOK : DAHDI_OFFHOOK);
i = dahdi_waitcall(chan, rings, DAHDI_ONHOOK, 0);
i = dahdi_flash(chan);
i = dahdi_arbtones(chan, 480, 620, 500, DAHDI_DTMFINT);
i = dahdi_silence(chan, 500, DAHDI_DTMFINT);
i = dahdi_clrdtmf(chan);
i = dahdi_dtmfms(chan);
i = dahdi_gains(chan, rxgain, txgain);
i = dahdi_getdtmf(chan, max, “#”, ’ ', 0, timeout, DAHDI_HOOKEXIT);
i = dahdi_conf(chan, 0, bridgeno, mode);
i = dahdi_digitmode(chan, flags);
i = dahdi_makelink(chan, our_bridgeno, their_bridgeno);
i = dahdi_breaklink(chan, our_bridgeno, their_bridgeno);
i = dahdi_clearlinks(chan);
i = dahdi_wink(chan);
i = dahdi_playf(chan, msgfile, flags);
i = dahdi_play(chan, iot, DAHDI_HOOKEXIT | DAHDI_DTMFINT);
i = dahdi_recf(chan, msgfile, bytes, flags);
i = dahdi_rec(chan,iot,DAHDI_HOOKEXIT);
i = dahdi_start(chan);
i = dahdi_getevent(chan);
i = dahdi_arbtones(chan, 440, 480, 100, DAHDI_DTMFINT);
i = dahdi_silence(chan, 100, DAHDI_DTMFINT);

There are not really any dahdi lib functions. Only a collection of ioctls on the driver. There are only very few ioctls that were added by DAHDI (some regarding buffer events, loadable echocans, loadable tone zones…) and only the conference link ones have been removed as far as I know off the top of my head. Most of them just had their named changed.

For example, compare the include/dahdi/user.h with the older zaptel.h. Generally they are the same, just some of the names have changed (and the DAHDI interface has the user mode interface split from the kernel-only interfaces).

Hopefully that will give you enough to get you going if you choose to port the library.

Im afriad I just dont understand. I dont understand how Asterisk or any other application does I/O from/to the digium card without simple functions like getdtmf or playf.

Sorry if I wasn’t being clear. I’ll take a crack at explaining this but forgive me is this is still not very understandable.

Since device drivers need physical access to the hardware in order to do things like setting up registers on telephony cards so they may write audio samples directly into system memory, they need to run inside the kernel with full system privileges. This is referred to as kernel mode. Normal applications on Linux run primarily in user-mode and the kernel controls what sort of access they have to the rest of the system.

When an application needs access to a physical resource (disk, clock, telephony card, etc…) it must make a system call. System calls all allow a process to switch from user-mode to kernel-mode so that the kernel may perform some action for the process. Because of the special nature of system calls their number and function is fixed by the kernel. A driver cannot just add a new system call that is callable by a normal application. What a driver is able to do, however, is set function pointers in a file_operations structure that the kernel will call when the user passes a file descriptor returned form an open() call on one of the /dev/dahdi/xxx files to the read(), write(), ioctl(), or poll() functions in the C library.

Most of the telephony specific operations on a DAHDI channel like taking a line off hook, reversing polarity, starting a ring cycle, etc… all must be done through DAHDI specific ioctls which are passed as the request parameter on the ioctl function in the C library. The C library and kernel will eventually hand these requests to the DAHDI kernel module.

If you look at the zapata library you linked before, I believe you will find at it’s lowest layers are calls into the kernel through read, write, ioctl, and poll calls. It is those Zaptel ioctls and parameters that you will need to change to their DAHDI equivalents if you want to port that library.

For example, search chan_dahdi.c in the Asterisk source for “ioctl”. That will provide examples of how Asterisk, through chan_dahdi, communicates with the hardware through read, write, ioctl, and poll calls.

As an aside, it would be possible to write a libdahdi.so which provide normal C function calls that map to ioctls. However I’m not aware of any versions of Asterisk that have used such a library which I assume was for performance reasons. Also Asterisk needs certain sorts of telephony functions like tone generators and detectors to run on any Asterisk channel and not just from DAHDI interfaces.

Hopefully this helps to explain why there isn’t a need for a DAHDI specific library you link to your application and call into like other libraries.

[quote=“sruffell”][quote]
Im afriad I just dont understand. I dont understand how Asterisk or any other application does I/O from/to the digium card without simple functions like getdtmf or playf.
[/quote]

Sorry if I wasn’t being clear. I’ll take a crack at explaining this but forgive me is this is still not very understandable.

Since device drivers need physical access to the hardware of the computer in order to do things like setting up registers on the cards so that they may write directly into system memory, they need to run inside the kernel with full system privileges. This is referred to as kernel mode. Normal applications on Linux run primarily in user-mode and the kernel controls what sort of access they have to the rest of the system.

When an application needs access to a physical resource (disk, clock, telephony card, etc…) it must make a system call which allows a process to switch from user-mode to kernel-mode. Because of the special nature of system calls the number and function is fixed by the kernel. A driver cannot just add a new system call that is callable by a normal application. What it is able to do is fill out function pointers in a file_operations structure[/quote]

I understand that part but there must be functions that Asterisk calls to communicate to the card. There must be a way for it to open a channel… wait for a call… answer it… wait for digits… process the digits… and then do something else.

Maybe I should DL asterisk and see how it does these things to give me some ideas as these functions must be somewhere. Even old school dialogic had functions to communicate with their cards (int i = getdtmf(FLAG); for example). There should be a very simple layer like that somewhere unless the DAHDI move crushed all of the simplicity of using Digium which was half the point of its existance in the first place. The other half being the ability to use the computers processing power instead of it being onboard and expensive in the case of Dialogic).

Yes…I posted my previous messages too soon when I meant to preview it (darn buttons are too close together in this forum interface). I suggest looking at source of chan_dahdi.c to see examples of what can be done on the hardware through the kernel interface.

I think I get it now. I took my latest version of the zapata lib and made some changes and I think I ported it to work with DADHI. I got it to compile I have my libs:

ls -la /usr/lib/libzap*
-rw-r–r-- 1 root root 211118 May 17 13:02 /usr/lib/libzap.a
lrwxrwxrwx 1 root root 11 May 17 13:02 /usr/lib/libzap.so → libzap.so.1
-rwxr-xr-x 1 root root 143323 May 17 13:02 /usr/lib/libzap.so.1

and my application compiles. All on Ubuntu 12.04 LTS 64bit :smiley:

Does it work? I have no idea lol. Im gonna get a card and put it that box and try it out. It will be interesting. If it works ill post my version of zapata here in case anyone else were to ever want it.

Thank you so very much for you help and patience with this. It is truley appreciated.

Wish me luck… :smile:

Well it worked. I successfully ported the zapata library and its up and running great on Ubuntu 12.04 LTS 64Bit.

For anyone who should ever want it, here is zapata.v2.0:

git clone git@github.com:tgwaste/zapata.git

Not that anyone will probably ever care or ever even read this. :smile:

Thanks for porting the zapata library to the DAHDI interface. I was tasked to implement ‘A $10 Linux Answering Machine’ by Bob Smith. I thought I was going to have to try to port the library myself until I found your post.

I am using a XP100 Special Edition FXO pci card on an OpenSuse 13.1 operating system. Everything is working except for one problem that I can work around or not use. The answering machine code has the option to output a beep before recording a voice message. If I choose not to output the beep the code works great, but if I choose to output the beep the code hangs.

I traced the problem to the zap_rec(…) function in the zap.c file. When the beep option is turned on, the code calls the ‘ioctl(zap_fd, DAHDI_SYNC, &i) == -1’ to wait until the beep stops. However, this ioctl call never returns.

I have not been able to find anyone with this issue while searching the internet. I was wondering if you have tried this in your code and had problems with it.

[quote=“maxum2400”]Thanks for porting the zapata library to the DAHDI interface. I was tasked to implement ‘A $10 Linux Answering Machine’ by Bob Smith. I thought I was going to have to try to port the library myself until I found your post.

I am using a XP100 Special Edition FXO pci card on an OpenSuse 13.1 operating system. Everything is working except for one problem that I can work around or not use. The answering machine code has the option to output a beep before recording a voice message. If I choose not to output the beep the code works great, but if I choose to output the beep the code hangs.

I traced the problem to the zap_rec(…) function in the zap.c file. When the beep option is turned on, the code calls the ‘ioctl(zap_fd, DAHDI_SYNC, &i) == -1’ to wait until the beep stops. However, this ioctl call never returns.

I have not been able to find anyone with this issue while searching the internet. I was wondering if you have tried this in your code and had problems with it.[/quote]

I realize this response is delayed quite a bit but I too had issues with the beep so I just made my own beep and play it before recording a message.