OK here is something simpler. All you need is something that will replace the bullet and connect to the Verizon hotspot and to your netgear wan port. You can keep using the bullet to connect to the unnamed "distant" wifi whatever that is, and to your AT&T phone when you turn on tethering since that works.
I'll send you out a couple routers you can play with one configured with a dd-wrt version that has a working client bridge and the other configured with openwrt. You can then either use the instructions here for openwrt: https://openwrt.org/docs/guide-user/network/routedclient or here for dd-wrt: https://wiki.dd-wrt.com/wiki/index.php/Client_Bridge whichever one you find easiest to use, to connect to the hotspot. OR THERE IS SOMETHING EVEN SIMPLER THAN THAT: I have a nice used Samsung S9 that originated on the Verizon network that I'm no longer using. Since you know you got good signal on the Verizon network, I'll send you that phone and you can contact Verizon and cancel the hotspot account, then contact AT&T and cancel your existing cell phone account, then get an unlimited data plan from Verizon and have them send you a sim out for the S9. Cost on an unlimited plan is likely cheaper than cost on the Verizon hotspot AND the AT&T cell plan. And I'll even throw in a dd-wrt router that will connect to the S9 when it's running it's wifi tethering. Ted -----Original Message----- From: PLUG <plug-boun...@pdxlinux.org> On Behalf Of Michael Barnes Sent: Thursday, May 11, 2023 9:08 PM To: Portland Linux/Unix Group <plug@pdxlinux.org> Subject: Re: [PLUG] Any Ubiquiti Experts? Thanks anyhow, folks. I was hoping for something simple. I'm afraid 80-90% of this disussion has gone way over my head. As I age, I think I have forgotten more about this networking stuff than I knew in the first place. I didn't think it was all that difficult to understand the layout, it is pretty simple. Outside gain antenna > Ubiquiti Bullet > Netgear WAN port > wifi/ethernet to devices. Log into Bullet and select available wifi network from scan list. Sometimes the available wifi network is distant or very weak, hence the big gain antenna. At times, no network was available, so I connected to my phone as a hotspot. Sometimes adequate AT&T signal is not available or I used up my monthly data allocation, so I acquired the Verizon hotspot. The Bullet shows the Verizon device on the scanned network list, but does not allow it to be selected. I have a very limited budget and even more limited skillset anymore. Obtaining the Verizon equipment and service was a huge hit. Acquiring additional equipment is simply out of the question for both financial and logistical reasons. Thank you all for your time anyhow. Unfortunately, it was more an exercise in frustration and futility for me. Michael On Thu, May 11, 2023, 21:55 Ted Mittelstaedt <t...@portlandia-it.com> wrote: > > -----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 >
