- App_rpt-users - lists.keekles.org

Re: [App_rpt-users] [PATCH] Zaptel modified for newer kernels & IOCTL issues.
by James Le Cuirot 18 Dec '11

18 Dec '11

Hello all, I'm not a radio user but I've been helping Ken out and I made the necessary changes to get Zaptel working with Linux 3.1.0. I know it is customary to send patches directly to the list so here it is. Ken didn't mention that I did not fix all the drivers. I was primarily just trying to get wctdm working. If you blank out the SUBDIR_MODULES variable in the Makefile then the build will complete, albeit with some drivers missing. No specialist knowledge is needed to complete this task as I merely applied the same changes that have already been applied to DAHDI. Both the name change and the other numerous modifications since then mean that existing patches cannot simply be applied. This brings me to a controversial point. As I won't be staying here long, I won't mince my words. Why on earth are you still dragging your heels with Zaptel? All the work that went into making this patch had already been done before by somebody else. This made the effort feel pointless, hence why I wasn't compelled to finish the job. There have no doubt been countless other feature additions and bug fixes to DAHDI that you are missing out on. Jim complains that DAHDI has stupid bugs that he had to fix in his Zaptel fork. I'm new here so I don't know if he's ever mentioned exactly what these bugs are. Why not fix them in DAHDI? If upstream doesn't agree, you can still continue to apply these patches against future versions. You can't cling to the past forever in the hope that things won't break because they inevitably do. Jim also stated that DAHDI would not work for radio setups. Is this really true? I gather that if you don't have a telephony card, only the ztdummy module is required for timing. I've seen the code for ztdummy and dahdi_dummy. It's relatively short. Do the aforementioned bugs apply to this code? Would they really be that hard to fix? I wish I had the radio hardware just so I could try it for myself. As for Asterisk, I don't know whether Jim insists on this old version because later versions don't support Zaptel or because he also has other issues with it. If it's the latter then I agree with the sentiment but not the solution. You only have to look as far as the publicly posted rationale for FreeSWITCH to learn that Asterisk has some fundamental flaws. This was written by someone who invested an awful lot of time and code in Asterisk but ultimately decided that a clean break was the only way to go. If Asterisk is so bad, why have you stuck with it and how does clinging to an older version help? One would hope that it has at least gone some way to address the flaws in more recent versions. I have just begun developing a new VoIP product and will be evaluating Yate in favour of Asterisk very soon. I don't know much about it yet but I like what I've seen so far. Maybe you should also consider the alternatives? Zaptel wasn't the only thing I had to modify for Linux 3.1.0. chan_usbradio itself was also broken. I need to go into some detail about that so I'll save it for another post. Regards, James

2 2

[PATCH] chan_usbradio fixes for newer kernels
by James Le Cuirot 18 Dec '11

18 Dec '11

Hello all, As mentioned in my previous post, I needed to make changes to chan_usbradio as well as Zaptel for Linux 3.1.0. The crux of the issue here was that the structure of /sys had changed. The first clue was when Asterisk started reporting that the USB device ".." had been assigned to a radio channel. The code previously looked up a path like: /sys/class/sound/dsp1/device On older kernels, this path would be a symlink to something like: ../../../devices/pci0000:00/0000:00:04.2/usb1/1-1/1-1:1.0 The second last component of this was extracted, resulting in 1-1. However, the above symlink now simply points to ../../card1, resulting in .. as I mentioned before. Now everything under /sys/class/sound is also a symlink and it is these that need to be queried instead. For dsp1, the new target is: ../../devices/pci0000:00/0000:00:04.2/usb1/1-1/1-1:1.0/sound/card1/dsp1 This is similar to before but the code that previously handled the path extraction was long winded. basename and dirname do the job for us much more efficiently. This new code will not work on older kernels. I was going to address that issue when it occurred to me that this whole process is very convoluted and over-complicated. Surely libusb can simply tell us the "devstr" value without having to iterate over all the sound cards and then go digging around in /sys? As it turns out, it can't, at least not in this version. The old "legacy" libusb API is being used here. The newer API includes a function called libusb_get_device_address but I'm not sure whether this returns the right information. The following discussion from August has led me to believe that the function we need may actually be introduced in the next version. http://libusb.6.n5.nabble.com/Find-specific-USB-device-based-on-udev-info-t… Despite this, I was still able to simplify the confusingly named usb_get_usbdev function. Instead of iterating over all the sound cards, looking for the one that matches the given devstr, we simply look up the device directly under /sys. For the 1-1 example: /sys/bus/usb/devices/1-1/1-1:1.0/sound This is a directory containing just one other directory, card1 in this case. We just look for a directory starting with "card" and take the number from the end. Job done. So to sum up, the attached patch works but only with newer kernels. I don't know exactly which kernel version introduced the change. It may have been as far back as 2.6.25. This could be fixed up to work with older kernels too but moving to the newer libusb and vastly simplifying this code is well worth considering. Of course, so is ditching Asterisk, but that's covered in my other post. ;) This code would look much the same under any system anyway. Regards, James

2 2

Allstar Link Support
by Marshall Oldham 18 Dec '11

18 Dec '11

Greetings fellow Allstar link members, I am writing this email with the hopes that we as the amateur community can step forward and support our hobby, mainly the app_rpt and allstarlink technology that we all enjoy today. As many of you might NOT know, the creator of app_rpt and the allstarlink network has never charged or asked for financial support to keep the allstarlink system going. He has never charged users money to be a part of the allstarlink network, nor has he ever made any profit off of specific hardware sales for the allstarlink network. Through the years he has put in a great deal of time and dedication along with his exceptional talents to make app_rpt and the allstarlink network the great VOIP technology that it has become today. No other VOIP technology in the amateur radio community can even compare to the technology, features and capability that is offered for free to anyone wishing to setup there own allstarlink node. Another unknown fact is that there are monthly costs associated with keeping things running smoothly for the allstarlink system. These costs are for server collocation, domain certifications and so on, amounting to roughly $175 per month. Jim has been paying these monthly fees out of his own pocket. Wouldn't it be nice if we could all pitch in and help him to at the least cover these monthly costs for this coming year? I am proposing that we all donate to this cause via PayPal at the following URL. https://allstarlink.org/ At the top of this webpage just slightly down there is a PayPal donate button. In the spirit and season of giving, lets all do our part to try and help out with the financial side, so we can continue to use and enjoy this great technology that we have all come to know and love! I would also like to say thanks to Jim, WB6NIL for all the many hours of work and support that he and others have donated to this hobby so that the amateur community at large can benefit and enjoy the use of this technology on a daily basis for free. 73 Marshall - ke6pcv Node 2065, 2066

3 2

Can't compile latest svn
by Buddy Brannan 17 Dec '11

17 Dec '11

Hi, I'm not sure what has changed (or what I should change), but for some reason, the latest asterisk from svn won't compile. This started a couple weeks ago, and I accidentally *really* broke things. Fortunately I had an old source tree and have a now working 0.281. Even grabbing a fresh download, rather than updating what's already there, nets the same exiting of the make. Here's what happens right before things quit compiling: CC] chan_voter.c -> chan_voter.o chan_voter.c: In function ‘voter_write’: chan_voter.c:769: error: request for member ‘ptr’ in something not a structure or union chan_voter.c: In function ‘ast_frcat’: chan_voter.c:805: error: request for member ‘ptr’ in something not a structure or union chan_voter.c:806: error: request for member ‘ptr’ in something not a structure or union chan_voter.c:811: error: request for member ‘ptr’ in something not a structure or union chan_voter.c: In function ‘voter_mix_and_send’: chan_voter.c:834: error: request for member ‘ptr’ in something not a structure or union chan_voter.c:904: error: request for member ‘ptr’ in something not a structure or union chan_voter.c:916: error: request for member ‘ptr’ in something not a structure or union chan_voter.c:917: error: request for member ‘ptr’ in something not a structure or union chan_voter.c:937: error: request for member ‘ptr’ in something not a structure or union chan_voter.c:972: error: request for member ‘ptr’ in something not a structure or union chan_voter.c:994: error: request for member ‘ptr’ in something not a structure or union chan_voter.c:1015: error: request for member ‘ptr’ in something not a structure or union chan_voter.c:1060: error: request for member ‘ptr’ in something not a structure or union chan_voter.c: In function ‘voter_xmit’: chan_voter.c:1116: error: request for member ‘ptr’ in something not a structure or union chan_voter.c:1147: error: request for member ‘ptr’ in something not a structure or union chan_voter.c:1167: error: request for member ‘ptr’ in something not a structure or union chan_voter.c:1198: error: request for member ‘ptr’ in something not a structure or union chan_voter.c:1208: error: request for member ‘ptr’ in something not a structure or union chan_voter.c:1245: error: request for member ‘ptr’ in something not a structure or union chan_voter.c:1255: error: request for member ‘ptr’ in something not a structure or union chan_voter.c: In function ‘voter_request’: chan_voter.c:1349: error: ‘DSP_FEATURE_DIGIT_DETECT’ undeclared (first use in this function) chan_voter.c:1349: error: (Each undeclared identifier is reported only once chan_voter.c:1349: error: for each function it appears in.) chan_voter.c:1350: warning: implicit declaration of function ‘ast_dsp_set_digitmode’ chan_voter.c:1459: error: too many arguments to function ‘ast_config_load’ chan_voter.c: In function ‘res2cli’: chan_voter.c:1767: error: ‘CLI_SUCCESS’ undeclared (first use in this function) chan_voter.c:1769: error: ‘CLI_SHOWUSAGE’ undeclared (first use in this function) chan_voter.c:1771: error: ‘CLI_FAILURE’ undeclared (first use in this function) chan_voter.c: At top level: chan_voter.c:1776: warning: ‘struct ast_cli_args’ declared inside parameter list chan_voter.c:1776: warning: its scope is only this definition or declaration, which is probably not what you want chan_voter.c: In function ‘handle_cli_debug’: chan_voter.c:1779: error: ‘CLI_INIT’ undeclared (first use in this function) chan_voter.c:1780: error: ‘struct ast_cli_entry’ has no member named ‘command’ chan_voter.c:1783: error: ‘CLI_GENERATE’ undeclared (first use in this function) chan_voter.c:1786: error: dereferencing pointer to incomplete type chan_voter.c:1786: error: dereferencing pointer to incomplete type chan_voter.c:1786: error: dereferencing pointer to incomplete type chan_voter.c: At top level: chan_voter.c:1790: warning: ‘struct ast_cli_args’ declared inside parameter list chan_voter.c: In function ‘handle_cli_test’: chan_voter.c:1793: error: ‘CLI_INIT’ undeclared (first use in this function) chan_voter.c:1794: error: ‘struct ast_cli_entry’ has no member named ‘command’ chan_voter.c:1797: error: ‘CLI_GENERATE’ undeclared (first use in this function) chan_voter.c:1800: error: dereferencing pointer to incomplete type chan_voter.c:1800: error: dereferencing pointer to incomplete type chan_voter.c:1800: error: dereferencing pointer to incomplete type chan_voter.c: At top level: chan_voter.c:1804: warning: ‘struct ast_cli_args’ declared inside parameter list chan_voter.c: In function ‘handle_cli_record’: chan_voter.c:1807: error: ‘CLI_INIT’ undeclared (first use in this function) chan_voter.c:1808: error: ‘struct ast_cli_entry’ has no member named ‘command’ chan_voter.c:1811: error: ‘CLI_GENERATE’ undeclared (first use in this function) chan_voter.c:1814: error: dereferencing pointer to incomplete type chan_voter.c:1814: error: dereferencing pointer to incomplete type chan_voter.c:1814: error: dereferencing pointer to incomplete type chan_voter.c: At top level: chan_voter.c:1818: warning: ‘struct ast_cli_args’ declared inside parameter list chan_voter.c: In function ‘handle_cli_tone’: chan_voter.c:1821: error: ‘CLI_INIT’ undeclared (first use in this function) chan_voter.c:1822: error: ‘struct ast_cli_entry’ has no member named ‘command’ chan_voter.c:1825: error: ‘CLI_GENERATE’ undeclared (first use in this function) chan_voter.c:1828: error: dereferencing pointer to incomplete type chan_voter.c:1828: error: dereferencing pointer to incomplete type chan_voter.c:1828: error: dereferencing pointer to incomplete type chan_voter.c: At top level: chan_voter.c:1832: warning: ‘struct ast_cli_args’ declared inside parameter list chan_voter.c: In function ‘handle_cli_reload’: chan_voter.c:1835: error: ‘CLI_INIT’ undeclared (first use in this function) chan_voter.c:1836: error: ‘struct ast_cli_entry’ has no member named ‘command’ chan_voter.c:1839: error: ‘CLI_GENERATE’ undeclared (first use in this function) chan_voter.c:1842: error: dereferencing pointer to incomplete type chan_voter.c:1842: error: dereferencing pointer to incomplete type chan_voter.c:1842: error: dereferencing pointer to incomplete type chan_voter.c: At top level: chan_voter.c:1846: warning: ‘struct ast_cli_args’ declared inside parameter list chan_voter.c: In function ‘handle_cli_display’: chan_voter.c:1849: error: ‘CLI_INIT’ undeclared (first use in this function) chan_voter.c:1850: error: ‘struct ast_cli_entry’ has no member named ‘command’ chan_voter.c:1853: error: ‘CLI_GENERATE’ undeclared (first use in this function) chan_voter.c:1856: error: dereferencing pointer to incomplete type chan_voter.c:1856: error: dereferencing pointer to incomplete type chan_voter.c:1856: error: dereferencing pointer to incomplete type chan_voter.c: At top level: chan_voter.c:1860: warning: implicit declaration of function ‘AST_CLI_DEFINE’ chan_voter.c:1860: warning: missing braces around initializer chan_voter.c:1860: warning: (near initialization for ‘voter_cli[0]’) chan_voter.c:1860: error: initializer element is not constant chan_voter.c:1860: error: (near initialization for ‘voter_cli[0].cmda[0]’) chan_voter.c:1861: error: initializer element is not constant chan_voter.c:1861: error: (near initialization for ‘voter_cli[0].cmda[1]’) chan_voter.c:1862: error: initializer element is not constant chan_voter.c:1862: error: (near initialization for ‘voter_cli[0].cmda[2]’) chan_voter.c:1863: error: initializer element is not constant chan_voter.c:1863: error: (near initialization for ‘voter_cli[0].cmda[3]’) chan_voter.c:1864: error: initializer element is not constant chan_voter.c:1864: error: (near initialization for ‘voter_cli[0].cmda[4]’) chan_voter.c:1865: error: initializer element is not constant chan_voter.c:1865: error: (near initialization for ‘voter_cli[0].cmda[5]’) chan_voter.c: In function ‘voter_reader’: chan_voter.c:2061: error: request for member ‘ptr’ in something not a structure or union chan_voter.c:2061: warning: statement with no effect chan_voter.c:2235: error: request for member ‘ptr’ in something not a structure or union chan_voter.c:2235: warning: statement with no effect chan_voter.c:2272: error: request for member ‘ptr’ in something not a structure or union chan_voter.c:2272: warning: statement with no effect chan_voter.c:2289: error: request for member ‘ptr’ in something not a structure or union chan_voter.c:2289: warning: pointer type mismatch in conditional expression chan_voter.c:2295: error: request for member ‘ptr’ in something not a structure or union chan_voter.c:2295: warning: pointer type mismatch in conditional expression chan_voter.c:2298: error: request for member ‘ptr’ in something not a structure or union chan_voter.c:2298: warning: pointer type mismatch in conditional expression chan_voter.c:2507: error: request for member ‘ptr’ in something not a structure or union chan_voter.c:2507: warning: statement with no effect chan_voter.c:2577: error: request for member ‘ptr’ in something not a structure or union chan_voter.c:2577: warning: statement with no effect chan_voter.c:2635: error: request for member ‘ptr’ in something not a structure or union chan_voter.c:2635: warning: statement with no effect chan_voter.c:2656: error: request for member ‘ptr’ in something not a structure or union chan_voter.c:2656: warning: statement with no effect chan_voter.c: In function ‘reload’: chan_voter.c:2824: error: too many arguments to function ‘ast_config_load’ chan_voter.c: In function ‘load_module’: chan_voter.c:3183: error: too many arguments to function ‘ast_config_load’ make[1]: *** [chan_voter.o] Error 1 make[1]: Leaving directory `/usr/src/trunk/asterisk/channels' make: *** [channels] Error 2 Any idea what went wrong/what I'm missing? I'm still using the Acid distro from last year sometime, all updated with yum. -- Buddy Brannan, KB5ELV - Erie, PA Phone: (814) 860-3194 or 888-75-BUDDY

2 1

Courtesy Tone
by Matt Roberts 16 Dec '11

16 Dec '11

I am trying to set up a courtesy tone when I'm connected to another node. My remote courtesy tone is working fine. I can't figure out how to have a tone to sound when a user on my repeater unkeys. When my repeater is linked, I want a "K" to be heard when a local user unkeys on my system. When a remote user unkeys, you hear a double dial tone, adn I have CT1 set if my repeater isn't linked to anyone. Does anyone know what I need to do? I'm also discovering when I'm connected on my remote base, I get inactivity timeout messages. How do I disable them? Matt Roberts n9gmr(a)me.com Call Sign N9GMR IRLP 4515 EchoLink 640860 Allstar 28142

2 1

Re: [App_rpt-users] Low Band Remote Base
by Monty 16 Dec '11

16 Dec '11

Been working off list with David on this issue. Tried the manual split in the memory channel: *06 = 53.720,136.5,1000,h-t *Still will only do a 0.5 mhz split, even tried 2000 just to make sure. In Checking the source, it looks like that only applies to Kenwood radios in 2m/70cm. My question is could this capability be added to accommodate the low band Syntors with the Xcat? Monty On Sat, Dec 10, 2011 at 9:42 PM, David KE6UPI <dshaw(a)ke6upi.com> wrote: > it does look like 2/70 and kenwood only. > > > David > > > On Fri, Dec 9, 2011 at 8:42 PM, Monty <monty(a)ke7jvx.com> wrote: > >> I searched app_rpt.c and found this: >> >> *static int setkenwood(struct rpt *myrpt) >> { >> char rxstr[RAD_SERIAL_BUFLEN],txstr[RAD_SERIAL_BUFLEN],freq[20]; >> char mhz[MAXREMSTR],offset[20],band,decimals[MAXREMSTR],band1,band2; >> int myrxpl,mysplit,step; >> >> int offsets[] = {0,2,1}; >> int powers[] = {2,1,0}; >> >> if (sendrxkenwood(myrpt,"VMC 0,0\r",rxstr,"VMC") < 0) return -1; >> split_freq(mhz, decimals, myrpt->freq); >> mysplit = myrpt->splitkhz; >> if (atoi(mhz) > 400) >> { >> band = '6'; >> band1 = '1'; >> band2 = '5'; >> if (!mysplit) mysplit = myrpt->p.default_split_70cm; >> } >> else >> { >> band = '2'; >> band1 = '0'; >> band2 = '2'; >> if (!mysplit) mysplit = myrpt->p.default_split_2m; >> }* >> >> Looks to be only for 2m and 70cm. >> >> Monty >> >> >> >> On Fri, Dec 9, 2011 at 2:50 PM, David KE6UPI <dshaw(a)ke6upi.com> wrote: >> >>> You can check the code (app_rpt.c) and see if there. I bet it is. I >>> don't think Jim would have limit for just 2m/70cm bands. >>> >>> David >>> >>> >>> On Fri, Dec 9, 2011 at 12:03 PM, Monty <monty(a)ke7jvx.com> wrote: >>> >>>> I know in the config program there is a split that is set, so I might >>>> have to play with that. From the webpage you referenced it looks to be >>>> only for 2m and 440. >>>> >>>> Monty >>>> >>>> >>>> >>>> On Fri, Dec 9, 2011 at 8:44 AM, David KE6UPI <dshaw(a)ke6upi.com> wrote: >>>> >>>>> Hello Monty, Sorry I don't know to much about your hardware. I do know >>>>> that the offset works on my TM-G707 kenwood. Could it be a Syntor problem? >>>>> >>>>> David >>>>> >>>>> >>>>> On Wed, Dec 7, 2011 at 8:02 PM, Monty <monty(a)ke7jvx.com> wrote: >>>>> >>>>>> Hey David, >>>>>> Thanks for your response. I tried this: >>>>>> >>>>>> *06 = 53.720,136.5,1000,h-t* >>>>>> >>>>>> When I call it up, it still splits to 0.5 mhz (53.220). Made sure I >>>>>> rebooted the node as well. So for grins I tried this: >>>>>> >>>>>> *06 = 53.720,136.5,2000,h-t >>>>>> * >>>>>> Still it transmits at 53.220 instead of 52.720. >>>>>> >>>>>> >>>>>> Monty >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Dec 7, 2011 at 9:26 AM, David KE6UPI <dshaw(a)ke6upi.com>wrote: >>>>>> >>>>>>> Check out this webpage. >>>>>>> >>>>>>> http://ohnosec.org/drupal/node/175 >>>>>>> >>>>>>> You may also specify the offset in a memory channel >>>>>>> by adding an additional parameter before the options, >>>>>>> for example: >>>>>>> >>>>>>> 01 = 147.435,103.5,1035,h-t ; This would be for W6NUT in Los Angeles with input of 146.40 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> David >>>>>>> >>>>>>> On Sun, Dec 4, 2011 at 2:37 PM, Monty <monty(a)ke7jvx.com> wrote: >>>>>>> >>>>>>>> Hello Everyone, >>>>>>>> I have successfully integrated a Low Band Syntor X with an Xcat to >>>>>>>> app_rpt using CI-V. I have a problem though. There are currently 6 6m >>>>>>>> repeaters here in Arizona, 3 have 0.5 mhz split and the other 3 have 1 mhz >>>>>>>> splits. I have only been successful in programing the 0.5 split >>>>>>>> frequencies in App_Rpt memories. Is there a trick to make it split to 1 >>>>>>>> mhz or is that not possible? >>>>>>>> >>>>>>>> Monty >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> App_rpt-users mailing list >>>>>>>> App_rpt-users(a)ohnosec.org >>>>>>>> http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >

2 5

Echolink whitelist limitation
by GARY BONEBRAKE 16 Dec '11

16 Dec '11

I added the "permit=" statement at the end of echolink.conf to limit access to club members only. I did this to eliminate the plague of ungracious and irresponsible skimmers, dropins and lurkers. Refer to http://ohnosec.org/drupal/node/56 for details. However, I discovered that there is a limit on the number of entries in the "permit=" statement. If you add more than 30 calls, the system will disconnect after about 10 seconds and respond with an RTCP TIMEOUT . Multiple "permit=" statements do not work - only the first statement is acknowledged. [The limitation is in line 154 of chan_echolink.c - "#define EL_MAX_CALL_LIST 30"] If you know of an alternate method to create a lengthy whitelist for Echolink in app_rpt, please advise. Gary Bonebrake W5BI Emergency Coordinator Sandoval County NM ARES <mailto:w5bi@arrl.net> w5bi(a)nmscares.org

1 0

Voterboard
by Monty 16 Dec '11

16 Dec '11

Hello Everyone, I know the dsp hysterious squelch has problems with narrow band radios, such as 900 mhz, does the voter board have the same problem as well? Monty

2 3

Echolink files not found
by Fran 15 Dec '11

15 Dec '11

I have ACID installed and node is working fine however I went into the /usr/src/configs/examples/echolink directory but cannot find the examples files needed for echolink. Frank

2 1

Re; Iphone app?
by K&R Yoksh 15 Dec '11

15 Dec '11

> Date: Wed, 14 Dec 2011 07:02:58 -0900 > From: Mark Huelskoetter > To: Lu Vencl > Subject: Re: [App_rpt-users] Iphone app? > Message-ID: > > Just about any SIP phone software will work. I use Fring sometimes. I > just edit the sip settings to use Allstar to dial in, then all I have to > do > is dial my node #, enter my user password and choose which way to connect > Vox of manual. Best of luck. Is it possible to use DTMF to control your node if connected via SIP softphone? That might be a neat capability to have. 73. Kyle K0KN

3 2