Re: [9front] rpi4 wifi USB dongle

[hiro <23hiro@gmail.com>]

yeah you got it right.

it's hard to find good terminology that still makes sense in all this.

on ethernet all nodes are the same, addressed by MAC addresses. on
wifi a station can only use one mac address, so bridges never work on
wifi stations but only on ap side, of which there can only be one.

On 3/4/21, Daniel Morandini <danielmorandini@me.com> wrote:
>> An ethernet client is a computer with a mac address.
>>
>> Given you have a group of M clients and another group of N clients and
>> you want to connect them, plug the M clients into a switch with M+1
>> ports on one side and the N clients into a switch with N+1 ports on
>> the other side, then use the remaining port and a long cable to
>> connect them together.
>>
>> Imagine now the M-AP is a wifi router, and you want to connect it to
> the N (not AP) over wifi.
>>
>> but here when wifi comes into play not every client is the same. you
>> have many wifi stations and just one wifi *ap*, if we make M-AP the
>> wifi AP, you can bridge all the M clients just fine. that works on AP
>> side.
> You mean “that works on M side" right?
>
>> But if you want to bridge a wifi *station* on the other side, you can
>> not. a station can only bridge N=1 mac addresses into a wifi.
> I’m getting there: practically I would have to make N-AP connect as a
> client to M-AP to keep the only one ap limitation, but at that point
> the new link would not be able to mux more than one ethernet client
> becoming useless for my usecase, did I get it right?
>
>> We have some code in 9front called mat damon, which is like NAT, but
>> for MAC addresses instead of IP addresses. This way one mac address
>> can hide all the N other mac addresses and translate between them. But
>> that's obviously a layer violation, a stupid hack that only exists due
>> to the limitation of wifi.
> :D
>
> dan