gluon-mesh-batman-adv: Do not add local-if to respondd - #2147
SmithChart wants to merge 1 commit into
Conversation
If there are local services running on an interface that sits on top of bat0 these interfaces may be added to the translocal batman-table. Contrary to the bat0-interface itself this entries are not marked with the TT_CLIENT_NOPURGE -flag and are thus added to the client-count reported by respondd. In this case the client-count reported is one too high. This change adds an additional check to the function doing the actual counting. This check makes sure that no local interface is counted as a client. Since respondd only collects data in an interval of minutes (depending on the site's configuration) the additional costs for this check should be negligible.
Can you explain this setup more thoroughly? I added an IPv4 address to |
I am not really sure if adding an IP address is really enough. In our setup there is also an
The line with This behavior occurs in our v2020.2.1-based parker net with |
|
Okay, I cannot reproduce this on master, even when I try to ping from/to the IPv4 address. Did you also modify firewall settings in your project? |
Yes, we have quite a few changes to the firewall and overall network setup. Regarding firewall there are two mayor steps to get from layer2-forwarding to layer3-routing: First: Set the defaults for our mayor zones: Second: Finetuning: I am suprised: even without firewall ( |
| // Check if client is a local interface | ||
| tt_addr = nla_data(attrs[BATADV_ATTR_TT_ADDRESS]); | ||
| for(ifa = opts->ifaddr; ifa != NULL; ifa = ifa->ifa_next) { | ||
| if( (ifa->ifa_addr) && (ifa->ifa_addr->sa_family == AF_PACKET)) { | ||
| struct sockaddr_ll *s = (struct sockaddr_ll*) ifa->ifa_addr; | ||
| if(memcmp(s->sll_addr, tt_addr, ETH_ALEN) == 0) { | ||
| // This client is a local interface. | ||
| // Do not increment client count | ||
| return NL_OK; | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
// Check if client is a local interface
tt_addr = nla_data(attrs[BATADV_ATTR_TT_ADDRESS]);
for (ifa = opts->ifaddr; ifa; ifa = ifa->ifa_next) {
if (!ifa->ifa_addr || ifa->ifa_addr->sa_family != AF_PACKET)
continue;
struct sockaddr_ll *s = (struct sockaddr_ll*) ifa->ifa_addr;
if(!memcmp(s->sll_addr, tt_addr, ETH_ALEN)) {
// This client is a local interface.
// Do not increment client count
return NL_OK;
}
}
| if (getifaddrs(& opts.ifaddr) == -1) { | ||
| opts.ifaddr = NULL; | ||
| } |
There was a problem hiding this comment.
Single statements are not wrapped in braces in this file. So remove them.
There was a problem hiding this comment.
I don't think this is a good idea in general.
There was a problem hiding this comment.
I am indifferent on this but I tend to go with @blocktrron for consistency in this file for now.
| if(opts.ifaddr != NULL) { | ||
| freeifaddrs(opts.ifaddr); | ||
| } |
|
br-client and bat0 always have the same MAC address in Gluon. |
Ah. good point. Some time ago we decided that we want to set this address to something known: I cannot remember why we decided to do so and our git history is not that conclusive: I will discuss this internally and update this PR once I have the information. |
It seems we don't need the self-set mac address anymore. I'll test that in the next days. And when I am successful I'll just close this PR. |
Thanks @neoraider! You guessed right. We have reverted our changes to the br-client mac-addr and now our client-count is fixed. |
If there are local services running on an interface that sits on top of bat0
these interfaces may be added to the translocal batman-table. Contrary
to the bat0-interface itself this entries are not marked with the
TT_CLIENT_NOPURGE -flag and are thus added to the client-count reported by
respondd. In this case the client-count reported is one too high.
This change adds an additional check to the function doing the actual
counting. This check makes sure that no local interface is counted as a
client.
Since respondd only collects data in an interval of minutes (depending
on the site's configuration) the additional costs for this check should
be negligible.
This problem appeared during development of the Project Parker mesh-vpn implementation. In this scenario br-client is configured with an IP address:
and services like DHCPD and RA are running on this interface.