> > Alternatively, if no answer comes back at all, the conntrack is in the
> > (extra) state UNREPLIED. When the connection table becomes full, UNREPLIED
> > connections are recycled preferentially.
>
> Hey, this is not fair !
The behaviour is as fair as it can be, IMO.
> This behaviour is
> My point is not to go "on and on and on", but "deeper and deeper
> and deeper". Once I reach to right amount of knowledge about it,
> I will fix it (or I will make it so clear that anybody which
> has followed the thread will be abble to fix it).
The latter approach won't be effective. You want
Hi all,
Ok, let's conclude this thread.
What was the initial problem ?:
---
FAQ: Some invalid ACK packets are going through my firewall !!!
By reading the current documentation, most of the people are assuming
that there is a perfect match between the states of t
Hello !
hope this is the right list & you're not annoyed.
What I am looking for:
- logging the netflter logs to an own file (think it would be a great feature
for the LOG target).
I was looking all over the web and also a bit through the source code of
netfilter, but found nothing.
- isn't ther
> hope this is the right list & you're not annoyed.
As a usage question, the user mailinglist, [EMAIL PROTECTED],
would have been the right place to ask.
> What I am looking for:
> - isn't there a particular piece of code where I can manually change kern to
> local4 or whatsoever?
Use the --l
On Saturday 08 June 2002 10:21, Patrick Schaaf wrote:
> Mostly in ip_conntrack_core.c. The early_drop() and unreplied()
> functions implement the checking, based on the IPS_ASSURED bit in
> conntrack->status. Use "grep" to see where that bit is set.
ip_conntrack_core is also where the NEW/ESTABL
On Thu, Jun 06, 2002 at 02:24:05PM +0200, Martin Josefsson wrote:
> There exists code to disable tracking of broadcasts but it's insice a
> #if 0 / #endif in ip_conntrack_core.c and looks like some old debugging
> code as it has printk's and stuff.
>
> this patch removes that chunk and replaces i
On Fri, Jun 07, 2002 at 11:42:08AM +0200, Mikkel Christiansen wrote:
> Hi
>
> I'm still not sure I quite understand what actions an
> ACK packet from an unregistered connection causes when
> running in connection-pickup mode. Mainly, I'm interested
> in knowing whether it causes a new connecti
On Thu, Jun 06, 2002 at 02:24:04PM +0200, Martin Josefsson wrote:
> Here's the patch that lead up to the first patch (the renaming of
> death_by_timeout and exporting it).
ah. now I understand what the exporting was all about :)
> This patch adds a check to ip_ct_refresh() so it doesn't update t
On Sat, 2002-06-08 at 09:35, Harald Welte wrote:
> hm. I would generally agree with you, but there is one issue which
> needs to be looked into before considering this patch:
>
> What happens if some client sends an ip-unicast diagram as link layer
> broadcast? How does the linux stack react t
On Sat, 2002-06-08 at 09:37, Harald Welte wrote:
> ah. now I understand what the exporting was all about :)
:)
> sounds interesting and should give quite some speedup. Did you do any
> benchmarking on that?
I need to get a slower test-router so I can benchmark properly :(
I need to get a v
On Sat, Jun 08, 2002 at 04:13:58AM +0200, Emmanuel Fleury wrote:
> If I have to fix the documentation, I would like to understand the
> exact behaviour of the connection tracking module.
>
> My point is not to go "on and on and on", but "deeper and deeper
> and deeper". Once I reach to right amou
Hi,
Excellent.
Thanks a lot for pointing ip_conntrack_core.c and explain all this !
Henrik Nordstrom wrote:
>
> The above states are "ctinfo" and is derived from the conntrack state
> flags and the packet currently being processed. The actual conntrack
> state flags are:
>
> ASSURED
13 matches
Mail list logo
