sendpage-devel Mailing List for Sendpage
Brought to you by:
keescook
Menu
▾
▴
sendpage-devel — List for discussing sendpage use and development.
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
(10) |
May
(11) |
Jun
(5) |
Jul
(1) |
Aug
(35) |
Sep
(26) |
Oct
(15) |
Nov
(6) |
Dec
(17) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(27) |
Feb
(38) |
Mar
(10) |
Apr
(6) |
May
(34) |
Jun
(3) |
Jul
(7) |
Aug
(7) |
Sep
(5) |
Oct
(2) |
Nov
|
Dec
|
| 2002 |
Jan
(8) |
Feb
(2) |
Mar
(32) |
Apr
(6) |
May
(5) |
Jun
(1) |
Jul
(7) |
Aug
(26) |
Sep
(4) |
Oct
(11) |
Nov
(5) |
Dec
(4) |
| 2003 |
Jan
(15) |
Feb
(2) |
Mar
|
Apr
(1) |
May
(8) |
Jun
(4) |
Jul
(5) |
Aug
(5) |
Sep
(8) |
Oct
|
Nov
(4) |
Dec
(9) |
| 2004 |
Jan
(14) |
Feb
(1) |
Mar
(18) |
Apr
(4) |
May
(10) |
Jun
(6) |
Jul
|
Aug
(7) |
Sep
(11) |
Oct
(12) |
Nov
(11) |
Dec
(5) |
| 2005 |
Jan
(3) |
Feb
(22) |
Mar
(7) |
Apr
(19) |
May
(8) |
Jun
(3) |
Jul
(3) |
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
(1) |
| 2006 |
Jan
|
Feb
(7) |
Mar
(1) |
Apr
|
May
(4) |
Jun
(17) |
Jul
(2) |
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(7) |
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Walt W. <wd...@gm...> - 2012-03-21 19:38:01
|
Has anyone noticed that this has not been picked up by main stream media? http://articles.nydailynews.com/2012-03-04/news/31122324_1_white-boy-fire-tv-station |
|
From: Ahmed M. <ahm...@gm...> - 2011-08-11 20:06:49
|
Hi,
I'm currently unable to get page from sendpage. First I used qpage, it was
running perfect and no issues for receiving pages. As I tried to test
sendpage I was unable to send page. The configuration for qpage is listed
below;
#Administrators email
administrator=ac...@at...
#Make sure qpage can write to this dir.
queuedir=/var/spool/qpage
identtimeout=5
snpptimeout=60
modem=ttya
device=/dev/modem
initcmd=ATZ
initcmd=ATE1
service=abc
device=ttya
baudrate=9600
parity=none
maxtries=3
maxmsgsize=255
maxpages=9
allowpid=true
password=password
phone=9,18886561727
pager=User1
pagerid=11122233444
service=abc
As far this part of configuration is working in qpage. The configuration for
sendpage is listed below;
debug=true
queuedir = /var/spool/sendpage
syslog=true
syslog-facility=local6
syslog-minlevel=debug
snpp-port=444
snpp-addr=localhost
snpp-acl="127.0.0.1/255.255.255.255:ALLOW"
[modem:usr]
debug=true
dev=/dev/modem
data=8
parity=none
stop=1
baud=9600
dialwait=20
#init=ATZV1E1
#init=ATE +MS=v34,0
#init=ATZ
#init=ATZE1
#init=ATZQ0V1E1S0=0&C1&D2+FCLASS=0
#dial=ATDT
#dialout="9,"
#flow=soft
[pc:sprint]
enabled=true
debug=true
modems=usr
phonenum=9,18886561727
#stricttap=true
#proto=PG1
rundelay=10
[recip:abc]
dest = 11223344@sprint
After reloading logs I get is listed below;
Aug 11 15:43:26 rltd114 sendpage[20847]: initiating reload ...
Aug 11 15:43:26 rltd114 sendpage[20847]: Stopping 'att' ...
Aug 11 15:43:26 rltd114 sendpage[20847]: signalling 'QUIT' to pid '3797'
Aug 11 15:43:26 rltd114 sendpage[20847]: Stopping 'sprint' ...
Aug 11 15:43:26 rltd114 sendpage[20847]: signalling 'QUIT' to pid '3798'
Aug 11 15:43:26 rltd114 sendpage[20847]: Waiting for 2 PCs/SNPPs to die
off...
Aug 11 15:43:26 rltd114 sendpage[3797]: Shutting down nicely: 'att'
Aug 11 15:43:26 rltd114 sendpage[3797]: Queue runner for 'att' shutting down
Aug 11 15:43:26 rltd114 sendpage[3797]: PagingCentral object 'att' being
destroyed
Aug 11 15:43:26 rltd114 sendpage[3798]: Shutting down nicely: 'sprint'
Aug 11 15:43:26 rltd114 sendpage[3798]: Queue runner for 'sprint' shutting
down
Aug 11 15:43:26 rltd114 sendpage[3798]: PagingCentral object 'sprint' being
destroyed
Aug 11 15:43:26 rltd114 sendpage[20847]: Letting old PC 'sprint' rest in
peace
Aug 11 15:43:26 rltd114 sendpage[20847]: Letting old PC 'att' rest in peace
Aug 11 15:43:26 rltd114 sendpage[20847]: Reinitializing...
Aug 11 15:43:26 rltd114 sendpage[20847]: found listing for modem: usr
Aug 11 15:43:26 rltd114 sendpage[20847]: found listing for pc: att
Aug 11 15:43:26 rltd114 sendpage[20847]: found listing for pc: sprint
Aug 11 15:43:26 rltd114 sendpage[20847]: Locking with '/var/lock/LCK..modem'
...
Aug 11 15:43:26 rltd114 sendpage[20847]: Modem 'usr' setting 'Baud': '9600'
Aug 11 15:43:26 rltd114 sendpage[20847]: Modem 'usr' setting 'Parity':
'none'
Aug 11 15:43:26 rltd114 sendpage[20847]: Modem 'usr' setting 'StrictParity':
'0'
Aug 11 15:43:26 rltd114 sendpage[20847]: Modem 'usr' setting 'Data': '8'
Aug 11 15:43:26 rltd114 sendpage[20847]: Modem 'usr' setting 'Stop': '1'
Aug 11 15:43:26 rltd114 sendpage[20847]: Modem 'usr' setting 'Flow': 'rts'
Aug 11 15:43:26 rltd114 sendpage[20847]: Modem 'usr' setting 'Init':
'ATZQ0V1E1S0=0&C1&D2+FCLASS=0'
Aug 11 15:43:26 rltd114 sendpage[20847]: Modem 'usr' setting 'InitOK': 'OK'
Aug 11 15:43:26 rltd114 sendpage[20847]: Modem 'usr' setting 'InitWait': '4'
Aug 11 15:43:26 rltd114 sendpage[20847]: Modem 'usr' setting 'InitRetry':
'2'
Aug 11 15:43:26 rltd114 sendpage[20847]: Modem 'usr' setting 'Error':
'ERROR'
Aug 11 15:43:26 rltd114 sendpage[20847]: Modem 'usr' setting 'Dial': 'ATDT'
' g 11 15:43:26 rltd114 sendpage[20847]: Modem 'usr' setting 'DialOK':
'CONNECT.*
Aug 11 15:43:26 rltd114 sendpage[20847]: Modem 'usr' setting 'DialWait':
'20'
Aug 11 15:43:26 rltd114 sendpage[20847]: Modem 'usr' setting 'DialRetry':
'3'
Aug 11 15:43:26 rltd114 sendpage[20847]: Modem 'usr' setting 'NoCarrier':
'ERROR|NO CARRIER|BUSY|NO DIAL|VOICE'
Aug 11 15:43:26 rltd114 sendpage[20847]: Modem 'usr' setting
'CarrierDetect': 'on'
Aug 11 15:43:26 rltd114 sendpage[20847]: Modem 'usr' setting
'DTRToggleTime': '0.5'
Aug 11 15:43:26 rltd114 sendpage[20847]: Modem 'usr' setting 'LongDist': '1'
Aug 11 15:43:26 rltd114 sendpage[20847]: Modem 'usr' setting 'DialOut': ''
Aug 11 15:43:26 rltd114 sendpage[20847]: baud requested: '9600' baud set:
'9600'
Aug 11 15:43:26 rltd114 sendpage[20847]: parity requested: 'none' parity
set: 'none'
Aug 11 15:43:26 rltd114 sendpage[20847]: databits requested: '8' databits
set: '8'
Aug 11 15:43:26 rltd114 sendpage[20847]: stopbits requested: '1' stopbits
set: '1'
Aug 11 15:43:26 rltd114 sendpage[20847]: flow requested: 'rts' flow set:
'rts'
Aug 11 15:43:26 rltd114 sendpage[20847]: reseting DTR ...
Aug 11 15:43:27 rltd114 sendpage[20847]: forcing RTS ...
Aug 11 15:43:27 rltd114 sendpage[20847]: to send: ATZ{0x0D}
Aug 11 15:43:27 rltd114 sendpage[20847]: want: OK
Aug 11 15:43:27 rltd114 sendpage[20847]: kicker: ATZ{0x0D}
Aug 11 15:43:27 rltd114 sendpage[20847]: timeout: 4 retries: 2
Aug 11 15:43:27 rltd114 sendpage[20847]: have:
Aug 11 15:43:27 rltd114 sendpage[20847]: wrote: 29
ATZQ0V1E1S0=0&C1&D2+FCLASS=0{0x0D}
Aug 11 15:43:27 rltd114 sendpage[20847]: 6 seen: {0x0D}{0x0A}OK{0x0D}{0x0A}
Aug 11 15:43:27 rltd114 sendpage[20847]: have: {0x0D}{0x0A}OK{0x0D}{0x0A}
Aug 11 15:43:27 rltd114 sendpage[20847]: chat success: OK
Aug 11 15:43:27 rltd114 sendpage[20847]: Modem Object 'usr' being destroyed
Aug 11 15:43:27 rltd114 sendpage[20847]: unlocking Modem 'usr'
Aug 11 15:43:27 rltd114 sendpage[20847]: Modem Object 'usr' destroyed
Aug 11 15:43:27 rltd114 sendpage[20847]: found functioning modem: usr
Aug 11 15:43:27 rltd114 sendpage[20847]: starting Queue Manager (sendpage
v1.0.3)
Aug 11 15:43:27 rltd114 sendpage[3881]: I am child: 3881 for PC 'att'
Aug 11 15:43:27 rltd114 sendpage[3881]: 0: open
Aug 11 15:43:27 rltd114 sendpage[3881]: 2: open
Aug 11 15:43:27 rltd114 sendpage[3881]: 3: open
Aug 11 15:43:27 rltd114 sendpage[20847]: spawned child: 3881 for PC 'att'
Aug 11 15:43:27 rltd114 sendpage[3881]: starting queue runs for 'att'
Aug 11 15:43:27 rltd114 sendpage[3882]: I am child: 3882 for PC 'sprint'
Aug 11 15:43:27 rltd114 sendpage[3882]: 0: open
Aug 11 15:43:27 rltd114 sendpage[3882]: 2: open
Aug 11 15:43:27 rltd114 sendpage[3882]: 3: open
Aug 11 15:43:27 rltd114 sendpage[3882]: starting queue runs for 'sprint'
Aug 11 15:43:27 rltd114 sendpage[20847]: spawned child: 3882 for PC 'sprint'
Aug 11 15:43:27 rltd114 sendpage[20847]: starting SNPP listeners
Aug 11 15:43:27 rltd114 sendpage[20847]: select loop failed: Illegal seek
To send a page I issue command as listed below;
sendpage -d -f sendpage -m 'hello again' abc
OR
sendpage -d -f sendpage -m 'hello again' 11223344@sprint
And the logs after executing the command I'm getting is listed below;
Aug 11 15:46:09 rltd114 sendpage[4007]: Locking with '/var/lock/LCK..modem'
...
Aug 11 15:46:09 rltd114 sendpage[4007]: Modem 'usr' setting 'Baud': '9600'
Aug 11 15:46:09 rltd114 sendpage[4007]: Modem 'usr' setting 'Parity': 'none'
Aug 11 15:46:09 rltd114 sendpage[4007]: Modem 'usr' setting 'StrictParity':
'0'
Aug 11 15:46:09 rltd114 sendpage[4007]: Modem 'usr' setting 'Data': '8'
Aug 11 15:46:09 rltd114 sendpage[4007]: Modem 'usr' setting 'Stop': '1'
Aug 11 15:46:09 rltd114 sendpage[4007]: Modem 'usr' setting 'Flow': 'rts'
Aug 11 15:46:09 rltd114 sendpage[4007]: Modem 'usr' setting 'Init': 'ATZ'
Aug 11 15:46:09 rltd114 sendpage[4007]: Modem 'usr' setting 'InitOK': 'OK'
Aug 11 15:46:09 rltd114 sendpage[4007]: Modem 'usr' setting 'InitWait': '4'
Aug 11 15:46:09 rltd114 sendpage[4007]: Modem 'usr' setting 'InitRetry': '2'
Aug 11 15:46:09 rltd114 sendpage[4007]: Modem 'usr' setting 'Error': 'ERROR'
Aug 11 15:46:09 rltd114 sendpage[4007]: Modem 'usr' setting 'Dial': 'ATDT'
' g 11 15:46:09 rltd114 sendpage[4007]: Modem 'usr' setting 'DialOK':
'CONNECT.*
Aug 11 15:46:09 rltd114 sendpage[4007]: Modem 'usr' setting 'DialWait': '20'
Aug 11 15:46:09 rltd114 sendpage[4007]: Modem 'usr' setting 'DialRetry': '3'
Aug 11 15:46:09 rltd114 sendpage[4007]: Modem 'usr' setting 'NoCarrier':
'ERROR|NO CARRIER|BUSY|NO DIAL|VOICE'
Aug 11 15:46:09 rltd114 sendpage[4007]: Modem 'usr' setting 'CarrierDetect':
'on'
Aug 11 15:46:09 rltd114 sendpage[4007]: Modem 'usr' setting 'DTRToggleTime':
'0.5'
Aug 11 15:46:09 rltd114 sendpage[4007]: Modem 'usr' setting 'LongDist': '1'
Aug 11 15:46:09 rltd114 sendpage[4007]: Modem 'usr' setting 'DialOut': ''
Aug 11 15:46:09 rltd114 sendpage[4007]: baud requested: '9600' baud set:
'9600'
Aug 11 15:46:09 rltd114 sendpage[4007]: parity requested: 'none' parity set:
'none'
Aug 11 15:46:09 rltd114 sendpage[4007]: databits requested: '8' databits
set: '8'
Aug 11 15:46:09 rltd114 sendpage[4007]: stopbits requested: '1' stopbits
set: '1'
Aug 11 15:46:09 rltd114 sendpage[4007]: flow requested: 'rts' flow set:
'rts'
Aug 11 15:46:09 rltd114 sendpage[4007]: reseting DTR ...
Aug 11 15:46:10 rltd114 sendpage[4007]: forcing RTS ...
Aug 11 15:46:10 rltd114 sendpage[4007]: to send: ATZ{0x0D}
Aug 11 15:46:10 rltd114 sendpage[4007]: want: OK
Aug 11 15:46:10 rltd114 sendpage[4007]: kicker: ATZ{0x0D}
Aug 11 15:46:10 rltd114 sendpage[4007]: timeout: 4 retries: 2
Aug 11 15:46:10 rltd114 sendpage[4007]: have:
Aug 11 15:46:10 rltd114 sendpage[4007]: wrote: 4 ATZ{0x0D}
Aug 11 15:46:10 rltd114 sendpage[4007]: 6 seen: {0x0D}{0x0A}OK{0x0D}{0x0A}
Aug 11 15:46:10 rltd114 sendpage[4007]: have: {0x0D}{0x0A}OK{0x0D}{0x0A}
Aug 11 15:46:10 rltd114 sendpage[4007]: chat success: OK
Aug 11 15:46:10 rltd114 sendpage[4007]: Calling with Num: '9,18886561727'
Aug 11 15:46:10 rltd114 sendpage[4007]: to send:
ATDT9,18886561727{0x0D}
Aug 11 15:46:10 rltd114 sendpage[4007]: want: CONNECT.*{0x0D}
Aug 11 15:46:10 rltd114 sendpage[4007]: kicker:
Aug 11 15:46:10 rltd114 sendpage[4007]: timeout: 20 retries: 1
Aug 11 15:46:10 rltd114 sendpage[4007]: have: {0x0D}{0x0A}
Aug 11 15:46:10 rltd114 sendpage[4007]: wrote: 18 ATDT9,18886561727{0x0D}
Aug 11 15:46:10 rltd114 sendpage[4007]: (timeout: 0/20, retries: 0/1)
Aug 11 15:46:10 rltd114 sendpage[4007]: 6 seen: {0x0D}{0x0A}OK{0x0D}{0x0A}
Aug 11 15:46:10 rltd114 sendpage[4007]: have:
{0x0D}{0x0A}{0x0D}{0x0A}OK{0x0D}{0x0A}
Aug 11 15:46:11 rltd114 sendpage[4007]: (timeout: 1/20, retries: 0/1)
Aug 11 15:46:12 rltd114 sendpage[4007]: (timeout: 2/20, retries: 0/1)
Aug 11 15:46:13 rltd114 sendpage[4007]: (timeout: 3/20, retries: 0/1)
Aug 11 15:46:14 rltd114 sendpage[4007]: (timeout: 4/20, retries: 0/1)
Aug 11 15:46:15 rltd114 sendpage[4007]: (timeout: 5/20, retries: 0/1)
Aug 11 15:46:16 rltd114 sendpage[4007]: (timeout: 6/20, retries: 0/1)
Aug 11 15:46:17 rltd114 sendpage[4007]: (timeout: 7/20, retries: 0/1)
Aug 11 15:46:18 rltd114 sendpage[4007]: (timeout: 8/20, retries: 0/1)
Aug 11 15:46:19 rltd114 sendpage[4007]: (timeout: 9/20, retries: 0/1)
Aug 11 15:46:20 rltd114 sendpage[4007]: (timeout: 10/20, retries: 0/1)
Aug 11 15:46:21 rltd114 sendpage[4007]: (timeout: 11/20, retries: 0/1)
Aug 11 15:46:22 rltd114 sendpage[4007]: (timeout: 12/20, retries: 0/1)
Aug 11 15:46:23 rltd114 sendpage[4007]: (timeout: 13/20, retries: 0/1)
Aug 11 15:46:24 rltd114 sendpage[4007]: (timeout: 14/20, retries: 0/1)
Aug 11 15:46:25 rltd114 sendpage[4007]: (timeout: 15/20, retries: 0/1)
Aug 11 15:46:26 rltd114 sendpage[4007]: (timeout: 16/20, retries: 0/1)
Aug 11 15:46:27 rltd114 sendpage[4007]: (timeout: 17/20, retries: 0/1)
Aug 11 15:46:28 rltd114 sendpage[4007]: (timeout: 18/20, retries: 0/1)
Aug 11 15:46:29 rltd114 sendpage[4007]: (timeout: 19/20, retries: 0/1)
Aug 11 15:46:30 rltd114 sendpage[4007]: chat failed
Aug 11 15:46:30 rltd114 sendpage[4007]: Failed to dial modem
Aug 11 15:46:30 rltd114 sendpage[4007]: Modem Object 'usr' being destroyed
Aug 11 15:46:30 rltd114 sendpage[4007]: unlocking Modem 'usr'
Aug 11 15:46:30 rltd114 sendpage[4007]: Modem Object 'usr' destroyed
Aug 11 15:46:30 rltd114 sendpage[4007]: proto startup failed (Could not dial
out)
Aug 11 15:46:30 rltd114 sendpage[4007]: sprint/q131309196404010000:
state=Temp-Failure, to=ahmed, from=sendpage, size=11, PC=Could not dial out
Aug 11 15:46:30 rltd114 sendpage[4007]: sprint: rewriting page to queue
Even I tried to change its parity bits and init but unable to send a page
and the end I getting message "Failed to dial modem", "proto startup failed
(Could not dial out)" and "sprint/q131309196404010000: state=Temp-Failure,
to=ahmed, from=sendpage, size=11, PC=Could not dial out".
Please advice to resolve this issue.
Note: With using parity=none on qpage I was able to send a page via AT&T and
Sprint.
--
Regards,
Ahmed Munir Chohan
|
|
From: Ahmed M. <ahm...@gm...> - 2011-06-07 18:02:50
|
Hi, Quite a while ago, I've tested out sendpage using usb modem (usrobotics) and worked perfectly. Now the thing I would like to know which modem card/hardware will you all recommend for PRI T1? Because now I'm planing to use PRI T1 instead of using 24 bundle of telephones lines for sending out paging messages to the pagers. Please do advise at earliest. -- Regards, Ahmed Munir |
|
From: Peter S. <Peter.Smith@UTSouthwestern.edu> - 2009-09-16 19:04:53
|
Sorry I wasn't watching the thread too closely. That's good news that you figured out a solution. If your modem can discern voice, then I believe you can just make sure that its response code set includes the VOICE responses, and it will likely get logged. X6 perhaps? Peter |
|
From: Walt W. <wd...@gm...> - 2009-09-16 18:31:18
|
Is there any method that could be added in the debug logs that would indicate if the phone line were not answered by another computer? i.e Someone puts in a direct pager number and an auto-attendant answers. That way it would be much easier to notice if the paging center number is not used. Thanks, Walt On Wed, Sep 16, 2009 at 6:38 AM, Walt Wyndroski <WDW> wrote: > Hey Peter, it takes a man to admit when the problem was on his side and > that's what I'm doing. Though I had a correct paging number, the required > paging center number for my service was incorrect. :( /cry. Next I'll have > to check my companies pager records more closely. > > However, it did give me a chance a read through some of the Perl code and > learn a lot about serial I/O with Perl. :) There's an upside to everything > if you look. > > Anyway, I want to give a big thanks to the developers for such robust and > great opensource code! > > Walt > > > On Tue, Sep 15, 2009 at 9:30 AM, Walt Wyndroski <WDW> wrote: > >> Hello there all. >> >> 1) I have RHEL5 64 bit running on a Dell server. The server has an >> internal PCIE 56k faxmodem. I also tried an external USR Sportster modem. >> >> 2) I am able to cleanly install the sendpage package with the required >> Perl modules. The daemon starts up correctly and accepts pages correctly >> from the command line and my Zenoss monitoring server. >> >> 3) Everything works fine until sendpage proceeds to dial. I get the >> following error message: >> sendpage[30748]: Failed to dial modem >> sendpage[30748]: proto startup failed (Could not dial out) >> >> 4) I am able to dial my office phone through either modem with minicom. I >> know both modems work. I've tried uninstalling and reinstalling. I've even >> read the Perl code hoping I might find something to indicate a had a system >> issue. The modemtest perl script appears to be successful when running. I've >> included an abbreviated config below. >> >> [modem:sportster] >> dev=/dev/modem >> baud=2400 >> areacode=555 >> dialwait=20 >> [pc:propage] >> phonenum=1234567 >> #stricttap=true >> [recip:pager_wdw] >> dest = @propage >> I would greatly appreciate any help. Thanks in advance! >> >> WDW >> > > |
|
From: Walt W. <wd...@gm...> - 2009-09-16 10:38:48
|
Hey Peter, it takes a man to admit when the problem was on his side and that's what I'm doing. Though I had a correct paging number, the required paging center number for my service was incorrect. :( /cry. Next I'll have to check my companies pager records more closely. However, it did give me a chance a read through some of the Perl code and learn a lot about serial I/O with Perl. :) There's an upside to everything if you look. Anyway, I want to give a big thanks to the developers for such robust and great opensource code! Walt On Tue, Sep 15, 2009 at 9:30 AM, Walt Wyndroski <WDW> wrote: > Hello there all. > > 1) I have RHEL5 64 bit running on a Dell server. The server has an internal > PCIE 56k faxmodem. I also tried an external USR Sportster modem. > > 2) I am able to cleanly install the sendpage package with the required Perl > modules. The daemon starts up correctly and accepts pages correctly from the > command line and my Zenoss monitoring server. > > 3) Everything works fine until sendpage proceeds to dial. I get the > following error message: > sendpage[30748]: Failed to dial modem > sendpage[30748]: proto startup failed (Could not dial out) > > 4) I am able to dial my office phone through either modem with minicom. I > know both modems work. I've tried uninstalling and reinstalling. I've even > read the Perl code hoping I might find something to indicate a had a system > issue. The modemtest perl script appears to be successful when running. I've > included an abbreviated config below. > > [modem:sportster] > dev=/dev/modem > baud=2400 > areacode=555 > dialwait=20 > [pc:propage] > phonenum=1234567 > #stricttap=true > [recip:pager_wdw] > dest = @propage > I would greatly appreciate any help. Thanks in advance! > > WDW > |
|
From: Walt W. <wd...@gm...> - 2009-09-16 03:46:28
|
I tried the init string below and got the same results. However I get an
'OK' if I issue it from minicom. I now have all the debug logging enabled.
Here is a snippet of the start up:
Tue Sep 15 23:24:05 2009 [32767 info]: baud requested: '9600' baud set:
'9600'
Tue Sep 15 23:24:05 2009 [32767 info]: parity requested: 'even' parity set:
'even'
Tue Sep 15 23:24:05 2009 [32767 info]: databits requested: '7' databits set:
'7'
Tue Sep 15 23:24:05 2009 [32767 info]: stopbits requested: '1' stopbits set:
'1'
Tue Sep 15 23:24:05 2009 [32767 info]: flow requested: 'rts' flow set: 'rts'
Tue Sep 15 23:24:05 2009 [32767 info]: reseting DTR ...
Tue Sep 15 23:24:05 2009 [32767 info]: forcing RTS ...
Tue Sep 15 23:24:05 2009 [32767 info]: to send: ATZ{0x0D}
Tue Sep 15 23:24:05 2009 [32767 info]: want: OK
Tue Sep 15 23:24:05 2009 [32767 info]: kicker: ATZ{0x0D}
Tue Sep 15 23:24:05 2009 [32767 info]: timeout: 4 retries: 2
Tue Sep 15 23:24:05 2009 [32767 info]: have:
Tue Sep 15 23:24:05 2009 [32767 info]: wrote: 4 ATZ{0x0D}
Tue Sep 15 23:24:05 2009 [32767 info]: 1 seen: A
Tue Sep 15 23:24:05 2009 [32767 info]: have: A
Tue Sep 15 23:24:05 2009 [32767 info]: (timeout: 0/4, retries: 0/2)
Tue Sep 15 23:24:06 2009 [32767 info]: 9 seen:
TZ{0x0D}{0x0D}{0x0A}OK{0x0D}{0x0A}
Tue Sep 15 23:24:06 2009 [32767 info]: have:
ATZ{0x0D}{0x0D}{0x0A}OK{0x0D}{0x0A}
Tue Sep 15 23:24:06 2009 [32767 info]: chat success: OK
Tue Sep 15 23:24:06 2009 [32767 info]: Modem Object 'sportster' being
destroyed
Tue Sep 15 23:24:06 2009 [32767 info]: unlocking Modem 'sportster'
Tue Sep 15 23:24:06 2009 [32767 info]: Modem Object 'sportster' destroyed
Tue Sep 15 23:24:06 2009 [32767 info]: found functioning modem: sportster
Here is a snippet after I issue snpp from the command line: (I replaced the
10 digit number with @'s)
Sep 15 23:41:08 nms sendpage[1586]: QueueRun requested for 'propage' ...
Sep 15 23:41:08 nms sendpage[1586]: Locking with '/var/lock/LCK..modem' ...
Sep 15 23:41:08 nms sendpage[1586]: Modem 'sportster' setting 'Baud': '9600'
Sep 15 23:41:08 nms sendpage[1586]: Modem 'sportster' setting 'Parity':
'even'
Sep 15 23:41:08 nms sendpage[1586]: Modem 'sportster' setting
'StrictParity': '0'
Sep 15 23:41:08 nms sendpage[1586]: Modem 'sportster' setting 'Data': '7'
Sep 15 23:41:08 nms sendpage[1586]: Modem 'sportster' setting 'Stop': '1'
Sep 15 23:41:08 nms sendpage[1586]: Modem 'sportster' setting 'Flow': 'rts'
Sep 15 23:41:08 nms sendpage[1586]: Modem 'sportster' setting 'Init':
'ATZwwww&Q6S11=40S7=20M0'
Sep 15 23:41:08 nms sendpage[1586]: Modem 'sportster' setting 'InitOK': 'OK'
Sep 15 23:41:08 nms sendpage[1586]: Modem 'sportster' setting 'InitWait':
'4'
Sep 15 23:41:08 nms sendpage[1586]: Modem 'sportster' setting 'InitRetry':
'2'
Sep 15 23:41:08 nms sendpage[1586]: Modem 'sportster' setting 'Error':
'ERROR'
Sep 15 23:41:08 nms sendpage[1586]: Modem 'sportster' setting 'Dial': 'ATDT'
' p 15 23:41:08 nms sendpage[1586]: Modem 'sportster' setting 'DialOK':
'CONNECT.*
Sep 15 23:41:08 nms sendpage[1586]: Modem 'sportster' setting 'DialWait':
'60'
Sep 15 23:41:08 nms sendpage[1586]: Modem 'sportster' setting 'DialRetry':
'3'
Sep 15 23:41:08 nms sendpage[1586]: Modem 'sportster' setting 'NoCarrier':
'ERROR|NO CARRIER|BUSY|NO DIAL|VOICE'
Sep 15 23:41:08 nms sendpage[1586]: Modem 'sportster' setting
'CarrierDetect': 'on'
Sep 15 23:41:08 nms sendpage[1586]: Modem 'sportster' setting
'DTRToggleTime': '0.5'
Sep 15 23:41:08 nms sendpage[1586]: Modem 'sportster' setting 'AreaCode':
'-'
Sep 15 23:41:08 nms sendpage[1586]: Modem 'sportster' setting 'LongDist':
'1'
Sep 15 23:41:08 nms sendpage[1586]: Modem 'sportster' setting 'DialOut': ''
Sep 15 23:41:08 nms sendpage[1586]: baud requested: '9600' baud set: '9600'
Sep 15 23:41:08 nms sendpage[1586]: parity requested: 'even' parity set:
'even'
Sep 15 23:41:08 nms sendpage[1586]: databits requested: '7' databits set:
'7'
Sep 15 23:41:08 nms sendpage[1586]: stopbits requested: '1' stopbits set:
'1'
Sep 15 23:41:08 nms sendpage[1586]: flow requested: 'rts' flow set: 'rts'
Sep 15 23:41:08 nms sendpage[1586]: reseting DTR ...
Sep 15 23:41:09 nms sendpage[1586]: forcing RTS ...
Sep 15 23:41:09 nms sendpage[1586]: to send:
ATZwwww&Q6S11=40S7=20M0{0x0D}
Sep 15 23:41:09 nms sendpage[1586]: want: OK
Sep 15 23:41:09 nms sendpage[1586]: kicker:
ATZwwww&Q6S11=40S7=20M0{0x0D}
Sep 15 23:41:09 nms sendpage[1586]: timeout: 4 retries: 2
Sep 15 23:41:09 nms sendpage[1586]: have:
Sep 15 23:41:09 nms sendpage[1586]: wrote: 24 ATZwwww&Q6S11=40S7=20M0{0x0D}
Sep 15 23:41:09 nms sendpage[1586]: 17 seen: ATZwwww&Q6S11=40S
Sep 15 23:41:09 nms sendpage[1586]: have: ATZwwww&Q6S11=40S
Sep 15 23:41:09 nms sendpage[1586]: (timeout: 0/4, retries: 0/2)
Sep 15 23:41:09 nms sendpage[1585]: SNPP connection (pid 1588) finished
Sep 15 23:41:09 nms sendpage[1586]: 13 seen:
7=20M0{0x0D}{0x0D}{0x0A}OK{0x0D}{0x0A}
Sep 15 23:41:09 nms sendpage[1586]: have:
ATZwwww&Q6S11=40S7=20M0{0x0D}{0x0D}{0x0A}OK{0x0D}{0x0A}
Sep 15 23:41:09 nms sendpage[1586]: chat success: OK
Sep 15 23:41:09 nms sendpage[1586]: Calling with Num: '@@@@@@@@@@'
Sep 15 23:41:09 nms sendpage[1586]: to send: ATDT@@@@@@@@@@{0x0D}
Sep 15 23:41:09 nms sendpage[1586]: want: CONNECT.*{0x0D}
Sep 15 23:41:09 nms sendpage[1586]: kicker:
Sep 15 23:41:09 nms sendpage[1586]: timeout: 60 retries: 1
Sep 15 23:41:09 nms sendpage[1586]: have: {0x0D}{0x0A}
Sep 15 23:41:09 nms sendpage[1586]: wrote: 15 ATDT@@@@@@@@@@{0x0D}
Sep 15 23:41:09 nms sendpage[1586]: 15 seen: ATDT@@@@@@@@@@{0x0D}
Sep 15 23:41:09 nms sendpage[1586]: have: {0x0D}{0x0A}ATDT@@@@@@@@@@{0x0D}
Sep 15 23:41:09 nms sendpage[1586]: (timeout: 0/60, retries: 0/1)
Sep 15 23:41:10 nms sendpage[1586]: (timeout: 1/60, retries: 0/1)
Sep 15 23:41:11 nms sendpage[1586]: (timeout: 2/60, retries: 0/1)
Sep 15 23:41:12 nms sendpage[1586]: (timeout: 3/60, retries: 0/1)
Sep 15 23:41:13 nms sendpage[1586]: (timeout: 4/60, retries: 0/1)
Sep 15 23:41:14 nms sendpage[1586]: (timeout: 5/60, retries: 0/1)
Sep 15 23:41:15 nms sendpage[1586]: (timeout: 6/60, retries: 0/1)
Sep 15 23:41:16 nms sendpage[1586]: (timeout: 7/60, retries: 0/1)
Sep 15 23:41:17 nms sendpage[1586]: (timeout: 8/60, retries: 0/1)
Sep 15 23:41:18 nms sendpage[1586]: (timeout: 9/60, retries: 0/1)
Sep 15 23:41:19 nms sendpage[1586]: (timeout: 10/60, retries: 0/1)
Sep 15 23:41:20 nms sendpage[1586]: (timeout: 11/60, retries: 0/1)
Sep 15 23:41:21 nms sendpage[1586]: (timeout: 12/60, retries: 0/1)
Sep 15 23:41:22 nms sendpage[1586]: (timeout: 13/60, retries: 0/1)
Sep 15 23:41:23 nms sendpage[1586]: (timeout: 14/60, retries: 0/1)
Sep 15 23:41:24 nms sendpage[1586]: (timeout: 15/60, retries: 0/1)
Thanks again for your help.
Walt
On Tue, Sep 15, 2009 at 11:59 AM, Walt Wyndroski <WDW> wrote:
> I actually had already tried that. Knowing that it defaulted to init=ATZ, I
> mannually inserted that anyway with the same results. I also copied the init
> string from minicom with the same results.
>
> Walt
>
> On Tue, Sep 15, 2009 at 10:38 AM, Peter Smith <
> Pet...@ut...> wrote:
>
>> Have you tried adding an "init=" entry to your "[modem:]" section?
>> Perhaps just put in a reset, like "init=ATZ". Mine use the following, but
>> really I don't think it is *much* more than a reset.
>> "init=ATZwwww&Q6S11=40S7=20M0"
>>
>> Peter
>>
>> >>> WDW >>>
>> Hello there all.
>>
>> 1) I have RHEL5 64 bit running on a Dell server. The server has an
>> internal
>> PCIE 56k faxmodem. I also tried an external USR Sportster modem.
>> <snip>
>>
>> WDW
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry® Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and stay
>> ahead of the curve. Join us from November 9-12, 2009. Register
>> now!
>> http://p.sf.net/sfu/devconf
>> _______________________________________________
>> sendpage-devel mailing list
>> sen...@li...
>> https://lists.sourceforge.net/lists/listinfo/sendpage-devel
>>
>
>
|
|
From: Walt W. <wd...@gm...> - 2009-09-15 15:59:42
|
I actually had already tried that. Knowing that it defaulted to init=ATZ, I mannually inserted that anyway with the same results. I also copied the init string from minicom with the same results. Walt On Tue, Sep 15, 2009 at 10:38 AM, Peter Smith < Pet...@ut...> wrote: > Have you tried adding an "init=" entry to your "[modem:]" section? Perhaps > just put in a reset, like "init=ATZ". Mine use the following, but really I > don't think it is *much* more than a reset. "init=ATZwwww&Q6S11=40S7=20M0" > > Peter > > >>> WDW >>> > Hello there all. > > 1) I have RHEL5 64 bit running on a Dell server. The server has an internal > PCIE 56k faxmodem. I also tried an external USR Sportster modem. > <snip> > > WDW > > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > sendpage-devel mailing list > sen...@li... > https://lists.sourceforge.net/lists/listinfo/sendpage-devel > |
|
From: Peter S. <Peter.Smith@UTSouthwestern.edu> - 2009-09-15 14:38:45
|
Have you tried adding an "init=" entry to your "[modem:]" section? Perhaps just put in a reset, like "init=ATZ". Mine use the following, but really I don't think it is *much* more than a reset. "init=ATZwwww&Q6S11=40S7=20M0" Peter >>> Walt Wyndroski <wd...@gm...> 2009-09-15 8:30 AM/08:30:18 >>> Hello there all. 1) I have RHEL5 64 bit running on a Dell server. The server has an internal PCIE 56k faxmodem. I also tried an external USR Sportster modem. <snip> WDW |
|
From: Walt W. <wd...@gm...> - 2009-09-15 14:01:37
|
Hello there all.
1) I have RHEL5 64 bit running on a Dell server. The server has an internal
PCIE 56k faxmodem. I also tried an external USR Sportster modem.
2) I am able to cleanly install the sendpage package with the required Perl
modules. The daemon starts up correctly and accepts pages correctly from the
command line and my Zenoss monitoring server.
3) Everything works fine until sendpage proceeds to dial. I get the
following error message:
sendpage[30748]: Failed to dial modem
sendpage[30748]: proto startup failed (Could not dial out)
4) I am able to dial my office phone through either modem with minicom. I
know both modems work. I've tried uninstalling and reinstalling. I've even
read the Perl code hoping I might find something to indicate a had a system
issue. The modemtest perl script appears to be successful when running. I've
included an abbreviated config below.
[modem:sportster]
dev=/dev/modem
baud=2400
areacode=555
dialwait=20
[pc:propage]
phonenum=1234567
#stricttap=true
[recip:pager_wdw]
dest = @propage
I would greatly appreciate any help. Thanks in advance!
WDW
|
|
From: Mark S. <ma...@su...> - 2009-03-19 15:33:48
|
Hello, I work at a small hosting company where we use TAP paging to alert ourselves to problems, including that networking is not working. We have been sending out pages through Sprint, but would like to not be tied to a single phone company anymore. In looking for alternatives, one of the only providers we found to serve us in Richmond, Indiana is InterPage: http://www.interpage.net/ I'd like to know if there are competitors to InterPage that we should be evaluating. I found some of the lists of "TAP Centrals" online, but have had difficulty narrowing down to ones that actually apply to us. Because we are small, and may send out less than 100 pages per month, some of the "Enterprise" services don't apply to us. I have also wondered if it is at all feasible to run a TAP server myself, by having a server hosted remotely with a modem attached and the right software installed. I researched that a little bit, but couldn't confirm that this was feasible. Thanks! Mark |
|
From: Johan <joh...@ti...> - 2007-10-15 10:34:19
|
I know HP-UX is reported untested in the documentation. But I just want to ask, have anyone tried it yet? I have need for the sendpage software on a HP-UX platform, and it feels abit overkill to setup a linuxmachine at the side of it just to send messages to pagers. But I guess that's what we have to do if it's still unsupported/untested. Please cc to my personal emailaddress, as I'm not on this mailinglist. Johan |
|
From: Kees C. <sen...@ou...> - 2006-08-19 16:41:29
|
On Thu, Aug 17, 2006 at 10:52:46AM +0100, Steve Kennedy wrote: > Have a look at Kannel, www.kannel.org and look at the AT driver which is > basically a GSM modem driver (written in C). Yup. Kannel, gnokii, and best of all, Device::Gsm. I want to use Device::Gsm, but it requires I shuffle code in Sendpage a little to use Device::Modem instead of Device::SerialPort directly. -- Kees Cook @outflux.net |
|
From: Steve K. <ste...@gb...> - 2006-08-17 09:52:52
|
On Wed, Aug 16, 2006 at 06:48:31PM -0700, Kees Cook wrote: > While at LWE this week, I spent some time to add beta SMS support to the > Sendpage devel branch. Many thanks go to Brian Murray who proved that > it could work. :) I'd like to move to using Device::Gsm instead of > doing it by hand currently. :) Have a look at Kannel, www.kannel.org and look at the AT driver which is basically a GSM modem driver (written in C). Steve -- NetTek Ltd UK mob +44-(0)7775 755503 UK +44-(0)20 79932612 / US +1-(310)8577715 / Fax +44-(0)20 7483 2455 Skype/GoogleTalk/AIM/Gizmo/Mac stevekennedyuk / MSN st...@gb... Euro Tech News Blog http://eurotechnews.blogspot.com |
|
From: Kees C. <sen...@ou...> - 2006-08-17 01:48:38
|
While at LWE this week, I spent some time to add beta SMS support to the Sendpage devel branch. Many thanks go to Brian Murray who proved that it could work. :) I'd like to move to using Device::Gsm instead of doing it by hand currently. :) It will appear in the 1.1.1 release, but I want to test it a bit more before I package it. Anyone interested in it can get it out of CVS for the moment. We've reproduced two physical configurations: - GSM PCMCIA card (required an init of "AT+CFUN=1") - Bluetooth phone (motorola RAZR - required an init of "AT+CMGF=1") For the PCMCIA card, the serial port is just a "regular" ttyS* device. For the bluetooth, I had to build an "rf serial channel" under Linux with: # verify bluetooth is running hciconfig # look for our phone's ID hcitool scan # bind a serial channel rfcomm bind 0 $ID which results in /dev/rfcomm0 existing. Device::SerialPort seems to have intermitant issues using it, but I suspect the Linux rfcomm driver, or maybe some of the extra magic I see Device::Gsm doing. My Modem, Paging Central, and Recip config looks like this: [modem:razr] debug=true dev=/dev/rfcomm0 init=AT+CMGF=1 dial= carrier-detect=off [pc:sms] debug=true proto=SMS modems=razr [recip:kees] dest = my_phone_number_here@sms -- Kees Cook @outflux.net |
|
From: Zak B. E. <za...@sp...> - 2006-08-10 17:14:49
|
Hi all! =) I'm requesting for a sponsor for my `libdevice-serialport-perl' package for the Perl module Device::SerialPort version 1.002 . This package is supposed to be under the care of Michael D. Mattice (mattice on db, LoRez on IRC,) but it hasn't been touched by him in exactly 2 years (the last upload from him was on 2004-08-10.) Since then this package has underwent 3 NMUs, the first of which severely broke the package because it somehow patched back the old release code to the new release. I have tried pinging mattice via email and IRC, but to no avail. Sometime ago I asked for the advice of debian-qa, and I was told that taking his package seems ok now, short of a real QA upload. As such, I have taken steps to create a package with the _real_ new upstream release, closing bugs, and acknowledging the three NMUs along the way. The new package is available at Debian Mentors,[0] and it is lintian clean. [0] http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=libdevice-serialport-perl Furthermore, let me emphasize that I did this package not just because it needed updating, but because I needed this package to be updated for the `sendpage' package to work correctly (speaking of which, the two packages are software that I'm involved with on the Google Summer of Code project for Sendpage/OSDL.[1]) Thus the urgency of my request. [1] http://code.google.com/soc/osdl/appinfo.html?csaid=F69CC123BDA4788A I would be glad if someone uploaded this package for me. Thanks in advance! Cheers, Zakame -- Zak B. Elep || http://zakame.spunge.org za...@ub... || za...@sp... 1486 7957 454D E529 E4F1 F75E 5787 B1FD FA53 851D |
|
From: Kees C. <ke...@ou...> - 2006-07-18 23:18:37
|
On Wed, Jul 05, 2006 at 06:30:37PM -0400, Graham Pearson wrote: > Since I am not a application programmer would this issue be a result of > Perl where this is not the case with C. I would even start a bounty for > the solution to this issue. Hi Graham! If it used to work with qpage, it should work with sendpage too. If you set "debug=yes" for both the PC and the Modem sections, send the output from syslog to the mailing list. That should give us a sense of what's happening, and we should be able to help you from there. -- Kees Cook @outflux.net |
|
From: Graham P. <gpe...@gl...> - 2006-07-05 22:29:51
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am in the process of reading the archives regarding this issue and I am trying to convert from qpage to sendpage since I have outgrown qpage with my 750,000 Text Messages that I send on a yearly basis for the K-12 School Districts in our state. Over this holiday I have been able to install sendpage, get it configured but having a problem connecting to verizon during handshake where as the qpage server does not have a problem. I have discovered in my test with the other providers I support with SMS messages sendpage is superb in the Modem area as it knows when the modem is in use and when it is not where qpage does not and is why I am wanting to move to sendpage. In my sendpage.cf file I have tried PG1, PG3 and UCP for the proto and also have changed carrier-detect along with stricttap. All of the options have not worked. Since I am not a application programmer would this issue be a result of Perl where this is not the case with C. I would even start a bounty for the solution to this issue. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: GnuPT 2.6.2.1 by EQUIPMENTE.DE Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFErD2MC9Rk5Ie0reIRAoJmAJsFQsvRvqC96UQbQJhKGl5wXdYgqACfSIbB /9G9fPGiat410knrvU549MI= =Iato -----END PGP SIGNATURE----- |
|
From: Zak B. E. <za...@sp...> - 2006-06-29 07:07:04
|
Status Report for Week 2
========================
Hi all! =)
Here is the second status report for my Summer of Code project for
improving Sendpage. I'd like to apologize for the lateness of this
report, for it was unavoidably delayed due to a few real-life hits
(see below.) Nevertheless, even as I have not been able to provide
timely updates, I have been rather hard at work doing the project
offline, and putting notes on it in my newly-acquired notebook
(thanks Google!)
Without further ado, here are the details of what has been done so
far:
Code Improvements
=================
Picking up from where I left off, I have proceeded with continuing
my annotations/modifications to the code in preparation for
restructuring. I have enforced Kees' suggested coding style in
almost all the library modules, and in doing so I simplified some of
the minor chunks. I have also enforced using strictures in the
modules; although not all of them are fully strict-compliant yet.
Exploring Alternatives to Object Representations
================================================
The most work that I've done, however, was in reassessing the
current object representation of the modules and in analyzing the
strength of their `objectiveness,' so to speak. In particular, I
felt rather uneasy about some the modules' behaviors when dealing
with their internal state; it was particularly easy, for example, to
be able to modify Sendpage::Modem's underlying hash representation
from the outside, which IMO may cause side effects later on.
I am aware of Perl's underlying attitude WRT objects--wrap objects
around a warning that says:
"IN CASE OF FIRE, BREAK GLASS"
However, in this case, accessing an object's underlying
representation (even in the case of object methods) leads to code
that assumes too much about an object's particular implementation,
thus breaking encapsulation.
In response to this, I see a few solutions to help clarify the code:
- Enforce the use of accessor methods throughout the codebase,
both for public users and for other methods. E.g.
$self->{USER}; becomes $self->user();
$self->{USER} = "name"; becomes $self->user("name");
Accessor methods are relatively cheap to make, usually just
involving a foreach() loop to make new names in the package's
symbol table, assigning to anonymous subs.
- Use a closure as the object representation itself. This leads
to code that is a little bit more persnickety, but a lot more
discerning, since the object itself can now implement checks to
its state upon access and/or modification.
I am already at work in doing the former; see my patches to
Sendpage::Recipient. I am still looking at the feasibility of the
latter, especially if there are any concerns about speed.
Updating the Debian Packages
============================
Because the Debian (and Ubuntu, et al.) packages of Sendpage (and
Device::SerialPort) are quite out of date, I have contacted their
respective maintainers, Preston Smith (sendpage) and Mike Mattice
(libdevice-serialport-perl) for their information. I have also
asked them if they are still interested in maintaining these
packages.
As a side note, I noticed that Sendpage and Device::SerialPort both
contain a `./debian' directory in CVS; while I find that myself not
too surprising, Debian has insisted time and again that upstream
sources should not ship a `./debian' in their tarball, since package
maintainers may opt to implement their own package building and/or
patch system that may not be compatible with what upstream currently
has.
Since in this case both Sendpage and Device::SerialPort CVS have
their own `./debian' tree, I suggest that these directories be moved
in their own CVS module, `debian-dir', that can be tracked and
developed separately from the Perl code; e.g. we can have
`debian-dir/sendpage' and `debian-dir/libdevice-serialport-perl'
containing the Debian packaging bits, separate from the module code.
Real Life Hits
--------------
During the past week I experienced my first stumbling block:
hardware failure. My monitor, which has been exhibiting signs of
power loss in the past months, had finally given way, and I was at a
loss on how to continue my work given that I have no monitor :/
Fortunately, my uncle had a spare, so I was able to get it working
on my system.
Also, there seemed to be a snag regarding my enrollment status at
the school, which effectively rendered me incapable of accessing my
online class portals. Fortunately this has since been resolved, and
I'm happy to be back in class :D
Unfortunately, another hit is making its way: I will be going to
Manila this weekend to attend my first class session for the
semester, and I expect to be back by Monday next week :/ Hopefully
I'll be back with my very own monitor by then, as well as a couple
or so of unit tests for the Sendpage modules. :D
Next Steps
==========
The delays made by my real-life hits may have tested my patience a
little, but I look forward to completing what I left off:
- The design spec for Sendpage and the modules
- Filling out the documentation
- Updating the Debian packages
__END__
Cheers,
Zakame
--
Zak B. Elep || http://zakame.spunge.org
za...@ub... || za...@sp...
1486 7957 454D E529 E4F1 F75E 5787 B1FD FA53 851D
|
|
From: Kees C. <sen...@ou...> - 2006-06-19 18:07:02
|
On Sat, Jun 17, 2006 at 04:41:38PM +0800, Zak B. Elep wrote:
> That's what I did first actually; grab a working copy from anoncvs, then
> read and make changes in it. It just so happened that my preferred
> editor also had the convenience of being able to store working copies to
> to version control systems simultaneously, so I can make incremental
> changes with log notes on each change.
Ah-ha! Yeah, that's a good idea.
> Much of my latest changes has been on getting the existing variables
> properly localized, removing spurious variables (or at least commenting
> them out) and revising oft-used constructs to their clearer Perl
> equivalents (i.e. if(!defined(foo)) becomes unless(defined(foo)) or even
> unless(foo).) This is the first pass; the next would be to plow through
> the algorithms themselves and simplify them.
I can't wait to see the first patch bundle. :)
> Yeah, I isolated the locking code in a test program a while ago and
> found its usefulness; indeed Perl's flock() mechanism isn't strong
> enough to ram up with pppd and friends :P Still, I think we could put in
> some flock() magic in the locking code to avoid some redundancy when
> multiple calls to lock are performed (AIUIC a nonblocking flock() would
> stop locks sooner, or at least allow us to have some better `while you
> wait' code up...)
I added a perl test directory ("t") to the CVS tree too. I figure I'll
start writing more and more tests as the modules get worked on. The
locking would be a good one to test. That's nice and stand-alone. :)
--
Kees Cook @outflux.net
|
|
From: Kees C. <sen...@ou...> - 2006-06-17 19:28:12
|
Sendpage 1.0.2 (stable) has been released. This is a bug-fix release,
solving a number issues. Changelog reads:
1.0.2: (2006-06-16)
- fixed time-out code to handle endless failure situation
- fixed recipient bleed-through across SEND/RESE in SNPP
- fixed queue filename collision
- added minimal "use" testing
- corrected version number reporting on banner
Download able via sourceforge or sendpage.org:
http://prdownloads.sourceforge.net/sendpage/sendpage-1.000002.tar.gz
http://sendpage.org/download/sendpage-1.000002.tar.gz
For those of you running on Ubuntu Dapper, watch out,
"libdevice-serialport-perl" isn't the version it claims to be. You'll
likely have to build your own.
--
Kees Cook @outflux.net
|
|
From: Zak B. E. <za...@sp...> - 2006-06-17 09:39:35
|
Hi again! =)
On 6/16/06, Kees Cook <sen...@ou...> wrote:
> You should be able to check out an "anonymous" copy of the CVS tree.
> >From that, you can generate "cvs diff -up" output, and also merge in
> changes as new stuff is added upstream ("cvs update"). This may be more
> flexible than using the RCS method.
That's what I did first actually; grab a working copy from anoncvs, then
read and make changes in it. It just so happened that my preferred
editor also had the convenience of being able to store working copies to
to version control systems simultaneously, so I can make incremental
changes with log notes on each change.
> There was a goal to move to using "Device", so that "Modem" and
> "TCPModem" could be abstracted. (For example, there are some Paging
> Centrals that have their serial ports attached to network console
> servers, which can only be reached over the network (instead of via a
> serial line).
Ah! So that's why! I'll note that then :)
> > - The Perl `metagoofs' of _not_ using the `warnings' and `strict'
> > pragmas as appropriate are evident in all modules of the code.
> > [...]
>
> I couldn't agree more. :) There will likely be a lot of clean-up
> needed to solve this. It would be a major improvement, though.
Much of my latest changes has been on getting the existing variables
properly localized, removing spurious variables (or at least commenting
them out) and revising oft-used constructs to their clearer Perl
equivalents (i.e. if(!defined(foo)) becomes unless(defined(foo)) or even
unless(foo).) This is the first pass; the next would be to plow through
the algorithms themselves and simplify them.
> Serial devices need to be locked in a very specific way ("uucp-style"
> IIRC) to in-operate correctly with other programs that want to use those
> devices.
Yeah, I isolated the locking code in a test program a while ago and
found its usefulness; indeed Perl's flock() mechanism isn't strong
enough to ram up with pppd and friends :P Still, I think we could put in
some flock() magic in the locking code to avoid some redundancy when
multiple calls to lock are performed (AIUIC a nonblocking flock() would
stop locks sooner, or at least allow us to have some better `while you
wait' code up...)
> > - Last (but not the least) is perhaps the main object of the
> > enhancements project: making the object configuration code
> > simpler and easier to understand. From my reading, it seems
> > [...]
>
> This is true (even in Modem.pm). I was thinking about the device itself
> (from a locking perspective), and then later about the connection
> through the device (baud rate, parity, etc). Since the connection
> parameters can change, that's why there is a separate "init" function.
I see; yeah, both the new() and init() methods make sense here. Anyhow
a Modem or Device can re-init() itself, or can be re-init()-ed by the
user.
> I'd like to make the follow suggestion for a common "style", which is
> what I currently use. (There's not need to change old code's style
> unless you really want to.)
Actually this is the style I'm using right now (enforced by CPerl-mode's
styles-alist.)
> That's fine by me. Once you've got a collection of patches ready, I can
> cut a branch and get it started in the CVS tree for you to follow.
Great! =) I hope to be able to get my first set done by next week, along
with the draft of the specs document.
> > now work on proceeding with formulating a coherent design
> > specification for improving Sendpage and its associated modules (I
> > personally feel that the sendpage program itself it quite big, and
> > that seems to be an indication for further redesign.) Also, since I
>
> Agreed. There are elements that I'd love to see pushed out into
> separate CPAN modules (names the badly-named "KeesConf" -- should be
> "IniConf" or "FallbackConfig" or something, and the SNPP server -- which
> was actually PUT in CPAN by someone else, based on the Sendpage SNPP
> class).
Erm, `KeesConf' is badly-named? I'd rather think otherwise, but yeah,
it should be something that describes itself neatly.
> Zakame, sorry I took so long replying to this! I should be quick to
> respond from now on. :)
Hehe, no problem =) Truth is I've been away too for some schoolwork, but
now I think there isn't much at the way for me to focus on the
project. =)
Cheers,
Zakame
--
Zak B. Elep || http://zakame.spunge.org
za...@ub... || za...@sp...
1486 7957 454D E529 E4F1 F75E 5787 B1FD FA53 851D
|
|
From: Kees C. <sen...@ou...> - 2006-06-16 20:52:26
|
On Fri, Jun 16, 2006 at 01:08:57PM -0600, James Bourne wrote: > OK, I've tested the patch and it now works as expected with PAGE/MESS/SEND > PAGE/MESS/SEND and PAGE/PAGE/PAGE/MESS/SEND Great! That's a relief. :) Take care, -- Kees Cook @outflux.net |
|
From: James B. <jb...@mt...> - 2006-06-16 19:09:01
|
On Fri, 16 Jun 2006, Kees Cook wrote: > On Fri, Jun 16, 2006 at 10:20:52AM -0700, Kees Cook wrote: >> 1) My "getUniqueFilename" function, uh, isn't, it seems. :( > > Okay, I've got this worked around now. > >> 2) I don't yet see HOW the recipient list isn't cleared after a "SEND". >> There is a call to clear it, but something must be funny about it. > > This was a little harder to track, but is now also fixed. (Hey zakame, > remember the strict/warnings this? Yeah, that would have caught this bug.) > > Attached is a patch for 1.0.1 to fix it. I will be releasing 1.0.2 > shortly (this is a pretty major bug that I'm surprised no one else has > run into). OK, I've tested the patch and it now works as expected with PAGE/MESS/SEND PAGE/MESS/SEND and PAGE/PAGE/PAGE/MESS/SEND Thanks and regards James > > Thanks for the report! > > -- James Bourne, Senior Systems Administrator Mount Royal College, Calgary, AB, CA www.mtroyal.ca "There are only 10 types of people in this world: those who understand binary and those who don't." ***************************************************************************** This communication is intended for the use of the recipient to which it is addressed, and may contain confidential, personal, and or privileged information. Please contact the sender immediately if you are not the intended recipient of this communication, and do not copy, distribute, or take action relying on it. Any communication received in error, or subsequent reply, should be deleted or destroyed. ***************************************************************************** |
|
From: James B. <jb...@mt...> - 2006-06-16 18:54:28
|
On Fri, 16 Jun 2006, Kees Cook wrote: > On Fri, Jun 16, 2006 at 10:20:52AM -0700, Kees Cook wrote: >> 1) My "getUniqueFilename" function, uh, isn't, it seems. :( > > Okay, I've got this worked around now. > >> 2) I don't yet see HOW the recipient list isn't cleared after a "SEND". >> There is a call to clear it, but something must be funny about it. > > This was a little harder to track, but is now also fixed. (Hey zakame, > remember the strict/warnings this? Yeah, that would have caught this bug.) > > Attached is a patch for 1.0.1 to fix it. I will be releasing 1.0.2 > shortly (this is a pretty major bug that I'm surprised no one else has > run into). > > Thanks for the report! Excellent response time, thanks! I'm applying the patch and will test it here to ensure it corrects the problem. Thanks again and regards James -- James Bourne, Senior Systems Administrator Mount Royal College, Calgary, AB, CA www.mtroyal.ca "There are only 10 types of people in this world: those who understand binary and those who don't." ***************************************************************************** This communication is intended for the use of the recipient to which it is addressed, and may contain confidential, personal, and or privileged information. Please contact the sender immediately if you are not the intended recipient of this communication, and do not copy, distribute, or take action relying on it. Any communication received in error, or subsequent reply, should be deleted or destroyed. ***************************************************************************** |
4 messages has been excluded from this view by a project administrator.