NAT causing X problems?

NAT causing X problems?

Post by Jeremy Gibso » Fri, 24 Aug 2001 09:32:17



System: AMD 1.4ghz with 256mb DDR
Dist: Slackware 8.0
kernel: 2.4.5
Iptables: as module
eth0: Realtek (ne2k)
eth1: Intel (pcnet_32)

Problem: When transfering large amounts of data across eth0 to the
internal network on eth1, my X session becomes unusable.  The mouse herks
and jerks. Action clicks never make it to the screen. Windows won't
take focus even with a key commands.

Has anyone had this problem? Eth1 is sharing an IRQ with my soundcard, could
that be it?

Can someone point me in the right direction on this?

-- Jeremy

--------------------------------------------------------------------------------
For it is a false assertion that the sense of man is the measure of things.  On
the contrary, all perceptions as well of the sense as of the mind are according
to the measure of the individual and not according to the measure of the
universe.  And the human understanding is like a false mirror, which, receiving
rays irregularly, distorts and discolors the nature of things by mingling its
own nature with it.   --Francis Bacon
--------------------------------------------------------------------------------

 
 
 

NAT causing X problems?

Post by Cedric Blanche » Fri, 24 Aug 2001 15:56:12



Quote:> System: AMD 1.4ghz with 256mb DDR
> Dist: Slackware 8.0
> kernel: 2.4.5
> Iptables: as module
> eth0: Realtek (ne2k)
> eth1: Intel (pcnet_32)
> Problem: When transfering large amounts of data across eth0 to the
> internal network on eth1, my X session becomes unusable.  The mouse herks
> and jerks. Action clicks never make it to the screen. Windows won't
> take focus even with a key commands.
> Has anyone had this problem? Eth1 is sharing an IRQ with my soundcard, could
> that be it?

NAT consumes CPU cycles but it is quite surprising that is can disturb X that
much. Try Netfilter build in kernel instead of modularized.

--
 Il y a un festnoz retransmis en realaudio. La transmission est, sauf erreur
 assure par oleane:impossible d'avoir image ou son...Que passa ????
 Trop de bretons connects en mme temps ? Ou bien pb avec ci ???
 -+-TS in : GNU - Ils ont plein de connexions, vive la bretagne -+-

 
 
 

NAT causing X problems?

Post by Nils O. Sel?da » Mon, 27 Aug 2001 08:21:30




>> System: AMD 1.4ghz with 256mb DDR
>> Dist: Slackware 8.0
>> kernel: 2.4.5
>> Iptables: as module
>> eth0: Realtek (ne2k)
>> eth1: Intel (pcnet_32)
>> Problem: When transfering large amounts of data across eth0 to the
>> internal network on eth1, my X session becomes unusable.  The mouse herks
>> and jerks. Action clicks never make it to the screen. Windows won't
>> take focus even with a key commands.
>> Has anyone had this problem? Eth1 is sharing an IRQ with my soundcard,
>> could that be it?

> NAT consumes CPU cycles but it is quite surprising that is can disturb X
> that much. Try Netfilter build in kernel instead of modularized.

Also when transferring alot of date this causes lotsn'n'lots of interrupts
to be triggered, seems like mouseinterrupts comes abit back in the queue
here..

--
Nils O. Sel?sdal

 
 
 

1. Ftp problems caused by NAT

The situation:
We recently had to switch ISPs (from PSInet to Verio).  With PSInet,
we were using PSInet's addresses on our internal network as this was
set up before NAT was available.  I decided to switch to using the
network 192.168.2.0/24 for our internal address and NAT them to
our external network of 198.172.243.0/24.  I am using Red Hat Linux
7.1 with a Sangoma T1 card to connect to our ISP.  I am using iptables
to implement our firewall and to set up NAT.

For each machine, I set up a pair of rules such as the following
iptables -t nat -A POSTROUTING -s 192.168.2.137 -j SNAT --to-source
198.172.243.137
iptables -t nat -A PREROUTING -d 198.172.243.137 -j DNAT --to-destination
192.168.2.137

This worked fine for everything but ftp.  For outgoing ftp, I can not
transfer data with the port command, but can with the passive mode.
For incomming ftp, the situation is reversed with the port command
working and passive mode broken.  The problem appears to be that
the machine at our end of the connection likes to give out it's address
as 192.168.2.137 (the internal address) which is useless to the machine
at the other end of the connection.

The problem is that some ftp programs (such as SUN's) do not know how
to do passive mode, and browsers such as Netscape don't like to use
the port command.

To work arround this for incomming ftp, I removed the PREROUTING NAT
entry, added an alias interface of 198.172.243.1 to our router, and
added an alias interface of 198.172.243.137 to our ftp machine.  This
avoids the use of NAT for incomming ftp connections, but somewhat
defeats the purpose of using NAT.

Is there a correct way to fix this?  It would seem that for NAT to work
for ftp, the command channel would have to be intercepted and the internal
addresses changed to the external address.  Can this be done?  What
should I be doing?
--
Tom Schulz

2. HELP! .htaccess disaster

3. Specific nat problem - GURUS HELP (bug in pf/nat?)

4. compressed .tgz files

5. NAT'ing twice causes slowdowns?

6. cron job and e-mail confirmation to users

7. ip nat or ip masq, ttl exceeded (but its not), what causes this?

8. Tape busy, won't come back

9. Nat to Nat?

10. NAT-T (NAT Traversal) support for Linux

11. Is NAT in Linux the same as NAT in FreeBSD ?

12. NAT with 2 public interfaces and 1 privat nat interface

13. Double NAT! Or is that NAT squared?