/
This version fixes a bug introduced in 1.8.1 that prevented IPv4 routes
from being redistributed. There are no other changes.
Enjoy,
-- Juliusz Chroboczek
pgpF4ODGV1yUo.pgp
Description: OpenPGP Digital Signature
___
Babel-users mailing list
Babel
> it works!
Thanks for the info. It's a serious bug, so I'll make a release this
week-end -- please let me know if you see anything bad.
-- Juliusz
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
> Using master / 1.8.1 really does improve the situation with triggered
> updates. They happen consistently and quickly.
Thanks for the info.
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
Babeld-1.8.1 breaks redistribution of IPv4 routes (but not of IPv4 local
addresses). Sorry for that.
Here's the bug report:
https://github.com/jech/babeld/issues/13
I've committed a quick fix into master:
https://github.com/jech/babeld/commit/157e44a4a507786f5626070d9b1f3e371389
The
Dear all,
Clara Dô and Weronika Kołodziejak, in copy of this mail, are currently
working on adding symmetric authentication (à la RFC 7298) to babeld.
We're wondering how to provision the keys.
My current choice would be have a new configuration statement
hmac 1 sha1
Dear all,
I've just rebased the "unicast" branch over 1.8.2. This means that:
- if you're tracking branch "unicast", you'll need to "git pull --rebase";
- if you've got a branch based on "unicast", you'll need to rebase
(Antonin, Clara, Weronika -- that means you).
Happy rebasing,
--
Hi,
I've just spent four days in Osijek, a small city in the East of Croatia,
invited by Valent Turković (in copy of this mail). It was an interesting
stay.
For those of you who are not up to scratch in European Geography, the part
of Croatia that everyone knows about is the west, on the
> I see a seprate repo for the new hmac code, the revised source
> specific stuff is where?, the rfc-bis stuff is in a branch. etc. It's
> confusing. can it all get rolled up into one thing now? :)
Yeah, it's a mess. I badly need a technician to give me a hand.
We've got the following branches:
Dear all,
The Babel working group of the IETF will be meeting on Tuesday 17 July at
9:30 Montréal time (EDT, UTC-4)
1:30 UTC
3:30 Paris time (UTC+2)
Highlights include a presentation by David Schinazi about DTLS security
for Babel (joint work with Antonin Décimo), and a presentation by
> For multi-homed devices it would be interesting being able to specify
> a preferred source address for routes exported via babel. If the preferred
> src address is not specified, the kernel will select the src address and
> thus will leak ipv6 addresses into a network where they are foreign.
>> If I am building a network now that utilises source-specific routing,
>> how can I best prepare for a migration path?
> If you can just deploy the new version everywhere and reboot the
> network, that would be the best. The 1.9.0 branch (and all future
> versions) are not experimental and will
>> [babel 1.9.0 will introduce incompatible wire-format for src-specific
>> routing]
> If I am building a network now that utilises source-specific routing, how
> can I best prepare for a migration path?
Make sure you run 1.8.2 or later, not an earlier version. Deploy your
network with no fear.
> 2a02 is assigned to br-wan 2a06 is assigned to local-node which is
> a veth-pair bridged into br-client. The mesh is mesh0, mesh1 and so on.
> The node can be addressed by its 2a06 address. This is the default setup
> of gluon. When now communicating over the mesh, neither the 2a02 nor
> the
Hi,
> I know Babel can now run over unicast addresses.
Yes, and I would welcome help testing this feature.
> How can I improve my babeld configuration to utilize the new feature?
First, you need to switch to branch "unicast":
git checkout unicast
Then, rebuild babeld, and put the following
>> Please be also aware that it currently doesn't do source-specific
>> routing (if you don't know what that is, it's not a problem for you.)
> What a pity. SADR is exactly the reason I'm using Babel for.
Give me two-three weeks, then.
-- Juliusz
___
Dear all,
While working on the HMAC security mechanism, we have found an off-by-two
error in the packet parser which could cause babeld to read two octets
after the end of the read buffer. The overflow is not believed to be
exploitable -- a maliciously crafted packet will merely cause two octets
> Following a more-or-less recent trend, I wrote some time ago a Meson
> build file for babeld.
I'm an old man, Antonin, and I've learnt to avoid recent trends.
> On my laptop, a clean build takes 5s with Meson+Ninja, from 10s with
> make.
Are you running "make -j"?
> The pull-request lives on
> * Unless you want to setup unicast Babel you need an individual port and
> tunnel for every Babel connection.
(You mean every Babel neighbour association. Babel is an unconnected protocol.)
> Wireguard's secure IP's feature won't allow you to use the peer
> discovery broadcast address twice
> 92.52 18.1718.17 38243948 0.00 0.00 find_resend
Thanks, that's helpful.
> fix with binary search? timer wheel? ?
Binary heap?
-- Juliusz
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
> is your preferred workflow still patches to the mailing list?
I now know how to generate a patch from a github pull request (ghi --patch),
so either is fine.
-- Juliusz
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
> I keep seeing people talk about running tunnels via babel. Is there a howto
> about how to do it? With wireguard? ipsec ? ssh? Or ?
We've had good success with both GRE (insecure) and OpenVPN over UDP.
In both cases, it's pretty trivial:
- start the tunnel;
- make sure the tunnel endpoints
0. Pro memoria, babeld-1.8.1 and later are safe to use in networks with
the new source-specific code.
1. I've added a new per-interface flag "rfc6126-compatible" to the babeld
config file. It's a noop in the 1.8 branch, in the 1.9 branch it
prevents sending of packets that might confuse
> 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.
> 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
>> 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 >
> 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
> #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=,
>
> 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
> 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
> * 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
Dear Volodymyr,
> default via 192.168.2.1 dev eth0.2 proto static
If you look at /etc/iproute2/rt_protos, you will see that "proto static"
is a protocol number of 4. Now your redistribution rule says:
option 'proto' '3'
This says that only routes with "proto boot" are redistributed. The
Dave,
If you look at the branch xroute-nlogn, there's some code to update
xroutes in n logn time. It's almost completely untested.
If you've got time, I'd be grateful if you could have a look.
___
Babel-users mailing list
> the box doing the injection ate a cpu for all of the 5 minutes the
> test ran
How did the BIRD box behave?
-- Juliusz
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
> Also it would be really helpful if that remaining PR (prefsrc) could be
> considered.
Christof, are you willing to send me a clean patch against the rfc6126bis
branch, or shall I do the merge myself?
-- Juliusz
___
Babel-users mailing list
> Being a meshy protocol, though, if something escapes, usually over
> a "backup" link, suddenly a whole bunch more specific routes end up
> going through that backup link and life goes to hell quickly.
Yeah, that's a common user interface issue.
Now that we have mandatory bits, though, this
> struct babel_addrs { // could use a better name
> unsigned char src_prefix[16]
> unsigned char prefix[16];
> unsigned char src_plen;
> unsigned char plen;
> unsigned short nexthop; // an index, not a ptr, into the nexthop
> table, sometimes unused
> };
> struct resend
Dear all,
This is to remind you that the Babel working group will be meeting
tomorrow at
15:40 Bangkok (UTC+7)
9:40 Paris (UTC+1)
3:30 New York, NY
0:30 San Luis Obispo, CA
Remote participation is free and warmly welcome. Please see
https://www.ietf.org/how/meetings/103/remote/
> Oh, thank you! I stared at this bit of code for hours, trying
> different things, printfing, stepping through a debugger... trying to
> figure out where infinity was missed.
Except it's completely wrong ;-)
Careful, I'm going to rebase the branch.
-- Juliusz
Thanks for all the patches, Dave.
> the nlogn branch has a bug in that redistribute local deny does not work.
This should be fixed now.
-- Juliusz
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
>> Except it's completely wrong ;-)
> yes, I just tried it. :(
Fixed. (Hopefully, I really need to take a couple of days off.)
-- Juliusz
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
>> Yeah, we should just include an implementation of SHA-256 in the code.
> There's also the option...
Given that the main selling point of HMAC vs. DTLS is that it has no
dependencies, it wouldn't be particularly wise to make the reference
implementation depend on a Linux-specific library.
Of
> In looking over the bird patch, it looks like I merged the wrong
> thing.
Yes, it looks like it. hmac-challenge is the right code.
Weronika, perhaps you could rename the branch hmac to something less
exciting?
Dave, please be aware that the HMAC code is not quite finished yet. Once
we got a
> +rc = setsockopt(s, SOL_SOCKET, SO_MAX_PACING_RATE, , sizeof(rate));
It's only effective on TCP sockets, and only when using the FQ scheduler.
-- Juliusz
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
>> do loop-free routing.
> Hah. :)
> I note that babel doesn't actually do that, any more.
Pick a pair (p, id), where p is a prefix and id is a router id. Consider
the graph defined by all route table entries indexed by (p, id). Then
Babel guarantees that at any time this graph is acyclic.
Hi,
I've just merged a bunch of stuff into master:
- branches xroute-nlogn and rfc6126bis are now obsolete;
- please track master instead.
This means that master now implements the new revision of the protocol,
temporarily known as RFC 6126bis. Please see
Dear all,
Babeld-1.8.4 is available from
https://www.irif.fr/~jch/software/files/babeld-1.8.4.tar.gz
https://www.irif.fr/~jch/software/files/babeld-1.8.4.tar.gz.asc
This is hopefully the last release in the babeld-1.8 branch, and the last
release to implement the old source-specific
> Received prefix with no router id.
> Couldn't parse packet (8, 12) from fe80::230:18ff:fec9:de9c on eno1.
Dave, this is concerning, as it indicates that either BIRD or babeld is
violating the spec. I'll try to reproduce it, but if you manage to
capture the paket that's causing this message,
> And I'm *not* importing proto 51 of this list into babeld, but when it
> does a kernel dump, it gets it all, hits an internal memory limit
> processing the netlink data and doesn't manage to import *any* kernel
> routes.
Right. As I've mentioned previously, the redistribution code in babeld is
> Well, I will go test in the lab. You are saying that even relaying
> routes through a 1.8.0/1 box will mess things up?
No, it's redistribution that's broken.
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
> I also discussed issues with tim (cc'd) was having on his raspberri pi
> (arm) based version. He seems to have got a much stabler result after
> reverting to 1.7.1.
Correct. In 1.7.1, babeld got more stable and less reactive. We tweaked
the logic again in 1.8.0 to make it more reactive again.
> One of my environments uses BGP full-table from 3 upstream ISPs (each
> with 785k routes currently).
Well, that's a lot. BGP is designed with that in mind -- it uses
incremental updates layered over a reliable protocol, and therefore scales
beautifully in a stable network. Babel uses
>> I tested the babel-1.8.3 release under some extreme loads with 90
>> routes present (30 ipv6 total)
> BTW, I disagree with the word "extreme".
We should have no problem with this kind of load on wired. OTOH, it's
rather extreme for wireless -- 802.11 doesn't behave well in dense
networks.
>
>> I'll point out that the BIRD codebase is cleaner and better designed
>> than babeld, and might be able to scale better. I'd be interested in
>> seeing a comparison.
> Yeah, me too.
Toke, perhaps you'd like to post some instructions?
-- Juliusz
___
> It happens with almost no data at all being passed except the babel overhead.
> I
> can watch it in wireshark.
Could you please try reproducing this with "babeld -d2", and send me the
logs by private mail?
___
Babel-users mailing list
Dear all,
Babeld-1.8.3 is available from
https://www.irif.fr/~jch/software/files/babeld-1.8.3.tar.gz
https://www.irif.fr/~jch/software/files/babeld-1.8.3.tar.gz.asc
For more information about the Babel routing protocol, please see
https://www.irif.fr/~jch/software/babel/
The main news
> Received prefix with no router id.
> Couldn't parse packet (8, 13) from fe80::eea8:6bff:fefe:9a2 on enp6s0.
> Received prefix with no router id.
> Couldn't parse packet (8, 14) from fe80::eea8:6bff:fefe:9a2 on enp6s0.
Toke, are you mis-parsing retractions? No router-id is necessary for
a
Your config looks fine to me. Perhaps I've missed something.
Please run babeld with "-g 33123" and do
echo dump | nc ::1 33123
and send us the output.
Also send us the output of "ip route show".
-- Juliusz
___
Babel-users mailing list
>>> Received prefix with no router id.
>>> Couldn't parse packet (8, 13) from fe80::eea8:6bff:fefe:9a2 on enp6s0.
>>> Received prefix with no router id.
>>> Couldn't parse packet (8, 14) from fe80::eea8:6bff:fefe:9a2 on enp6s0.
>>
>> Toke, are you mis-parsing retractions? No router-id is
> Well, I took a stab at some of that. In particular, babeld has to compare
> a lot of bytes, and while profiling it on these loads, was totally
> bottlenecked on memcmp.
Yep, the code in xroute.c is pretty pessimal, since I wan't expecting
people to have massive numbers of redistributed routes.
> I've lost track of where that repo is, but if you find a version of
> babeld that speaks the new source-specific protocol, bird should
> interoperate just fine with that :)
I'm working on merging the Matthieu's new source-specific code into
the unicast branch of babeld. Please hold your breath
> I used to have a patch to update_neighbour that logged late hellos. The
> new update_neighbor code in 1.8.3, well, in a half hour of staring at it
> I didn't figure out a good place to stick this. But it was a useful
> patch to have. you can't fix what you can't measure.
Try the "missed_hellos
> -const int ds = 0xc0;/* CS6 - Network Control */
> +const int ds = 0xc2;/* CS6 - Network Control + ECN */
Nope. If we start lying about ECN, people will start disabling ECN in
routers, which would not be a good thing.
___
> --- a/kernel_netlink.c
> +++ b/kernel_netlink.c
> +static int ipv4_metric = 0;
> +static int ipv6_metric = 1024;
That's exactly the wrong layer at which to do that. Policy should be
happening at least 17 layers higher.
What problem is that intended to solve?
>> B) you run out of cpu - babeld uses linked lists,
Not quite -- the route table is a flat array, with per-destination
linked-lists. We don't walk the linked lists often, we mostly walk the
flat arary.
>> and tries to recalc bellman-ford every 4 seconds also.
No, it doesn't. It only does the
> And yes, reverting the apu2 to 1.7.1 fixed the default route issue.
Can you confirm that 1.8.2 didn't work? There was a bug in 1.8.[01] that
could be what you're seeing.
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
> I can confirm now that this has been happening for quite some time, both
> my lab gws are 1.8.0.
Cool, known bug then. Fixed in 1.8.2.
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
> 'Cause I'd sent you a patch earlier for just e (240/4) and you didn't
> apply it? :)
I'm a bad man. Please double-check commit 19a442ba.
-- Juliusz
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
> I find it difficult to read the babeld code
It was difficcult to write. I don't see why it should be easy to read ;-)
> I guess that reach is a bitmap of some kind, storing on which of the
> last 16 hellos the neighbour was reachable.
That's right. The logic is in update_neighbour, and
Thanks, applied.
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
> I would like the bird and babel implementations to allow for and use
> BASE64 and hex encodings.
> This allows for a shorter, more human friendly representation of both
> cryptographically generated keys and the keys humans are more likely
> to remember and type without error. In the latter
Thanks for the code.
> The task queue allows to schedule tasks that happen in the future.
This implements a binary heap as a linked tree, which has very poor
locality. In order to improve locality and avoid memory allocations, we
should be implementing the heap as an array.
An alternative
> this illustrates how the taskqueue can be used and removes a little bit of
> code from the main loop
It would be more interesting to see how you can replace the mess that is
resend.c. That will require an interface for task cancellation.
-- Juliusz
Great, I've been planning that for a long time.
> +.B neighbour-monitor
> +and
> +.BR neighbour-unmonitor ;
Please use the syntax "monitor neighbours" and "unmonitor neighbours".
Two keywords.
> +#define CONFIG_ACTION_NEIGHBOUR_MONITOR 6
> +#define CONFIG_ACTION_NEIGHBOUR_UNMONITOR 7
> +#define
> I happen to really like timerfds but they are a linuxism.
How would they be used here?
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Thanks, applied.
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
> This patch enables both class-e and multicast IP addresses to be
> carried within the babel protocol.
No objection to class E, but why multicast?
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
>> I think that the HMAC key should be generated automatically. I'd hope
>> that any actual production deployment of HMAC would generate HMAC keys
>> either randomly or by using a suitable KDF (or whatever the right acronym
>> is) and distribute it automatically.
> Should we pick a KDF? Not
> This is the present babel conf file format:
> key id key1 type sha1 value deadbeefdeadbeefdeadbeefdeadbeefdeadbeef
> key id key2 type sha1 value dea2f0d01a57b0071057a11da7adeadbeeff
> interface enp7s0 unicast false hmac key1
> interface wg1 hmac key2
Right. It currently cannot be updated
> In glibc (not musl so far as I know) the clock_getttime lookup is
> incredibly fast because it just maps in the relevant kernel page and
> does the work without a syscall,
In musl too:
https://git.musl-libc.org/cgit/musl/tree/src/time/clock_gettime.c
Also, babeld doesn't make that many
> as keys (currently) protect each interface, not each router association...
Correct. Babel uses both unicast and multicast, and Babel-HMAC is
designed so that it can protect multicast traffic while remaining immune
to replay, even in the absence of persistent state or hardware clocks.
>
> The "one interface per key" rule adds complexity but I think it also
> brings benefits by requiring such.
It's conceptually elegant and easy to explain. These are good features to have.
> About the only issue I see for an interchange like this is that you'd
> also need one ipv4 address per
> FWIW, for homenet the thought was to use HNCP to distribute keys amongst
> routers.
HNCP is not a good choice for symmetric key distribution, since it floods
all information across the HNCP domain. It's impossible to use HNCP to
distribute a key to some routers only while keeping it secret
> Setting that aside for the moment, having a standardized file format
> for babel keys would be a boon and boost interoperability between
> bird/babel and other possible implementations.
Have you looked at RFC 7210?
-- Juliusz
___
Babel-users mailing
Thanks, Christof.
I'm still dealing with exams and student defenses, I'll review all of your
proposals during the holidays.
Genuinely sorry for the delay,
-- Juliusz
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
>> With these numbers, I withdraw my support of including anything else
>> than SHA256 as MTI. I think specifying Blake2B or 2S as well makes
>> sense (mostly for crypto robustness reasons for having alternative
>> that is specified) but making it MAY-SHOULD seems sensible to me.
> I can probably
>> (1) leave the document as it is;
>> (2) add a mention that implementation of Blake2S is RECOMMENDED (SHOULD);
>> (3) add a mention that implementation of Blake2B is RECOMMENDED;
>> (4) add a mention that implementation of both 2B and 2S is RECOMMENDED.
> I'm in favour of (2).
Where is
> I'm not sure if we *can* make [blake2s] MTI in the spec as well (does it
> need to be defined by a standards track RFC for us to do that?), but if
> we can, I think we should seriously consider it...
Opinions?
___
Babel-users mailing list
> Anyway, the default hash function is sha256 in the hmac-challenge
> branch. I approve, there's hardware support for it, and if someone
> breaks it, civilization collapses, so an alternate hmac is a "good to
> have", and what's in that branch... is ripemd160.
From a standardisation point of
> Dave had a good point as well though, comparing -2s and -2b performance
> on some set of hardware (e.g. arm, mips, intel) might be in order before
> picking between the two.
HMAC only protects the control traffic, not the data traffic. I'm not
convinced that performance is particularly
> Why not? If it's not MTI you risk the case where you get to pick between
> "good performance on weak devices" and "interoperability with RFC-only
> implementations".
Is there any evidence that there are devices that can reasonably run Babel
and that are too weak to use SHA256 for protecting
> in https://github.com/jech/babeld/pull/16 I provided a small patch that
> fixes a crash on ipv6-only nodes
The issue, I believe, was with interfaces that don't have a link-local
address (yet) when they are being monitored over the local interface. It
was triggered by your netlink patch --
> (I ran across this babelweb pic from my old c.h.i.p + rtod experience,
> which cracked 16sec of delay in the mcast queue:
Bufferbloat in the driver queues?
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
> Recently I tried to deploy a few babel 1.8.2 nodes with the latest
> openwrt, which I had to back out rapidly because I was dropping so many
> babel packets under contention.
That's interesting. Could I please see a log?
> A patch to universally enable babel ecn in net.c "solves" this
Hi,
A number of fixes have accumulated in the master branch. I'd like to
release a 1.8.3 fairly soon, so if anyone has time to do some testing, I'd
appreciate the help.
Thanks.
babeld-1.8.3 (unreleased)
* Fixed a read-only two byte buffer overflow in the packet parser.
This is a
>> Interesting. AFAIK, ECN is only considered by AQM queues, so this implies
>> there's a queue in the way that's dropping Babel packets.
> There's fq_codel on every queue, which does FQ, and codel assumes
> everything is at least moderately TCP friendly (and/or reasonably
> responsive to ecn
>> Where is Blake2S-based HMAC defined? RFC 7693 merely says
> Section 3.3 simply says:
>If a secret key is used (kk > 0), it is padded with zero bytes and
>set as d[0]. Otherwise, d[0] is the first data block. The final
>data block d[dd-1] is also padded with zero to "bb" bytes
Dear all,
The Babel meeting at IETF 104 will be this Thursday 28 March in room
Athens/Barcelona.
https://datatracker.ietf.org/meeting/agenda/
If you're in Prague, please come. If you're not in Prague, please attend
through the Internet :
https://www.ietf.org/how/meetings/104/remote/
The
>> Is there a command to check if babeld is working and which
>> nodes are in the topology?
> There is the `-d level` (level 1 is good enough) of babeld that
> shows neighbours and installed routes.
Uh-huh.
You can also:
- send a SIGUSR1 to babeld to get a dump;
- run babeld with '-g
> For BATMAN, I’m using LibreMesh.org and for BABEL, I’m trying to find a
> solution using OpenWRT and babeld but it is not a success… Does anybody know
> where I can find a simple solution using Babel protocol to implement on my
> routers with OpenWRT (or something similar)?
It is my opinion
> Yes, in this situation all neighbor stations enumerate. Everyone can ping
> everyone via 802.11s mesh.
You're running Babel over an 802.11s mesh? Why?
Both Babel and 802.11s are routing protocols (more exactly, 802.11s
contains a routing protocol). Running both in the same mesh is
1 - 100 of 278 matches
Mail list logo
