iptraf i kernel 2.2.2 oraz network stals

[Marcin Dalecki]

Tomasz K³oczko wrote:
> 
> Dwiez rzeczy.
> Primo o przej¶ciu (w³a¶nie) na 2.2.2 nie mogê uruchomiæ iptraf. Wyrzuca
> komunikat :
> 
> IP traffic monitor active in another process


W³a¶nie co¶ nieco¶ zmieniono pod wzglêdem filtrowania pakietów w
przej¶ciu
z 2.2.1 na 2.2.2. Doparwdy nie rozumiem jednak zbytnio dlaczego ma to
toaki wp³yw na iptraf!.

diff -u --recursive --new-file v2.2.1/linux/net/core/filter.c
linux/net/core/filter.c
--- v2.2.1/linux/net/core/filter.c	Mon Jan 12 15:28:25 1998
+++ linux/net/core/filter.c	Thu Feb 18 11:59:28 1999
@@ -11,6 +11,8 @@
  * modify it under the terms of the GNU General Public License
  * as published by the Free Software Foundation; either version
  * 2 of the License, or (at your option) any later version.
+ *
+ * Andi Kleen - Fix a few bad bugs and races.
  */

Mo¿e iptraf jest zimplementowny jako filtr pakietów? Nie znam go zbyt
dok³adnie.

Albo spróbuj wywaliæ t± zmianê:

diff -u --recursive --new-file v2.2.1/linux/include/net/tcp.h
linux/include/net/tcp.h
--- v2.2.1/linux/include/net/tcp.h	Tue Jan 19 11:32:53 1999
+++ linux/include/net/tcp.h	Mon Feb 22 14:51:31 1999
@@ -912,7 +912,7 @@
  * can generate.
  */
 extern __inline__ void tcp_syn_build_options(__u32 *ptr, int mss, int
ts, int sack,
-					     int offer_wscale, int wscale, __u32 tstamp)
+					     int offer_wscale, int wscale, __u32 tstamp, __u32 ts_recent)
 {
 	/* We always get an MSS option.
 	 * The option bytes which will be seen in normal data
@@ -936,7 +936,7 @@
 			*ptr++ = __constant_htonl((TCPOPT_NOP << 24) | (TCPOPT_NOP << 16) |
 						  (TCPOPT_TIMESTAMP << 8) | TCPOLEN_TIMESTAMP);
 		*ptr++ = htonl(tstamp);		/* TSVAL */
-		*ptr++ = __constant_htonl(0);	/* TSECR */
+		*ptr++ = htonl(ts_recent);	/* TSECR */
 	} else if(sack)
 		*ptr++ = __constant_htonl((TCPOPT_NOP << 24) | (TCPOPT_NOP << 16) |
 

Dodatkowo zachowanie jakie opisujesz mo¿e byæ wywo³ane nastêpuj±cym:


diff -u --recursive --new-file v2.2.1/linux/net/ipv4/af_inet.c
linux/net/ipv4/af_inet.c
--- v2.2.1/linux/net/ipv4/af_inet.c	Thu Jan  7 15:11:41 1999
+++ linux/net/ipv4/af_inet.c	Mon Feb 22 09:05:55 1999
@@ -5,7 +5,7 @@
  *
  *		PF_INET protocol family socket handler.
  *
- * Version:	$Id: af_inet.c,v 1.82 1999/01/04 20:36:44 davem Exp $
+ * Version:	$Id: af_inet.c,v 1.83 1999/02/22 13:54:18 davem Exp $
  *
  * Authors:	Ross Biro, <bir7 w leland.Stanford.Edu>
  *		Fred N. van Kempen, <waltje w uWalt.NL.Mugnet.ORG>
@@ -828,6 +828,8 @@
 	sk->shutdown |= how;
 	if (sk->prot->shutdown)
 		sk->prot->shutdown(sk, how);
+	/* Wake up anyone sleeping in poll. */
+	sk->state_change(sk);
 	return(0);
 }
 

> Co jest nieprawd± gdy¿ nie mam w tym momencie uruchomionych innych
> programów robi±cych podobne rzeczy co iptraf.
> 
> Secundo. Obserwujê ciekawe zachowanie na kernelach 2.2.[12]. Otó¿ co kilka
> minut mam kompletn± g³uchotê na na eth. Jak próbujê monitorowaæ tuch na
> sieci to obserwujê korelacje, ze zawsze taka g³uchota ma miejsce po tym
> jak na miêdzymordziu sieciowym pojawiaj± mi sie ramki no-ip. Wyci±gi z
> iptraf i tcpdump:
> 
> (iptraf)
>  Non-IP packet (0x4) from 00800f703ea3 to 0180c2000000 on eth0
>  Non-IP packet (0x4) from 00800f703ea3 to 0180c2000000 on eth0
>  Non-IP packet (0x4) from 00800f703ea3 to 0180c2000000 on eth0
>  Non-IP packet (0x4) from 00800f703ea3 to 0180c2000000 on eth0
> 
> (tcpdump)
> 12:36:48.601717 0:80:f:70:3e:a3 1:80:c2:0:0:0 002e 60: 802.1d ui/C len=43
>                          0000 0000 0080 0000 800f 703e a000 0000
>                          0080 0000 800f 703e a080 0400 0014 0002
>                          000f 0000 0093 5740 0609 2b
> 12:36:50.616782 0:80:f:70:3e:a3 1:80:c2:0:0:0 002e 60: 802.1d ui/C len=43
>                          0000 0000 0080 0000 800f 703e a000 0000
>                          0080 0000 800f 703e a080 0400 0014 0002
>                          000f 0000 0053 3840 0609 2b
> 12:36:52.646853 0:80:f:70:3e:a3 1:80:c2:0:0:0 002e 60: 802.1d ui/C len=43
>                          0000 0000 0080 0000 800f 703e a000 0000
>                          0080 0000 800f 703e a080 0400 0014 0002
>                          000f 0000 0053 8340 0609 2b
> 12:36:54.661912 0:80:f:70:3e:a3 1:80:c2:0:0:0 002e 60: 802.1d ui/C len=43
>                          0000 0000 0080 0000 800f 703e a000 0000
>                          0080 0000 800f 703e a080 0400 0014 0002
>                          000f 0000 0093 bb40 0609 2b

I faktycznie te nag³ówki za cholerê nie wygl±daj± jak cokolwiek
majace wspólnego z IP lub UNIX-em! Zwykle w pierwszych bajtach powinny
siê
bowiem pojawiaæ informacje o portach lub d³ugo¶ciach pakietów a tu
nic....

Mo¿liwe, ¿e wywo³uj± one po prostu kolizjê na twoim hubie, który mówi
sobie:
"O cholera, kto¶ mi co¶ pod¿uca co niebardzo wygl±da na ethernet,
poczekamy,
mo¿e siê popawi..." Ale to nie t³umaczy³oby oczywi¶cie zale¿no¶ci od
j±dra
jakie stosujesz, chyba ¿e te pakiety s± adresowane do twojej karty
ethernetowej
Sprawdz w pierwszej kolejno¶ci czy 0180c2000000 to nie ty przypadkiem,
choæ
te zera po 0180c2000000 wygl±daj± mi bardzo podej¿anie, co wspiera
hipotezê o
hubie k³adz±cym ca³y ether na "odczekanie".

Takie tylko moje trzy grosze...

--Marcin