Re: [Babel-users] [PATCH] Relax martians check
> '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 https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] [PATCH 2/3] Introduce taskqueue for easier tasks and timeout handling
>> I happen to really like timerfds but they are a linuxism. > How would they be used here? >From what I understand, after having used timerfd for a small “projet de réseau”… Instead of what babeld is currently doing: struct timeval tv; gettime(&now); timeval_min(&tv, &some_timer); select(maxfd + 1, &readfds, NULL, NULL, &tv); You create a file descriptor for each new timer. You can chose which clock to use, and if the timer should fire periodically, or at some defined later time. The fd can be monitored with select. When the timer expires, it generates some kind of read event and select exits. A timerfd can be re-armed after it expires, it’s reusable. The API is quite minimalistic. Of course, it’s all managed by the kernel. timerfd_create, timerfd_settime, timerfd_gettime. LWN and the manual are my sources. A quick grep shows that libev does not use timerfd, but libevent does. -- Antonin ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] [PATCH] Relax martians check
On Sat, Dec 22, 2018 at 8:51 AM Juliusz Chroboczek wrote: > > > 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? 'Cause I'd sent you a patch earlier for just e (240/4) and you didn't apply it? :) I have no strong feelings regarding allowing/not allowing 224/4 within the daemon but felt it was better to disallow via a separate bogon list. My project is looking into what it would take to reclaim much of this space also. on the 240/4 front... Linux kernel upstream has obsoleted IN_EXPERIMENTAL, and the backport is now in openwrt, so having babel allowing 240 at least, would allow for further progress. Want another patch? -- 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] [PATCH] interface: clarify error message when adding existing interface
Thanks, applied. ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] [PATCH] Relax martians check
> 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 https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] [PATCH] FIX: interface.c: flush_interface() call local_notify_interface() once
Thanks, applied. ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] [PATCH 2/3] Introduce taskqueue for easier tasks and timeout handling
> 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
Re: [Babel-users] [PATCH] v2: Allow to independently monitor events for neighbour, interface, route, xroute
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 CONFIG_ACTION_ROUTE_MONITOR 8
> +#define CONFIG_ACTION_ROUTE_UNMONITOR 9
> +#define CONFIG_ACTION_XROUTE_MONITOR 10
> +#define CONFIG_ACTION_XROUTE_UNMONITOR 11
> +#define CONFIG_ACTION_INTERFACE_MONITOR 12
> +#define CONFIG_ACTION_INTERFACE_UNMONITOR 13
Please use a single action with a parameter.
> +static void
> +local_notify_all_1(struct local_socket *s)
> +{
> +local_notify_all_interface_1(s);
> +local_notify_all_neighbour_1(s);
> +local_notify_all_xroute_1(s);
> +local_notify_all_route_1(s);
>}
Why is that refactoring necessary?
> +inline void set_flag(uint8_t *d, uint8_t flag) {
> +*d |= 0x01 << flag;
> +}
Please don't -- just but the bit manipulation inline, I find that easier
to read.
-- 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] [PATCH 3/3] utilize taskqueue for check_interfaces()
> 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 ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] [PATCH 2/3] Introduce taskqueue for easier tasks and timeout handling
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 would be to use the opportunity to make babeld multithreaded by using work-stealing scheduler, but that might be overkill. I'd also like somebody to explain to me what are the tradeoffs between a binary heap and the timer wheel. I've used binary heaps (implemented as arrays) since I was but a bairn, but I don't fully understand the timer wheel. -- 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] [babel] BASE64 and hex encoding HMAC keys for user presentation
Juliusz Chroboczek writes: >> 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 case, guidelines as >> to length, mixed case and punctuation would be useful. > > 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 necessarily for the RFC, but at least try to get compatibility between bird and babeld, so users can just input a password and expect things to work? -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
[Babel-users] Marginal IHU [was: more eyeballs on some scaling bugs]
> 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 described in human terms in Appendix A of RFC 6126bis. > If a marginal ihu really is just a ihu that is sent on specific > conditions, we could name this function send_ihu_on_$CONDITION() and avoid > many questions with this small change. > The only thing left to do is: understand the condition. The idea is that: - we send at least one IHU every three Hellos; - if the link is lossy, we send one IHU with every Hello. The condition reads as follows: if(neigh->txcost >= 384 || (neigh->hello.reach & 0xF000) != 0xF000) If the direct cost of the link is above 384, or we've missed at least one of the last four hellos, then the link is marginal, and we send the IHU unconditionally. -- 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] [babel] BASE64 and hex encoding HMAC keys for user presentation
> 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 case, guidelines as > to length, mixed case and punctuation would be useful. 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. (At the current time, I'm not advocating designing a key distribution protocol to go with HMAC -- I'm in favour of using a centralised script that uses ssh to distribute keys. Please see https://cr.yp.to/djbdns/tcp.html) So no, I'd rather not encourage people to generate HMAC keys manually. -- Juliusz ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
