Winfax issues when dumping Novell Netware for Mars_Nwe under Linux
Peter Caffin
newsgroup boundaries and I have been having a *lot* of problems finding
the answer to this one. Maybe what I'm doing wrong is obvious to
somebody :).
Our faxing system is on Windows 95 boxes using Winfax Pro for Networks
4.0. The protocol it appears to be running with appears to be NetBIOS or
IPX.
The PC with the modem attached that's doing the faxing runs Windows 95.
The PCs that connect are running Windows 95.
The Novell Netware server is v3.12 running on top of MSDOS (not sure which
version; I don't want to take down the server to find out).
I'm trying to completely ditch the Netware server (it's old, crusty and
prone to IO card problems) and have all its services hanging off the
Linux server (which is currently providing the file and printer services
via Samba aka Win95 peer-to-peer, Netware and NFS).
The only thing now holding up the forced removal and scrapping of the
Novell server is Winfax. Winfax client PCs won't talk to the Winfax server
PC unless there's a Netware server up -- the Novell one. The Mars_Nwe
Netware server appears to be not providing the Netware clients or server
something important.
The docs for Winfax Pro state that the software requires either: NetBIOS
or IPX support. But it also seems to need something that isn't supplied
by the basic protocols alone.
My /etc/nwserv.conf contains:
-------------------------------------------------------------------------
1 SYS /var/netware/sys kt 711 600
2 NW_SERV
3 0x0 2
4 0x10 * AUTO 1
5 0x1
6 1 0x0
7 0
8 0x0
9 0751 0640
11 65534
12 SUPERVISOR root [PASSWORD]
13 STM_STAFF stmstaff [PASSWORD]
13 ALISON stmstaff [PASSWORD]
13 SCANFX stmstaff [PASSWORD]
13 SEAN stmstaff [PASSWORD]
15 0 [PASSWORD]
16 1
17 0x0
18 0x1
21 C2S - lpr -Pc2s
40 /var/spool/nwserv/.volcache
41 /var/spool/nwserv/.locks
42 /var/spool/nwserv
45 /var/nwserv/db
46 /var/nwserv/attrib
47 /var/nwserv/trustees
60 10 # MAX_CONNECTIONS
61 10 # MAX_NW_VOLS
63 50 # MAX_DIR_BASE_ENTRIES
61 10 # MAX_NW_VOLS
# 68 1 # USE_MMAP (use mmap=1, no mmap=0)
# 69 1 # HANDLE_ALL_SAP_TYPS (all sap typs=1, only typ 4=0)
# 70 0x44444444 # NETWORK_SERIAL_NMBR (4 byte)
# 71 0x2222 # NETWORK_APPL_NMBR (2 byte)
100 0 # debug IPX KERNEL (0 | 1)
101 1 # debug NWSERV
102 0 # debug NCPSERV
103 0 # debug NWCONN
104 0 # debug (start) NWCLIENT, should *always* be '0'
!
105 1 # debug NWBIND
106 1 # debug NWROUTED
200 1 # 0 = no logfile and dont daemonize
nwserv/nwrouted
201 /var/log/nw.log # filename of logfile
202 0x1 # flag in hex notation
210 10 # 1 .. 600 (default 10) seconds after server
211 60 # 10 .. 600 (default 60) broadcasts every x
seconds
300 1 # > 0 print routing info to file every x
broadcasts.
301 /var/log/nw.routes # filename of logfile
302 0x1 # flags will be interpreted as hex value.
310 7 # send wdog's only to device net < x ticks.
400 /etc/nwserv.stations # for syntax see file in the examples
directory.
401 0 # 0 = ignore entry 400, get nearest response always
enabled.
402 0 # 0 = ignore entry 400, create connection always enabled.
-------------------------------------------------------------------------
Any and all help most gratefully appreciated.
--: _ _ _ _
_oo__ |_|_ |__ _ | _ |_|_o _ pc at it dot net dot a u |
//`'\_ | (/_|(/_| |_(_|| | || | it.net.au/~pc |
/ PO Box 869, Hillarys WA 6923, AUSTRALIA |
Ted Kouba
sharing. It uses TCP/IP. Works well (or at least better than WFPN 4.0).
-Ted
Peter Caffin <pe...@ptcc.it.net.au> wrote in message
news:92528725...@beldin.it.net.au...
> file://`'\_ | (/_|(/_| |_(_|| | || | it.net.au/~pc |
Peter Caffin
> OTOH, it's common for Winfax network installations to use a
> shared directory on the server. You probably need to uninstall the whole
> fax system and reinstall from scratch set up to use directories on the Linux
> server,
Nah, it shouldn't need this. All files and directories were copied across.
(mounted the old server's directories under Linux with ncpmount). The only
stuff I really had to remake from scratch were passwords. To all
DOS and Windows clients, they're still mounting servername/sys/ as F:
> On the Novell server, by the way, much as I love Linux, if there's a Netware
> server with sufficient user count paid for and patchable to a current level,
> I can think of no reason to abandon it for file and print services.
The main reason is that the hardware is dying and we no longer have anyone
on staff who is Netware-aware. We're primarily a UNIX-running company,
and we'd rather have all these sorts of services together on the one box.
> Netware
> 3.12 on good hardware and patched to current levels is as stable an
> operating system as you're going to find. Only time it ever has to come
> down is to move, modify, or repair the hardware.
This is one thing I do like about Netware: it is very stable, plus, fairly
simple to reboot or fix problems with. I also like its `load module.vlm`
interface -- fairly simple. But in the end, Linux wins out because we're
on more familar ground when it comes to more complex issues.
Back to the issue of Winfax Pro v4.0, someone wrote by email (I'm not sure
if they posted) with a suggestion that what the Netware server is doing --
which the Linux server probably isn't -- is routing between the different
IPX protocols.
Where there are Windows boxes set up to "automatically guess" or set with
Ethernet types that are different to the Winfax Server, the Netware box is
acting as a frame type translator, essentially. If this is so (I'll test
this today), then it should just be a matter of visiting each PC and the
server and changing their IPX frame type to Ethernet_II.
--: _ _ _ _
_oo__ |_|_ |__ _ | _ |_|_o _ pc at it dot net dot a u |
Peter Caffin
> Back to the issue of Winfax Pro v4.0, someone wrote by email (I'm not sure
> if they posted) with a suggestion that what the Netware server is doing --
> which the Linux server probably isn't -- is routing between the different
> IPX protocols.
> Where there are Windows boxes set up to "automatically guess" or set with
> Ethernet types that are different to the Winfax Server, the Netware box is
> acting as a frame type translator, essentially. If this is so (I'll test
> this today), then it should just be a matter of visiting each PC and the
> server and changing their IPX frame type to Ethernet_II.
As a followup to this, lets say it's achieved mixed results. One of the
client PCs can connect up quite happily, the rest cannot. Most are set to
Ethernet_II (including the working one) but there are a couple still on
Auto.
However, a problem introduced by this setup is what appears to be CPU or
network halts; each Windows 95 PC (other OSes aren't affected) will pause
in the middle of opening a window or somesuch, wait for something to
timeout, then carry on doing what it was doing. The pauses can be
anything from 5 sec to a minute or so.
Is Ethernet_II generally succeptable to odd packet sizes and ICMP ping
data from other protocols
(TCP/IP)?
Will switching to Ethernet_802.3 be likely to show any benefit?
(The old Novell server seemed to be set to support 802.2 and 802.3; it's
been taken down during the switch-over period).
Bernd-Ulrich Adrigam
Ethernet_II is used by TCP/IP, so change the IPX frame type to
Ethernet_802.2 at each Win-PC
_AND_ also at the Novell server, if not already set ( at the
server-console: load inetcfg)
_AND_ also in /etc/nwserv.conf at the Linux server.
You can list the Netware netconfiguration by typing "config" at the
server-console.
Bernd
Peter Caffin <pe...@ptcc.it.net.au> schrieb in im Newsbeitrag:
92578742...@beldin.it.net.au...
<snip>
>
> Where there are Windows boxes set up to "automatically guess" or set with
> Ethernet types that are different to the Winfax Server, the Netware box is
> acting as a frame type translator, essentially. If this is so (I'll test
> this today), then it should just be a matter of visiting each PC and the
> server and changing their IPX frame type to Ethernet_II.
>
> --: _ _ _ _
> _oo__ |_|_ |__ _ | _ |_|_o _ pc at it dot net dot a u |
> file://`'\_ | (/_|(/_| |_(_|| | || | it.net.au/~pc |
Ken Agress
(Bernd-Ulrich Adrigam) wrote:
>Hi Peter,
>
>Ethernet_II is used by TCP/IP, so change the IPX frame type to
>Ethernet_802.2 at each Win-PC
Not quite accurate. Ethernet_II *supports* TCP/IP, but it can also be
used for IPX or NetBEUI. So long as the frame type is the same on the
servers and workstations that are on the same network, things should
work fine.
Ken Agress/CNE