| View previous topic :: View next topic |
| Author |
Message |
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3131
|
 Posted: Sat Sep 10, 2022 7:52 am Post subject: Wifi and bridging - not supported |
 |
|
I tried to enslave wifi (client mode) with a bridge, it fails, and I'm looking for some workaround.
I need to cover a large area with few clients, it would be most convenient if I could just bridge wifi in AP mode with wifi in client mode and have a single address space spanning multiple devices.
hostapd attaches AP to the bridge, so that part is covered. Client makes problems. Setting the other device in WDS mode would probably solve it, but the device does not support it, so I'm looking for some workaround.
Ideas? |
|
| Back to top |
|
 |
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 4133
Location: Bavaria
|
| Posted: Sat Sep 10, 2022 11:35 am Post subject: Re: Wifi and bridging - not supported |
|
|
If bridging is not possible you have routing ...
| szatox wrote: | | [...] and have a single address space spanning multiple devices. |
... and this shouts for "Do subnetting". If your servers see a a.b.c.d/24 address its no problem to give e.g. many a.b.c.d/28-addresses ...  |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3131
|
| Posted: Sat Sep 10, 2022 1:38 pm Post subject: |
|
|
Sure, I'd totally go for it without second thought if I didn't want to support roaming.
I'm not too concerned with scalability, it has to support like a dozen of clients and up to a few dozens is in "nice to have" category, but I don't want to chain the clients to their nearest walls.
Obviously, there are things like tunnels, vpns, vxlan etc, but I'd rather keep it as simple as possible; it's just a handful of devices, so don't want to overengineer it. |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3131
|
| Posted: Sun Sep 11, 2022 11:26 pm Post subject: |
|
|
Well, I guess I'll go with vxlan.
It can be configured with multicast endpoint and it can be configured over ipv6, which is very convenient in for me right now, since I can autoconfigure 2 interfaces for 2 different purposes using 2 methods different enough they don't collide. Apipa for wired admin access, and ipv6 neighbor discovery for tunnel's endpoints, which should allow me to seamlessly add a few additional leaf nodes after I'm done with initial setup. Like in: I flip the power switch and it works.
So, I'll have ipv4 over ethernet over ipv6 over wifi.
I wonder if making this wifi backbone part an ad-hoc network is a bad idea. Just to eliminate the central hub. Some devices will definitely not see each other though...
Madness 
It's going to be a pretty funny little project. |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 4133
Location: Bavaria
|
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3131
|
| Posted: Mon Sep 12, 2022 12:59 am Post subject: |
|
|
| Yes, OvS is more madness. Man, I don't want to see it's UI ever again |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3131
|
| Posted: Tue Sep 13, 2022 7:48 pm Post subject: |
|
|
I've been thinking of introducing more madness with ipv6 site-local addresses and BIRD for OSPF and RADV.
However, it turns out there is no need to do that. When I chained devices A - B - C, and they all subscribed to the same site-local multicast group, device B automagically became a relay between A and C.
Nice.
Now, I can't realistically get rid of the central hub, since I do actually need some place for dhcp and dns and this is the only device that will be physically secured, but I am tempted to try wifi in ad-hoc mode along with multicast vxlan just to see if devices without direct line of sight would still get the message...
Kinda feels like I was reinventing ZigBee and making it worse. It is funny though. |
|
| Back to top |
|
|
|
Networking & Security
