OpenWrt news, tools, tips and discussion. Related projects, such as DD-WRT, Tomato and OpenSAN, are also on-topic.
Rules
Stay on topic:
All posts should be related to OpenWrt and related projects, including DD-WRT, Tomato, OpenSAN, and more!
No offensive or low-effort content:
Don't post offensive or unhelpful content. Be nice - keep it civil and friendly!
Describe images/videos, no memes:
Please include a text description when sharing images or videos.
No self-promotion spam:
Active community members can post their apps if they answer any questions in the comments. Please do not post links to your own website, YouTube, blog content, or communities.
No reposts or rehosted content:
Share only the original source of an article, unless it's not available in English, behind a paywall or requires logging in (like Twitter). Avoid reposting the same topic from other sources.
No editorializing titles:
You can add the author or website's na
Im considering purchasing a Banana Pi OpenWRT router.
My previous devices have all had internal aerials but this device has four connectors.
Knowing almost nothing about Wifi 6 and aerials How feasible is it to run extensions from one or more of those aerials out the wall of our house and use a larger uni or directional aerial to extend coverage in a particular direction from a high point or should you always have the same short aerials that come with the router?
Hello! I have a repeater setup that has been doing this for a long time, across different builds. I'm pretty confused as to why. is this due to a DHCP drop, or a radio problem? the system log doesn't give me much info besides just saying "link has connectivity loss" before dropping. if anyone might know what's going on, I'll post my system logs and any other info needed, as requested.
Hi, The OpenWrt community is proud to announce the newest stable release of the OpenWrt 23.05 stable series. It improves device support and brings a few bug fixes including security fixes. Download firmware images using the OpenWrt Firmware Selector: https://firmware-selector.openwrt.org/?versio...
I dont even know how to summarize that machine 😄 It is absolutely awesome.
Turris [https://www.turris.com] is a company by the czech TLD registrar CZ.NIC
[https://www.nic.cz/], which is ran as a nonprofit and invests a ton in open
source network software. ## The Origin This talk summarizes it well:...
Asking for a friend - Because I have similar ideas - AP/router hardware recommendations for RV
I'm looking for hardware recommendations for the depicted setup, with an AP/router running OpenWRT in an RV. Requirements:
Compact footprint: Very small equipment cabinet in RV.
Stable (unattended connectivity with light traffic for months).
Dual radios to support simultaneous WIFI uplink to Internet gw, as well as acting as a WIFI AP to clients.
802.11ac or better WIFI speeds.
1 Gbps or better Ethernet ports (at least two).
Light traffic over Wireguard link to home base (telemetry).
Low power usage preferred, 5V or 12V power supply preferred (available without shore power).
Any ideas? Thanks!
My thought was to also add a Starlink Connection using ethernet adapter for when no wifi or Mobile signal is a available and montior the bus with HomeAssistant for security and power management.
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 c
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.
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.
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
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:
undefined
#!/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 "Ma
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 LA
Hi, where I live we have cable internet, it seems this is not supported by
existing OpenWRT firmware. But as far as I understood, the router is the same
and just has a different modem. This could need proprietary firmware, maybe
blobs etc. everything not nice, but isnt the router Software kinda inde...
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).
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.