I use wifi bridging all the time. In fact there are so many people that use wifi brides that you get on Amazon and many of the outdoor Aps are sold in pairs because people intend to use them as bridges.
Now, granted all of these setups are manufacturer-provided. Yes they may be "hackey tricks" going on behind the scenes, my guess is the biggest hacky trick is silently enabling WDS. When you go into a tp-link wifi AP and click on the interface to configure it to bridge to another tp-link wifi AP then yes, possibly it is doing that behind the scenes and not telling you it's using WDS. Or it's doing some other hacky trick behind the scenes. I don't know I don't care. It Just Works as a bridge. And you don't have to give a tinkers damn about infrastructure mode, etc. What I was trying to get him to think about is the ROUTING vs BRIDGING issue vs NAT issue. The reason I mentioned using an Atheros chipset specifically is because dd-wrt dropped support for client bridging in Broadcom chipsets a couple years ago since it never worked right. But it is in Atheros gear. I don't know if OpenWRT supports wifi bridging. OpenWRT is a load that is built by a religious order who is only concerned with purity of OSS. In some respects it is a huge disappointment since it has spotty support for what people actually need to use wifi stuff for and the openwrt developers are very snobby about hardware. In other respects it works well and supports gear that dd-wrt does not. Maybe it does not support bridging. Dd-wrt is built by a pragmatic individual who understands what people need in wifi gear. It supports wifi bridging and gear that has inadequate amounts of ram and it's developer regularly discards kitchen-sink applications that people beg to have shoved into the distro. Unsurprisingly, many manufacturers of wifi gear (like Netgear) -also- have a client bridged mode in their gear. Getting back to his problem we don't know (yet) what all is going on with IP addressing, public or private, so we really can't make any usable recommendations other than speculating. And as for multi-layer NAT not being a problem that is just not true. On SOME implementations you can get away with it. But there are NO guarantees. I've seen stacked NAT devices that worked fine and I've seen NAT devices that worked fine when they were just a single NAT device but fell on their face when used behind another NAT device. The idea that stacked NAT or multilayer NAT is at all widespread in industry is baloney. The only people that do it are either gurus who are trying to save a buck on Internet connections or are trying to get completely untenable situations working for connectivity, or utter bumbling amateurs who don't know the difference between a public IP and a private IP. And 95% of the people using multilayer NAT that I see posting problems about it are of the latter type and half of them don't even know they are doing it. It absolutely is not considered good network practices by any measure. For that matter NAT itself isn't even considered good network practice. Ted -----Original Message----- From: PLUG <[email protected]> On Behalf Of Russell Senior Sent: Thursday, May 11, 2023 11:36 AM To: Portland Linux/Unix Group <[email protected]> Subject: Re: [PLUG] Any Ubiquiti Experts? While bridging an AP-mode interface is fine, without hacky tricks adding a wifi station mode interface to a bridge DOES NOT WORK, by design. Infrastructure mode wifi only uses three MAC addresses (to save 6 bytes of packet header). See https://en.wikipedia.org/wiki/IEEE_802.11#Layer_2_%E2%80%93_Datagrams, You need four to bridge at the station. I learned this painfully in 2005. You can get around this by using WDS (that uses 4 MAC addresses), or adhoc mode (IBSS). Both require the cooperation of the AP (which you won't have from the Verizon hotspot's firmware). There is also something called Proxy ARP (at least in OpenWrt), which I've never used and (iirc) has its own shortcomings, probably more dire than just routing. Multi-layer NAT usually isn't a problem. The computational load is distributed across the devices that you are traversing, and almost everyone uses NAT already. It only becomes awkward to manage if you want to initiate connections from the "outside" to the "inside". The only unexpected thing with Michael's situation is that the Bullet doesn't want to associate with the Verizon hotspot. A Bullet M2 is an 802.11N radio. Maybe the Verizon hotspot is requiring an 802.11ac radio to connect, but that seems unlikely, as a lot of little IOT devices won't have 802.11ac radios either. I'd make sure to reboot everything and try again (which you've probably done already). You might confirm you are using an up-to-date firmware on the Bullet M2 in case there were bug fixes. With OpenWrt on the Netgear, you could configure a station mode interface there, but since we don't understand what the problem is with the Bullet, it's not clear that would help beyond removing a device from the chain. You are probably using the Bullet with a directional antenna to be able to connect to a more distant AP (which you wouldn't need with the Verizon hotspot, if it is nearby). One other thing to note, modern OpenWrt might not fit easily on a Bullet M2 anymore, primarily because it only has 32MB of RAM. OpenWrt was historically very good at squeezing things into tiny spaces, but upstream kernel growth and modern devices with more resources (and less consequent pressure to keep things small) have led to progressive abandonment of older, more constrained devices. Even 8MB of flash (with the Bullet M2 has) is becoming inadequate these days. But the 32MB of RAM is the more painful constraint at the moment. I have experimented (thus far, unsuccessfully on a single attempt) to update the RAM chip in a Bullet M2 to 64MB with a pin-compatible part from the same product line, and it ALMOST worked (it booted and ran for 30 seconds or so before panicking). -- Russell Senior [email protected] On Thu, May 11, 2023 at 8:50 AM Ted Mittelstaedt <[email protected]> wrote: > Yeah one of the problems with schemes like this is you are running > double and sometimes triple network address translation and it can be > SLOW if it even works at all. > > Here is my suggestion: > > Get an Atheros-based chipset router. Install either dd-wrt or Openwrt on > it. Configure the unit as a wifi-to-ethernet bridge. Associate it to the > Verizon hotspot and use the translation on the hotspot. > > As for the Bullet that matters how your source wifi is configured. If > the bullet is being supplied by a WISP then you will be getting a > single assigned public IP from that and will need to use your netgear > router to handle that. Otherwise if it's just getting connectivity > from some friend's wifi elsewhere then the bullet also needs to be in bridged > mode. > > Broadcom-based chips don't handle bridging properly, never have. > > You have way too many routers involved here. You need to be thinking > bridging, not routing. > > Ted > > -----Original Message----- > From: PLUG <[email protected]> On Behalf Of Michael Barnes > Sent: Wednesday, May 10, 2023 8:54 PM > To: Portland Linux/Unix Group <[email protected]> > Subject: Re: [PLUG] Any Ubiquiti Experts? > > On Wed, May 10, 2023 at 7:35 PM Tomas Kuchta > <[email protected] > > > wrote: > > > On Wed, May 10, 2023, 17:47 Michael Barnes <[email protected]> > wrote: > > > > > I have a local network using an Ubiquiti Bullet M2 feeding a > > > Netgear > > router > > > that serves my various devices. The Bullet serves as an access > > > point and pulls from an available wifi source. > > > I got a hotspot from Verizon for internet access. When I log into > > > the Bullet to select a source, the hotspot shows up on the list, > > > but is not selectable. It has good signal strength, just not the > > > little circle that allows me to select it. > > > . > > > > > > I am confused about your network topology. So, you get in internet > > over wifi from somewhere, received by the bullet - that feeds > > Netgear router by what? (Ethernet cable?) Then you get your other > > wifi devices connected to Netgear or back to bullet on different > > vlan or ?? Very confusing .... Now you want the bullet to be able to > > get internet from 2nd source (hotspot), but only when it is on? > > > > It loos like pretty complex order. Perhaps you need some low level > > access to the Linux network config on the bullet. If that is so, > > please consider > > a) simplifying your network topology and b) installing wrt on the > > bullet so that you can configure the network and routing directly. > > > > -T > > > > Tomas > > > > Sorry if it was confusing. > > The bullet is connected to an antenna that picks up internet via wifi. > The ethernet from the bullet goes through a POE injector into the > Internet/WAN port of the Netgear router. My various devices (TV, > Portal, a couple Raspberry Pis, etc.) all connect to the Netgear > router. Most of the time there is local wifi available for me to > connect to, but not always. When wifi is not available, I have turned > on the hotspot on my phone and connected to it. However, when I leave, the > network looses internet. > Lately, I've been having to use my phone a lot and have used up my > meager > (6GB) monthly data allocation. Trying to resolve this, I obtained a > Verizon hotspot with 100GB monthly data. When I log into the bullet > to tell it what wifi to connect to, it shows the hotspot on the list, > but does not have the little circle that allows that source to be selected. > > Otherwise, every time I change the internet source, I have to go to > every device and log onto the new wifi. With up to seven or more > devices, and sometimes changing internet sources daily, that is a real > pain. It is so much easier to just have everything connected to the > local network and only change the bullet access point. And since > lately local wifi hasn't always been available to me, I wanted to use the > hotspot. > > Does that clarify it at all? Any ideas on why the bullet connects to > pretty much everything but the Verizon hotspot? I am suspecting the > issue is with the Verizon hotspot, but not sure. > > Michael >
