Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FR: make respondd-listenaddress configurable by site.conf #1758

Closed
Adorfer opened this issue Jun 18, 2019 · 13 comments

Comments

@Adorfer
Copy link
Contributor

@Adorfer Adorfer commented Jun 18, 2019

According to #1030
current master (2019.x candidate) changed respondd listen address from ff02::1/2 to additionally(?) ff05::1

  • i understand that this change is needed for babel networks
  • during testing in a network with nodes between 2016.2.x, 2018.2.x and master we did not find a single adress which lets all nodes reply
  • for current existing batman-adv-networks this may be a breaking change
  • in existing networks there are nodes with "autoupdater turned off" and users not reachable/responding to "please update your node" requests.
  • sending requests to multple address is possible, but may burden additional background traffic for the network
  • for now some nodes "without vpn" behind (vpn uplink) of older gluon nodes seem not reply to the hopglass-server at all (my be hopglas issue, has to be investigated)

my suggestion:

please make the listener-address/mcastgroup for respondd configurable by site.conf

@belzebub40k

This comment has been minimized.

Copy link
Contributor

@belzebub40k belzebub40k commented Jun 18, 2019

Simply request on both addresses ff05::2:1001 and ff02::2:1001. This is what we are doing to scrape both old and new nodes.

If your using Yanic as Meshviewer Backend this is pretty easy.

[[respondd.interfaces]]
ifname = "br0"
multicast_address = "ff05::2:1001"
[[respondd.interfaces]]
ifname = "br0"
multicast_address = "ff02::2:1001"
@Adorfer

This comment has been minimized.

Copy link
Contributor Author

@Adorfer Adorfer commented Jun 18, 2019

@belzebub40k thank you for stating the obvious.
I assume that you did not read my point 4 ("background traffic") and 5 ("new nodes behind old nodes").

@belzebub40k

This comment has been minimized.

Copy link
Contributor

@belzebub40k belzebub40k commented Jun 18, 2019

Sorry, missed that. No need to be rude.

@Adorfer

This comment has been minimized.

Copy link
Contributor Author

@Adorfer Adorfer commented Jun 18, 2019

"change the setup of the mapserver" is not a valid answer to "please make the address configurable".

@belzebub40k

This comment has been minimized.

Copy link
Contributor

@belzebub40k belzebub40k commented Jun 18, 2019

True but this is what was requested in the v2017.1 release notes.

respondd now listens on ff05::2:1001 in addition to ff02::2:1001 for mesh-wide operation (#984)

Eventually, ff02::2:1001 will be available for exchanging information between neighbouring nodes only; map servers should be moved to ff05::2:1001.

https://gluon.readthedocs.io/en/latest/releases/v2017.1.html#internals

@Adorfer

This comment has been minimized.

Copy link
Contributor Author

@Adorfer Adorfer commented Jun 18, 2019

and therefore i ask to make it configurable, since point 2 in my request:
We are running a mapserver for more than a dozend of different L2-domains of different communities. And there are some communities where "by default" autoupdater is (or was) off and they will stick with their 2016.2.x nodes foreever. (luckly they are on 11s already, but that's a different issue).

The point is: We are not living in an ideal world, i simply ask to make this configurable.

What i can do in my "own domain" on my own mapserver: i stated in the initial posting that am quite aware about that. I am just asking to make it configurable.

if (in case) we agree that "those networks with old nodes shall suffer":
then this may be the official position of the gluon community and the request can be declined.

But please do not try to explain things to me already know (see initial statement).

@belzebub40k

This comment has been minimized.

Copy link
Contributor

@belzebub40k belzebub40k commented Jun 18, 2019

I only tried to provide a quick solution as it took my some time to fix our map server. I wasn't saying your request is not valid and I would leave that decision to the gluon maintainers.

@Adorfer

This comment has been minimized.

Copy link
Contributor Author

@Adorfer Adorfer commented Jun 18, 2019

o.k understood. Thank you for explaining to everybody in verbose what i wrote on point 5 in the initial statement. ("sending requests to multiple mcast groups from the map server")

if it's not possible via config-option in site.conf (or site.mk....) i would patch it in some or the other ways here locally before build. But that's just the 2nd option.

@petabyteboy

This comment has been minimized.

Copy link
Contributor

@petabyteboy petabyteboy commented Jun 18, 2019

I could not make ff05::2 work with hopglass server. I suspent this is because it is not a link-local address and additional setup is required?

@mweinelt

This comment has been minimized.

Copy link
Contributor

@mweinelt mweinelt commented Jun 18, 2019

You'll probably need to bind your socket to the link local address of the interface you want send the packet out of.

@NeoRaider

This comment has been minimized.

Copy link
Member

@NeoRaider NeoRaider commented Jun 18, 2019

We removed the deprecated address to fix #1701, and for that reason, we won't allow adding it back.

Regarding hopglass, it might have the same issue that gluon-neighbour-info had before a5614a5 - it is necessary to set IPV6_MULTICAST_IF using setsockopt for non-link-local multicast groups. Please open an issue against hopclass if you suspect this is the case.

@NeoRaider NeoRaider closed this Jun 18, 2019
@T-X

This comment has been minimized.

Copy link
Contributor

@T-X T-X commented Jun 18, 2019

Another option to select the outgoing interface for IPv6 multicast is to set a route like:

$ ip -6 route add ff05::2/128 dev <out-iface> table local

At least that's the first issue I usually come across with routable IPv6 multicast and multiple network interfaces and when the default route is not where I want the IPv6 multicast to go out on.

(but hopglass probably still needs to set a hop-limit/ttl > 1 via setsockopt() for routed/babel networks)

@Adorfer

This comment has been minimized.

Copy link
Contributor Author

@Adorfer Adorfer commented Jun 18, 2019

it's pitty that this will kick all 2016.x nodes from the map, until they update or i send requests to both addresses systematically.
(l2-bridges/routers of different domains in the same area as described in #1701 should be avoided anyway). So my request would still be to keep it configurarable in respondd, but if it's not possible, i will just patch it locally as long as there are 2016.x nodes in the network.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.