Also sprach Marc Haber <[EMAIL PROTECTED]> (Sun, 04 Dec 2005 14:01:37 +0100): > On Sun, 4 Dec 2005 12:18:21 +0100, Richard Mittendorfer > <[EMAIL PROTECTED]> wrote: > >Also sprach "Felix M. Palmen" <[EMAIL PROTECTED]> (Sun, 4 Dec 2005 > >10:22:34 +0100): > >> Was ist dann bei UPD-Verbindungen, die ja keinen dedizierten > >> Abbau-Mechanismus haben? Blockieren die alle für mindestens 5 Tage > >> einen Tabellen-Eintrag? > > > >ip_conntrack_udp_timeout > > > >Wie schon erkannt, ist udp "stateless" (keine "established" Verbindung). > > Wenn ich mich richtig erinnere, hat Netfilter bei klassischem > "Frage-Antwort-UDP" einen recht kurzen Timeout, der bei Beobachtung > eines zweiten "Antwort"-Pakets drastisch erhöht wird. So erhofft man, > Streaminganwendungen zu erkennen. > > Bei Amanda fällt dieses Verfahren auf die Schnauze, weil dort im > ersten Paket drin steht "schick mir mal eine Schätzung für die Größe > Deines Dateisystems /usr", in der Antwort steht "Ja, in Ordnung", und > wenn dann zehn Minuten später die eine Seite mit der Schätzung fertig > ist, ist die Session auf dem Paketfiler längst ausgetimed und das > Paket mit der "richtigen" Antwort zerschellt.
Da scheint wohl ip_conntrack_udp_timeout_stream zu helfen? Nein - tut es nicht. Hab mir das nun genauer angesehen: Ein UDP-Link wird einige Zeit mit einem kurzen timeout (default 30s) gehalten, und bei Bedarf (aka falls es als "stream" erkannt wird) obiges timeout_stream (180s) verwendet. Gehen aber zu wenige Packete/Zeit zum Sender retour, wird das nicht als stream erkannt und ip_ct_udp_timeout greift. sl ritch
