HylaFAX The world's most advanced open source fax server

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

Re: Some Hylafax SNPP patches



Greg wrote:
    
    Hi,
        I've recently started using hylafax for outbound paging.  (IXO/TAP).
    It is well suited for a high volume environment we plan to use it in, as
    it supports queueing and multiple modems. Anyway, in my travels I have
    encountered some problems and include my solutions. The first problem I
    ran into was that I could not specify the TAP dialup number when sending
    a page request. Hylafax supports a regular expression maching and
    substitution on the PIN, but not the Number. The first section of the
    patch enables the use of things such as  111111@18005551212 to be sent
    to pin number 111111 at TAP dialup 18005551212 (using the rule
    "(.*)\@(.*) \2/\1").

The pager identifier specified with the "-p pid" in sendpage(1)
is send via SNPP in the PAGEr directive to the SNPP-server (e.g.
to hfaxd(1M)). The PAGEr directive in RFC 1861 has no room for
a specification of the IXO/TAP service provider. That's why the
hfaxd(1M) uses a file pagermap(4F) to map the pager identifier to
a service provider phone number. IMHO this mapping should be
a privilege part of the server daemon and not in the hand of
a user also.

                            The second problem I encountered was the use of
    this software on a solaris Autoclient system. Solaris supports what it
    calls an autoclient, which is basicly a diskless workstation which uses
    its local drive as a cache. I suspect the problem I encountered was
    possibly due to this, perhaps a file updating on nfs and not in cache,
    or vice versa. The symtoms are that faxes work properly, however when
    sending a page you get an error message (if you use the -v -d flags in
    sendpage) "scheduler NAK'd request", furthermore, your syslog will have
    messages from FaxQueuer stating:"null or missing number in job request".
    The second patch included seems to aleviate this problem by updating the
    job request   after the tap number and pin have been filled into the job
    request. These patches were made on 4.0-pl1, on a Solaris-x86 2.5.1
    machine, using GCC as the compiler. The patches are to be applied to
    SNPPServer.c++, located in the hfaxd source subdirectory. I hope you
    find this information usefull..

I'll put this on my list of bugs but I'm not sure about this
solution (see also the comment in SNPPServer.c++ at line 1094).

Thanks anyway.

	matthias
    
    *** SNPPServer.c++      Tue Nov 26 15:21:51 1996
    --- SNPPServer.c++.new  Fri Sep 26 15:18:44 1997
    ***************
    *** 300,305 ****
    --- 300,306 ----
                                pin = cp;
                                if (re)                     // do
    substitutions
                                    subRHS(pin, *re, pagerID);
    +                               subRHS(number, *re, pagerID);
                            } else {                        // <dialstring>
                                number = np;
                                pin = pagerID;
    ***************
    *** 1118,1123 ****
    --- 1119,1125 ----
                , (const char*) curJob->jobid
            );
            msgs.append(curJob->jobid);
    +         updateJobOnDisk(*curJob, emsg);
          } else
            reply(554, "%s.", (const char*) emsg);
          initSNPPJob();                            // reset job-related
    state




Project hosted by iFAX Solutions