Closed ilario closed 5 years ago
Hi ilario, I never came across this setup... can you share a more detailed example on how would you expect to use it, and if you have a rough idea on how to implement it?
I will copy here a comment I made originally elsewhere, tell me if it is clear to you:
a user could want to build a point to multipoint network with hardware that does not support adhoc nor ieee802.11s (I was planning to do this with a lot of modem-routers we received as donations with the local hacklab), for doing this some nodes should be configured as client via radio specific configuration or general configuration (unsupported, I think), see #415 for some problems hindering this
Another reason for using AP-STA as a backbone could be a better support in the drivers for these two modes rather than for adhoc or for ieee802.11s, so for performances and stability reasons.
If the inclusion in bat0 is a solution (it worked for me, maybe there's a better one? @G10h4ck?) I would suggest to expand this line in lan.lua into a section managing the interface inclusion in bat0 (is there also the risk that this interface configuration happens before bat0 is up?)
Awesome. No particular interest of having this kind of networks, neither know anyone that uses them (other than traditional WISPs), but please, no problem on supporting it, sound like falls into something we could be interested in having as a collective.
wifi client can't be used in LAN because there is no standard way to bridge a wifi STA interface
@G10h4ck read above
@nicopace for example, in NinuxRoma they use AP-sta with original firmware for maximizing link performances and they manage the routing via ground routing approach
@G10h4ck suggested to use specific configuration for including the client interface in the routing protocols, something like:
config wifi 'radio0'
list modes 'client'
option channel_2ghz 'auto'
option client_ssid 'LibreMesh.org'
option distance 1000
config net 'wirelessclientBackbone'
option linux_name 'wlan0-sta'
list protocols 'bmx6:0'
list protocols 'client'
See #426 for a partial solution (as this seems a non frequent scenario, we could consider closing).
I think this functionality is very important. Being able to connect to the internet gateway via WiFi instead of cable is very useful and can make network deployment less expensive, faster, and more flexible. See this thread for an example https://lists.libremesh.org/pipermail/lime-users/2018-November/001339.html
@patogit I think you refer to something that is already implemented in mode client here and documented in lime-example. See my answer to the email thread. This issue is about more or less the same thing but for connecting two LibreMesh routers via AP+client, instead you're looking to connect a non-LibreMesh gateway to a LibreMesh router via AP+client.
Until when some non-BMX6 networks (e.g. NinuxRoma with only OLSR on WDS AP-client links or eigenNet with only BATMANadv on adhoc) ask for this feature to be expanded to their scenario, I would consider this issue closed :)
Seems that BMX6 is not going to be included in next release while Babeld will be.
So the current solution in #426 has to be adapted to work with Babeld. Both BMX6 and Babeld are disabled on AP interfaces but BMX6 was running on it anyway as the AP interface was into br-lan which is included in BMX6. I hope that the same situation happens also for Babeld, so that the adaptation of #426 will be straightforward.
Currently the wifi client mode works just if used as WAN, so with a natting and a DHCP client for having the internet access. To build a point to multipoint (as opposed to mesh) network can be a great option in many cases (for example when the topology is a tree or when the hardware does not support neither adhoc nor ieee80211s or if we want to use the better supported ap-sta mode rather than mesh) and being able to use wifi client in LAN network is what's missing. The main trouble in doing this is described here. A proposed solution is to include the wlan0-sta interface in bat0 bridge instead than in br-lan bridge. Related issues: #127, #383, #47