Re: [App_rpt-users] URI-X Issues With New Raspbian build
So, I 'blew' the latest Stretch build into a new USB flash device... booted and tried to configure an existing node onto it on hardware that is known to work under prior. 1. ASL-MENU did NOT over-write the rpt.conf nor iax.conf files with given parameters - run as 'repeater' sudo root or enabled root user. FAIL. How is this fail 'possible' ? 2. Asterisk -rvvvvv... consistently revealed that the attached known interface did not exist and failed out with "...var/run/asterisk.ctl..." does not exist... when it actually does - what condition manifests this? NO low voltage errors on the console... all this on a known Pi3 AND RA-40 interface configuration under prior Jessie install... To this... after decades of WinTel system support and a variety of x-Nix support work... ... please understand I do NOT *want* to hint at, support, or indicate that 'Crompton' may be on to something because his builds aren't all that stable and documentation and support are no better an often wrong, accusational... but have not exhibited this level of 'stupid' non-function. I am also someone at the brunt of "it doesn't work" as an esclation point in massive enterprises, and can at least identify and analyze log files that may contain some hints... "give me (path)xxx log file..." and at least I provide or know full paths, not casual non-specific references. I would hope, expect the contributing community to be robust in definitive, helpful logging and not simply dismiss users to unqualified rhetoric/fault. That said...the latest Jessie build is a failure. The latest Stretch build is a failure. "change my mind" I'm back to tweaking the prior Jessie build to work as 'advertised' sans asl-menu and don't dare chance an upgrade/update process to the latest... I merely anticipate the coders know various failure conditions, can detect and log them... but that is an anticipation not rendered in actual logical recorded fact.| OK - get it - code contributors are volunteers. Volunteers that are supposedly intimate and knowledgeable with the code, functions, conditions, etc. Bad power (not evident), bad storage/boot device (not evident), yadda... so, what? If you cannot document the 'proper' necessary requirements for hardware, process, etc. you cannot hold us users accountable or nor unknown circumstances to blame for failures. This is logical, programmatic... SOMETHING can detect (or not) attached hardware and communications functions... but yet not tell us what part(s) failed? Certainly when a convenient configuration menu/utility cannot/will not write-out changed parameters - one can determine a file system or rights issue... and reveal same... not leaving the user with the deception the system is good to go when it is sitting there at useless defaults. We really do NOT want this project left to Crompton for the popular vote, nor the x-Nix elitists... it's much too good for either of that. I among others are willing to dig deep and provide any log files, etc. that are effective to supportive solutions. If logging content is ambiguous, not adequate to specific known logical issues, improve logging. If scripts do not work... let's debug... The leave behind is that if you were lucky enough to capture a prior Jesse build... sans asl-menu... stash it away and work around manual configs, leave it not user-friendly. If there are specific hardware, storage device requirements, document and better test for them. Obviously a current bootable latest Jessie build is NOT effective to new or existing node success. Why? Leave all of this to unstable, undocumented Crompton builds, or do equal or better... How can I/we help? -------------------Today's Topics: 1. Re: URI-X Issues With New Raspbian build (Steve Zingman) 2. Replay of June 26th Net at 8pm EDT (tonight) on 29999 (Mike) ---------------------------------------------------------------------- Message: 1 Date: Tue, 10 Jul 2018 15:31:47 -0400 From: Steve Zingman <szingman@msgstor.com> To: Users of Asterisk app_rpt <app_rpt-users@lists.allstarlink.org> Subject: Re: [App_rpt-users] URI-X Issues With New Raspbian build Message-ID: <b9e5a338-8b97-9d40-5a73-7a1757b76366@msgstor.com> Content-Type: text/plain; charset="utf-8"; Format="flowed" If I had to guess, I would say a bad SD card burn. or a bad card. Steve N4IRS
Could you state what the 'first few' commands are on 1st boot with your new image ? ...mike/kb8jnm On 7/11/2018 11:47 PM, Jim Aspinwall No1PC wrote:
So, I 'blew' the latest Stretch build into a new USB flash device... booted and tried to configure an existing node onto it on hardware that is known to work under prior.
1. ASL-MENU did NOT over-write the rpt.conf nor iax.conf files with given parameters - run as 'repeater' sudo root or enabled root user. FAIL. How is this fail 'possible' ?
2. Asterisk -rvvvvv... consistently revealed that the attached known interface did not exist and failed out with "...var/run/asterisk.ctl..." does not exist... when it actually does - what condition manifests this?
NO low voltage errors on the console... all this on a known Pi3 AND RA-40 interface configuration under prior Jessie install...
To this... after decades of WinTel system support and a variety of x-Nix support work...
... please understand I do NOT *want* to hint at, support, or indicate that 'Crompton' may be on to something because his builds aren't all that stable and documentation and support are no better an often wrong, accusational... but have not exhibited this level of 'stupid' non-function.
I am also someone at the brunt of "it doesn't work" as an esclation point in massive enterprises, and can at least identify and analyze log files that may contain some hints... "give me (path)xxx log file..." and at least I provide or know full paths, not casual non-specific references. I would hope, expect the contributing community to be robust in definitive, helpful logging and not simply dismiss users to unqualified rhetoric/fault.
That said...the latest Jessie build is a failure. The latest Stretch build is a failure. "change my mind"
I'm back to tweaking the prior Jessie build to work as 'advertised' sans asl-menu and don't dare chance an upgrade/update process to the latest...
I merely anticipate the coders know various failure conditions, can detect and log them... but that is an anticipation not rendered in actual logical recorded fact.|
OK - get it - code contributors are volunteers. Volunteers that are supposedly intimate and knowledgeable with the code, functions, conditions, etc. Bad power (not evident), bad storage/boot device (not evident), yadda... so, what?
If you cannot document the 'proper' necessary requirements for hardware, process, etc. you cannot hold us users accountable or nor unknown circumstances to blame for failures. This is logical, programmatic... SOMETHING can detect (or not) attached hardware and communications functions... but yet not tell us what part(s) failed?
Certainly when a convenient configuration menu/utility cannot/will not write-out changed parameters - one can determine a file system or rights issue... and reveal same... not leaving the user with the deception the system is good to go when it is sitting there at useless defaults.
We really do NOT want this project left to Crompton for the popular vote, nor the x-Nix elitists... it's much too good for either of that.
I among others are willing to dig deep and provide any log files, etc. that are effective to supportive solutions. If logging content is ambiguous, not adequate to specific known logical issues, improve logging. If scripts do not work... let's debug...
The leave behind is that if you were lucky enough to capture a prior Jesse build... sans asl-menu... stash it away and work around manual configs, leave it not user-friendly.
If there are specific hardware, storage device requirements, document and better test for them. Obviously a current bootable latest Jessie build is NOT effective to new or existing node success. Why?
Leave all of this to unstable, undocumented Crompton builds, or do equal or better...
How can I/we help?
------------------- Today's Topics:
1. Re: URI-X Issues With New Raspbian build (Steve Zingman) 2. Replay of June 26th Net at 8pm EDT (tonight) on 29999 (Mike)
----------------------------------------------------------------------
Message: 1 Date: Tue, 10 Jul 2018 15:31:47 -0400 From: Steve Zingman <szingman@msgstor.com <mailto:szingman@msgstor.com>> To: Users of Asterisk app_rpt <app_rpt-users@lists.allstarlink.org <mailto:app_rpt-users@lists.allstarlink.org>> Subject: Re: [App_rpt-users] URI-X Issues With New Raspbian build Message-ID: <b9e5a338-8b97-9d40-5a73-7a1757b76366@msgstor.com <mailto:b9e5a338-8b97-9d40-5a73-7a1757b76366@msgstor.com>> Content-Type: text/plain; charset="utf-8"; Format="flowed"
If I had to guess, I would say a bad SD card burn. or a bad card.
Steve N4IRS
_______________________________________________ App_rpt-users mailing list App_rpt-users@lists.allstarlink.org http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users
To unsubscribe from this list please visit http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.
Answers in-line.
On 7/11/2018 11:47 PM, Jim Aspinwall No1PC wrote:
So, I 'blew' the latest Stretch build into a new USB flash device... booted and tried to configure an existing node onto it on hardware that is known to work under prior. Lem me see if I understand, you blew which image on to a "new USB flash device"? what hardware did you try to boot? Do I understand that you tried to boot a "new USB flash device"
1. ASL-MENU did NOT over-write the rpt.conf nor iax.conf files with given parameters - run as 'repeater' sudo root or enabled root user. FAIL. How is this fail 'possible' ? I would guess possible with a bad disk.
2. Asterisk -rvvvvv... consistently revealed that the attached known interface did not exist and failed out with "...var/run/asterisk.ctl..." does not exist... when it actually does - what condition manifests this? Bad disk.
NO low voltage errors on the console... all this on a known Pi3 AND RA-40 interface configuration under prior Jessie install... Ah, so this is a Pi 3. OK, back to my first question. You blew the latest Raspbian image on to a "new USB flash device" and booted it in a Raspberry Pi 3?
To this... after decades of WinTel system support and a variety of x-Nix support work...
... please understand I do NOT *want* to hint at, support, or indicate that 'Crompton' may be on to something because his builds aren't all that stable and documentation and support are no better an often wrong, accusational... but have not exhibited this level of 'stupid' non-function This looks to me like a bad burn. to a "new USB flash device" I am also someone at the brunt of "it doesn't work" as an esclation point in massive enterprises, and can at least identify and analyze log files that may contain some hints... "give me (path)xxx log file..." and at least I provide or know full paths, not casual non-specific references. I would hope, expect the contributing community to be robust in definitive, helpful logging and not simply dismiss users to unqualified rhetoric/fault. OK, give me /var/log/syslog. /var/log/messages and /var/log/asterisk/messages.
That said...the latest Jessie build is a failure. The latest Stretch build is a failure. "change my mind" There are a LOT of ASL 1.01 installs on RPi hardware out in the field. If the image did not work we would know by now.
I'm back to tweaking the prior Jessie build to work as 'advertised' sans asl-menu and don't dare chance an upgrade/update process to the latest...
I merely anticipate the coders know various failure conditions, can detect and log them... but that is an anticipation not rendered in actual logical recorded fact. Show me /var/log/syslog and or /var/log/messages |
OK - get it - code contributors are volunteers. Volunteers that are supposedly intimate and knowledgeable with the code, functions, conditions, etc. Bad power (not evident), bad storage/boot device (not evident), yadda... so, what? Are you running with a screen connected to the HDMI port? Show me the /var/log/boot.log
If you cannot document the 'proper' necessary requirements for hardware, process, etc. you cannot hold us users accountable or nor unknown circumstances to blame for failures. This is logical, programmatic... SOMETHING can detect (or not) attached hardware and communications functions... but yet not tell us what part(s) failed? I'm betting either a bad SD card or take you at your word that you booted a RPi on a "new USB flash device"
Certainly when a convenient configuration menu/utility cannot/will not write-out changed parameters - one can determine a file system or rights issue... and reveal same... not leaving the user with the deception the system is good to go when it is sitting there at useless defaults.
We really do NOT want this project left to Crompton for the popular vote, nor the x-Nix elitists... it's much too good for either of that. I can see not wanting this left to others but what is a "x-Nix elitist"
I among others are willing to dig deep and provide any log files, etc. that are effective to supportive solutions. If logging content is ambiguous, not adequate to specific known logical issues, improve logging. If scripts do not work... let's debug... Happy to. Show me the log files
The leave behind is that if you were lucky enough to capture a prior Jesse build... sans asl-menu... stash it away and work around manual configs, leave it not user-friendly. There is a lot more to ASL 1.01 then the menus. That is not to say that Nate did not do a great job with the menus.
If there are specific hardware, storage device requirements, document and better test for them. Obviously a current bootable latest Jessie build is NOT effective to new or existing node success. Why? Still trying to figure out what hardware and boot device you are running.
Leave all of this to unstable, undocumented Crompton builds, or do equal or better...
How can I/we help? Give me SSH access to the machine. See below for my e-mail address.
Steve N4IRS
------------------- Today's Topics:
1. Re: URI-X Issues With New Raspbian build (Steve Zingman) 2. Replay of June 26th Net at 8pm EDT (tonight) on 29999 (Mike)
----------------------------------------------------------------------
Message: 1 Date: Tue, 10 Jul 2018 15:31:47 -0400 From: Steve Zingman <szingman@msgstor.com <mailto:szingman@msgstor.com>> To: Users of Asterisk app_rpt <app_rpt-users@lists.allstarlink.org <mailto:app_rpt-users@lists.allstarlink.org>> Subject: Re: [App_rpt-users] URI-X Issues With New Raspbian build Message-ID: <b9e5a338-8b97-9d40-5a73-7a1757b76366@msgstor.com <mailto:b9e5a338-8b97-9d40-5a73-7a1757b76366@msgstor.com>> Content-Type: text/plain; charset="utf-8"; Format="flowed"
If I had to guess, I would say a bad SD card burn. or a bad card.
Steve N4IRS
That's a lot of text I'm not going to fully read. I sense some frustration. *(Under statement/insert sarcasm)* First idea I have for you... Your "asterisk -rvvv" command is trying to connect with an already running instance of the asterisk service. That error message about "...var/run/asterisk.ctl..." does not exist... simply means that the service isn't online. You might try this command... "asterisk -cgvvv". I suspect you'll learn more about what's failing from that output. Here's a reference to the command line options... https://www.voip-info.org/asterisk-options PS: I know nothing about this build... Just some basic asterisk administration... Hope it helps you and you in turn pay it forward and help others. 73 - Good luck... NØNKI - Eric in Minneapolis Minnesota On Wed, Jul 11, 2018 at 10:47 PM, Jim Aspinwall No1PC <no1pc@yahoo.com> wrote:
So, I 'blew' the latest Stretch build into a new USB flash device... booted and tried to configure an existing node onto it on hardware that is known to work under prior.
1. ASL-MENU did NOT over-write the rpt.conf nor iax.conf files with given parameters - run as 'repeater' sudo root or enabled root user. FAIL. How is this fail 'possible' ?
2. Asterisk -rvvvvv... consistently revealed that the attached known interface did not exist and failed out with "...var/run/asterisk.ctl..." does not exist... when it actually does - what condition manifests this?
NO low voltage errors on the console... all this on a known Pi3 AND RA-40 interface configuration under prior Jessie install...
To this... after decades of WinTel system support and a variety of x-Nix support work...
... please understand I do NOT *want* to hint at, support, or indicate that 'Crompton' may be on to something because his builds aren't all that stable and documentation and support are no better an often wrong, accusational... but have not exhibited this level of 'stupid' non-function.
I am also someone at the brunt of "it doesn't work" as an esclation point in massive enterprises, and can at least identify and analyze log files that may contain some hints... "give me (path)xxx log file..." and at least I provide or know full paths, not casual non-specific references. I would hope, expect the contributing community to be robust in definitive, helpful logging and not simply dismiss users to unqualified rhetoric/fault.
That said...the latest Jessie build is a failure. The latest Stretch build is a failure. "change my mind"
I'm back to tweaking the prior Jessie build to work as 'advertised' sans asl-menu and don't dare chance an upgrade/update process to the latest...
I merely anticipate the coders know various failure conditions, can detect and log them... but that is an anticipation not rendered in actual logical recorded fact.|
OK - get it - code contributors are volunteers. Volunteers that are supposedly intimate and knowledgeable with the code, functions, conditions, etc. Bad power (not evident), bad storage/boot device (not evident), yadda... so, what?
If you cannot document the 'proper' necessary requirements for hardware, process, etc. you cannot hold us users accountable or nor unknown circumstances to blame for failures. This is logical, programmatic... SOMETHING can detect (or not) attached hardware and communications functions... but yet not tell us what part(s) failed?
Certainly when a convenient configuration menu/utility cannot/will not write-out changed parameters - one can determine a file system or rights issue... and reveal same... not leaving the user with the deception the system is good to go when it is sitting there at useless defaults.
We really do NOT want this project left to Crompton for the popular vote, nor the x-Nix elitists... it's much too good for either of that.
I among others are willing to dig deep and provide any log files, etc. that are effective to supportive solutions. If logging content is ambiguous, not adequate to specific known logical issues, improve logging. If scripts do not work... let's debug...
The leave behind is that if you were lucky enough to capture a prior Jesse build... sans asl-menu... stash it away and work around manual configs, leave it not user-friendly.
If there are specific hardware, storage device requirements, document and better test for them. Obviously a current bootable latest Jessie build is NOT effective to new or existing node success. Why?
Leave all of this to unstable, undocumented Crompton builds, or do equal or better...
How can I/we help?
------------------- Today's Topics:
1. Re: URI-X Issues With New Raspbian build (Steve Zingman) 2. Replay of June 26th Net at 8pm EDT (tonight) on 29999 (Mike)
----------------------------------------------------------------------
Message: 1 Date: Tue, 10 Jul 2018 15:31:47 -0400 From: Steve Zingman <szingman@msgstor.com> To: Users of Asterisk app_rpt <app_rpt-users@lists.allstarlink.org> Subject: Re: [App_rpt-users] URI-X Issues With New Raspbian build Message-ID: <b9e5a338-8b97-9d40-5a73-7a1757b76366@msgstor.com> Content-Type: text/plain; charset="utf-8"; Format="flowed"
If I had to guess, I would say a bad SD card burn. or a bad card.
Steve N4IRS
_______________________________________________ App_rpt-users mailing list App_rpt-users@lists.allstarlink.org http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users
To unsubscribe from this list please visit http://lists.allstarlink.org/ cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.
Eric, Good catch on the -rvvv. That's what I get for answering a e-mail at 04:30 AM. Steve On 7/12/2018 9:48 AM, Eric Osterberg wrote:
That's a lot of text I'm not going to fully read. I sense some frustration. /_(Under statement/insert sarcasm)
_/ First idea I have for you... Your "asterisk -rvvv" command is trying to connect with an already running instance of the asterisk service. That error message about "...var/run/asterisk.ctl..." does not exist... simply means that the service isn't online. You might try this command... "asterisk -cgvvv". I suspect you'll learn more about what's failing from that output.
Here's a reference to the command line options... https://www.voip-info.org/asterisk-options PS: I know nothing about this build... Just some basic asterisk administration... Hope it helps you and you in turn pay it forward and help others.
73 - Good luck... NØNKI - Eric in Minneapolis Minnesota
On Wed, Jul 11, 2018 at 10:47 PM, Jim Aspinwall No1PC <no1pc@yahoo.com <mailto:no1pc@yahoo.com>> wrote:
So, I 'blew' the latest Stretch build into a new USB flash device... booted and tried to configure an existing node onto it on hardware that is known to work under prior.
1. ASL-MENU did NOT over-write the rpt.conf nor iax.conf files with given parameters - run as 'repeater' sudo root or enabled root user. FAIL. How is this fail 'possible' ?
2. Asterisk -rvvvvv... consistently revealed that the attached known interface did not exist and failed out with "...var/run/asterisk.ctl..." does not exist... when it actually does - what condition manifests this?
NO low voltage errors on the console... all this on a known Pi3 AND RA-40 interface configuration under prior Jessie install...
To this... after decades of WinTel system support and a variety of x-Nix support work...
... please understand I do NOT *want* to hint at, support, or indicate that 'Crompton' may be on to something because his builds aren't all that stable and documentation and support are no better an often wrong, accusational... but have not exhibited this level of 'stupid' non-function.
I am also someone at the brunt of "it doesn't work" as an esclation point in massive enterprises, and can at least identify and analyze log files that may contain some hints... "give me (path)xxx log file..." and at least I provide or know full paths, not casual non-specific references. I would hope, expect the contributing community to be robust in definitive, helpful logging and not simply dismiss users to unqualified rhetoric/fault.
That said...the latest Jessie build is a failure. The latest Stretch build is a failure. "change my mind"
I'm back to tweaking the prior Jessie build to work as 'advertised' sans asl-menu and don't dare chance an upgrade/update process to the latest...
I merely anticipate the coders know various failure conditions, can detect and log them... but that is an anticipation not rendered in actual logical recorded fact.|
OK - get it - code contributors are volunteers. Volunteers that are supposedly intimate and knowledgeable with the code, functions, conditions, etc. Bad power (not evident), bad storage/boot device (not evident), yadda... so, what?
If you cannot document the 'proper' necessary requirements for hardware, process, etc. you cannot hold us users accountable or nor unknown circumstances to blame for failures. This is logical, programmatic... SOMETHING can detect (or not) attached hardware and communications functions... but yet not tell us what part(s) failed?
Certainly when a convenient configuration menu/utility cannot/will not write-out changed parameters - one can determine a file system or rights issue... and reveal same... not leaving the user with the deception the system is good to go when it is sitting there at useless defaults.
We really do NOT want this project left to Crompton for the popular vote, nor the x-Nix elitists... it's much too good for either of that.
I among others are willing to dig deep and provide any log files, etc. that are effective to supportive solutions. If logging content is ambiguous, not adequate to specific known logical issues, improve logging. If scripts do not work... let's debug...
The leave behind is that if you were lucky enough to capture a prior Jesse build... sans asl-menu... stash it away and work around manual configs, leave it not user-friendly.
If there are specific hardware, storage device requirements, document and better test for them. Obviously a current bootable latest Jessie build is NOT effective to new or existing node success. Why?
Leave all of this to unstable, undocumented Crompton builds, or do equal or better...
How can I/we help?
------------------- Today's Topics:
1. Re: URI-X Issues With New Raspbian build (Steve Zingman) 2. Replay of June 26th Net at 8pm EDT (tonight) on 29999 (Mike)
----------------------------------------------------------------------
Message: 1 Date: Tue, 10 Jul 2018 15:31:47 -0400 From: Steve Zingman <szingman@msgstor.com> To: Users of Asterisk app_rpt <app_rpt-users@lists.allstarlink.org> Subject: Re: [App_rpt-users] URI-X Issues With New Raspbian build Message-ID: <b9e5a338-8b97-9d40-5a73-7a1757b76366@msgstor.com> Content-Type: text/plain; charset="utf-8"; Format="flowed"
If I had to guess, I would say a bad SD card burn. or a bad card.
Steve N4IRS
_______________________________________________ App_rpt-users mailing list App_rpt-users@lists.allstarlink.org <http://allstarlink.org> http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users
To unsubscribe from this list please visit http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.
_______________________________________________ App_rpt-users mailing list App_rpt-users@lists.allstarlink.org http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users
To unsubscribe from this list please visit http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.
Ok, so I have gotten _somewhat_ passed the OSS kernel module requirement... now I see these in my events for asterisk (ASL) but it does open the DSP, I see that it is polling in the osspd output (no errors there) and the error from asterisk now is gone stating that it can't re-open DSP 1... [Jul 12 13:22:55] WARNING[1129]: chan_usbradio.c:2736 usbradio_read: Possibly stuck USB read channel. [usb] [Jul 12 13:22:55] WARNING[1129]: chan_usbradio.c:2739 usbradio_read: Nope, USB read channel [usb] wasn't stuck after all Those are the ASL/Asterisk warns being thrown now (at each poll) if anyone has any idears, I feel like I'm close to getting rid of the requirement of OSS! JJC N0PKT On Thu, Jul 12, 2018 at 9:24 AM ARS W5OMR <ars.w5omr@gmail.com> wrote:
On Thu, Jul 12, 2018, 08:50 Steve Zingman <szingman@msgstor.com> wrote:
Eric, Good catch on the -rvvv. That's what I get for answering a e-mail at 04:30 AM.
If he's trying to connect to a console, shouldn't it be -Rcvvvv ?
_______________________________________________ App_rpt-users mailing list App_rpt-users@lists.allstarlink.org http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users
To unsubscribe from this list please visit http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.
participants (6)
-
ARS W5OMR -
Eric Osterberg -
Jim Aspinwall No1PC -
JJC -
Mike -
Steve Zingman