On Sat, 6 Jul 2002, Henrik Nordstrom wrote:
> The recent discussions and Oskar Andreassons work on a iptables
> tutorial made me take a closer look into the TCP tracking states, and
> I notices a couple of odd things that looks like they may be bugs..
>
> 1. What is the use of LAST_ACK? From what
On Tue, 2 Jul 2002, Patrick Schaaf wrote:
> please have a look at init_conntrack(), in ip_conntrack_core.c.
>
> static unsigned int drop_next = 0;
> ...
> if (drop_next >= ip_conntrack_htable_size)
> drop_next = 0;
> if (!early_drop(&ip_conntrack_hash[drop_
On Tue, 2 Jul 2002, Harald Welte wrote:
> On Mon, Jul 01, 2002 at 09:50:18AM +0200, Balazs Scheidler wrote:
> > On Sat, Jun 29, 2002 at 12:36:36PM +0200, Henrik Nordstrom wrote:
> > > On Saturday 29 June 2002 11.46, Patrick McHardy wrote:
> > > So the question to the Netfilter core team is if it
On Tue, 2 Jul 2002 [EMAIL PROTECTED] wrote:
> I would like to SNAT icmp fragmentation-needed messages that have source
> address from private network range (RFC1918). Because these packets are
> part of valid TCP connection, they are processed by ip_conntrack module
> and cannot be SNATed...
Jus
On Mon, 1 Jul 2002, Henrik Nordstrom wrote:
> > - rewrite the IPT_CONTINUE targets as matches
>
> I am not very fond of this.. besides the order dependency it also has the
> question on how to easily determine what will happen with the packet.. No
> obvious distinction between something that matc
On Sat, 29 Jun 2002, Henrik Nordstrom wrote:
[...]
> I proposed adding a new class of iptables things between matches and
> targets, being neither a match for filtering or a target that
> determines the ultimate fate of the packet. The names proposed for
> these in the discussion was modifiers or
On Wed, 26 Jun 2002, Henrik Nordstrom wrote:
> A running TCP packet flow (even for a "half-closed" uni-directional TCP)
> is never uni-directional. If there is data in flowing in one direction
> then there is ACKs in the other direction.
Yes, right.
> Idea on how conntrack could deal with such
On Tue, 25 Jun 2002, Henrik Nordstrom wrote:
> > if conntrack doesn't see a FIN or RST packet, it won't be forwarded by
> > the machine and thus never arrive at the receiver. The sender will thus
> > retransmit, and hope the packet makes it next time.
>
> FIN will be retransmitted a couple of t
On Tue, 25 Jun 2002, Harald Welte wrote:
> > According to your first mail, the machine has 256M RAM and you issued
> >
> > insmod ip_conntrack 16384
> >
> > That requires 16384*8*~600byte ~= 75MB non-swappable RAM.
> >
> > When you issued "iptables -t nat -L", the system tried to reserve plus
> >
On Tue, 25 Jun 2002, Jean-Michel Hemstedt wrote:
> > From where do you think that the module usage counter reports how many
> > packets/connections are handled (currently? totally?) by the module.
> > There is no whatsoever connection!
>
> module usage counter increases when a TARGET needs it (i.
On Tue, 25 Jun 2002, Harald Welte wrote:
> > But this raises one additional problem:
> > 1) the hash index size and the hash total size should be configurable
> > separately (get rid of that factor 8, and use a free list for the tuple
> > allocation).
> > 2) NAT hash sizes should also be configur
On Tue, 25 Jun 2002, Harald Welte wrote:
> > According to your first mail, the machine has 256M RAM and you issued
> >
> > insmod ip_conntrack 16384
> >
> > That requires 16384*8*~600byte ~= 75MB non-swappable RAM.
> >
> > When you issued "iptables -t nat -L", the system tried to reserve plus
> >
On Tue, 25 Jun 2002, Jean-Michel Hemstedt wrote:
> > connections. As good as possible. If the conntrack table becomes full,
> > there are two possibilities:
> >
> > - conntrack table size is underestimated for the real traffic flowing
> > trough. Get more RAM and increase the table size.
> > -
On Tue, 25 Jun 2002, Jean-Michel Hemstedt wrote:
> > > not only: a crashed endpoint breaking the tcp sequence causes also
> > > garbage entries in conntrack (known issue).
> >
> > Did I miss something? What do you mean by this "known issue" above?
> > I don't understand what do you refer.
>
> I r
On Sun, 23 Jun 2002, Jean-Michel Hemstedt wrote:
> > > I'm doing some tcp benches on a netfilter enabled box and noticed
> > > huge and surprising perf decrease when loading iptable_nat module.
> >
> > Sounds as expected.
>
> loading a module, doesn't mean using it (lsmod reports it as 'unused'
>
On Sun, 23 Jun 2002, Jean-Michel Hemstedt wrote:
> > So I'm guessing that large number of entries in conntrack table is
> > evidence that packets are being lost.
>
> not only: a crashed endpoint breaking the tcp sequence causes also
> garbage entries in conntrack (known issue).
Did I miss someth
On Thu, 20 Jun 2002, Jean-Michel Hemstedt wrote:
> I'm doing some tcp benches on a netfilter enabled box and noticed
> huge and surprising perf decrease when loading iptable_nat module.
>
> - ip_conntrack is of course also loading the system, but with huge memory
> and a large bucket size, the pr
On Fri, 21 Jun 2002, Jozsef Kadlecsik wrote:
> On Fri, 21 Jun 2002, Patrick Schaaf wrote:
>
> > > What about simply returning by an error code if there is an attempt to
> > > create a chain wich clashes with a target name?
>
> Here is the patch according to my p
On Fri, 21 Jun 2002, Patrick Schaaf wrote:
> > What about simply returning by an error code if there is an attempt to
> > create a chain wich clashes with a target name?
>
> Wasn't there recent discussion about "how do I find all available
> target names"? But I agree in principle, that would be
On Fri, 21 Jun 2002, Patrick Schaaf wrote:
> > The built-in chain and target names are all fully capitalized.
> > What about the simple restriction that user-defined chain name cannot be a
> > string consisting of capitalized letters only.
>
> This is again breaking backwards compatibility. For e
On Thu, 20 Jun 2002, Laurence J. Lane wrote:
> The problem deals with user-defined chain names clashing with iptables
> module names. Basically, it's entirely possible to create a user-defined
> chain with the same name (case sensitive) as a target module, but the
> new chain cannot be used as a
On Fri, 14 Jun 2002, Balazs Scheidler wrote:
> It is a strange idea I know, but I'd be interested in what the opinion of
> the core netfilter developers is on porting the whole netfilter subsystem to
> Solaris?
You must have plenty of time. I envy you! :-)
> Apart from the technical issues, wou
On Wed, 12 Jun 2002, Balazs Scheidler wrote:
> > > Is you patch available somewhere?
> >
> > Not yet, but real soon I'll post it :-).
>
> Can you send me what you have available? I'd like to close my transparency
> project, and so I'd be willing to contribute to the conntrack exemption
> project
Hi,
On Mon, 10 Jun 2002, Oskar Andreasson wrote:
> Sorry for the late reply. I never suggested that this usage (see
> below) is only theoretical and I'm very sorry if it was misinterpreted
> as that.
Oh, no! I wanted to *second* you in this argument.
Regards,
Jozsef
> - Original Message -
On Fri, 7 Jun 2002, Oskar Andreasson wrote:
> Another, related, usage is
> if we have a redundant firewall (I haven't seen this discussed so far
> so Consider this:
>
> 1 main firewall
> 1 router
> and a secondary firewall.
>
> The three are set up in a routing zone. If the main firewall goes
On Wed, 5 Jun 2002, Balazs Scheidler wrote:
> ok, should I simply add fields somewhere in struct ip_conntrack, or there's
> a bitfield I can add a flag to?
There is no such bitfield you could use at the moment.
> Looking at the struct I can't see a place general enough, so I can add a new
> fie
On Wed, 5 Jun 2002, Balazs Scheidler wrote:
> Let me think a bit about it. For UDP packets I don't really need
> conntracking sessions, I only need to translate single packets, but I'd like
> to avoid messing with IP and UDP header translation myself.
>
> So NOTRACK is good for me, I don't need N
On Wed, 5 Jun 2002, Balazs Scheidler wrote:
> The only features for an UDP proxy is the following:
> * being able to receive frames originally destined elsewhere (the REDIRECT
> case)
> * being able to receive frames from an arbitrary host, originally destined
> to another arbitrary host (the
On Tue, 4 Jun 2002, Balazs Scheidler wrote:
> I'd like to make tproxies easier to administer, so I'm thinking about a
> simple way of matching tproxied packets, which can be ACCEPTed from the
> INPUT chain.
>
> Possible solutions:
>
> * use a new state (called TPROXY), which would be applied to a
On Mon, 3 Jun 2002, A. van Schie wrote:
> > > What I find strange is that it starts with 2 almost the same packets
> > > (except for ip_id), and that they both get the conntrack state NEW!
> >
> > What else state should they got? But those first two packets looks
> > strange, that's true.
>
> I e
Hi,
On Sun, 2 Jun 2002, A. van Schie wrote:
> I saw something strange that I think comes from ip_conntrack.
>
> I'm using conntrack-state to filter my packets.
> A simple version of my rules look like this:
> iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> iptables -A OUT
On 30 May 2002, Andras Kis-Szabo wrote:
> > don't forget that ICMP error messages only quote the first 64 bytes of the
> > original packet. Adding up IP and TCP headers (both 20 bytes without
> > options), you only have 24 bytes of original payload. This might be somewhat
> > more in UDP though d
On Wed, 29 May 2002, Maciej Soltysiak wrote:
> I was hoping for some kind of discussion on it.
> Also i like it seperated from unclean, because unclean does not allow you
> to:
> -m unclen --unclean-option-x
Yes, the "monoliticy" of unclean is a little bit disturbing. I'd be much
more better if
Hi Maciej,
On Wed, 29 May 2002, Maciej Soltysiak wrote:
> please lookup my mail with subject line:
> [PATCH] IP unused bit match.
>
> nobody cared to reply, strange.
Overloaded-like-a-dog... Sorry, it must be frustating for you.
I think it'd be much more better if the checking would be added t
On Tue, 28 May 2002, Jean Bel wrote:
> I don't think so because it is the only iptables command which causes
> this error and it takes a few times before sending this error message
> even if it's the first iptables I launch. I think there is an infinite
> loop which take all the memory.
> Did you
Hello,
I have just updated the newnat compatible tcp-window-tracking patch in
patch-o-matic/extra.
- a nasty window scaling related bug fixed. Thanks to Mattias Wadenstein
and Josip Rodin for reporting me the problem.
- systctl parameter ip_conntrack_tcp_loose added: when a
connection is pic
Hi Roberto,
On Thu, 23 May 2002, Roberto Romano wrote:
> I just want to report an endiannes issue found with 2.4.18+newnat running on
> a PPC architecture.
>
> The problem comes from a change in the definition of both ip_conntrack_manip
> and ip_conntrack_tuple structures.
> (kernel/include/linu
Hi,
On Tue, 7 May 2002, Jacques WERNERT wrote:
> as shadha on 04 Apr 2002, I'm getting an "LIST_DELETE:
> ip_conntrack_core.c:163" in my /var/log/messages and then my machine hangs.
>
> I'm running Linux 2.4.18 on a P133 with no extra patches as my firewall.
> It's an UP machine with
> gcc versi
On Thu, 18 Apr 2002, Patrick Schaaf wrote:
> I like the idea (a lot!), as well as the placement, but I'm not really
> fond of the name. May I suggest one of two things?
>
> A) Call the table "netdev", with chains "RX" and "TX"
> B) Call the table "filter", with chains "RX" and "TX"
>
On Wed, 17 Apr 2002, Joakim Axelsson wrote:
> We would like to call this "border". Just the same as "filter INPUT", but
> the absoluty first thing that happens after the packet comes from the
> netcard-driver. Behaps a border OUTPUT doing the same thing just before
> entering the netcard driver.
On Wed, 17 Apr 2002, Brad Chapman wrote:
> > So we need to filter them out before conntrack and currently that seems
> > impossible without adding the notrack/prestate table.
> Everyone so far seems to be thinking about adding a new
> autonomous table with separate hooks positioned at a
On Wed, 17 Apr 2002, Harald Welte wrote:
> No, I'm fine with that. However, we might also think about adding
> debug output to the NAT code, since paket manipulations are done without
> any rule matching (after the first packet has passed through).
> So maybe there could be some macro used at se
On Wed, 17 Apr 2002, Brad Chapman wrote:
> > As 2.4.20 comes out with newnat included, I'd like to start to work on the
> > debug and notrack tables we talked about at the netfilter workshop in
> > Enschede.
>
>Before I go any further, is any of this slated for 2.5 only?
I'd say no. It'd
On Wed, 17 Apr 2002, Javor Marinov wrote:
> ok oks , this patch is apply to the kernel source and compiling whith
> small warnings , so now its good ,
What are those "small warnings", exactly?
> BUT I GET THE KERNEL DUMP
> Apr 10 02:09:48 NAT-Router-9 kernel: Unable to handle kernel NULL poin
On Mon, 8 Apr 2002, Takuya Satoh wrote:
> > newnat has an own talk-conntrack-nat.patch. In the extra directory you can
> > find the non-newnat variant.
>
> Thanks, but where is the newnat version then? The only talk modules are
> these in the extra dir:
You're right and I spread false informati
On Mon, 8 Apr 2002, Takuya Satoh wrote:
> the extra/talk-conntrack-nat.patch doesn't apply on the top of
> newnat13+tcp-window-tracking. There is reject in
> include/linux/netfilter_ipv4/ip_conntrack.h which I cannot resolve even
> manually. netfilter-1.2.6a-cvs20020405 with patches applied by
On 28 Mar 2002, Frank wrote:
> and this BUG appeared again today but with Kernel 2.4.19-pre4-ac2 and
> Iptables CVS from 27.03.02. Applied all pending-patches cleanly but
> newnat would so i forced it and compiled fine.
Still, there is no proof that this is a bug.
> Mar 28 01:26:32 Frankux kern
On 27 Mar 2002, Frank wrote:
> kernel: ip_conntrack: max number of expected connections 1 of ftp
> reached for 195.211.47.154->80.129.111.208, reusing
>
> appeared in my Syslog Today. Using CVS Version from March 23 and Kernel
> 2.4.18-pre3-ac5 after 3 Days uptime. Reloaded my Iptables Script and
On Thu, 21 Mar 2002, Marc Haber wrote:
> On Tue, 19 Mar 2002 11:56:50 +0100 (CET), Jozsef Kadlecsik
> <[EMAIL PROTECTED]> wrote:
> >Yes, that's all what is required to switch on debugging.
>
> I now have a syslog slice showing a complete cycle of "boot -
>
On Tue, 19 Mar 2002, Marc Haber wrote:
> On Tue, 19 Mar 2002 08:56:03 +0100 (CET), Jozsef Kadlecsik
> <[EMAIL PROTECTED]> wrote:
> >Do you have an SMP machine?
>
> No, it is an old faithful single processor P133.
Ack!
> >Can the crash be reproduced at will?
>
On Mon, 18 Mar 2002, Marc Haber wrote:
[...]
> However, today, I was on the phone (having called out myself) and was
> able to finish the call normally. Immediately afterwards, somebody
> tried to call me. The phone rang, but I wasn't able to hear the
> called. Nor did he hear me. After consultin
Hi Kisza,
On 13 Mar 2002, Andras Kis-Szabo wrote:
> I totally run out of ideas, so any comments are welcome! :)
But what is the problem? I'm blind, I cannot see it...
Or are you thinking on introducing NAT for IPv6 (guessing)?
Regards,
Jozsef
-
E-mail : [EMAIL PROTECTED], [EMAIL PROTECTED]
WW
Hello,
I have updated the tcp-window-tracking patch in cvs.
One serious bug is fixed: window parameters were updated only once
and not whenever it was required in the case of NAT. This caused
connection freeze when packets were enlarged at NATing the carried IP
address/port.
Other modifications
On Thu, 28 Feb 2002, Brad Chapman wrote:
> I am currently writing my conntrack expiration patch for the
> non-newnat version of the conntrack core. When I examined the core on
> ways to properly destroy a connection entry, I found several:
>
> ct->ct_general->destroy()
> skb->nf
Hi Fabrice,
On Tue, 26 Feb 2002, Fabrice MARIE wrote:
> Any news to what is going to happen with the testsuite ? Just curious.
> Last time I tryied to compile it, it wouldn't even compile
> anymore..
I have a working version on which I test most of my patches before
doing any real-life testing.
On Thu, 21 Feb 2002, andre achternaam wrote:
> In the if statement ctinfo is checked for some conditions. The way they test
> the conditions tells me that the IP_CT_ESTABLISHED and IP_CT_IS_REPLY are
> bitmasks because they are added and they are part of an enumaration. When i
ctinfo doesn't sto
56 matches
Mail list logo
