|Summary:||Problem with TCP/IP Stack?|
|Product:||[Retired] Red Hat Linux||Reporter:||dchann|
|Component:||ppp||Assignee:||Nalin Dahyabhai <nalin>|
|Status:||CLOSED NOTABUG||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2002-12-14 01:37:57 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
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 184.108.40.206:220.127.116.11\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 firstname.lastname@example.org 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.