[hylafax-users] QualifyCID -and- HylaFAX Version 4.1

["alt" <syncope@speakeasy.net>]

The following is still not resolved.  Even tho the logs show the
faxes/calls are being rejected they are in-fact being accepted.
A perfect example is shown below.
===========================
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.*