[hylafax-users] Hylafax-Sendfax Client produces error when accessing server to send fax
Bob Lightfoot
I have HylaFax set up and running beautifully on my Centos 5.6
i386 server. I've edited the hosts file and installed hylafax on my
Fedora 14 workstation client as well. The firewall is open between
client and server since both are linux boxes and on the same subnet.
But when I attempt a sendfax command from the client workstation it
errors as shown below. Whether std user or root user. I've googled and
binged, but found little on point. Ideas anyone.
[Bob@Mythbox HSCA20110420]$ sendfax -vv -n -m -h @192.168.2.200 -d
9414288 page0001.ps
Trying 192.168.2.200 [2] (192.168.2.200) at port 4559...
Connected to 192.168.2.200.
220 Comp100.Ladodomain server (HylaFAX (tm) Version 5.2.5) ready.
-> USER Bob
230 User Bob logged in.
match against (..., 512)
rule: offset 0 string = "%!" -- success (result postscript, rule "")
Apply DisplayNumber rules to "9414288"
--> return result "9414288"
-> FORM PS
200 Format set to PS.
-> TYPE I
200 Type set to Image.
SEND compressed data, 182268 bytes
-> EPRT |1|192.168.2.201|60911|
500 EPRT: Command not recognized.
Warning, EPRT not supported, trying PORT
-> PORT 192,168,2,201,237,239
200 PORT command successful.
-> MODE Z
200 Mode set to ZIP.
-> STOT
425 Cannot build data connection: No route to host.
425 Cannot build data connection: No route to host.
[Bob@Mythbox HSCA20110420]$
[Bob@Mythbox HSCA20110420]$ su
Password:
[root@Mythbox HSCA20110420]# sendfax -vv -n -m -h @192.168.2.200 -d
9414288 page
page-0001.pnm page0001.ps page-0002.pnm page0002.ps
page-0003.pnm page0003.ps
[root@Mythbox HSCA20110420]# sendfax -vv -n -m -h @192.168.2.200 -d
9414288 page0001.ps
Trying 192.168.2.200 [2] (192.168.2.200) at port 4559...
Connected to 192.168.2.200.
220 Comp100.Ladodomain server (HylaFAX (tm) Version 5.2.5) ready.
-> USER root
230 User root logged in.
match against (..., 512)
rule: offset 0 string = "%!" -- success (result postscript, rule "")
Apply DisplayNumber rules to "9414288"
--> return result "9414288"
-> FORM PS
200 Format set to PS.
-> TYPE I
200 Type set to Image.
SEND compressed data, 182268 bytes
-> EPRT |1|192.168.2.201|37537|
500 EPRT: Command not recognized.
Warning, EPRT not supported, trying PORT
-> PORT 192,168,2,201,146,161
200 PORT command successful.
-> MODE Z
200 Mode set to ZIP.
-> STOT
425 Cannot build data connection: No route to host.
425 Cannot build data connection: No route to host.
[root@Mythbox HSCA20110420]#
Sincerely,
Bob Lightfoot
____________________ HylaFAX(tm) Users Mailing List _______________________
To subscribe/unsubscribe, click http://lists.hylafax.org/cgi-bin/lsg2.cgi
On UNIX: mail -s unsubscribe hylafax-us...@hylafax.org < /dev/null
*To learn about commercial HylaFAX(tm) support, mail sa...@ifax.com.*
Lorenzo Monti
dynamic ports.
you have to load nf_conntrack_ftp, so ftp traffic is monitored and ports are
opened "on the fly".
you must also tell nf_conntrack_ftp that it has to monitor port 4559, in
addition to the classic port 21.
create the file /etc/modprobe.d/nf_conntrack_ftp.conf
put this line into it:
options nf_conntrack_ftp ports=21,4559
then:
modprobe nf_conntrack_ftp
put this last command into an init script (such /etc/rc.local or so), so
that module gets loaded at every boot
- Lorenzo -
2011/4/29 Bob Lightfoot <bobl...@gmail.com>
John Hudak
I think there is a routing issue and not a problem with Hylafax.
HylaFAX uses a connection protocol based on the ftp protocol where files are
transferred via a second (data) connection. Here, the client asks the
server to connect to 192.168.2.201 port 237 which is not routable from
the server.
You need to us either some kind of ftp module on port 237 on the NAT
gateway or put a vpn between the two machines so that private addresses can
be routable between them. You could also send the file via another means
(ssh, smtp, ...) to the server and have sendfax be called from there. (I
don't know if sendfax supports passive connections (hfaxd does)
but since the server does not have a routable address, a passive
connection wouldn't help here).
This is just a guess, eventhough the two machines are on the same
subnet, the 192.168.x.x is not routable.
Does a Hylafax client work from one machine to another?
- John
Bob Lightfoot
I may be thick here, but I am obviously missing something or failed to
communicate something.
Let me clarify the setup.
PC Box A - HylaFax Server -- Works OK
DNS Name = Comp100.Ladodomain
IP ADDR = 192.168.2.200
OS = Centos 5.6-i386
Box is Print Server, Samba Server, HTTP Server, FTP server and
NFS Server for all other PC's on Lan 192.168.2.1 and these services work
just fine.
Hylafax-5.2.5-1.el5.rf from RPMFORGE is installed and
configured to use /dev/ttySHSF0. sendfax commands issued on this box
reach the hfaxd and work.
PC Box B - HylaFax Client -- Works NG
DNS Name = MYTHBOX.Ladodomain
IP ADDR = 192.168.2.201
OS = Fedora F14-x86_64
Box is Print Client, Samba Client, HTTP Client, FTP Client, NFS
Client and hosts several qemu VM's which are clients also of the server
Box A.
hylafax-5.5.0-1.fc14.i386 from SourceForge is installed via yum
localinstall of the rpm.
PC Box C- HylaFax Client -- Works OK
DNS Name = WinXpHome.Ladodomain
IP ADDR = 192.168.2.111
OS = Window XP Home in a qemu VM on PC Box B above
Box is Print Client, Samba Client, HTTP Client, and FTP Client
of server Box A.
WinPrint Hylafax from SourceForge is installed and configured
using the applewriter printer as the project page suggested.
Now I do not follow your comment about Box B being routable from Box
A. I tried several things including setting iptables on both the
server and client to accept all input connections for a short test
period. Still no improvement in performance.
One would think that with hylaxfax installed on both Linux boxes getting
faxes from Client Box to Server Box would be straight forward. I am
finding it anything but.
Forgive the rant. If someone knows where I can find a step by step or
manual for setting up a linux hylafax client box I'd love to read and
test it.
Bob Lightfoot
> <http://192.168.2.200> -d 9414288 page0001.ps <http://page0001.ps>
> <http://192.168.2.200> -d 9414288 page
> page-0001.pnm page0001.ps <http://page0001.ps> page-0002.pnm
> page0002.ps <http://page0002.ps> page-0003.pnm page0003.ps
> <http://page0003.ps>
> [root@Mythbox HSCA20110420]# sendfax -vv -n -m -h @192.168.2.200
> <http://192.168.2.200> -d 9414288 page0001.ps <http://page0001.ps>
> <mailto:hylafax-us...@hylafax.org> < /dev/null
Bodo Meissner
Hash: SHA1
Hello Bob,
does FTP work from PC Box B to PC Box A?
Use command "debug" to see if it is using PORT or PASV.
Example connection to localhost using both modes on my Ubuntu system:
$ ftp localhost
Connected to localhost.
220 ProFTPD 1.3.2c Server (Debian) [127.0.0.1]
Name (localhost:bodo):
331 Password required for bodo
Password:
230 User bodo logged in
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> debug
Debugging on (debug=1).
ftp> put foobar baz
local: foobar remote: baz
- ---> TYPE I
200 Type set to I
ftp: setsockopt (ignored): Permission denied
- ---> PORT 127,0,0,1,143,131
200 PORT command successful
- ---> STOR baz
150 Opening BINARY mode data connection for baz
226 Transfer complete
252 bytes sent in 0.00 secs (8789.1 kB/s)
ftp> get foobar baz
local: baz remote: foobar
ftp: setsockopt (ignored): Permission denied
- ---> PORT 127,0,0,1,219,82
200 PORT command successful
- ---> RETR foobar
150 Opening BINARY mode data connection for foobar (252 bytes)
226 Transfer complete
252 bytes received in 0.00 secs (3281.2 kB/s)
ftp> passive
Passive mode on.
ftp> put foobar baz
local: foobar remote: baz
ftp: setsockopt (ignored): Permission denied
- ---> PASV
227 Entering Passive Mode (127,0,0,1,210,94).
- ---> STOR baz
150 Opening BINARY mode data connection for baz
226 Transfer complete
252 bytes sent in 0.00 secs (12304.7 kB/s)
ftp> get foobar baz
local: baz remote: foobar
ftp: setsockopt (ignored): Permission denied
- ---> PASV
227 Entering Passive Mode (127,0,0,1,159,19).
- ---> RETR foobar
150 Opening BINARY mode data connection for foobar (252 bytes)
226 Transfer complete
252 bytes received in 0.00 secs (3238.1 kB/s)
ftp> by
- ---> QUIT
221 Goodbye.
Bodo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEARECAAYFAk28Ov0ACgkQnMz9fgzDSqdS1ACfYBVOtgos7CnpWvar+hl/XoDd
UsIAniIvpQMBgreKwLnaeVEcwwnmXmDI
=gGJb
-----END PGP SIGNATURE-----
____________________ HylaFAX(tm) Users Mailing List _______________________
To subscribe/unsubscribe, click http://lists.hylafax.org/cgi-bin/lsg2.cgi
On UNIX: mail -s unsubscribe hylafax-us...@hylafax.org < /dev/null
Bob Lightfoot
With all the helpful responses I received in Digest V12 #45 I
thought I should provide feedback.
First I have been able to succcessfully use Fedora 14 client
HylaFax-SendFax-5.5.0-1.fc14.i386 to reach my Centos 5.6 Server running
hylafax-5.2.5-1.el5.rf and send a fax. I added the lines -A INPUT -s
Hylafax.Server.IP.Addr -p tcp -j ACCEPT and -A INPUT -s
Hylafax.Server.IP.Addr -p udp -j ACCEPT to /etc/sysconfig/iptables and
then service restart iptables. After this the exchange would succeed.
More work will make this iptables modification more restrictive in the
future.
For Lorenzo Monti I tried setting up the nf_conntrack_ftp as you
suggested, but found that nf_conntrack_ftp is called by adding a line to
/etc/sysconfig/ip-tables-config not by modprobe at least on Fedora 14.
Your suggestion appears to have been in the correct vein of thought but
did not resolve the situation. I do, however think that a conntrack
helper opening the port for the data handshake from Server to client
will be the key. See my note to John Hudak below for more on that.
For John Hudak your responses have been useful and yes Hylafax
Client will work from one machine to another. The question of was there
a route from Server to Client was at the heart of the matter. At the
suggestion of a fellow Centos Sysop I sniffed the HylaFax Client to
Server exchange with wireshark. Low and behold the Client was rejecting
the handshake attempt from the Server to the Client which would have
transferred the data because it was originating from port 4558 of the
Server and hitting a random port number on the Client. I added the
lines -A INPUT -s Hylafax.Server.IP.Addr -p tcp -j ACCEPT and -A INPUT
-s Hylafax.Server.IP.Addr -p udp -j ACCEPT to /etc/sysconfig/iptables
and then service restart iptables. After this the exchange would
succeed. I have not found a means to restrict the access between the
client and server yet, but I am working on this. I think Lorenzo's
suggestion of using nf_conntrack_ftp or one of the conntrack helpers
will be key.
For Robert Branham, the system will work with different versions
on the client and server. Also with Fedora/Redhat/Centos family there
is one package installed and it is done with the yum install hylafax
command. This installs everything so that issuing a service hylafax
start command runs the server and chkconfig hylafax on ensures it is
started at boot. The client application sendfax is also available from
any cli call. I was in process of re-building the 5.2.5-1 from source
on f14 when I stumbled across the Wireshark suggestion and found the
root cause mentioned above.
For Bodo Meissner I never reched the point of testing ftp between
cllent and server. I did find a hylafax documentation page which
described a check of ftp using hylafax client app. I performed this
check and found ti working so focused on other comments with plans to
revisit ftp test as a last resort. Thanks for the idea.
Sincerley,
John Hudak
Thank you for the feedback. It is very useful. I don't remember the
details of how the server chooses a port to reply back to the client. It
has been quite some time since I looked at this. I didn't think it was
random....I'll have to read through the code, which is the definitive
answer. Actually, I don't understand why the rational is to choose a random
port.
I am glad that you were able to get it working to some extent.
-John
Bob Lightfoot
After a few wireshark captures it appears the source port on the
server is repeatable at 4558, it is the client port the server targets
which is random in appearance. Based on that I've tightened my iptables
rules to
-A INPUT -s Hylafax.Server.IP.Addr -p tcp --sport 4558:4559 -j ACCEPT
-A INPUT -s Hylafax.Server.IP.Addr -p udp --sport 4558:4559 -j ACCEPT
This appears to work quite well and is significantly tighter than
the previous "patch code"
Sincerely,
Bob Lightfoot
> <mailto:hylafax-us...@hylafax.org> < /dev/null