Re: [Babel-users] more nlogn crash details
must be late for you too. You should really compile check stuff... there's no ifp pointer in send_multihop_request. On Sun, Oct 28, 2018 at 3:57 PM Juliusz Chroboczek wrote: > > > #0 0x0040c1d4 in start_message (buf=buf@entry=0x171e5b8, > > type=type@entry=10, len=len@entry=22) at message.c:957 > > #1 0x0040c568 in send_multihop_request (buf=0x171e5b8, > > prefix=0x1cf66b8 "\374c\311/S\266)j", plen=, > > src_prefix=0x1cf66c9 "", src_plen=, seqno= > out>, > > id=0x1cf66b0 "\002%\220\377\376\302*\242\374c\311/S\266)j", > > hop_count=127) > > at message.c:1806 > > Thanks, that's helpful. Fixed in branch rfc6126bis. -- Dave Täht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
[Babel-users] checking for correctness better
Here's a cool one. This predates your few minute ago fix for ifup... and my sources are out of sync and I really need to reboot the whole lab at this point. And did I mention climbing some trees? :) d@dancer:~/git/rtod$ ip route default via 172.22.0.2 dev eno1 169.254.0.0/16 dev eno1 scope link metric 1000 172.22.0.0/24 dev eno1 scope link 172.22.0.193 via 172.22.0.215 dev eno1 proto babel onlink 172.22.0.215 via 172.22.0.193 dev eno1 proto babel onlink WTF? it persists for a while... goes to unreachable... then back to this. 193 IS on this lan... 172.22.148.0/22 via 172.22.0.193 dev eno1 proto babel onlink 172.22.192.0/22 via 172.22.0.193 dev eno1 proto babel onlink 172.22.193.1 via 172.22.0.215 dev eno1 proto babel onlink 172.22.220.0/22 via 172.22.0.193 dev eno1 proto babel onlink 192.168.0.0/24 dev eno1 proto kernel scope link src 192.168.0.2 192.168.122.1 via 172.22.0.193 dev eno1 proto babel onlink ultimately after things calm down some: default via 172.22.0.2 dev eno1 50.197.142.144/29 via 172.22.0.1 dev eno1 proto babel onlink 169.254.0.0/16 dev eno1 scope link metric 1000 172.20.0.0/14 via 172.22.0.193 dev eno1 proto babel onlink 172.22.0.0/24 dev eno1 scope link 172.22.0.193 via 172.22.0.215 dev eno1 proto babel onlink 172.22.0.215 via 172.22.0.215 dev eno1 proto babel onlink 172.22.148.0/22 via 172.22.0.85 dev eno1 proto babel onlink 172.22.192.0/22 via 172.22.0.85 dev eno1 proto babel onlink 172.22.193.1 via 172.22.0.215 dev eno1 proto babel onlink unreachable 172.22.220.0/22 proto babel metric 4294967295 192.168.0.0/24 dev eno1 proto kernel scope link src 192.168.0.2 192.168.122.1 via 172.22.0.215 dev eno1 proto babel onlink I gotta stop for the day, sync up my sources, climb a tree and try again. ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] more nlogn crash details
> #0 0x0040c1d4 in start_message (buf=buf@entry=0x171e5b8, > type=type@entry=10, len=len@entry=22) at message.c:957 > #1 0x0040c568 in send_multihop_request (buf=0x171e5b8, > prefix=0x1cf66b8 "\374c\311/S\266)j", plen=, > src_prefix=0x1cf66c9 "", src_plen=, seqno=, > id=0x1cf66b0 "\002%\220\377\376\302*\242\374c\311/S\266)j", hop_count=127) > at message.c:1806 Thanks, that's helpful. Fixed in branch rfc6126bis. ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
[Babel-users] more nlogn crash details
I'm presently testing the below patch again
so I went back to the pure nlogn branch to see if I could duplicate
the one crash I had early on.
It takes a while (injecting and reinjecting 12k routes over about 20
minutes), but ultimately crashed here:
#0 0x0040c1d4 in start_message (buf=buf@entry=0x171e5b8,
type=type@entry=10, len=len@entry=22) at message.c:957
#1 0x0040c568 in send_multihop_request (buf=0x171e5b8,
prefix=0x1cf66b8 "\374c\311/S\266)j", plen=,
src_prefix=0x1cf66c9 "", src_plen=, seqno=,
id=0x1cf66b0 "\002%\220\377\376\302*\242\374c\311/S\266)j", hop_count=127)
at message.c:1806
#2 0x0040dfd9 in send_request_resend (
prefix=0x1cf66b8 "\374c\311/S\266)j", plen=64 '@',
src_prefix=0x1cf66c9 "", src_plen=0 '\000', seqno=,
id=0x1cf66b0 "\002%\220\377\376\302*\242\374c\311/S\266)j")
at message.c:1904
#3 0x0040a7ee in flush_route (route=route@entry=0x1cf8af0)
at route.c:300
#4 0x0040b02e in expire_routes () at route.c:1216
#5 0x00403121 in main (argc=, argv=)
at babeld.c:751
This box does have a ton of currently disabled interfaces on it (only
eno1 exists)
babeld -L bla
eno1 wlp2s0 wlx9cefd5ff0b2c wlxec086b113afd enxd23bf0e38d7c
enx2a1c0359e29b enx029b514afb6f enx88c255560f15 enp0s20u1u1u4
enp0s20u1u1u4 enp0s20u1u2
I also managed to crash the other box same way.
the "fix" for this (been re-testing for a while), but for all I know
I'm covering up a symtom, was:
diff --git a/message.c b/message.c
index 3ca92ff..83183fe 100644
--- a/message.c
+++ b/message.c
@@ -1901,8 +1901,10 @@ send_request_resend(const unsigned char
*prefix, unsigned char plen,
} else {
struct interface *ifp;
FOR_ALL_INTERFACES(ifp)
+ if(ifp->buf.buf) {
send_multihop_request(&ifp->buf, prefix, plen,
src_prefix, src_plen,
seqno, id, 127);
+ }
}
}
--
2.7.4
--
Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Tcpdump or wireshark
> It doesn't show up in my version of wireshark, but does in tcpdump. > sorry for the noise It's a useful report, it indicates that Wireshark doesn't correctly indicate unknown sub-TLVs. Needs fixed. ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Tcpdump or wireshark
On Sun, Oct 28, 2018 at 2:32 PM Juliusz Chroboczek wrote: > > > is there an updated tcpdump or wireshark for the newer subtlvs? > > Not yet. It's an easy hack, unless somebody beats me to it, I may offer > it as a first- or second-year project next spring. The trick was then (as I lost a day to doing it) to pull from the right branch of tcpdump and fix that. Which I don't remember. > > > there are no timestamps in the multicast hello according to wireshark. > > I may have broken something. I'll have a look. > > -- Juliusz -- Dave Täht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Tcpdump or wireshark
On Sun, Oct 28, 2018 at 2:42 PM Juliusz Chroboczek wrote: > > >> there are no timestamps in the multicast hello according to wireshark. > > > I may have broken something. I'll have a look. > > Works for me (TM). > > 22:41:33.171052 IP6 (class 0xc0, flowlabel 0x27d4c, hlim 1, next-header > UDP (17) payload length: 52) fe80::8aa8:f6d:d885:2851.6696 > ff02::1:6.6696: > [udp sum ok] babel 2 (40) > Hello seqno 64302 interval 4.00s sub-timestamp 3093.772159s > IHU fe80::e246:9aff:fe4e:9178 txcost 292 interval 12.00s > sub-timestamp 3629.213133s|3091.035168s It doesn't show up in my version of wireshark, but does in tcpdump. sorry for the noise -- Dave Täht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Tcpdump or wireshark
>> there are no timestamps in the multicast hello according to wireshark. > I may have broken something. I'll have a look. Works for me (TM). 22:41:33.171052 IP6 (class 0xc0, flowlabel 0x27d4c, hlim 1, next-header UDP (17) payload length: 52) fe80::8aa8:f6d:d885:2851.6696 > ff02::1:6.6696: [udp sum ok] babel 2 (40) Hello seqno 64302 interval 4.00s sub-timestamp 3093.772159s IHU fe80::e246:9aff:fe4e:9178 txcost 292 interval 12.00s sub-timestamp 3629.213133s|3091.035168s ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
[Babel-users] Tcpdump or wireshark
> is there an updated tcpdump or wireshark for the newer subtlvs? Not yet. It's an easy hack, unless somebody beats me to it, I may offer it as a first- or second-year project next spring. > there are no timestamps in the multicast hello according to wireshark. I may have broken something. I'll have a look. -- Juliusz ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] unicast branch test
On Sun, Oct 28, 2018 at 1:54 PM Juliusz Chroboczek wrote: > > > ah, ok, so the nlogn branch I've been running was derived from the > > unicast branch? which in turn was derived from the rfc-bis branch? and > > I've been running that all along? > > The other way around (unicast branched into rfc6126bis which branched into > xroute-nlogn), but yes. > > > So all that's left is hmac? and dtls? > > No decision has been taken yet. I'm rather keen on merging HMAC (since we > took a lot of care with Clara and Weronika to make it easy to merge). I had tried that sometime in the past week, there was only one conflict I could not easily resolve. It would be so great for all this to land and then mattheiu's datum idea to go in... > > I'm a little more hesitant as to DTLS. On the one hand, it requires some > changes to the core of Babel, on the other hand, most of the work has been > done already (DTLS is why we wrote the unicast code in the first place). Well, my own goal with unicast was to get vastly better wifi rates for route transfers, and also fq_codel will hand it its own queue, so multicast hellos go out without HOL blocking. I'm glad you found another motivation. > I guess it depends on how aggressive Antonin will want to be ;-) > > > I added default unicast true to one of those boxes, and yea! lots of > > unicast! > > lots of ns solicit and response. Route transfers. over unicast. > > I'll be listening. The only thing I've noticed in the cap thus far is that I'd set default enable-timestamps true unicast true and there are no timestamps in the multicast hello according to wireshark. btw, is there an updated tcpdump or wireshark for the newer subtlvs? > > -- Juliusz -- Dave Täht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Babel security [was: 57 forks of babel on github]
On Sun, Oct 28, 2018 at 1:48 PM Juliusz Chroboczek wrote: > > > One of my issues with crypto, rather than auth, is I'd wanted a way to > > have a partially untrusted network to bootstrap off of and/or to allow at > > least some unauthed or uncrypted nodes to participate with filters or > > inflated > > metrics. > > The important thing to understand is that both security mechanisms that > we're currently developing protect Babel messages. We're not attempting > to secure Babel updates end-to-end. > > Both security models use auth per-interface. Either you allow anyone to > associate on a given interface, or you require crypto on that interface. Basically, you have to do setup in your lab, and not in the forest. I get by on just installing a static default route in the forest 'cept on p2p links. > > So in order to build a partially untrusted network: > > - set up security for your backbone links, either at the application > layer (DTLS or HMAC), or at the link layer (WPA2, 802.1X) or at the > physical layer (a guy or gal with an AK47 (Chinese clones will do) in > front of every Ethernet socket); It is my hope that all this stream of consciousness traffic during a deployment will lend itself one day to a better, more coherent bcp for folk to leverage. While AK47s are readily available on the aftermarket at low cost, the glock 43 is far more transportable, and when used in the hands of an experienced operator, in single shot mode, causes less damage to other valuable pieces of equipment. Toxins spread liberally around the outlet work 24x7 until they evaporate and don't require payroll or a health benefit plan. > - set up strict filtering rules for your guest interfaces; Do you have recommendations? > - set up ingress firewall rules for your guest interfaces; I currently run with firewalls only at the edges. I found deploying the bcp38 package internally on every router to ultimately cause breakage when something changed, and the sanest thing to do in ipv6-land is limit what protocols you run in the first place (it's almost entirely "just ssh" now, and I may kill snmp off too). I probably will push the basic ipset or route based bogon filter out to the APs this time around (no 10, 169, 192) firewalling dynamic ipv6 is nearly an impossible task. I already talked about filtering out public ipv4 in this message. This is all a good topic for a bcp. > - allow anyone to associate on the guest interfaces. Although babel will be available on several bridged devices I do plan to secure it via hmac in the long run. Until then, security through obscurity. Very few people walk onto the campus with attack tools in hand, and there's so many other basic attacks (arp spoofing, ra spoofing, etc, etc) that it is kind of pointless. The basic goal, though, is when exposing a private network at all to a larger interconnected mesh outside the campus, is to keep those vulnerabilities at a minimum. Physical security is hard, even with a glock. > To restate -- there is no way in Babel currently to have end-to-end > signatures on route announcements. Doing that properly is difficult, > and as far as I'm aware nobody is working on it. yep. The core thing that I somehow wanted was to make available a source specific addr/60 to share with other folk, while forcing other attempts at my address space out through the regular internet. I believe that is possible (with or without hmac) at this point > > -- Juliusz -- Dave Täht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] unicast branch test
> ah, ok, so the nlogn branch I've been running was derived from the > unicast branch? which in turn was derived from the rfc-bis branch? and > I've been running that all along? The other way around (unicast branched into rfc6126bis which branched into xroute-nlogn), but yes. > So all that's left is hmac? and dtls? No decision has been taken yet. I'm rather keen on merging HMAC (since we took a lot of care with Clara and Weronika to make it easy to merge). I'm a little more hesitant as to DTLS. On the one hand, it requires some changes to the core of Babel, on the other hand, most of the work has been done already (DTLS is why we wrote the unicast code in the first place). I guess it depends on how aggressive Antonin will want to be ;-) > I added default unicast true to one of those boxes, and yea! lots of unicast! > lots of ns solicit and response. Route transfers. over unicast. I'll be listening. -- Juliusz ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
[Babel-users] Babel security [was: 57 forks of babel on github]
> One of my issues with crypto, rather than auth, is I'd wanted a way to > have a partially untrusted network to bootstrap off of and/or to allow at > least some unauthed or uncrypted nodes to participate with filters or inflated > metrics. The important thing to understand is that both security mechanisms that we're currently developing protect Babel messages. We're not attempting to secure Babel updates end-to-end. Both security models use auth per-interface. Either you allow anyone to associate on a given interface, or you require crypto on that interface. So in order to build a partially untrusted network: - set up security for your backbone links, either at the application layer (DTLS or HMAC), or at the link layer (WPA2, 802.1X) or at the physical layer (a guy or gal with an AK47 (Chinese clones will do) in front of every Ethernet socket); - set up strict filtering rules for your guest interfaces; - set up ingress firewall rules for your guest interfaces; - allow anyone to associate on the guest interfaces. To restate -- there is no way in Babel currently to have end-to-end signatures on route announcements. Doing that properly is difficult, and as far as I'm aware nobody is working on it. -- Juliusz ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] unicast branch test
On Sun, Oct 28, 2018 at 1:12 PM Juliusz Chroboczek wrote: > > > since, what the heck, I have 7 different versions of babel in the lab, > > I figured why not add in the unicast branch on two boxes and see what > > else breaks. > > The unicast branch is obsolete -- the rfc6126bis branch is based of it. > So if you're running rfc6126bis (or nlogn), you're already running the > unicast code. got it. > As soon as I have some time, I'll release 1.8.4, then branch off a new > babeld-1.8 branch for bug fixes, and then merge all of the other branches > into master. In the meantime, please run rfc6126bis only, and ignore all > of the other branches. > > > An oddity, I think, is I see one box making a mh-request unicast, and > > the other box seems to respond with a mcast (?). > > Perfectly legal and expected. > > > Is there fun, happy, new config options I can enable to enable way > > more unicast? :) > > The unicast code does nothing by default. To enable it, say > > default unicast true > > in your config file. yep, I RTFC'd. there's a need to update the man page so RTFM would work. > > > However, I now have enough lab boxes to basically do interop between > > a lot of versions, I figure adding 1.5, 1.6, 1.7.1 to the mix would be > > useful? > > At this stage, we're only interested in reports against: > > - BIRD; > - rfc6126bis/xroute-nlogn, soon to be master; > - master, soon to be babeld-1.8 FRR is built, I just haven't got around to configuring it. ? I did have to put one tiny segvio patch on that branch, I'll beat it up without it for a while, see if I can make it happen again. I really wanted to try unicast over some p2p links. > If you're running older routers, make sure that you say > > default rfc6126-compatible true Almost not anymore! > in the config file of the more recent branches. > > > and I *gotta* go climb a few trees. > > And put Babel routers on a few drones? (Speak to Valent, in copy of this > mail.) I don't know if I mentioned this here or not, but this wifi bug: http://blog.cerowrt.org/post/disabling_channel_scans/ was *physically* crashing a few drones, according the maker that contacted me. I had thoughts towards trying flying drones over adhoc mode across multiple routers, but I think the default hold time on switching routes is not fast enough, you can go out of range in seconds. If C&C were over multicast and everybody forwarded the packet (discarding the dups) it might actually work, but... ... not today. Jim and I long ago discussed the possibilities of connecting sailboats up via adhoc & babel, which I think would work great... but, climbing the mast is less fun than climbing trees. > -- Juliusz -- Dave Täht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] unicast branch test
On Sun, Oct 28, 2018 at 12:46 PM Dave Taht wrote: > > since, what the heck, I have 7 different versions of babel in the lab, > I figured why not add in the unicast branch on two boxes and see what > else breaks. > > An oddity, I think, is I see one box making a mh-request unicast, and > the other box seems to respond with a mcast (?). Cap here: > > http://www.taht.net/~d/unicast.cap > > Is there fun, happy, new config options I can enable to enable way > more unicast? :) ah, ok, so the nlogn branch I've been running was derived from the unicast branch? which in turn was derived from the rfc-bis branch? and I've been running that all along? So all that's left is hmac? and dtls? yea! I added default unicast true to one of those boxes, and yea! lots of unicast! lots of ns solicit and response. Route transfers. over unicast. yea! > > next up, is sending much smaller numbers of routes and veriyfing > correctness... and getting it down to a few less versions. However, I > now have enough lab boxes to basically do > interop between a lot of versions, I figure adding 1.5, 1.6, 1.7.1 to > the mix would be useful? > > and I *gotta* go climb a few trees. > > > -- > > Dave Täht > CTO, TekLibre, LLC > http://www.teklibre.com > Tel: 1-831-205-9740 -- Dave Täht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] unicast branch test
> since, what the heck, I have 7 different versions of babel in the lab, > I figured why not add in the unicast branch on two boxes and see what > else breaks. The unicast branch is obsolete -- the rfc6126bis branch is based of it. So if you're running rfc6126bis (or nlogn), you're already running the unicast code. As soon as I have some time, I'll release 1.8.4, then branch off a new babeld-1.8 branch for bug fixes, and then merge all of the other branches into master. In the meantime, please run rfc6126bis only, and ignore all of the other branches. > An oddity, I think, is I see one box making a mh-request unicast, and > the other box seems to respond with a mcast (?). Perfectly legal and expected. > Is there fun, happy, new config options I can enable to enable way > more unicast? :) The unicast code does nothing by default. To enable it, say default unicast true in your config file. > However, I now have enough lab boxes to basically do interop between > a lot of versions, I figure adding 1.5, 1.6, 1.7.1 to the mix would be > useful? At this stage, we're only interested in reports against: - BIRD; - rfc6126bis/xroute-nlogn, soon to be master; - master, soon to be babeld-1.8 If you're running older routers, make sure that you say default rfc6126-compatible true in the config file of the more recent branches. > and I *gotta* go climb a few trees. And put Babel routers on a few drones? (Speak to Valent, in copy of this mail.) -- Juliusz ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
[Babel-users] unicast branch test
since, what the heck, I have 7 different versions of babel in the lab, I figured why not add in the unicast branch on two boxes and see what else breaks. An oddity, I think, is I see one box making a mh-request unicast, and the other box seems to respond with a mcast (?). Cap here: http://www.taht.net/~d/unicast.cap Is there fun, happy, new config options I can enable to enable way more unicast? :) next up, is sending much smaller numbers of routes and veriyfing correctness... and getting it down to a few less versions. However, I now have enough lab boxes to basically do interop between a lot of versions, I figure adding 1.5, 1.6, 1.7.1 to the mix would be useful? and I *gotta* go climb a few trees. -- Dave Täht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] 57 forks of babel on github
resending this because spamhaus doesn't like my ipv6 address. On Sun, Oct 28, 2018 at 12:06 PM Dave Taht wrote: > > Toke Høiland-Jørgensen writes: > > > Dave Taht writes: > > > >> I haven't figured out enough of bird to get it to stop announcing all > >> the local ips, btw, and am quite > > > > That part it doesn't actually do by default; I added it to the sample > > config to match babeld. > > > > Just get rid of the "protocol direct" section and they should go away... > > Cool. I got rid of that. Now the local ip stays routable (covered by > a kernel route) and less bad stuff is happening. Hmm... yes, in general > it is a bad idea to export your local ip. just rely on the /24 > kernel route for an ethernet subnet > > Any idea why I get this back? > > Couldn't parse packet (8, 12) from fe80::230:18ff:fec9:de9c on enp7s0. > Received prefix with no router id. > Couldn't parse packet (8, 11) from fe80::230:18ff:fec9:de9c on enp7s0. > Received prefix with no router id. > > ... > > I'm sitting here watching 12,000 routes injected from this box > not kill anything... > > d@ceres:~$ cat /etc/babeld.conf > default enable-timestamps true > interface enp7s0 > interface enp6s0 > interface enp4s0 > redistribute proto 50 allow > redistribute local deny > redistribute deny > > > but a whole bunch of routes on lesser boxes went unreachable or were > lost at 20k. For giggles, I injected 20k routes at the ceres (nlogn box) > and 40k routes at the bird (prancer) box. > > > d@ceres:~/git/babeld-fixes$ ip -6 route | wc -l > 60099 > > root@rudolf:~/git/babeld-taht# ip -6 route | wc -l # apu2 100mbit > 27559 > > root@gw1:~# ip -6 route | wc -l # openwrt arm, gigE theoreticall > 9434 > > This is just me being a bull in the china shop. It is generally my > intepretation of the results that I'm not seeing bugs in the protocol, > or implementation, as forcing stuff into overload like this, seemed to > me to be mostly related to first seeing late hellos and the metric > going to infinity, from looking at nc ::1 33123. But I can certainly > look harder... after I settle on one set of source code to be running, > take some packet captures, do some port mirroring, etc. > > root@rudolf:~/git/babeld-taht# ip route > 172.22.0.0/24 dev enp3s0 proto kernel scope link src 172.22.0.193 > unreachable 172.22.148.0/22 proto babel > unreachable 172.22.192.0/22 proto 44 > 172.22.193.0/24 dev enp2s0 proto kernel scope link src 172.22.193.1 > linkdown > unreachable 172.22.220.0/22 proto babel > unreachable 192.168.122.1 proto babel > > This box is also rate limited to 20mbits presently and is not > dropping or marking all that many packets, so that doesn't really > explain why it only had 9k routes when the others got more. > > I tend to use sqm to outbound/inbound rate limit with fq_codel to > 1mbit for a 2ghz wifi semi-emulation, and 6mbit for 5ghz. This > approach will break down entirely once we see unicast stuff... and I'll > have to go back to wifi > > > > root@rudolf:~/git/babeld-taht# tc -s qdisc show dev ifb4enp3s0 > qdisc htb 1: root refcnt 2 r2q 10 default 10 direct_packets_stat 0 > direct_qlen 32 > Sent 1046332742 bytes 987960 pkt (dropped 4062, overlimits 1070697 requeues > 0) > backlog 0b 0p requeues 0 > qdisc fq_codel 110: parent 1:10 limit 1001p flows 1024 quantum 1514 target > 5.0ms interval 100.0ms ecn > Sent 1046332742 bytes 987960 pkt (dropped 4062, overlimits 0 requeues 0) > backlog 0b 0p requeues 0 > maxpacket 9084 drop_overlimit 2816 new_flow_count 155299 ecn_mark 1470 > new_flows_len 0 old_flows_len 3 > > > > > -Toke > > > > ___ > > Babel-users mailing list > > Babel-users@alioth-lists.debian.net > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users -- Dave Täht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] 57 forks of babel on github
Dave Taht writes: > I haven't figured out enough of bird to get it to stop announcing all > the local ips, btw, and am quite That part it doesn't actually do by default; I added it to the sample config to match babeld. Just get rid of the "protocol direct" section and they should go away... -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] 57 forks of babel on github
On Sun, Oct 28, 2018 at 9:56 AM Dave Taht wrote:
>
> On Sun, Oct 28, 2018 at 1:52 AM Antonin Décimo
> wrote:
> >
> > Hello Dave,
> >
> > There's also my dtls branch.
> > https://github.com/MisterDA/babeld/tree/unicast-dtls
> >
> > It requires some cleanups, updates to the latest draft, and
> > harmonisation with the hmac branch, but I'm confident we'll eventually
> > get there.
>
> cool. What's your intended deployment model?
>
> One of my issues with crypto, rather than auth, is I'd wanted a way to
> have a partially untrusted network to bootstrap off of and/or to allow at
> least some unauthed or uncrypted nodes to participate with filters or inflated
> metrics.
>
> You bring a new node up. It needs to get on the network long enough
> to at least get a route to somewhere that has the configuration info you
> need to stick into it. Being "stubby" is almost enough (unless you are
> trying to come up as a p2p interface) - which will work with hmac auth nodes
> - a default route to the internet is all you need to (for example) install
> essential updates and tools, but being able to express that you'd like
> a couple unprotected routes to exist is a difficult problem
>
> As another example, I'd like to share part of my ipv6 source specific
> space with the meshy universe, but not allow anyone further access inside
> my network, or allow anyone in attempting to use or spoof part of the
> rest of the space in it at all.
>
> (simple example, I filter out nearly all announcements
> of normal ipv4 address space, so 8.8.8.8 can't be spoofed, and I used to
> filter out anything outside of comcast's ASN as that's the only public
> IPv6 space I have (used to just limit it to my dedicated hurricane tunnel),
> and certainly filter out their dns server ipv6 addrs also)
>
> It would be good to be able to log certain forms of possible malfeasance...
To expand on this a tiny bit. Babeld has a hard coded martians filter, which
logs what it classifies as martians. (I'd actually like that to be
overridable and extendable but, not today...)
a useful extension to babel's filtering language would be "denylog"...
and forgive me
for not getting the language straight pre-coffee
in ip 172.20.0.0/14 # my network and today I can't remember if it's ge or le
redistribute ip 172.20.0.0/14 allow # my network and today I can't
remember if it's ge or le
in ip 192.168.0.0/16 denylog # God 192.168.x is everywhere or...
redistribute ip 169.254.0.0/16 denylog # I'm perpetually exporting
this from various unconfigured interfaces
in denylog 99 "bad guys present!!"
I'd mentioned an idea for a new verb "block" which (configured
cheaply) would stop some of this kind of stuff at the xroute interface
also
(and let me have that enormous bogon route list). Tossing some stuff
early (ebpf, also) is generally a win.
as a side note, in bird, if I hit it with 2 routes here, and filter thusly,
filter import_filter
{
# Filter routes in blacklist
if (net ~ blacklist) then reject "blacklisted";
if (krt_source = 50) then reject "dont rtod me today";
accept;
}
they all get tossed early, *not stored in memory*, and bird barely
registers on cpu. Clear win for bird, though I should go retry this on
the xroute-nlogn branch
verb: in? install? what?
(NetworkManager and dnsmasq go nuts but... ag... I really should
go patch dnsmasq too)
I haven't figured out enough of bird to get it to stop announcing all
the local ips, btw, and am quite
far from using it on my default gws, but definately in the long run,
on the loaded edges (apu2s mostly soon), after mucho testing I intend
to switch to it.
>
> (this is partially equivalent to the BGP path validation problem, and
> basically,
> in running any network larger than a few people, all the social and technical
> problems that happen in the "big" Net, start happening here.)
>
> After that, things get hairier.
>
> I really don't "get" the tunneldigger/wlan-slovenia and other efforts
> that make things even more complicated. It seems like the first thing
> anybody does upon designing a mesh network is overlay a link state set
> of tools and tunnels over it to capture statistics and control
> information. Is that an artifact of the OLSR deployments or control
> freakery? My own paranoia about partially
> trustable networks (like wanting to have big bogon filters at my
> gateways at least - and maybe even APs) come from many scars of
> running a rather public network with a ton of visitors that never
> heard of anti-virus software. the openwrt bcp38 package is really
> helpful when someone starts ping -f the universe...
>
> Me, I run ssl/ssh and ssh port forward enabled tools, and have *one*
> dedicated collection point for statistics that I can export to the
> world as I see fit, and normally, any given view of my network comes
> down to a few dozen routes, tops. I don't want to know about any of
> the churn elsewhere.
>
> I have a whole /56 from linode I should go use up s
Re: [Babel-users] 57 forks of babel on github
On Sun, Oct 28, 2018 at 1:52 AM Antonin Décimo wrote: > > Hello Dave, > > There's also my dtls branch. > https://github.com/MisterDA/babeld/tree/unicast-dtls > > It requires some cleanups, updates to the latest draft, and > harmonisation with the hmac branch, but I'm confident we'll eventually > get there. cool. What's your intended deployment model? One of my issues with crypto, rather than auth, is I'd wanted a way to have a partially untrusted network to bootstrap off of and/or to allow at least some unauthed or uncrypted nodes to participate with filters or inflated metrics. You bring a new node up. It needs to get on the network long enough to at least get a route to somewhere that has the configuration info you need to stick into it. Being "stubby" is almost enough (unless you are trying to come up as a p2p interface) - which will work with hmac auth nodes - a default route to the internet is all you need to (for example) install essential updates and tools, but being able to express that you'd like a couple unprotected routes to exist is a difficult problem As another example, I'd like to share part of my ipv6 source specific space with the meshy universe, but not allow anyone further access inside my network, or allow anyone in attempting to use or spoof part of the rest of the space in it at all. (simple example, I filter out nearly all announcements of normal ipv4 address space, so 8.8.8.8 can't be spoofed, and I used to filter out anything outside of comcast's ASN as that's the only public IPv6 space I have (used to just limit it to my dedicated hurricane tunnel), and certainly filter out their dns server ipv6 addrs also) It would be good to be able to log certain forms of possible malfeasance... (this is partially equivalent to the BGP path validation problem, and basically, in running any network larger than a few people, all the social and technical problems that happen in the "big" Net, start happening here.) After that, things get hairier. I really don't "get" the tunneldigger/wlan-slovenia and other efforts that make things even more complicated. It seems like the first thing anybody does upon designing a mesh network is overlay a link state set of tools and tunnels over it to capture statistics and control information. Is that an artifact of the OLSR deployments or control freakery? My own paranoia about partially trustable networks (like wanting to have big bogon filters at my gateways at least - and maybe even APs) come from many scars of running a rather public network with a ton of visitors that never heard of anti-virus software. the openwrt bcp38 package is really helpful when someone starts ping -f the universe... Me, I run ssl/ssh and ssh port forward enabled tools, and have *one* dedicated collection point for statistics that I can export to the world as I see fit, and normally, any given view of my network comes down to a few dozen routes, tops. I don't want to know about any of the churn elsewhere. I have a whole /56 from linode I should go use up somehow A pending use for a tunnel is on my default gws where I might attempt a wireguard fallback route for the whole net (172.20.0.0/14), after I retire that cerowrt box. and at some point (currently about 4k routes), you run out of bandwidth, or cpu, or memory. On this go-round of my deployment I've disabled every last extra daemon that I used to run (dnsmasq, netperf, uhttpd, odhcpd, and I'm probably giving up on snmp in favor of just using smokeping. I used to use xnetd for some things. Superservers still make sense when you only have ~6MB of memory that is better off used for packets and routes). And it really pays to have the bare minimum number of exported routes to any other zone in your network. > > > Happy hacking, > > -- Antonin > > ___ > Babel-users mailing list > Babel-users@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users -- Dave Täht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
[Babel-users] [PATCH] Log late hellos
When low on cpu an early sign of trouble is starting to see late hellos.
---
neighbour.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/neighbour.c b/neighbour.c
index 6bba726..d562ff0 100644
--- a/neighbour.c
+++ b/neighbour.c
@@ -135,6 +135,11 @@ update_neighbour(struct neighbour *neigh, struct
hello_history *hist,
missed_hellos = 0;
rc = 1;
} else if(missed_hellos < 0) {
+/* Late hello. Probably due to the link layer buffering
+ packets during a link outage, or a cpu overload. */
+ fprintf(stderr,
+"Late hello: bufferbloated neighbor %s\n",
+ format_address(neigh->address));
hist->reach <<= -missed_hellos;
missed_hellos = 0;
rc = 1;
--
2.17.1
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] basic bird//babeld interop for ss
Juliusz Chroboczek writes: >> * I hit the nlogn branch with the same stuff... it's cpu barely ticks >> over, thousands of routes get distributed... it gets knocked off the >> network... and all end up unreachable, after everybody else runs out of >> some resource or another > > Dave, I'm planning to merge nlogn into master, so if you have time to > debug that, that'd be helpful. Sorry to have been unclear. So far the nlogn patch is a vast improvement on getting xroutes in. It appears to be correct from eyeballing the route distribution and doing things like ip -6 route show proto babel | grep that:addr | wc -l elsewhere. Ship it. ... The confusion part stems from, what I had been doing before to induce carnage, and bypassing the xroute import issue, was injecting lesser tons of routes into multiple other boxes, rather than one. The cpu bottleneck shifts over the various resend routines (I'd sent you a gprof of that at some point) Once you get over ~8k routes, you end up compute bound again on every architecture, late hellos ensue, metrics climb, stuff goes unreachable, routes get retracted, and you probably hit other cpu bottlenecks while clearing things out (the injector is 12 core xeon, and it too goes unreachable because it's in resend, or it's got late hellos from elsewhere) In other words, I can blow up the network by injecting 16k routes from one now very fast nlogn xroute capable box, where before it took 8 injecting 1k each. :) anyway - the babel.conf over there is: default enable-timestamps true interface enp7s0 interface enp6s0 interface enp4s0 redistribute proto 50 allow And this used to just ssh to various boxes to do them in. It was unclear which of the xroute vs resend routines that would do them in... #!/bin/sh for i in `seq 1 32` # really! don't go above 2-4 unless you are crazy do ./rtod -r 2000 -H test$i # -H generates a different ipv6 prefix sleep 13 done Now it's just resend. The good thing to note is *no crashes*. After the route flood clears, all the lost routes to "normal" stuff reappear, and everything returns to normal. There's a mips (campusgw) box doing heavy filtering, a bird box now, a couple boxes with this patch (arm, mips, x86 apu2), I'm going to add a second bird box at some point, but I have trees to climb. Things are pretty good in the sub 2k route range, across all arches. My goal in life today was to get the last 6 routers up and since nlogn has the latest rfcbis stuff in it (?) and source specific seems to be working (when not under stress) I may finally go retire the last cerowrt box also. (note I did send a small patch for a segvio at one point, "check for interface buffer on a multihop request") and ya should take the "late hello" patch as it's the first sign of trouble. ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] basic bird//babeld interop for ss
> * I hit the nlogn branch with the same stuff... it's cpu barely ticks > over, thousands of routes get distributed... it gets knocked off the > network... and all end up unreachable, after everybody else runs out of > some resource or another Dave, I'm planning to merge nlogn into master, so if you have time to debug that, that'd be helpful. ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] 57 forks of babel on github
Hello Dave, There's also my dtls branch. https://github.com/MisterDA/babeld/tree/unicast-dtls It requires some cleanups, updates to the latest draft, and harmonisation with the hmac branch, but I'm confident we'll eventually get there. Happy hacking, -- Antonin ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
