Vincent Wiemann

@christf Everyone who does virtualization in a way which would work with LXC Gluon - including every Freifunk community. In LXC you can only use the kernel/kernel modules provided by...

What is the goal you want to achieve with this gluon-online-status? Better say for what do you want to collect this information? I think gluon-online-status is a bad naming as...

@AiyionPrime What about adding a respondd provider for publishing the gluon-state results?

@AiyionPrime A respondd provider for this would be very useful for diagnostics in the future (maybe not the currently implemented) and I think the overhead is negligible as these are...

@christf This should not interfere with the Babel setup as the local node route table lookup is /128 /32. If it does it should be easy to fix. @rotanid Please...

On layer 3 this patch should work this way: 1. (local_node_rule) IPv4 packet from our local node IP address (indirectly means client is local)? -> put in routing table 2...

@mweinelt We already have simple CLAT and PLAT packages. Maybe you want to play around with them: https://github.com/freifunk-ffm/gluon/tree/christf_next/package/gluon-xlat464-clat https://github.com/freifunk-ffm/gluon/tree/christf_next/package/gluon-xlat464-plat What I'm working on (NAT426) is superior to ordinary CLATs, because...

@christf I'm going to release it, when it's working as expected and cleaned up. The complexity increased on a large scale with the consideration of DDHCP. Unfortunately my time is...

@rubo77 I don't think so. NAT426 is not really a workaround. Babel is initially not designed to handle multiple IPv4 gateways behind a Babel node which don't speak Babel on...

@mweinelt Why is this still blocked? Why can't it be part of v2019.1?