-----Original Message----- From: PLUG <plug-boun...@pdxlinux.org> On Behalf Of Russell Senior Sent: Thursday, May 11, 2023 2:46 PM To: Portland Linux/Unix Group <plug@pdxlinux.org> Subject: Re: [PLUG] Any Ubiquiti Experts?
On Thu, May 11, 2023 at 1:07 PM Ted Mittelstaedt <t...@portlandia-it.com> >Bridging when both ends are cooperating is not difficult (see 4-address mode). >The Verizon hotspot is not >cooperating. I've had no issues bridging using dd-wrt to my phone in portable setups where a device with an ethernet port needed to get on the Internet and there was no Ethernet port available. Possibly if you have never used dd-wrt you are drawing conclusions based on inferior wifi bridging implementations in openwrt?? >I always recommend routing at the station over trying to bridge *UNLESS YOU >CONTROL BOTH ENDS*. I have to disagree with this one. Inserting routers at both ends of a wifi bridge is actually best network practices. And I mean a real router not an address translator. For starters it eliminates all the TCP/IP broadcast traffic which just adds useless traffic to the wifi link. The issue is not in the network design on this one. The issue is in the "ISP handoff" or rather the border. Best practices is to have the ISP handoff a PUBLIC IP address whether it's DHCP supplied or static. The moment the ISP hands you a PRIVATE number you are off in the weeds and you really need to recognize you are in the insane asylum. And you are in an insane asylum inside of a sinking ship if you don't have control over the NAT device. >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. My go-to is Ubiquiti hardware and software for corporate WDS installs. But I don't judge them to be "the best" Their propensity for the software update of the month is highly annoying, frankly. They are just the cheapest out there that is "corporatized" LOL >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. Then quit being myopic about it and spend the money on a Raspberry Pi or it's clone the Le Potato or whatever they call it, and plug in a wireless USB stick and have a REAL computer not a toy with a crappy power supply, a weak CPU and a propensity for locking up (with certain flaky hardware) >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. Except that dd-wrt somehow CAN build kernels and implement desired features. As can TomatoNG. You are just quoting the OpenWRT bullshit excuses they use to justify not doing the work to support some devices. And OpenWRT does in fact support a lot of Broadcom. Dd-wrt also runs modern kernels on SOCs that have ports of modern kernels to them. I get it, like any OSS project they have limited development time and can't get around to all hardware so they concentrate on a core hardware template. Dd-wrt is no different they have Broadcom based devices they don't support because the main developer didn't put the work into it either, but he isn't inventing BS excuses about OSS purity and megacorporations to explain why he doesn't support it. The Linux network stack and NAT modules are INCREDIBLY inefficient and slow. There was a large research project someone did as their thesis a few years ago that built an efficient NAT implementation that when used to replace NAT in the Linux stack was 50 times faster in some implementations. But Linux Torvalds is not interested in people showing his dirty underwear so he ignored it. And the OpenWRT people pretend that Linux makes a great router platform when the reality is it makes a crappy router platform. This has been proven by FreeBSD multiple times in the past which has a far better network stack as well. dd-wrt's developer finally had to admit this and incorporate the Broadcom software NAT (which they claim is hardware but it really isn't it's just microcode on their SOC) into select models with the Broadcom Northstar CPU and now, for the price of less than $10 for a device you can find in a Goodwill bin, you can get gigabit NAT speeds in a router that has a 500Mhz CPU and a Broadcom SOC. OpenWRT could do this also with the Atheros chipset but they would have to abandon the Linux NAT module to do it. Plus do a lot of work porting in the alternative NAT code. It's just easier for them to spread BS around about megacorporations. > 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. I've run testing on both OpenWRT and dd-wrt for years. Right now I a using a Netgear R6080 running OpenWRT version 22.03.3 and a 5.10.161 kernel, using a MediaTek MT7628AN ver:1 eco:2. About once every couple months the device just stops communicating on the 2.4Ghz band and I have to reboot it. OpenWRT isn’t locking up, but clearly OpenWRT is not watching the radio status or something like that. I have another AP a Linksys E3000 running dd-wrt r47695 with a 2.6.24 kernel, the AP has never once dropped a radio or a client. I have a Netgear r6300v2 running dd-wrt r47608 and the CTF (cut through forwarding) Broadcom go-fast module with a 4.4.289 kernel that is one side of a OpenSSH vpn and right now an uptime of 135 days. I have another one on the other end of that VPN. And the VPN is configured as site-to-site, and it is routed, not bridged. It is so reliable I can run perfectly clear VoIP over it. OpenWRT is fine if you can place the AP somewhere that a user can power-cycle it. I have 10 OpenWRT AP's of various router hardware - all Atheros chips - deployed at another client. These supply wifi for Apple tablets that run the Square app. The users know if Square does not come up to power cycle the Aps and they do that every once in a while. But I have _never_ gotten the uptime out of OpenWRT that I have got out of dd-wrt. Granted, some AP hardware is just crap, and it does not matter if you run DD-WRT on it or OpenWRT on it, it will periodically have to be power-cycled. I would say I probably run about 10% of my wifi gear as an actual router. In fact my main router/translator is a Cisco. Everything else is run as an AP supplying wifi. The simple fact is that with wifi AP's the entire AP hardware is built around the radio. Yes some people can coax the hardware into doing cool stuff but in the last analysis you will have a far better network with more features if you just take some old PC you were going to throw in the trash and stick another NIC in it and turn it into a router, the CPU will be an order of magnitude faster and even with the inefficient crappy Linux stack you can run 1GB all day long, and reserve the AP hardware for the job of moving packets from the wire to the air. Once a vendor like Netgear or Linksys or whoever gets ahold of the radio chip even if it's an Atheros radio they are stamping these things out on an assembly line in such huge quantities that they can screw with the radio chip and make a corresponding screw with in their driver. THAT is why the OpenWRT device I have has problems. Clearly Netgear modified the MediaTek SOC in some manner and modified their driver for it and so that chip now does not exactly match the reference chip MediaTek makes available that OpenWRT is using. >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. Which is exactly what I just said, the best world is to run that netfilter code on a real PC with a powerful CPU not some piece of crap cost-reduced SoC device in a plastic case. Give the piece of crap SOC the job of running the radio gear not translating or routing the packets. And if you have a cow about using a real PC then use a real computer like a Rpi. >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. I don't know since the OP didn't even really outline what his setup was. >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. No it does not. As long as you take care of your numbering AND use NAT implementations that work in a stacked mode it all works fine. But you do have to test it. Personal Telco does that whenever they drop in a new setup like that. If you are able to discard devices that don't work and try a different one why then you can build anything even if it's dependent on ugly hacks. That's why I carry around about 20 different Aps and test on so many. But stacked NAT is just as much as a hack as proxy tricks to create what looks like a "bridge" Ted
