[Berlin-wireless] next bug olsr dyngw plugin mit ff-luci auf kamikaze macht pingflood
L. Aaron Kaplan
aaron
Mo Nov 24 22:03:00 CET 2008
Hi Jens und Ulf!
bin gerade am durchtesten und schauen, ob ich den bug reproduzieren kann.
Habe dazu den trunk von olsrd hergenommen und dyn_gw mit folgenden
settings gestartet.
------------ 8< ---------------------
LoadPlugin "olsrd_dyn_gw.so.0.4"
{
# how often to look for a inet gw, in seconds
# defaults to 5 secs, if commented out
PlParam "Interval" "40"
# if one or more IPv4 addresses are given, do a ping on these in
# descending order to validate that there is not only an entry in
# routing table, but also a real internet connection. If any of
# these addresses could be pinged successfully, the test was
# succesful, i.e. if the ping on the 1st address was successful,the
# 2nd won't be pinged
PlParam "Ping" "193.99.144.80"
PlParam "HNA" "192.168.100.0 255.255.255.0"
}
Wenn olsrd -d 1 rennt:
------------ 8< ---------------------
Source IP addr Dest IP addr LQ ETX
192.168.100.125 192.168.100.1 0.439/0.200 11.384
\
Do ping on 193.99.144.80 ...
PING 193.99.144.80 (193.99.144.80) 56(84) bytes of data.
--- 193.99.144.80 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 27.814/27.814/27.814/0.000 ms
...OK
HNA[0064a8c0/00ffffff](ping is possible) VIA eth0 detected in routing table.
\
Do ping on 193.99.144.80 ...
PING 193.99.144.80 (193.99.144.80) 56(84) bytes of data.
--- 193.99.144.80 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 34.197/34.197/34.197/0.000 ms
...OK
HNA[0064a8c0/00ffffff](ping is possible) VIA eth0 detected in routing table.
\
------------ 8< ---------------------
Wenn ich tcpdumpe, um zu sehen, wie haeufig der ping rausgeht, schaut
alles OK aus:
------------ 8< ---------------------
aaron at uhu:~/olsrd-current/olsrd$ sudo tcpdump -ni eth0 host 193.99.144.80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
21:32:33.355500 IP 192.168.100.125 > 193.99.144.80: ICMP echo request,
id 23416, seq 1, length 64
21:35:29.716294 IP 192.168.100.125 > 193.99.144.80: ICMP echo request,
id 50808, seq 1, length 64
21:35:29.743317 IP 193.99.144.80 > 192.168.100.125: ICMP echo reply, id
50808, seq 1, length 64
21:36:09.747836 IP 192.168.100.125 > 193.99.144.80: ICMP echo request,
id 51576, seq 1, length 64
21:36:09.775623 IP 193.99.144.80 > 192.168.100.125: ICMP echo reply, id
51576, seq 1, length 64
21:36:49.781347 IP 192.168.100.125 > 193.99.144.80: ICMP echo request,
id 53112, seq 1, length 64
21:36:49.815517 IP 193.99.144.80 > 192.168.100.125: ICMP echo reply, id
53112, seq 1, length 64
21:37:29.820771 IP 192.168.100.125 > 193.99.144.80: ICMP echo request,
id 54392, seq 1, length 64
21:37:29.987434 IP 193.99.144.80 > 192.168.100.125: ICMP echo reply, id
54392, seq 1, length 64
21:38:09.992764 IP 192.168.100.125 > 193.99.144.80: ICMP echo request,
id 55160, seq 1, length 64
21:38:10.023359 IP 193.99.144.80 > 192.168.100.125: ICMP echo reply, id
55160, seq 1, length 64
------------ 8< ---------------------
Man beachte, dass 192.168.100.0/24 gerade hier mein Netz ist. Und ich
kann nur dieses Netz announcen, da dyn_gw abcheckt ob man selbst in dem
netz ist (liest /proc/net/route). Aber das ist sicher ncihts neues.
Hm... wie koennen wir sonst den fehler noch finden?
Koennt ihr mir mal verraten, welche version das jetzt war?
Hm... in die function looped_checks springt er mit einem neuen thread.
Also das ist der thread handler. Passt. Das problem ist natuerlich, wenn
nanosleep zu kurz schlaeft, dann kostet dich der thread zu viel CPU.
Das einzige, wo ich mir vorstellen kann, dass nanosleep unterbrochen
wird, ist durch a) einen falschen timer bei dir am system (system clock
spinnt herum) oder b) signal.
Um das zu testen: kannst du mal ein
perror ("nanosleep woke up");
direkt hinter
sleeptime_spec = remainder_spec;
stellen?
Also:
while (nanosleep (&sleeptime_spec, &remainder_spec) < 0)
{
sleeptime_spec = remainder_spec;
perror ("nanosleep woke up");
}
Und mir sagen, was der perror sagt?
Vielleicht bringt uns das weiter.
Und falls du profi C coder bist und ich das nur nicht weiss und jetzt
gerade selber herumtappe - sorry. Just trying to help...
Aber ich kanns halt nicht reproduzieren.
L. Aaron Kaplan wrote:
> ulf kypke wrote:
>
>> das ist ja prima, jens, das es diesen bug schon so lange gibt, du dazu
>> auch eine mail geschrieben hast, die ich dummerweise nicht gesehen
>> haben und sich noch keiner der olsr entwickler daran gemacht hat das
>> zu fixen.
>> maybe its time for batman - so long
>> ulf
>>
>>
>>
>
>
> Ulf,
>
>
> *Esc-x ignore-flame-bait-mode on* ;-)
> (fuers sachliche - siehe die antwort von sven-ola, dass das nichts
> gebracht haette)
>
>
> Im ernst: niemand hat bist jetzt meiner meinung nach *die* loesung.
> AFAIK kaempfen die batmaenner mit ihren bugs genauso.
>
>
> my 2 cents,
> a.
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Berlin mailing list
> Berlin at berlin.freifunk.net
> http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin
>
>
Mehr Informationen über die Mailingliste Berlin