Bug 7230

Summary:	Problem with TCP/IP Stack?
Product:	[Retired] Red Hat Linux	Reporter:	dchann
Component:	ppp	Assignee:	Nalin Dahyabhai <nalin>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	high	Docs Contact:
Priority:	high
Version:	5.2	CC:	ml
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2002-12-14 01:37:57 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description dchann 1999-11-22 17:25:06 UTC

Hello,

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
install-time.

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)
ppp-2.3.5 (binary)
ipfwadm-2.3.0 (binary)

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 199.212.15.230:199.212.15.222\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.

/sbin/depmod -a
/sbin/modprobe ip_masq_ftp
/sbin/modprobe ip_masq_raudio
/sbin/modprobe ip_masq_irc

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 dchann.ca or call me at the number below if you require
more information.

Dean Channing
Technical Assistant
807 Northwest Network
Tel: (807) 768-6621
Fax: (807) 767-8008
http://www.807-city.on.ca

Comment 1 Nalin Dahyabhai 2000-01-20 01:34:59 UTC

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.

Comment 2 Mario Lorenz 2000-02-02 10:23:59 UTC

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.