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

[Campbell McKilligan <cowboycam@2die4.com>]

I looked at the answering code in faxGetty again to see why a fax might
be received if CID is rejected in your version.  CID Rejection
essentially short circuits any form of answering - sends an ath0 to the
modem and drops DTR just to be absolutely sure that the call isn't
answered.

As far as etc/cid is concerned, you don't need to restart faxGetty with
changes to the file.  If the etc/cid can't be found or read (ie the
perms are wrong) then all calls get rejected.

alt wrote:
> 
> 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.*

____________________ 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.*