On Mon, Jan 28, 2002 at 10:02:13PM +0300, Alexey Kuznetsov wrote:
> > this partial retransmission is dropped, assuming that the next
> > retransmission will be a retransmission of the whole packet, as we have
> > seen it before.
> The assumption can be wrong. This happens with linux. Even if
> tcp_retrans_collapse is on, collapcing may have obstacles not allowing
> to collapse.
but why would we have a partial retransmission in the first place?
under which circumstances would the receiver only ACK half the packet
it has received, causing a partial retransmission on the sender side?
The problem the comment was referring to was only if we already have
seen a full PORT command inside the first packet, but a retransmission
does not contain the full PORT.
> > a lot of cases (i.e. PORT command split over two seperate packets)
> What is difficult in this case? I simply do not understand this...
> If you have a defined transofrm, there is no problems in partial rewrites.
It is not difficult in the case above (i.e. conntrack has seen PORT command
in full length, only nat is seeing retransmission).
It's difficult in the case where we have a PORT command (or similar) split
over two packets all the time. Not talking about retransmissions. W'd have
tcp packet one: "PORT 192,16"
packet two: "8,1,1,12,34\r"
(or even more packets). How would we reliably match against the command?
Where do you draw the line? what is about each character in one packet?
To cover this (other) case, we would need to remember a certain amount of
payload of every ftp connection. to be precise: strlen(MAX_PORTCMD_LEN-1)
bytes. We would need to keep this like a ringbuffer.
We've been discussing this on the netfilter developer workshop - but I was
the only one arguing for this approach. Normally I'm arguing from your
point of view and the others have to defend ;)
I rarely see the 'partial port command' issue on all the systems under my
adminstration - and we haven't received more than a hand full of people
reporting the respective printk() during all the time this code exists.
And please don't think that any previous linux version did better than
we currently do.
> > your kernel. transparent proxies are better if you want to be perfect in
> > this.
> No ack. If it were a real fault of approach, it would be true.
> But as soon as it is explained only by lazyness of author... no ack.
well, don't blame me - I'm not the author ;).
I think we have to find a practical trade-off between complexity and staying
It's always a question of how much effort do you want to spend on those things.
You definitely _can_ implement the conntrack / nat / payload modification /
sack handling / sequence number alteration in a way which covers all cases,
and handles everything correctly.
But then, nat is always ugly and un-perfect. And how much additional
code complexity and performance penalty do you want to have for covering
> It is simply unpleasant. When seeing report of Cisco director blocking
> some valid data, we refer to Cisco. But when our own code does the same
> shit, it is _double_ shame.
I know you are a perfectionist. I consider myself as a perfectionist as well,
and I think the current netfilter conntrack/nat code tries quite hard to
get it right in almost all cases.
Live long and prosper
- Harald Welte / laforge@xxxxxxxxxxxx http://www.gnumonks.org/
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M-
V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*)