I get about 350-400 both ways which AFAIK is what my Unifi AC-Lite tops at since it's WiFi 5 and it's only got 2 antennas and tops at 80MHz channels. I get about 200-250 on my phone (1+8T) which I think is single stream.
Everything indicates me that's as best as it can be with the set of hardware I have. Signal is solid, latency is solid.
You'll need 802.11ax and/or more MIMO streams to get higher speeds, and/or 160MHz/320MHz channels.
So what's stopping the workers from saying no? If they have labor shortages then the job market should be favorable to the workers as you gotta be the most attractive employer, which would be those that don't abuse that law and overwork their employees. It's not like they can force people to work.
Felons should be able to vote, even while in prison. Otherwise you just have to make sure your political opponents are all charged with a felony and skew and keep skewing the results because those people can never vote to potentially make their crime no longer a crime.
Like, if they ever make it a crime to be gay, now they've basically also stopped gays from being able to vote on the issue. That's not good democracy.
The guy that manages Kbin has been having personal issues and stepped away from the fediverse so yeah Kbin is kind of in limbo at the moment and indeed not well moderated. There's mods but there's just so much they can do. The software doesn't federate the deletions so even if they're gone on Kbin, they remain everywhere else.
Kbin is not currently maintained due to the guy that makes it having personal issues and not having time to keep up with it. Some instances are even defederating kbin due to spam not being cleaned up and also some bugs sending the same activities over and over again.
It's default since systemd afaik. I think systemd-tmpfiles manages this. It's never been a problem for me, it pretty much remains fairly empty most of the time. Most things like sockets are in /run which is also tmpfs.
That works too. Ultimately theyâre all NAT, thatâs why theyâre in the NAT table to begin with. Masquerade specifically is to rewrite the traffic as if it was originating from the router itself, which can be useful if you donât know which interface itâll go out, you just want it to NAT no matter where. SNAT just rewrites the source address so itâs a bit less smart. Thereâs also DNAT to rewrite where the packet will go. Itâs not just addresses either, you can rewrite ports too. Thereâs also REDIRECT.
Just different ways of doing similar things, but theyâre all doing network address translation. For OpenWRTâs purposes it is indeed what everyone thinks of a NAT, the most simple and common one. Past that a GUI becomes more of an annoyance than a feature anyway, so might as well go for scripts or at least raw iptables rules.
Thereâs also the whole connection tracking system on top of the firewall rules. If youâre clever you can make a load balancer right in iptables, since connection mappings will stick. You donât have to always rewrite it the same for every packer.
Thatâs not quite what masquerade does. Masquerade enables NAT, essentially.
Without masquerade, the router would send packets out like 192.168.0.109->8.8.8.8 and your ISP would be like âwhat is that IP I donât know how to route thatâ. With masquerade on, the router remaps it to its own WAN IP so you have like 3.16.87.54->8.8.8.8, your ISP can handle that, and when the reply comes back, the router then switches it back to the correct internal IP.
Erm, okay thatâs not looking promising. Itâs starting to look like Router A doesnât like this setup at all. Itâs not routing Bâs traffic, possibly because itâs not the subnet it expects to serve. Ugh. Check all the options you can in Router A if you can find something that will allow it to work.
You can fairly easily test that by enabling masquerading on B. Itâll break most of what we just set up but itâll confirm that.
We still have some options on the OpenWRT side to make it masquerade only public traffic but now Iâm wondering if A will even let you port forward to something on B. I would try that now and see if it works.
Is A able to ping B and devices on B, or only on A? A itself has a route for Bâs subnet right?
Interesting, lan zone doesnât allow forward from wan but wan does allow both ways, maybe thatâs the one missing. I expect OpenWRT to wire it up both ways automatically⊠OpenWRT is a mystery sometimes.
Actually no, both show unspecified. You need both zones to allow both ways from the other zone.
I think you also need to enable full forwarding to and from wan on Router B. I forgot it defaults to not doing that. Set input, output and forward to ACCEPT on Router B on the wan zone, and make sure you also allow forwarding to and from the lan zone. Router A should be fine, I assume Aâs WiFi and LAN is the same?
Basically now, Router A sends the traffic to B but B doesnât forward it to its LAN. But since we donât have NAT, Aâs devices addresses Bâs devices directly, not B itself, and there isnât any connection tracking happening, so it doesnât ârememberâ to allow the ping response back in. If you WireShark this, I bet B is successfully sending packets to A and Aâs devices, and Aâs packets make it all the way to B but B doesnât forward it to its own LAN, and it stops there.
Can you post the output of ip ro and ip a on both routers? (Feel free to redact your public IP/ISP stuff if it shows up)
I think I set this right: Network->Routing->Add->(Interface: wwan, Route type: unicast, Target: 192.168.0.1/24, Gateway: 192.168.1.1)
That doesnât seem right. If youâre using the exact same subnet numbers Iâve used for example: thatâs be target 192.168.1.0/24 (Bâs network) gateway 192.168.0.2 (Bâs IP on Aâs network as a WiFi client).
Router B is on two networks at the same time: its own (192.168.1.1/24) and Aâs network (192.168.0.2/24).
Router A is only on its own network (192.168.0.1/24) and talks to router B as just a client on its network (192.168.0.2). Whenever it has data to send to the 192.168.1.x network, it sends it to 192.168.0.2 which is on that network and will relay it.
How would I go about doing this? I canât find any definitive information on how to disable NAT in OpenWRT.
Router B would wan configured as a WiFi client with a static IP of 192.168.0.2/24 and default gateway of 192.168.0.1 (router A). The regular default route will do just fine, as that will cover Aâs network as well. Weâd only need to configure more if there was a third router involved. From there you just need to disable IP masquerading option in Network -> Firewall (you want it unchecked):
You donât need masquerade even though itâs technically a âwanâ because A knows how to send traffic to Bâs clients, so B itself doesnât have to pretend its clients come from itself.
I do need this. I believe this would then require an mDNS reflector, right (it wasnât required before as relayd was bridging the networks)?
If that proves too complicated, Iâd consider trying out the GRE tunnel method your original article suggests as an alternative to relayd. Itâs kind of like a super basic VPN that I think can be hardware offloaded so I wouldnât expect much of a performance hit, maybe even less than the relayd option.
