On Thu, May 11, 2023 at 1:07 PM Ted Mittelstaedt <t...@portlandia-it.com> wrote:
> 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. > Bridging when both ends are cooperating is not difficult (see 4-address mode). The Verizon hotspot is not cooperating. > 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. > I always recommend routing at the station over trying to bridge *UNLESS YOU CONTROL BOTH ENDS*. My recollection of the ubiquiti firmware on the M-class devices is that station-mode implies routing. I use a lot of ubiquiti hardware, but rarely their software. > > 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. > OpenWrt is for people who want to treat their device as a tiny computer that happens to have wifi interfaces... that is, for people who want to be able to construct their own solutions for their particular problem. OpenWrt is not religious, it is entirely practical if you can't build the system you want because some megacorporation doesn't release required programming information for their equipment and reliable reverse engineering isn't available. OpenWrt doesn't support some hardware, mostly Broadcom, because they can't build modern kernels or implement desired features with it. So they focus on hardware where they can. If you don't mind being stuck on some ancient vendor kernel and all you want is a regular router, then sure, dd-wrt is fine. I find dd-wrt repulsive, but tastes vary and that's fine. Unsurprisingly, many manufacturers of wifi gear (like Netgear) -also- have > a client bridged mode in their gear. > It is a widely desired feature. Vendors who implement this for the general case are probably using some form of ProxyARP, which is some hacky NAT-like technology, but at the MAC address layer rather than the IP layer. So, you are relying on probably one firmware engineer at the vendor company to have gotten it right. In contrast to well-exercised netfilter code that has been in the upstream kernel for 20 years and is used by billions of people every day. The problems I recall hearing-about/experiencing with "client bridging" often involve broadcast traffic of one form or another not traversing the "bridge". DHCP not working some of the time, and things like that. > > 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. If the ubiquiti firmware is telling him he can't select the network to even *TRY* to connect, then ubiquiti thinks there is some incompatibility. His set up was working with his phone's wifi tethering and the now-unconnectable distant access point. > 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. > The problem people are likely to encounter is clashing network numbering. Like, for example, 192.168.1.x/24 on both sides of a router. Personal Telco has *many* (NAT'ing) routers stuck behind an ISP's (NAT'ing) gateway routers and they work exactly as expected. As long as you take care with your network numbering, it all works fine. -- Russell Senior russ...@personaltelco.net
