All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] Small fixes to Polish FAQ
@ 2002-09-13 18:53 Maciej Soltysiak
  2002-09-15 11:25 ` Harald Welte
  0 siblings, 1 reply; 3+ messages in thread
From: Maciej Soltysiak @ 2002-09-13 18:53 UTC (permalink / raw)
  To: netfilter-devel

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1547 bytes --]

Hi,

Here are some small fixes to the FAQ/pl.

Unfortunately, the Netfilter website still contains the old, unupdated
FAQ, i have written to the webmaster but there was no response :(

Regards,
Maciej Soltysiak

diff -Nru /netfilter.old/documentation/FAQ/pl/netfilter-faq.sgml /netfilter/documentation/FAQ/pl/netfilter-faq.sgml
--- /netfilter.old/documentation/FAQ/pl/netfilter-faq.sgml	Fri Jul 26 22:19:42 2002
+++ /netfilter/documentation/FAQ/pl/netfilter-faq.sgml	Fri Sep 13 20:43:00 2002
@@ -410,12 +410,11 @@

 </sect1>

-<sect1>Dlaczego system śledzenia połączeń (connectrion tracking) śledzi
-połączenia UNREPLIED (bez odpowiedzi) z dużym timeoutem?
+<sect1>Dlaczego system śledzenia połączeń (connectrion tracking) śledzi połączenia UNREPLIED (bez odpowiedzi) z dużym timeoutem?

 <p>
 Sprawdziłeś /proc/net/ip_conntrack i znalazłeś wpisy połączeń w stanie
-UNREPLIED o bardzo wysokim licznik (aż do pięciu dni) i zastanawiasz się
+UNREPLIED o bardzo wysokim czasie (aż do pięciu dni) i zastanawiasz się
 dlaczego marnujemy wpisy conntrack (które oczywiście nie są połączeniami)?
 <p>
 Odpowiedź jest prosta: wpisy UNREPLIED są tymczasowe, tj. jak tylko
@@ -459,8 +458,7 @@

 </sect1>

-<sect1>Moja aplikacja libipq mowi "Failed to receive netlink message: No
-buffer space available"
+<sect1>Moja aplikacja libipq mowi "Failed to receive netlink message: No buffer space available"
 <p>
 Oznacza to, ze bufor socketu Netlink po stronie kernela wyczerpał pamięc;
 aplikacja przestrzeni użytkownika nie jest w stanie obsłużyć ilości danych

[-- Attachment #2: faq_pl --]
[-- Type: TEXT/plain, Size: 1368 bytes --]

diff -Nru /netfilter.old/documentation/FAQ/pl/netfilter-faq.sgml /netfilter/documentation/FAQ/pl/netfilter-faq.sgml
--- /netfilter.old/documentation/FAQ/pl/netfilter-faq.sgml	Fri Jul 26 22:19:42 2002
+++ /netfilter/documentation/FAQ/pl/netfilter-faq.sgml	Fri Sep 13 20:43:00 2002
@@ -410,12 +410,11 @@
 
 </sect1>
 
-<sect1>Dlaczego system ¶ledzenia po³±czeñ (connectrion tracking) ¶ledzi
-po³±czenia UNREPLIED (bez odpowiedzi) z du¿ym timeoutem?
+<sect1>Dlaczego system ¶ledzenia po³±czeñ (connectrion tracking) ¶ledzi po³±czenia UNREPLIED (bez odpowiedzi) z du¿ym timeoutem?
 
 <p>
 Sprawdzi³e¶ /proc/net/ip_conntrack i znalaz³e¶ wpisy po³±czeñ w stanie
-UNREPLIED o bardzo wysokim licznik (a¿ do piêciu dni) i zastanawiasz siê
+UNREPLIED o bardzo wysokim czasie (a¿ do piêciu dni) i zastanawiasz siê
 dlaczego marnujemy wpisy conntrack (które oczywi¶cie nie s± po³±czeniami)?
 <p>
 Odpowied¼ jest prosta: wpisy UNREPLIED s± tymczasowe, tj. jak tylko
@@ -459,8 +458,7 @@
 
 </sect1>
 
-<sect1>Moja aplikacja libipq mowi "Failed to receive netlink message: No
-buffer space available"
+<sect1>Moja aplikacja libipq mowi "Failed to receive netlink message: No buffer space available"
 <p>
 Oznacza to, ze bufor socketu Netlink po stronie kernela wyczerpa³ pamiêc;
 aplikacja przestrzeni u¿ytkownika nie jest w stanie obs³u¿yæ ilo¶ci danych

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2002-09-15 19:42 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-09-13 18:53 [PATCH] Small fixes to Polish FAQ Maciej Soltysiak
2002-09-15 11:25 ` Harald Welte
2002-09-15 19:42   ` Stephen Frost

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.