<p dir="ltr">I think I remember to fix ssdp you brought some of route cache and igmp back. Do we know if cero routed setup without route cache can work with ssdp? I wouldn't like to force bringing back route cache just for ssdp.</p>

<p dir="ltr">I'm OK to test this scenario.</p>
<p dir="ltr">Maciej</p>
<div class="gmail_quote">On 20 Apr 2013 18:01, "Dave Taht" <<a href="mailto:dave.taht@gmail.com">dave.taht@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
iproute2's ip/iproute2.c code has a function called iproute_modify,<br>
which to a blurring eye appears to be capable of doing an atomic route<br>
update via it's netlink interface.<br>
<br>
"        if (matches(*argv, "change") == 0 || strcmp(*argv, "chg") == 0)<br>
                return iproute_modify(RTM_NEWROUTE, NLM_F_REPLACE,<br>
                                      argc-1, argv+1);<br>
        if (matches(*argv, "replace") == 0)<br>
                return iproute_modify(RTM_NEWROUTE, NLM_F_CREATE|NLM_F_REPLACE,<br>
                                      argc-1, argv+1);"<br>
<br>
The babel  native daemon and the quagga-re code, however, does a<br>
delete/add, which results in packets dropping on the floor when a<br>
route changes.<br>
<br>
Everyone that's tried to make this code do atomic updates has failed.<br>
<br>
Juliusz thinks this section of the codebase is cursed, and I<br>
personally, gave up, because dave miller had spent most of the last 3+<br>
years eliminating the linux kernel route cache, (which was finally<br>
eliminated a few kernel versions back (3.6?)) and I figured all<br>
attempts at doing anything fancy with routing during that phase was<br>
going to break in odd ways until the new cache-free-linux-kernel<br>
routing code stabilized.<br>
<br>
OK, so, like, it's kernel 3.8 time now, and ...  I find myself too<br>
scarred by previous attempts to give it a go myself, but I know that<br>
out there are intrepid explorers out there, just dying to delve into<br>
the gnarly details of netlink programming to keep a few more streams<br>
going full throttle in the face of a routing change! Yes? Anyone? So<br>
take a look at iproute2 and the relevant netlink code here:<br>
<br>
git://<a href="http://github.com/Quagga-RE/quagga-RE.git" target="_blank">github.com/Quagga-RE/quagga-RE.git</a><br>
git://<a href="http://github.com/jech/babeld.git" target="_blank">github.com/jech/babeld.git</a><br>
<br>
I note that I have a few other ideas for netlink-related changes to<br>
cero. Two of the big ones is that I'd like to be able to have a<br>
userspace daemon get back more details as to when *fq_codel drops a<br>
packet (e.g, send a multicast to a listener of the dropped the packet,<br>
and why), and get some sort of ongoing bandwidth estimate when it<br>
starts dropping, etc.<br>
<br>
I also have some hope for multi-prefix multi-homed routing too...<br>
<br>
but I find netlink really intimidating. It has an interface that only<br>
a bit-banger would love.<br>
<br>
--<br>
Dave Täht<br>
<br>
PS: I have a build of 3.8.8 at the moment that uses the new PROCD<br>
replacement for init that I'm losing a battle on, too. Also toke has<br>
got cero mostly independently buildable now.<br>
<br>
Fixing bufferbloat with cerowrt: <a href="http://www.teklibre.com/cerowrt/subscribe.html" target="_blank">http://www.teklibre.com/cerowrt/subscribe.html</a><br>
_______________________________________________<br>
Cerowrt-devel mailing list<br>
<a href="mailto:Cerowrt-devel@lists.bufferbloat.net">Cerowrt-devel@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/cerowrt-devel" target="_blank">https://lists.bufferbloat.net/listinfo/cerowrt-devel</a><br>
</blockquote></div>