With so many devices implementing there own proprietary standards it is nice to have a way to have something open and standard

Unfortunately, a Linksys E8450 of mine has succumbed to the OKOD (OpenWRT Kiss of Death) (in case you are unfamiliar). From what I understand, it should be recoverable from it's current effectively bricked state. I've tried going through the process, but I haven't had too much luck, and I'm somewhat stuck at the moment, so I would appreciate some guidance. There's two potential objectives that I am hoping to acheive: the first, and primary, objective is to simply recover the router from its currently bricked state so that it can be used like normal, and secondly, if possible, recover the data, and configuration that was on it.

I have tried following this guide, but I'm not sure what I am supposed to do at the end. I completed the last step, but the router still isn't able to boot on its own. If I run boot from the U-Boot console, it appears to be able to boot into the OpenWRT CLI, but if I then reboot from that CLI, it shows the following error:

F0: 102B 0000
F6: 0000 0000
V0: 0000 0000 [0001]
00: 0000 0000
BP: 0400 0041 [0000]
G0: 1190 0000
T0: 0000 02D7 [000F]
Jump to BL

NOTICE:  BL2: v2.9(release):OpenWrt v2023-07-24-00ac6db3-2 (mt7622-snand-1ddr)
NOTICE:  BL2: Built : 21:45:35, Oct  9 2023
NOTICE:  CPU: MT7622
NOTICE:  WDT: [40000000] Software reset (reboot)
NOTICE:  SPI-NAND: FM35Q1GA (128MB)
ERROR:   BL2: Failed to load image id 3 (-2)

That same error is what shows when I watch the serial output of the router while it boots from the power switch.

My Linksys E8450 has succumbed to the OKOD (OpenWRT Kiss of Death). In case you are unaware, the OKOD essentially is the E8450 spontaneously dying. loss of power, or a reboot can lead to it completely dying — the lights don't come on, and it is essentially bricked. Afaik, it is currently unknown exactly what causes it.

Anyways, it may be possible to recover, and I am currently working on that, but should I not be able to recover it, I will need to purchase a new router. To that end, I am looking for recommendations for a new router that is equal to, or better than the Linksys E8450 (it must be well supported by OpenWRT).

I may just buy another E8450, but I am curious if there is a better alternative.

I've noticed a few prosumer type devices are now on the market.

In the instructions it starts "The Outdoor, Wall, EAP225 v3, and later models can be installed via the web interface after disabling FW." - Can I check what FW refers to? I dont want to muck this up.

Hello everyone!

I'm trying to set up wireguard on my phone to access hosts in my LAN and the internet through my router.
I managed to set up wireguard on both ends and get the handshake working, but that's it. I can't ping any hosts in my LAN nor on the WAN.

I created a firewall rule to forward traffic from wg to the lan.
And changed the lan one to allow forwards from wg as well as allow forwards (so it can route the traffic to the wan)
https://imgur.com/a/b7yE0ul

So far no luck. Any ideas?

Hi!

Can anyone please help me to make my MAC be randomly generated after each reboot?

I need some kind of script or instructions. Thanks you!

Found this one:

#!/bin/sh

INSTALL_PATH="/etc/init.d/randomize_mac"

echo "Creating MAC randomizer script..."
cat << 'EOF' > $INSTALL_PATH
#!/bin/sh /etc/rc.common

START=99

start() {
    generate_random_mac() {
        echo $(printf '%02x' $((RANDOM%256)))":"$(printf '%02x' $((RANDOM%256)))":"$(printf '%02x' $((RANDOM%256)))":"$(printf '%02x' $((RANDOM%256)))":"$(printf '%02x' $((RANDOM%256)))":"$(printf '%02x' $((RANDOM%256)))
    }

    change_mac() {
        local iface=$1
        local new_mac=$(generate_random_mac)
        ip link set dev $iface down
        ip link set dev $iface address $new_mac
        ip link set dev $iface up
    }

    for iface in $(ip link show | grep -E '^[0-9]+:' | cut -d ':' -f 2 | cut -d ' ' -f 2); do
        if [ "$iface" != "lo" ]; then
            change_mac $iface
        fi
    done
}
EOF

echo "Making MAC randomizer script executable..."
chmod +x $INSTALL_PATH
echo "Success!"

echo "Enabling MAC randomizer script to run at boot time..."
/etc/init.d/randomize_mac enable
echo "Success!"

echo "Deleting installation script..."
rm -- "$0"

Here is example of output of this command:

echo $(printf '%02x' $((RANDOM%256)))":"$(printf '%02x' $((RANDOM%256)))":"$(printf '%02x' $((RANDOM%256)))":"$(printf '%02x' $((RANDOM%256)))":"$(printf '%02x' $((RANDOM%256)))":"$(printf '%02x' $((RANDOM%256)))

Output:

a7:03:f2:fa:45:5d

I need to make my router Admin panel be accessible not by HTTPS and block HTTP.

I am using Mudi v2

Chat gpt prompted to generate custom CA:

#!/bin/sh
openssl genrsa -out ca.key 4096
openssl req -new -x509 -days 36500 -key ca.key -out ca.crt -subj "/C=XX/ST=XX/L=XX/O=Example/OU=CA/CN=ca.example.lan"
openssl genrsa -out router.lan.key 4096
openssl req -new -key router.lan.key -out router.lan.csr -subj "/C=XX/ST=XX/L=XX/O=Example/OU=Devices/CN=router.lan"
openssl x509 -req -days 36500 -in router.lan.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out router.lan.crt
echo "CA and signed router.lan certificate generated in current directory"

It will generate certificates and key. What to do next?

I'm looking at buying a couple of EAP 225s to provide outdoor coverage for two houuses about 15 meters apart - But I haven't been able to confirm how much memory or The CPU it uses to determine if it would meet my needs. I'm looking to run a few Wireguard connections to route traffic through some other gateways as well as proving WAN access for approx five people. Would want to provide captive portals for visitors and some age related content filtering of Internet access for selected devices.

I'm new to Proxmox and have had Openwrt on an AP router for a while, but still am not all that good at it.

I followed a YouTube video yesterday to set up Openwrt as a Proxmox device. The idea being that I can patch all my containers through it and have a single IP address and many ports associated with it on my home lan.

But I'm also trying to get Mullvad VPN installed on it. When I've followed the instructions to install Mullvad I can no longer ping the outside world. If there's any pointers to getting that going I'd be grateful. I followed the instructions on their website.

Questions: if I get Mullvad working is there a way for me to route some containers through that and others through my own IP, or do I need 2 openwrt containers to get this? I noticed that during the setup I removed the WAN from the LAN and just left Mullvad as an exit route, so I assume I would need a second LAN with the WAN for me to be able to route via it. If that is the case, can I route some through one LAN and some through a second?

cross-posted to: https://sh.itjust.works/post/14114583

If the rule is about forwarding traffic from the lan interface to the wan interface, then why is there also a forward rule? How would inputs, and outputs make any sense if the rule is talking about forwarding? What does it mean for wan to forward to REJECT? I interperet that as saying that wan doesn't go anywhere, but that wouldn't make sense given that the router can send, and receive over the internet.

For example I would interperet the first rule as follows:

• lan => wan: the conditions for which connections from the lan interface are forwarded to to the wan interface.
• Input: accept: the lan interface accepts all connections originating from the network (I wouldn't understand the point of setting this to be reject).
• Output: accept: all connections exiting the wan interface are accepted (again, I'm not sure what the point of this would be).
• Forward: accept: forwarding of packets from lan to wan is allowed.
• Masquerade: I honestly don't know what the effect of enabling this would be. What would it mean to masquerade the lan interface?

I tried finding documentation, and I did come across this, and this, but, from what I could understand, they didn't really answer any of my questions.

I've been playing around with openwisp and it feels very unpolished. The firmware upgrader only supports a few devices and I half the features are broken.

What's worse is that the Github is semi abandoned. There are a decent amount of issues and from what I've seen the team is busy with other things. I have full respect for them but it doesn't look promising.

Have you guys used it?

Hello everyone, I am looking for a good router/modem combo or router that will work with wrt. Looking for something with 2.5gbps ethernet and fast wireless speeds that can be found online at Best Buy or similar stores.

Any reccomendations are appreciated, thanks!

cross-posted to: https://sh.itjust.works/post/13445734

I can see all the devices connected over WiFi, but their security choice seems to be unlisted. For example, if the wifi interface has both WPA2, and WPA3 available, I would like to see what devices are using which.

I'm tight on space with 23.05, and trying to get used to the complexity but IP Tables is like handing highschool students an ANSI C book to get started coding. I need the 90% effective implemented features version that covers 99% of users with 1% of the default verbosity.

The whitelist I have been using in PCWRT has been effective and is simply "IP-Address:port-number". That is all I really need.

I've converted my Asus PN40 mini pc into an openwrt router. Everything seems to be working fine. But since the pc has only one ethernet port I'm using a noname USB to ethernet converter as the second NIC for WAN. Is there a better solution? Are proper USB ethernet adapters a thing? Preferably with Intel chip?

Also i can't get the PC's intel 9000 series wireless chip to work in AP mode. I have hooked an old edimax repeater to the lan port as wifi AP but it's a wireless N device.

Should i invest on a better AP? My ISP connection is capped at 300mbs. Can you recommend a cheap wifi 6 AP?

Also I have 2 internet connections.

Is it a good idea use the wifi in client mode, connect to the first internet through wifi and bond its internet connection with the wired wan?

Thanks for you help in advance.

The core of the agreement is that United Cloud has engaged Sentinel Holding to jointly develop an OpenWrt-based open-source platform as the technological basis for driving innovation, development, reduction of operational complexities and revenue generation.

(Edit: If you have read this post before, please ignore what I posted before and re-read my updated content below, as there has been a number of drastic changes due to an inaccurate testing methodology in my previous attempt at configuring DAWN !)

For those who have not heard of DAWN, it allows Openwrt to steer clients to the AP with the strongest signal.

I spent a week experimenting with it to make it function the way I want it to (with several days' worth of effort wasted due to an app I used call "WiFi Analyzer" for my android phone. This app turns out to have the capability to make my phone make Wifi roaming decisions on its own, when I thought DAWN was the steering source). So these tips are what made it work for my environment. Please be reminded that every network setup is unique, and what works for me may require some additional tweaking for you.

It is very important to get up to speed with the basics by going through this website first and foremost: https://github.com/berlin-open-wireless-lab/DAWN

Use the site to do the initial installation and configuration.

As for the tips:

None of the faq's and wikis state this explicitly I believe: DAWN needs to be setup on EACH of your Openwrt bridge / gateway routers that's part of your connected / mesh Wifi. Each DAWN instance fires BSS transition instructions to clients that are currently connected to that particular router. So routers with no DAWN running on it will never be able to tell the clients it is time to move to another AP.

Also I had problem getting umdns (a DAWN dependency) to start working properly at router startup, so I had to write a startup script to give umdns some encouragement each time the router is powered on. If you run into the same issue, let me know and I can share my script. The symptom of DAWN not working due to this issue is the inability to show neighbor APs in DAWN's "View Network Overview".

Once you get DAWN up and running, it is all about tweaking the config file (and remember to update the file on each of your Openwrt router with DAWN running) to:

1. make each wireless client send proper beacon reports to show DAWN the signal strength of each AP that each client sees at any give time, and
2. make DAWN send out BSS transition requests in a nimble manner (otherwise wifi is disconnected before any roaming can even take place)

Note that for both points 1 and 2 above, I treated DAWN as a black box and just did a lot of trial and error experiments to make it work eventually. So some of the tweaks may look crazy, but it worked for me after making these changes.

1 - Making clients send beacon report that covers EVERY single AP they see (probably more power demanding resulting in more battery drain (?), but necessary for DAWN to have the information it needs to send out instructions accurately:

Under "config metric 'global'", update the values to the following:

    option min_probe_count '0'
    option bandwidth_threshold '0'
    option use_station_count '0'
    option max_station_diff '1'
    option eval_probe_req '0'
    option eval_auth_req '0'
    option eval_assoc_req '0'
    option kicking '1'
    option kicking_threshold '40'
    option deny_auth_reason '1'
    option deny_assoc_reason '17'
    option min_number_to_kick '2'
    option chan_util_avg_period '3'
    option set_hostapd_nr '1'
    option duration '200'
    option rrm_mode 'apt'

These values have the following effect:

• DAWN includes a feature to attempt steering "Legacy clients" that don't support 802.11v as documented in its github page. It DOESN'T work well. My testings show it very often severs the wifi connection of these 'legacy clients' before the client can make a new connection. And it also confuses clients that properly support 802.11v. My update disables this feature altogether.
• DAWN includes a alternative "kicking method" that considers the absolute RSSI (see "Kicking Method 2: Absolute RSSI" in DAWN's github website). It DOESN'T work well and serves to confuse everything. My update disables this feature altogether.
• DAWN's decision making process is sped up with changes made in min_number_to_kick. I tried decreasing chan_util_avg_period also but the kicking got too jittery.
• By changing rrm_mode and duration, WiFi clients will now send "active" beacon reports which means they will actively seek out APs they can connect to and gather info on each AP's signal strength to provide to DAWN. The duration parameter gives these clients enough time to gather the info it needs to generate beacon reports.

2 - Making DAWN work the way you want it to

This part is more like an art where your 'personal taste' comes into play. Here is my own underlying principle (yours may differ):

• I have several radios in both 2.4GHz and 5GHz. The stronger the signal, the more a 5GHz AP takes precedence even if there is a neighboring 2.4GHz AP with as strong a (or even stronger) signal.

• If all of the 5GHz APs are weak (say -70dBm or less), I will then prefer 2.4GHz that are more stable even at the same dBm level.

With this in mind, I only ended up utilizing the rssi_weight and disabled other calculation methods to determine each AP's final score. Here are the settings:

config metric '802_11g'
    option initial_score '200'
    option ht_support '0'
    option vht_support '0'
    option no_ht_support '0'
    option no_vht_support '0'
    option rssi '0'
    option rssi_val '-10'
    option low_rssi_val '-50'
    option low_rssi '0'
    option chan_util '0'
    option chan_util_val '140'
    option max_chan_util '0'
    option max_chan_util_val '170'
    option rssi_weight '4'
    option rssi_center '-25'

config metric '802_11a'
    option initial_score '80'
    option ht_support '0'
    option vht_support '0'
    option no_ht_support '0'
    option no_vht_support '0'
    option rssi '0'
    option rssi_val '-10'
    option low_rssi_val '-65'
    option low_rssi '0'
    option chan_util '0'
    option chan_util_val '140'
    option max_chan_util '0'
    option max_chan_util_val '170'
    option rssi_weight '8'
    option rssi_center '-65'

One caveat - be very cautious if you decide to use rssi_val or low_rssi_val (my above suggestion disables them). If used, the final scores can become super jerky especially when an APs signal strength borders on the threshold. This can easily cause insane jumping back and forth between different APs, and you end up confusing your network client and DAWN.

That's pretty much it ! DAWN works beautifully but only when your settings are right.

No docs yet on wiki - https://openwrt.org/docs/guide-user/base-system/basic-networking#switch_configuration_dsabridge-vlan - just says 'TO DO'.

But all you need to do in LuCi is go to Network -> Interfaces -> Devices -> Configure br-lan -> Bridge VLAN filtering -> Enable VLAN filtering -> define your VLANs -> then for 'bat0', tag the VLANs that you want the data of which to flow through your mesh.

Simple as that. Of course you also need to define your network interfaces (one per VLAN), and remember to attach br-lan.1, br-lan.2, etc (where 1, 2.... are actually your VLAN IDs) to each of your network interfaces.

“It is likely that other products relying either directly on upstream miniupnpd, or on router distribution such as openwrt , vyos or dd-wrt still ship today with vulnerable miniupnpd.”

The Banana Pi BPI-R3 Mini is a compact router board with 2G and 5G antennas. Compatible with OpenWRT, the BPI-R3 Mini supports Wi-Fi 6 connectivity, has 2 GB of DDR4 RAM, 8 GB of eMMC flash storage and a MediaTek MT7986 chipset.