All of
 help / color / mirror / Atom feed
From: Bogdan Costescu <>
To: Christian Reis <>
Cc: Trond Myklebust <>,
	Philippe Troin <>, <>
Subject: Re: SM_UNMON again -> kernel
Date: Mon, 21 Jul 2003 15:08:12 +0200 (CEST)	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Sun, 20 Jul 2003, Christian Reis wrote:

> Oh, the masquerading has nothing to do with NFS.

It might, by error. I don't know if this is relevant as I seem to have 
lost track of this thread, but some keywords suggested me to write this 

In some conditions when using iptables, UDP packets get wrongly re-routed
to the loopback interface. I've hit this some months ago with a RedHat 8.0
installation with the current (at that time) 2.4.18-something kernel; I
don't know if things changed in the meantime as I have rewritten the
iptables rules...

It seems that some forms of MASQ/NAT and marking packets (fwmark) don't 
play well together; this is mentioned towards the end of:

but there was not enough information about what exactly would happen.  So
when I did use them (MASQ and fwmark) together, some UDP packets which had
perfectly good IP headers (source: server-IP, dest: client-IP) would not
make it onto the wire towards the client, but could be captured with
tcpdump attached to "lo". I've searched the netfilter list and came up
with some hits, but there were only questions (so the problem is known!)  
and no solution.

Incidentally, I've noticed this packet loss when trying to mount a NFS
export. I don't remember exactly where the packet loss happened, but it
was always at the same point in the packet exchange (well, out of 5-6
tries that I've made, also with different client OSes) - most probably,
the final packet, the answer to the "MOUNT" request (sorry, fuzzy memory).
If I'd clear the iptables rules on the server, the same mount command
would succeed immediately.  After deleting all the rules that used
"fwmark" (but still using MASQ), everything worked fine.

Bogdan Costescu

IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868
E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De

This email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here:
NFS maillist  -

  reply	other threads:[~2003-07-21 13:08 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-11  6:16 SM_UNMON again -> kernel Lawrence Ong
2003-07-11  9:38 ` Trond Myklebust
2003-07-13  3:22   ` Philippe Troin
2003-07-13 15:25     ` Trond Myklebust
2003-07-13 18:00       ` Philippe Troin
2003-07-13 23:36         ` Lawrence Ong
2003-07-14  8:56         ` Trond Myklebust
2003-07-18  1:08           ` Philippe Troin
2003-07-19  3:26             ` Philippe Troin
2003-07-19 16:22               ` Christian Reis
2003-07-20 23:28                 ` Trond Myklebust
2003-07-20 23:45                   ` Christian Reis
2003-07-21 13:08                     ` Bogdan Costescu [this message]
2003-07-13  4:25   ` Lawrence Ong
2003-07-14  8:47     ` Trond Myklebust
2003-07-14 23:42       ` Lawrence Ong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.