<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hallo,<br>
<br>
also ich hab mich mal an der Idee versucht (teils zusammen
"ge-goggle-d"):<br>
<ul>
<li>Auf dem GW eingehende DHCP Broadcasts werden erkannte, wenn <br>
</li>
<ul>
<li>keine IP Adresse (0.0.0.0)</li>
<li>an UDP port 67</li>
<li>von UDP port 68</li>
</ul>
<li>davon wird jedes "n-te" Paket heraus gegnommen und markiert</li>
<li>und dann um 250 ms verzögert<br>
</li>
</ul>
Müsste man versuchen zu testen. Meinungen?<br>
<br>
P.S.: <br>
<ul>
<li>Bin mir nicht sicher, wie man die Verzögerung messen kann.
Evtl. ein Testlauf auf nue1, wobei jedes eintreffende DHCP Paket
verzögert wird<br>
</li>
<li>Noch cleverer wäre es, das DHCPOFFER zu verzögern. Das habe
ich iptable-technisch aber nicht zu greifen gekriegt <br>
</li>
<li>Die Batman GW selection sollte nicht so schnell aus dem
Rennen, weil (a) einfach, (b) vorhanden / out-of-the-box<br>
</li>
</ul>
Gruß...<br>
Torben<br>
<br>
<tt>=== statistic-dhcp-delay.sh ==== </tt><tt><br>
</tt><tt>#!/bin/bash</tt><tt><br>
</tt><tt><br>
</tt><tt>IF=bat0</tt><tt><br>
</tt><tt>IFSPEED=10Mbps # Get from sudo /sbin/ethtool $IF</tt><tt><br>
</tt><tt>DELAY=250ms</tt><tt><br>
</tt><tt>PORT_C=68 # DHCP Client</tt><tt><br>
</tt><tt>PORT_S=67 # DHCP Server</tt><tt><br>
</tt><tt>PROTO=UDP # DHCP IP Protocol</tt><tt><br>
</tt><tt>Nth=3 # act on every nth package</tt><tt><br>
</tt><tt><br>
</tt><tt><br>
</tt><tt>#</tt><tt><br>
</tt><tt># Create a tree of classful HTB objects</tt><tt><br>
</tt><tt>#</tt><tt><br>
</tt><tt>/sbin/tc qdisc add dev $IF handle 1: root htb</tt><tt><br>
</tt><tt><br>
</tt><tt>#</tt><tt><br>
</tt><tt># Create a classful child bucket with classid 1:11</tt><tt><br>
</tt><tt>#</tt><tt><br>
</tt><tt>/sbin/tc class add dev $IF parent 1: classid 1:11 htb rate
$IFSPEED</tt><tt><br>
</tt><tt><br>
</tt><tt>#</tt><tt><br>
</tt><tt># Create a qdisc (classless) netem child to provide a delay
for packets in this 'bucket'</tt><tt><br>
</tt><tt>#</tt><tt><br>
</tt><tt>/sbin/tc qdisc add dev $IF parent 1:11 handle 11: netem
delay $DELAY</tt><tt><br>
</tt><tt><br>
</tt><tt>#</tt><tt><br>
</tt><tt># Filter mangled/marked traffic to the above class</tt><tt><br>
</tt><tt>#</tt><tt><br>
</tt><tt>/sbin/tc filter add dev $IF parent 1:0 prio 1 protocol ip
handle 11 fw flowid 1:11</tt><tt><br>
</tt><tt><br>
</tt><tt>#</tt><tt><br>
</tt><tt># Use iptables to mangle TCP packets to port $PORT and
mark packet for tc filtering</tt><tt><br>
</tt><tt>#</tt><tt><br>
</tt><tt>#/sbin/iptables -A PREROUTING -t mangle -p $PROTO --source
0.0.0.0 --dport $PORT_S --sport $PORT_C -j MARK --set-mark 11</tt><tt><br>
</tt><tt>#/sbin/iptables -A PREROUTING -t mangle -p $PROTO --source
0.0.0.0 --dport $PORT_S --sport $PORT_C -j LOG --log-prefix
"Incoming DHCP traffic: "</tt><tt><br>
</tt><tt><br>
</tt><tt>/sbin/iptables -A PREROUTING -t mangle -p $PROTO --source
0.0.0.0 --dport $PORT_S --sport $PORT_C -m statistic --mode nth
--every $Nth --packet 0 -j MARK --set-mark 11</tt><tt><br>
</tt><tt>/sbin/iptables -A PREROUTING -t mangle -p $PROTO --source
0.0.0.0 --dport $PORT_S --sport $PORT_C -m statistic --mode nth
--every $Nth --packet 0 -j LOG --log-prefix "Incoming DHCP
traffic: "</tt><br>
<br>
<br>
<br>
<br>
<br>
On 11.09.2015 17:50, Michael Sessler wrote:<br>
<span style="white-space: pre;">> Hallo delphiN,
>
> Ich hätte spontan an ein zufälliges Delay gedacht, so dass per Zufallsprinzip irgendeiner der Schnellste ist. Statistisch sollte sich die Last dann verteilen.
> Aber wenn man das von der eigenen Systemlast abhängig machen könnte, wäre es sogar noch cleverer.
> Ich finde die Idee gut.
>
> DerMichy
>
> Am 11.09.2015 um 17:06 schrieb delphiN:</span><br>
<blockquote type="cite">Am 11.09.2015 16:54, schrieb Tim Niemeyer:<br>
>>> Wer in der Netztopologie am schnellsten den DHCP
Request<br>
>>> beantwortet,<br>
>>>> wird zum GW. Das ist in der Regel fff-nue. Wer am
weitesten weg<br>
>>>> ist, bekommt fast keine Clients, das ist in der
Regel meiner ;)<br>
Ich hab da auch schon öfters mal drüber nachgedacht.<br>
<br>
Ein Ansatz wäre es auf den Gateways einen speziellen DHCP-Server
zu<br>
verwenden, der eine gewisse Zeit abwartet, bis er antwortet.<br>
Diese kleine Verzögerung könnte man z.B. von der Anzahl der<br>
VPN-Verbindungen, oder dem aktuellen Netzwerkdurchsatz abhängig<br>
machen. So könnte man die Last dynamischer verteilen ohne eine<br>
zentrale Steuerung zu schaffen.<br>
Wenn Ihr die Idee gut findet würde ich mir das man anschauen.<br>
Eingelesen hab ich mich schon und halte es für einen gangbaren
Weg.<br>
<br>
delphiN<br>
<br>
-- <a class="moz-txt-link-abbreviated" href="mailto:freifunk@wunschik.net">freifunk@wunschik.net</a><br>
<a class="moz-txt-link-abbreviated" href="mailto:delphiN@jabber.ccc.de">delphiN@jabber.ccc.de</a><br>
Mitglied: Freie Netze e.V., CCC, Piratenpartei<br>
<br>
<br>
</blockquote>
<span style="white-space: pre;">>
>
></span><br>
<br>
<br>
</body>
</html>