Red Hat Bugzilla – Bug 7230
Problem with TCP/IP Stack?
Last modified: 2008-05-01 11:37:53 EDT
The following was install for a modem pool. RedHat Linux 5.2 on a 486DX
66Mhz, with: 16 Megs/RAM, Intel Ethernet 10/100 NIC, 2 Digi PC/x (8 ports),
2 IDE HDD (325 Megs each). Installation of the LAN was done at
The setup works perfectly for windows 95/98 users and Linux users. But for
some reason Win 3.x users can log on to the server, but can't search the
internet. I followed the IP-Masquerade HOW-TO and compiled the appropriate
options into the kernel. The following packages were also installed:
mgetty-1.1.14 (source code)
When the users first log on, their login shell is set to a perl script
which determines their ip address (based on the port the user logged in to
ie. ttyD0 = first ip address). Then it passes execution of the script to
"/usr/sbin/pppd 126.96.36.199:188.8.131.52\n" which starts pppd.
This is as far as I can follow. I setup the ipfwadm default policy to (and
yes, I know you shouldn't, but we don't want a firewall, so it seemed good
enough) "ipfwadm -F -p masquerade" and added that and the following lines
to our /etc/rc.d/rc.local file.
I did come across another problem, that may be related to this one. We
noticed that when a user log on, and tries to ping their own address,
nothing is returned. It is like nobody can see the ipaddress, unless a
request comes from it first. I feel that Trumpet Winsock (for Win 3.x
users) might be trying to do a reverse lookup of the ipaddress, and if it
can't find it, it disables the use of the TCP/IP stack. But I am not sure.
Anyway, that is all the information I can think of for now. Please e-mail
me at email@example.com or call me at the number below if you require
807 Northwest Network
Tel: (807) 768-6621
Fax: (807) 767-8008
If Trumpet is indeed failing on a reverse lookup, then I'd suspect a problem
with DNS. If Trumpet Winsock can use DNS server information supplied by the
PPP server, upgrading to a recent release of pppd and using its "ms-dns"
option might solve the problem, although if you're only seeing problems on
Windows 3.x clients I'd suspect the client software.
You do not want to use MASQ as a default policy. This most likely masquerades
DNS responses as well. Use a proper FORWARD rule and masq only the dialup
adresses. Judging from your example, you do use official IP space for your
dialup, that might mean you dont need any masquerading at all.
Side remark: If you give out your IP's based on port numbers, you could also
stuff the IP adresses into /etc/ppp/options.ttyS<number>, one file per port.
This would allow you to even use mgetty's AUTOPPP so that you dont need login
scripts on the clients at all.