gluon-mesh-batman-adv-core: disable bridge port learning on bat0 #780
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
PS: The included netifd patch was sent to openwrt-devel/lede-devel and is pending for review and upstream netifd inclusion. |
T-X
force-pushed
the
disable-bridge-fdb-learning-for-mesh
branch
2 times, most recently
from
9d1fb62 to
3dbdb2c
Compare
|
New version fixes a bug for the unicast-flood configuration (bug in the gluon-upgrade script part). |
|
The netifd patch is included in Gluon now, please rebase. |
| ) | ||
| for _, lanif in ipairs(lutil.split(sysconfig.lan_ifname, ' ')) do | ||
| uci:set('network', 'client_lan', 'ifname', lanif) | ||
| end |
There was a problem hiding this comment.
This loop won't work if there are multiple LAN interfaces. Maybe you meant add_to_set?
Just adding ifname = lutil.split(sysconfig.lan_ifname, ' ') to the uci:section above seems simpler though, or am I overlooking something?
There was a problem hiding this comment.
Hm, your two suggestions create a "list ifname" but a "list ifname eth0.1" for instance does not seem to work, unicast_flood is not set correctly upon reboot. Only an "option" works.
Is there supposed to ever be more than one lan interface?
neocturne
added
the
2. status: merge conflict
T-X
force-pushed
the
disable-bridge-fdb-learning-for-mesh
branch
from
3dbdb2c to
beab1d7
Compare
|
Rebased to master, removed netifd patch as available upstream now. |
T-X
force-pushed
the
disable-bridge-fdb-learning-for-mesh
branch
from
beab1d7 to
f316d09
Compare
| } | ||
| ) | ||
| for _, lanif in ipairs(lutil.split(sysconfig.lan_ifname, ' ')) do | ||
| uci:set('network', 'client_lan', 'ifname', lanif) |
There was a problem hiding this comment.
- We should investigate why the list doesn't work here
- In any case, this code is plain wrong. If you want to use an option, use
uci:set('network', 'client_lan', 'ifname', sysconfig.lan_ifname), your loop will replace the old value in each run otherwise!
The mesh side has become fairly huge in many communities. Up to a few thousand entries can currently be found in the forwarding database (fdb) of a bridge for its bridge port bat0. The bridge fdb is kind of redundant to the batman-adv global translation table here. Therefore this patch tries to reduce memory footprint by following an approach similar to the IGMP/MLD split patchset approach: Make the bridge oblivious not only regarding multicast listeners towards the mesh but with this patch unicast hosts on the mesh, too. If the destination of an ethernet frame is known by the bridge to be a local one, then the frame is forwarded to the according port. If it is unknown, then the frame is forwarded to the wifi AP interface and bat0. mac80211 and batman-adv then know whether to drop or forward a frame further through their own book-keeping. Note that unicast-flood is not disabled for the wifi AP bridge port, nor is learning disabled on the wifi AP. This is mainly to keep the configuration in UCI and according setup scripts simple ;). However, not disalbling unicast-flood on the wifi AP interface might also give a minor latency improvement for newly joining wifi clients. Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
T-X
force-pushed
the
disable-bridge-fdb-learning-for-mesh
branch
from
f316d09 to
3c3674d
Compare
T-X
removed
the
2. status: merge conflict
ecsv
pushed a commit
to FreifunkVogtland/gluon
that referenced
this pull request
Jun 9, 2017
…ifunk-gluon#780) The mesh side has become fairly huge in many communities. Up to a few thousand entries can currently be found in the forwarding database (fdb) of a bridge for its bridge port bat0. The bridge fdb is kind of redundant to the batman-adv global translation table here. Therefore this patch tries to reduce memory footprint by following an approach similar to the IGMP/MLD split patchset approach: Make the bridge oblivious not only regarding multicast listeners towards the mesh but with this patch unicast hosts on the mesh, too. If the destination of an ethernet frame is known by the bridge to be a local one, then the frame is forwarded to the according port. If it is unknown, then the frame is forwarded to the wifi AP interface and bat0. mac80211 and batman-adv then know whether to drop or forward a frame further through their own book-keeping. Note that unicast-flood is not disabled for the wifi AP bridge port, nor is learning disabled on the wifi AP. This is mainly to keep the configuration in UCI and according setup scripts simple ;). However, not disalbling unicast-flood on the wifi AP interface might also give a minor latency improvement for newly joining wifi clients. Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The mesh side has become fairly huge in many communities. Up to
a few thousand entries can currently be found in the forwarding
database (fdb) of a bridge for its bridge port bat0.
The bridge fdb is kind of redundant to the batman-adv global translation
table here. Therefore this patch tries to reduce memory footprint by
following an approach similar to the IGMP/MLD split patchset approach:
Make the bridge oblivious not only regarding multicast listeners towards
the mesh but with this patch unicast hosts on the mesh, too.
If the destination of an ethernet frame is known by the bridge to be a
local one, then the frame is forwarded to the according port. If it is
unknown, then the frame is forwarded to the wifi AP interface and bat0.
mac80211 and batman-adv then know whether to drop or forward a frame
further through their own book-keeping.
Note that unicast-flood is not disabled for the wifi AP bridge port, nor
is learning disabled on the wifi AP. This is mainly to keep the
configuration in UCI and according setup scripts simple ;). However, not
disalbling unicast-flood on the wifi AP interface might also give a
minor latency improvement for newly joining wifi clients.
Signed-off-by: Linus Lüssing linus.luessing@c0d3.blue