I’m surprisingly level-headed for being a walking knot of anxiety.
Ask me anything.
I also develop Tesseract UI for Lemmy/Sublinks
Avatar by @[email protected]
I’ve always thought the firewall color codes were arbitrary, though I might just have not paid attention all these years lol.
Just to clarify: I meant connect your OpenWRT device to your hotspot instead of the AP you’ve been working with. Just to rule out multiple MACs being blocked on the AP.
Beyond that, I’m not really able to help troubleshoot further, but worst case and if all you need is internet, you can set your OpenWRT device up so that it just NATs your downstream connections. Double-NAT, in most cases, is fine.
Hmm. Is the upstream AP some kind of fancy deal or a run of the mill consumer router?
I’ve seen some Cisco APs configured to not allow multiple MAC addresses from the same station. Caused problems when trying to do VMs on my laptop that had the network in bridge mode.
Are you able to put your phone into hotspot, connect to that instead of the upstream AP, and see if it works?
I did that with a GL.iNet travel router after flashing stock OpenWRT, and used it as a wireless bridge for several years. It uses relayd to bridge the Wifi station interface and Ethernet. Once you have an ethernet bridge, you can connect another AP or do whatever from there.
If you create a second wifi interface in AP mode (in addition to the station/client one connected to the upstream), you should be able to add that to the LAN bridge alongside the ethernet interfaces. That bridge will then be part of the relayd bridge, and it all should just work (should, lol. I haven’t tested that config since I only needed to turn wifi into wired ethernet with this setup).
Interfaces:
LAN Bridge: Ethernet interfaces to be bridged to the wifi
I have both of its interfaces in this bridge, and it also has a static management IP (outside of the WLAN subnet). This management IP is a static out-of-band IP since the devices connected over ethernet won’t be able to access it’s WLAN IP (in the main LAN) to manage it. To access this IP, I just statically set an additional IP on one of the downstream ethernet client devices.
The LAN bridge is in a firewall zone called LAN.
WWAN: Wireless station interface that’s configured as a client to the AP providing upstream access. I have this configured statically, but DHCP is fine too. Firewall zone is WLAN.
WLANBRIDGE: The relayd bridge (Protocol: relay bridge). It’s interfaces are the LAN bridge and the WWAN interface.
Disregard the WGMesh parts; that’s separate and not related to the wireless bridging mode.
Will do!
Github link if anyone else is curious: https://github.com/ripplebiz/MeshCore
That stinks.
The only other thing I can think of, if you’re developing PC apps to utilize Meshtastic, is to use them as local nodes. I’m working on some Python TUI apps and basically keep a Heltec tethered to my laptop over USB to work with that. Next step is to edit one of the case STL files to slim down the battery compartment since I don’t need it for this node and mod a clip to hang off the back of my screen.
Beyond that, I’m still new and haven’t thought up too many crazy uses yet. Hope you come up with something cool. If you do, please share.
I know the Heltecs don’t have PSRAM, but what about the RP2040’s?
If so, maybe set them up as store-and-forward nodes?
Just started playing around with MT a couple weeks ago. Currently have 11 nodes provisioned and ready to do…something with.
So far, I’ve just been playing around with things to learn: figuring out channel settings, deciding on whether to run my private channel in a custom frequency slot or override it to use the “default” frequency slot so it can relay for nodes outside my own mesh. Things like that. Have also been 3D printing various cases for them.
Original plan is/was to have 5 of them configured as portable nodes for when my friends and I go camping, backpacking, hiking, hunting, etc. Kind of a modern text-based version of the FRS walkie-talkies we used to carry (with position reporting as a bonus). Probably going to reserve a few nodes for that purpose and maybe a couple more with bigger antennas that can be temporarily dropped to act as relays (and pick them back up on our way out).
There’s not currently any near me, but I am also looking to start a local Meshtastic group. My backyard has a hill where I can mount a node, and the relative elevation is pretty optimal for it. According to the site planner, I should have pretty good coverage mounting it there (with a solar panel).
I haven’t decided if I want to link the community group nodes via MQTT or try to build it out natively. Maybe I can start with MQTT and hope that it fills in later?
I’ve been using the Meshtastic site planner (https://site.meshtastic.org/) to plan out my mesh before committing to anything. Among other variables, you can plug in the antenna gains/heights to get a good idea of what your coverage will be (though it is just an estimate). A 6 dBi antenna and a few meters of height can go a long way from the results I’ve been seeing. The biggest factor is line of sight, so getting your gateway node up as high above the “smaller” nodes will give the best results regardless of which antenna you go with.
I think “gateway” is the more correct term. From what I’ve read in the docs, “router” is usually used for nodes configured with the “router” role (which is different from a node connected to the internet via MQTT). In most cases, it’s recommended to just keep all the nodes in “client” role since the “router” role behavior can be counter-productive in many cases.