HylaFAX The world's most advanced open source fax server

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [hylafax-users] QualifyCID -and- (HylaFAX Version 4.1)



Strangeness seen below

----- Original Message -----
Sent: Friday, September 20, 2002 5:16 AM
Subject: Re: [hylafax-users] QualifyCID -and- (HylaFAX Version
4.1)


> I take it that the check that I suggested on your CID file
using tsitest
> comes up with the correct results?
Yes ... the results are correct for the pattens I've entered in
etc/cid

> Can you send the relevant part of your etc/config.xxxxx file to
do with
> cid checking?
Relevant as in QualifyCID:  (would be the the results of the
following cmd line.)
<prompt># grep -r QualifyCID /var/spool/hylafax
/var/spool/hylafax/etc/config.cuaa2:QualifyCID:
/var/spool/hylafax/etc/cid


> Lastly, can you capture what the modem is actually reporting
amongst the
> "RING" messages.  Used something like minicom to capture it
directly
> while ringing the modem.
I've used cu  and it reports:
the 1st ring= RING
the 2nd ring= " the CID information as provided by the telco"
all subsequent rings yield the string= RING
>
> Can you turn on tracing for SERVER STATE TRANSITIONS (add 256
to server
> tracing) and send the log for a fax being received when CID is
rejected.
This may take some time to produce the logs to you, because,
after looking back over the last month, this particular
telemarketer has his automation set to send faxes only on
Sunday's.  After adding '256 to server tracing'  I'll have to
wait for Sunday to roll around to gather further info from the
Sever-log.  I've only set CID REJECTION for ^0.*$

I've checked and tested these settings over and over before
initially mailing the list and yet again after reviewing this
post; only to find some instability.  When i first applied the
'cid patch' to HylaFAX and tested my patterns with tsitest and,
in etc/cid -- all was fine.

However, as a review for confirmation to your Email, I ran the
test again with the contents of my etc/cid and the patterns
therein and the tsitest fails.  I look further into this by
changing the pattern in my etc/cid to reject a common area code |
save etc/cid | then run tsitest again and, it works by rejecting
the 'common area code <pattern>'.  I also test the <pattern> by
calliing from my other lines which matches that common area code
I'm rejecting and Hylafax rejects the call just fine.

Now i change that pattern in etc/cid back to the pattern I had it
set to initially over that past month ^0.*$  | save etc/cid |
then run tsitest again ... now the pattern works; as if i
shook/kicked something back into place.  Prior to this juggling
of cid patterns within etc/cid, i have reboot the machine
numerous times in an attempt to correct this issue to no avail.

Would you have any further thoughts on this?
I'll post the server-log to you as soon as i get some results
from the new server-trace setting during the next time this
telemarketer calls.
>
> alt wrote:
> >
> > Thanks for the direction but I still seem to have problems
with
> > this issue (shown below)
> > After applying the patch calls qualifying the reject patterns
in
> > etc/cid seem to be rejected
> > EXAMPLE:
> > Sep 8 15:06:46 ANSWER: CID NUMBER "O" NAME "O"
> > Sep 8 15:06:52 ANSWER: CID REJECTED
> > However, recently, the same call shown above is shown to be
> > rejected but, a fax was infact received for the same
(rejected)
> > timestamp shown above.  This was verified via the contents of
the
> > session log for that call shown below. (partial log) .......
> > Sep 08 15:07:31.67: [  111]: TRAINING succeeded
> > Sep 08 15:07:31.68: [  111]: MODEM input buffering enabled
> > Sep 08 15:07:31.68: [  111]: MODEM set XON/XOFF/FLUSH: input
> > ignored, output generated
> > Sep 08 15:07:31.68: [  111]: <-- [11:AT+FRM=146\r]
> > Sep 08 15:07:32.47: [  111]: --> [7:CONNECT]
> > Sep 08 15:07:32.47: [  111]: RECV: begin page
> > Sep 08 15:07:59.57: [  111]: RECV: 1124 total lines, 0 bad
lines,
> > 0 consecutive bad lines
> > Sep 08 15:07:59.57: [  111]: RECV: end page
> > Sep 08 15:07:59.57: [  111]: --> [10:NO CARRIER]
> > Sep 08 15:07:59.57: [  111]: MODEM set XON/XOFF/DRAIN: input
> > ignored, output disabled
> > Sep 08 15:07:59.57: [  111]: MODEM input buffering disabled
> > Sep 08 15:07:59.57: [  111]: <-- [9:AT+FRH=3\r]
> > Sep 08 15:07:59.67: [  111]: --> [7:CONNECT]
> > Sep 08 15:08:00.75: [  111]: --> [2:OK]
> > Sep 08 15:08:00.75: [  111]: RECV recv EOP (no more pages or
> > documents)
> > Sep 08 15:08:00.76: [  111]: DELAY 150 ms
> > Sep 08 15:08:00.91: [  111]: <-- [9:AT+FTH=3\r]
> > Sep 08 15:08:01.09: [  111]: --> [7:CONNECT]
> > Sep 08 15:08:01.09: [  111]: <-- data [3]
> > Sep 08 15:08:01.09: [  111]: <-- data [2]
> > Sep 08 15:08:02.27: [  111]: --> [2:OK]
> > Sep 08 15:08:02.27: [  111]: RECV send MCF (message
confirmation)
> > Sep 08 15:08:02.29: [  111]: RECV FAX (00000246): from , page
1
> > in 0:31, INF, 3.85 line/mm, 1-D MR, 14400 bit/s
> > Sep 08 15:08:02.29: [  111]: RECV FAX (00000246):
> > recvq/fax00149.tif from , route to <unspecified>, 1 pages in
> > Sep 08 15:08:02.31: [  111]: <-- [9:AT+FRH=3\r]
> > Sep 08 15:08:02.87: [  111]: --> [7:CONNECT]
> > Sep 08 15:08:03.84: [  111]: --> [2:OK]
> > Sep 08 15:08:03.84: [  111]: MODEM input buffering enabled
> > Sep 08 15:08:03.84: [  111]: RECV FAX: bin/faxrcvd
> > "recvq/fax00149.tif" "cuaa2" "00000246" ""
> > Sep 08 15:08:04.53: [  111]: RECV FAX: end
> > Sep 08 15:08:04.53: [  111]: SESSION END
> >
> > ----- Original Message -----
> > From: "Campbell McKilligan" <cowboycam@2die4.com>
> > To: "alt" <syncope@speakeasy.net>
> > Cc: <hylafax-users@hylafax.org>
> > Sent: Monday, September 02, 2002 10:05 PM
> > Subject: Re: [hylafax-users] QualifyCID -and- (HylaFAX
Version
> > 4.1)
> >
> > > First test your etc/cid file with tsitest:
> > >
> > > [campbell@viper etc]# which tsitest
> > > /usr/sbin/tsitest
> > >
> > > [campbell@viper etc]# tsitest /var/spool/fax/etc/cid
> > > ready> 911
> > > [check ^0299290282$]
> > > [check ^0398702955$]
> > > [check ^.*$]
> > > accept (matched by ^.*$)
> > > ready>
> > >
> > > AS CID, TSI and tsitest use the same regex code this will
make
> > sure that the
> > > regex code is not broken in your version and that your
etc/cid
> > file is correct.
> > >
> > > There is a patch you can apply to util/RegEx which stops
> > Hylafax from
> > > incorrectly rejecting CID or TSIs (depending on which one
you
> > are checking)
> > > when the received string is empty.
> > >
> > > There is a second patch which ensures that CID passed on
for
> > checking properly
> > > once it is received.  Just because CID numbers appear in
the
> > logs, it doesn't
> > > guarantee that it got sent of for checking properly.
> > >
> > > alt wrote:
> > >
> > > > The bottom line is:
> > > > inserting             !^<pattern>$ <-- as the first line
in
> > > > /var/spool/hylafax/etc/cid -- eg. ^8005551212$
> > > > also inserting      ^.*$  <-- as the last line in
> > > > /var/spool/hylafax/etc/cid
> > > >
> > > > The <pattern> shown in the first line is being accepted
by
> > > > hylafax1 when it should be 'CID REJECTED.'
> > > >
> > > > Looking at this from another angle, should I only place
the
> > > > following:
> > > > ^<pattern>$ <-- as the first line in
> > > > /var/spool/hylafax/etc/cid -- eg. ^8005551212$
> > > > The above line will *not be accepted/answered by hylafax.
> > > >
> > > > Lastly when I try inserting (as an only line in the
> > etc/cid)-->
> > > > ^$ <-- all incoming calls are accepted.  It seems to me
> > > > QualifyCID is not working properly.  Its my understanding
> > that ^$
> > > > means a null or empty string.  The CID info is in-fact
> > available
> > > > (showing in my server log)  What I think may be happening
is;
> > the
> > > > patterns placed in etc/cid (in this instance) are being
> > matched
> > > > against the TSI info  --and not--  CID info
> > > >
> > > > With my per-modem config files set to ...
> > > > ServerTracing:          1
> > > > SessionTracing:         15
> > > > serverlogs do in fact show CID name and number However;
my
> > > > session logs will not show CID name and number
information
> > with
> > > > the setting shown above.  The session logs do show 'cid
> > rejected'
> > > > when QualifyCID is defined but etc/cid is empty.
> > > >
> > > > I don't need or use TSI screening.  I need and want to
screen
> > via
> > > > CID, providing we can figure what's going incorrectly
here.
> > > >
> > > > Thanks for your thoughts.
> >
> > ____________________ HylaFAX(tm) Users Mailing List
_______________________
> >   To subscribe/unsubscribe, click
http://lists.hylafax.org/cgi-bin/lsg2.cgi
> >  On UNIX: mail -s unsubscribe
hylafax-users-request@hylafax.org < /dev/null
> >   *To learn about commercial HylaFAX(tm) support, mail
sales@hylafax.org.*
>


____________________ HylaFAX(tm) Users Mailing List _______________________
  To subscribe/unsubscribe, click http://lists.hylafax.org/cgi-bin/lsg2.cgi
 On UNIX: mail -s unsubscribe hylafax-users-request@hylafax.org < /dev/null
  *To learn about commercial HylaFAX(tm) support, mail sales@hylafax.org.*




Project hosted by iFAX Solutions