@zandbelt
Thanks a lot :-)

Would it be possible that you also share the Makefiles to get libtiff and spandsp compiled under OpenWRT for other platforms ?

Regards
dynamic

(Last edited by dynamic on 11 Aug 2007, 15:31)

Why is Asterisk 1.4 not being put in the OpenWRT trunk for kamikaze?  Digium has deprecated the 1.2 line now,  Zandbelt has submitted patches several times, but they never seemed to be touched. 

While zandbelt has been good about posting new updates to his build, the OpenWRT package sources have been for the most part not included.   Please respect the GPL and post your sources!  I'd like to participate in getting this working on the several of the platforms I work with (Gateworks Avila, Routerboard 133, Meraki-mini, Ubiquiti LS5 to name a few), but the ball keeps getting dropped.

I just spent the better part of my weekend reproducing the work that zandbelt has already done for Asterisk 1.4.9, but still haven't caught him.  This is all unnecessary if his patches would have been accepted 5 months ago when he submitted them or his sources would have been posted.

Keeping it as a separate package besides the Asterisk 1.2 package currently in kamikaze until stabilized is probably the best idea, but it appears that is how zandbelt has designed it anyway. 

Who do we need to nudge to get this ball rolling?  There seems to be plenty of interest in Asterisk on OpenWRT, just not with those in control of the SVN.

you must be joking or deliberately trying to upset me: read the posts, visit the links and build it yourself using the available patches + full build script for 1.4.9, as I did for earlier releases; please do some decent research before making statements like this, sigh

"openwrt -> forum -> search" would have been your friend...

yap; although I'm now in favor of actually dropping 1.2 for 1.4 altogether

that part I do agree on

Hans.

At least your attention to this problem has been received.  You have posted no sources for kamikaze builds, only whiterussian.   

There are some patches for older versions of 1.4 in Trac tickets.   All your sources seem to be hosted on http://zandbelt.dyndns.org which is not browsable.  Without a public link the sources are effectively unavailable.  The binaries all seem to be at http://members.home.nl/hans.zandbelt/.  This is browsable, but no sources are there.

This thread is where all the current announcements of your new builds have been and seems to be the most appropriate place to also link to the sources.

See statements above...

My intention is not upset, but to get this ongoing problem brought to attention. 

Asterisk is very usable tool on OpenWRT.  I have been running an old trunk version of 1.2 on one of my Linksys routers since Jan 2006 for basic iax2 to sip call routing with great results.   

More than a few times I have revisited Asterisk on OpenWRT and there have been new binaries published by you without links to the sources.  Intentional or not, it creates problems for anyone wanting to experiment with building the packages you posted. 

Simply posting a patch file to your open tickets or a tar.gz of the Makefiles and patches for buildroot-ng along side the binaries will avoid people repeatedly asking for them.  Besides, if one of the official OpenWRT developers actually decides to update Asterisk in trunk, no one wants them to have to look far for your sources either. 

Frankly, you've brought Asterisk along more than anyone lately, I don't know why you haven't been given access to check it in SVN yourself.  Or have you even asked to?

the patches are for the packages branch, which means they are for both kamikaze and whiterussian; some investigation would have taught you that

there is no problem: this is open source software being delivered in an open source community; anyone trying to deduct rights from that apart from the right to be able to obtain GPL-ed sources is wrong; not being able to find the sources by yourself, you could have just asked where to download the sources instead of assuming that it is not possible

I did not ask you to use my stuff, I am not obliged nor inclined to support your experiments

there have been discussions on opening up the packages branch for developers, but no results yet

what you could do:
- being unable to find the sources by yourself you should ask others for it in a polite way (here you go: http://zandbelt.dyndns.org/asterisk/asterisk-build.sh)
- take those patches and upload/transform them into multiple smaller tickets
- convince the OpenWRT developers to commit those patches
- convince the OpenWRT developers that you can be the package maintainer for Asterisk 1.4 and get commit rights to do that
- forward patch upcoming new releases

This is the way that open source works, not by complaining about support.

Good luck,

Hans

Hello,

I'm currently trying to get a brisftuff enabled asterisk 1.4 to work on an 2.6-x86 openwrt.
I tried starting with zandbelt's zaptel-1.4.4 BuildRoot Package but could't get it to build the kmod-zaptel package für that target.
The problem seems that the original zaptel Makefile seems to get confused about the architecture for which to build the kernel modules and mixes in the architecture of the build machine (e.g. I get make errors like "sorry, 64Bit not supported" on a amd64 machine).

There is also a note on his website that the "zaptel/ztdummy kernel module is not yet available" on a 2.6 build.
Any enlighting thoughts why this is not possible for now or even better how to get this done.

Thanks
Fabian

the 2.4/2.6 build of kmod-zaptel was not yet done for buildroot-ng; I don't see any serious problems doing so, it is just the fact that somebody to spend some time on it

since the asterisk 1.4.x package is in the OpenWRT packages SVN repository now, patches can be provided against that

Hans.

Hi Zandbelt,

Would you have any Asterisk compiled built ipk package on your web site for kamikaze 7.09 2.6 kernel?
I got a WGT634U with USB port which would run 2.6 kernel I think.
Thank you for your support and wonderful package depot for Asterisk on Openwrt! Noticed the new 1.4.13 available for 2.4 kernel.

I updated the repository over here:

   http://members.home.nl/hans.zandbelt/openwrt/kamikaze/7.09/

The new thing to test is:

  kmod-zaptel14_2.6.22-1.4.6-brcm47xx-1_mipsel.ipk

if that loads on your router and creates a dummy timer device, I'll also re-enable building zaptel modules in the Asterisk 1.4 build for the OpenWRT package repository for app_meetme and iax2 trunking. (I'm not sure why it was removed in the first place)

Hans.

Thank you so much!
Just found out it was already updated with 2.6 kernel Kamikaze.
That was super quick.
I will test that dummy timer module, but I read it somewhere that WGT634U is using ohci/ehci, that zaptel needs uhci. But I will try it anyway...

It seems loaded, but not sure if it really works with ohci. How to test it?

dmesg
...
Zapata Telephony Interface Registered on major 196
Zaptel Version: 1.4.6
Zaptel Echo Canceller: MG2

dev tree
crw-r--r--    1 root     root     196, 254 Dec 17 22:47 /dev/zapchannel
crw-r--r--    1 root     root     196,   0 Dec 17 22:47 /dev/zapctl
crw-r--r--    1 root     root     196, 255 Dec 17 22:47 /dev/zappseudo
crw-r--r--    1 root     root     196, 253 Dec 17 22:47 /dev/zaptimer
crw-r--r--    1 root     root     196, 250 Dec 17 22:47 /dev/zaptranscode

And lsmod

Module                  Size  Used by    Tainted: P
ztdummy                 1440  0
zaptel                187824  1 ztdummy
snd_pcm_oss            40320  0
snd_mixer_oss          13792  1 snd_pcm_oss
snd_pcm                58400  1 snd_pcm_oss
snd_timer              16272  1 snd_pcm
snd_rawmidi            15904  0
snd_hwdep               4784  0
snd_page_alloc          5232  1 snd_pcm
snd                    35632  6 snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer,snd_
rawmidi,snd_hwdep
soundcore               3664  1 snd
fuse                   37520  0
usb_storage            27664  1
sd_mod                 18416  2
scsi_mod               71968  2 usb_storage,sd_mod
ehci_hcd               28016  0
ohci_hcd               14064  0
ath_pci                94384  0
wlan_xauth               480  0
wlan_wep                4000  0
wlan_tkip               9664  0
wlan_ccmp               5408  3
wlan_acl                1888  0
ath_rate_minstrel       7840  1
ath_hal               271168  3 ath_pci,ath_rate_minstrel
wlan_scan_sta           8736  1
wlan_scan_ap            2624  0
wlan                  146400  10 ath_pci,wlan_xauth,wlan_wep,wlan_tkip,wlan_ccmp
,wlan_acl,ath_rate_minstrel,wlan_scan_sta,wlan_scan_ap
ppp_async               9664  0
ppp_generic            20000  1 ppp_async
slhc                    5408  1 ppp_generic
crc_ccitt               1024  2 zaptel,ppp_async
nbd                    17296  0
vfat                    8512  0
fat                    42448  1 vfat
ext3                   97040  1
jbd                    54672  1 ext3
nls_iso8859_1           2880  0
nls_cp437               4416  0
usbcore               102032  4 usb_storage,ehci_hcd,ohci_hcd
nls_base                4416  4 vfat,fat,nls_iso8859_1,nls_cp437
switch_robo             4048  0
switch_core             5056  1 switch_robo
diag                    8272  0

(Last edited by Fall on 18 Dec 2007, 05:55)

The 2.6 ztdummy version is quite different from the 2.4 code: the 2.6 version does no longer need a usb device.
I compiled the zttest utility for mipsel; it is available over here:

  http://zandbelt.dyndns.org/asterisk/zttest

copy it onto your device and run it as:

  ./zttest -v

I'm also curious about the output of:

  cat /proc/zaptel

Hans.

Good stuff. So kernel has timmer built in, read it somewhere.

Here is the result and thank you for your help.

root@NetGear:~# ./zttest -v
Unable to open zap interface: No such file or directory
root@NetGear:~# cat /proc/zaptel
cat: read error: Is a directory
root@NetGear:~# ls -al /dev/zap*
crw-r--r--    1 root     root     196, 254 Dec 17 22:47 /dev/zapchannel
crw-r--r--    1 root     root     196,   0 Dec 17 22:47 /dev/zapctl
crw-r--r--    1 root     root     196, 255 Dec 17 22:47 /dev/zappseudo
crw-r--r--    1 root     root     196, 253 Dec 17 22:47 /dev/zaptimer
crw-r--r--    1 root     root     196, 250 Dec 17 22:47 /dev/zaptranscode
root@NetGear:~# cd /proc
root@NetGear:/proc# cd zaptel
root@NetGear:/proc/zaptel# ls -al
dr-xr-xr-x    2 root     root            0 Dec 18 11:37 .
dr-xr-xr-x   46 root     root            0 Dec 31  1999 ..
-r--r--r--    1 root     root            0 Dec 18 11:37 1
root@NetGear:/proc/zaptel# cat 1
Span 1: ZTDUMMY/1 "ZTDUMMY/1 (source: Linux26) 1"

hmm. some dev system mixups: I adapted zttest.c and recompiled; please download and try again...

Hans.

It works now! So guess the zdummy module should work for Asterisk as well.

root@NetGear:~# ./zttest -v
Opened pseudo zap interface, measuring accuracy...

8192 zaptel samples in 8183.104 system clock sample intervals (99.891%)
8192 zaptel samples in 8166.672 system clock sample intervals (99.691%)
8192 zaptel samples in 8168.496 system clock sample intervals (99.713%)
8192 zaptel samples in 8168.607 system clock sample intervals (99.714%)
8192 zaptel samples in 8168.328 system clock sample intervals (99.711%)
8192 zaptel samples in 8168.527 system clock sample intervals (99.713%)
8192 zaptel samples in 8168.688 system clock sample intervals (99.715%)
8192 zaptel samples in 8168.289 system clock sample intervals (99.711%)
8192 zaptel samples in 8168.408 system clock sample intervals (99.712%)
8192 zaptel samples in 8168.624 system clock sample intervals (99.715%)
8192 zaptel samples in 8168.280 system clock sample intervals (99.710%)
8192 zaptel samples in 8168.440 system clock sample intervals (99.712%)
8192 zaptel samples in 8168.656 system clock sample intervals (99.715%)
8192 zaptel samples in 8168.600 system clock sample intervals (99.714%)
8192 zaptel samples in 8168.520 system clock sample intervals (99.713%)
8192 zaptel samples in 8168.592 system clock sample intervals (99.714%)
8192 zaptel samples in 8168.296 system clock sample intervals (99.711%)
8192 zaptel samples in 8168.416 system clock sample intervals (99.712%)
8192 zaptel samples in 8168.600 system clock sample intervals (99.714%)
8192 zaptel samples in 8168.448 system clock sample intervals (99.713%)
--- Results after 20 passes ---
Best: 99.891 -- Worst: 99.691 -- Average: 99.720820, Difference: 99.720820

I updated the repository over here:

  http://members.home.nl/hans.zandbelt/openwrt/kamikaze/7.09/

to the latest Asterisk 1.4.15, including ztdummy and app_meetme for mipsel, kernel 2.6

let me know how things work out

Hans.

Sure. I'm trying to wget each ipk to local then install them, since the package info is still pointing to 1.4.13, so ipk refuse to upgrade.

zaptel package seems corrupted, I unpack it and loaded the modules manually under place.

Collected errors:
Package kmod-zaptel14 md5sum mismatch. Either the ipkg or the package index are
zaptel

Same for the lib
Package zaptel14-libtonezone md5sum mismatch. Either the ipkg or the package ind
ex are corrupt. Try 'ipkg update'.

I will post the result once I figure out how to get it setup, it will take a while.
Thanks!

(Last edited by Fall on 19 Dec 2007, 00:40)

Good news. It works!
The only problem other than the checksum not match in package that had to manually copy files into place, was the device files for zaptel are all created under /dev, not /dev/zap.

crw-r--r--    1 root     root     196, 254 Dec 17 22:47 /dev/zapchannel
crw-r--r--    1 root     root     196,   0 Dec 17 22:47 /dev/zapctl
crw-r--r--    1 root     root     196, 255 Dec 17 22:47 /dev/zappseudo
crw-r--r--    1 root     root     196, 253 Dec 17 22:47 /dev/zaptimer
crw-r--r--    1 root     root     196, 250 Dec 17 22:47 /dev/zaptranscode

* complains about can't open pseudo file, I figured there was a '/' missing when module created those device files, so I did a softlink from /dev/zappseudo to /dev/zap/pseudo.

Could you please help to check the source, where this '/' got missed between zap and pseudo. The same for the rest files listed above, which should be created under /dev/zap/*, not /dev/zap*.

Thanks again for the great work!

I updated the Packages file so the repository should be fine now.
I'll look into the device naming issue: when fixed (I suspect it is caused by wrongly detected module compile flags), I'll submit an Asterisk 1.4.15 +zaptel/ztdummy + app_meetme patch ticket.

Thanks for testing,

Hans.

My pleasure and thank you for your continuing support of * on openwrt. Your repository is the only place where we can get the latest * for whiterussian and Kamikaze, and now for both 2.4 and 2.6 kernel.

hi guys,

if I understand correctly it means the WGT634U running 2.6 kernnel is another option to get the timing working for Asterisk besides WL-500G Deluxe running 2..4, right?

Thanks!

Yes, that's right. 2.6 Kernel has built in timing function but you will still need ztdummy module. For 2.4, ztdummy would need uhci USB driver.

I updated the repository http://members.home.nl/hans.zandbelt/openwrt/kamikaze/7.09/ to:

  asterisk-1.4.16 (including app_meetme/zaptel-libtonezone)
  zaptel-1.4.7.1 kernel module for both mipsel 2.4 (usb-uhci-required) and 2.6 (no-usb-required)

Even with the most recent ztdummy module, my guess is that the device naming issue remains, but let me know. It looks to me like an upstream issue.

Hans.

I think it's somewhere in the source code of zaptel or header files that the device names changed. From strings and grep for these device names from zaptel.ko

zaptranscode
zaptimer
zapchannel
zappseudo
zapctl

I think they should be defined like these, so I dont have to manually link them into the right place for *.
zap/transcode
zap/timer
zap/channel
zap/pseudo
zap/ctl

sure; but the thing is that zaptel.h mentions that for 2.6 kernels devfs /dev/zaptel/* naming is not supported, but only udev /dev/zap* naming
it just looks like applications are not prepared to deal with that; we'll have to look upstream, I guess

Hans.