Messages

Thanks Franco. I think I had two things going on. The USB Wireless adapter hardware was going bad was the big one. After replacing with an identical tp-link AC600 Archer T2U Nano, I got things going again but it still doesn't like being turned off and on. Here's what I see from the console:

rtwn0: rtwn_tx_beacon_check: cannot push beacon into chip, error 60!
rtwn0: unable to push beacon into the chip, error 60
rtwn0: rtwn_newstate: could not move to RUN state
rtwn0: rtwn_bulk_tx_callback_qid: called; txeof qid=4, error=USB_ERR_TIMEOUT
rtwn0: rtwn_bulk_tx_callback_qid: called; txeof qid=4, error=USB_ERR_TIMEOUT
rtwn0: rtwn_bulk_tx_callback_qid: called; txeof qid=4, error=USB_ERR_TIMEOUT
rtwn0: rtwn_tx_beacon_check: cannot push beacon into chip, error 60!
rtwn0: unable to push beacon into the chip, error 60
rtwn0: rtwn_newstate: could not move to RUN state
rtwn0: rtwn_bulk_tx_callback_qid: called; txeof qid=4, error=USB_ERR_TIMEOUT
rtwn0: rtwn_bulk_tx_callback_qid: called; txeof qid=4, error=USB_ERR_TIMEOUT
rtwn0: rtwn_bulk_tx_callback_qid: called; txeof qid=4, error=USB_ERR_TIMEOUT
rtwn0: rtwn_bulk_tx_callback_qid: called; txeof qid=4, error=USB_ERR_TIMEOUT
rtwn0: rtwn_bulk_tx_callback_qid: called; txeof qid=4, error=USB_ERR_TIMEOUT

Like you said, I think the firmware must be buggy.

Thanks, franco. I guess talking about it helped. I had the idea to delete the interface and device and recreate them from scratch. After that, it seems I can now disable and enable the interface and it's working. Here is my guess on why that can happen now.... the field/setting for BSS vs. AP mode is now (after 26.7.4) on the wireless/devices page instead of the interfaces/edit page, so disabling/enabling the interface doesn't touch that anymore. As for why deleting and recreating the interface and device fixed it for me, I'd assume it's because there was something left over in the config from the pre-26.7.4 situation.

EDIT: I tested too quickly. While it's true I can disable the interface and re-enable it and it's working, I didn't check the behavior while it's still disabled. While the interface is disabled, the card is not actually turned off. The SSID is still broadcasting and clients can still connect but not get routed anywhere afterwords. So is there no way now to turn off the SSID besides deleting the wireless device or pulling out the physical USB adapter?

I didn't see the call-to-testing thread regarding the MVC/API migration for wireless until after upgrading to 26.7.4. I do use WiFi occasionally in my network as an access point (it's not on all the time). In the past, to enable it, it was necessary to (1) enable the WLAN interface, (2) toggle the mode from BSS to access point mode. This got it up and running and when done, I would (1) switch it back to BSS mode and then (2) disable the WLAN interface. The toggling between AP mode and BSS mode was necessary for clients to be able to connect.

Now, after 26.7.4 the old trick doesn't work anymore, nor does simply enabling the interface. In my troubleshooting, it seems to be necessary to enable the interface with the AP setting and then reboot the whole firewall. I'm hoping there's a way to fix this? It's not urgent as I don't use it very often, but it would be nice to have working right.

My experience was:
1. downloaded 26.1.2 nano and wrote the image to a new SD card
2. saved the configuration to file, powered down the firewall, swapped SD cards, powered it back up
3. imported the saved configuration
4. wifi seems to be working, interface and its configuration is there, but no ISC DHCP to provide addresses
5. upgraded to 26.1.3 from serial console, rebooted
6. installed the os-isc-dhcp plugin
7. DHCP didn't want to start, so rebooted
8. all is well, wifi clients can connect, no patches needed
9. the bug is still there where in AP mode you can't just disable the adapter and re-enable it and expect it to work- after enabling you have to toggle mode from Access Point to BSS and back, then it will work

@_Alchemist_ I realize this is 4 years later, and we have instances instead of servers now. But shouldn't

Code Select Expand

- Interface                                WAN2
- Protocol                                 UDP
- Destination                            WAN1 address
be

Code Select Expand

- Interface                                WAN2
- Protocol                                 UDP
- Destination                            WAN2 address
?

Thanks, franco!

I have a couple of clients with multi-wan on 25.1, they are not upgraded yet (thanks for posting!). Please do update when you find a fix.

Thanks for posting this (and the update!) I had a client down due to this yesterday, and could only isolate it to something going on with Starlink.

I found this reddit post that suggests if you boot the dishy up connected to the stock router, once it's been up for a few minutes, you can remove it and put your own 3rd party router back in. Then it should work until the next time the dishy reboots: https://www.reddit.com/r/Starlink/comments/1bjr8yf/how_i_mostly_got_back_to_normal_with_a_gen1_the/

Also found this unofficial starlink-related site stating the problem: https://www.starlinkhardware.com/firmware-updates/

Hopefully this gets fixed soon.

Clean install / reconfigured from scratch a relatively simple setup: Static WAN, LAN, WLAN, HE TunnelBroker, OpenVPN Server Instance. Everything is working great!

Of course, windows is very exploitable in general. This is not news. The issue is how you protect it. Your internal machines should never be reachable from the internet. That's something any firewall can accomplish, when properly configured, including opnsense, like codera said. You need to set up the correct rules to prevent inbound connections and avoid using technologies that bypass them like port forwarding, pinholes, upnp, cloud based remote access, etc.

Back up your config and start from a clean install - primary WAN and LAN only with default rules. Add Plex and Jabber for family harmony and test the ping again.

Add features back in until it breaks, then analyse what broke it.

I agree with bartjsmit. This could be any of many possibilities with your network configuration. We won't find it by guessing. The best way to find out is by backing up your current configuration, resetting to defaults, and configuring again, checking at each step for broken ping. Then you can analyze what it is about that step that's preventing the ping from working. If things get too hairy, or it takes too long, you can always restore your old working configuration from backup and be right back where you were before.

Your screenshots look similar to mine. I use Unmanaged (SLAAC only) instead of Assisted (SLAAC + DHCPv6) but that's a matter of preference and shouldn't make a difference.

When you say "clients do not receive ipv6", do you mean they don't get IPv6 addresses assigned? Double-check RADVD and DHCPDv6 services are running in System-Diagnostics-Services. Also, double-check client NIC configuration- is IPv6 enabled as a protocol?

Also- you did not share screenshot of LAN Interface Configuration/Overview. Make sure it is configured with and has a static IPv6 address in the /64 you need your clients to receive addresses in.

Hope that helps!

Well, two and a half weeks later and the IPv6 addresses and prefixes have not changed since installing the patch. So I can't say whether or not this works for us or not. But stable prefixes are even better!

Moral of the story is... I guess you never know what to expect with the "better than nothing beta" Starlink.  :)

Hi, you followed this guide? https://docs.opnsense.org/manual/how-tos/proxytransparent.html

You probably need to import the certificate into the Firefox Browser and not the OS. Or enable Firefox to search and import OS CA's: https://support.mozilla.org/en-US/kb/setting-certificate-authorities-firefox

I got the client's firewall upgraded and the patch has been applied. I'll update here the results here when the prefix changes for future people finding this topic by search.