Firmware-update: OpenWrt 23.05.0

OpenWRT logo (79 pix) Versie 23.05.0 van OpenWrt is uitgekomen. OpenWrt is alternatieve opensourcefirmware voor een groot aantal verschillende routers en embedded devices. Door middel van het opkg-package management system is er de mogelijkheid om zelf te bepalen wat de router allemaal wel en niet kan. Ook op GoT zijn er diverse mensen actief mee bezig; zie daarvoor dit topic. Bijwerken van de versie kan gewoon met sysupgrade vanuit de webinterface. De changelog voor deze uitgave kan hieronder worden gevonden.

Highlights in OpenWrt 23.05.0

OpenWrt 23.05.0 incorporates over 4300 commits since branching the previous OpenWrt 22.03 release and has been under development for over one year. Only the main changes are listed below. See changelog-23.05.0 for the full changelog.

Many new devices added

OpenWrt 23.05 supports over 1790 devices. Support for over 200 new devices was added in addition to the device support by OpenWrt 22.03.

  • The ipq807x target for the Qualcomm IPQ807x Wifi 6 SoCs was added
  • The mediatek/filogic subtarget for the Mediatek Filogic 830 and 630 SoCs was added
  • The sifiveu target for the HiFive RISC-V Unleashed and Unmatched boards
Highlights of device support
  • Switched ipq40xx target to DSA
  • VDSL support on AVM FRITZ!Box 7530
  • Support for devices with 2.5G PHYs
    • Acer Predator W6 (MT7986A), Mercusys MR90X v1 (MT7986BLA), Netgear WAX206 (MT7622), Netgear WAX220 (MT7986), ZyXEL NWA50AX Pro (MT7981), Asus (TUF Gaming) AX4200 (MT7986A), Netgear WAX218 (IPQ8074), Xiaomi AX9000 (IPQ8074), Dynalink DL-WRX36 (IPQ8074), GL.iNet GL-MT6000 (MT7986A), Netgear WAX620 (IPQ8072A), ZyXEL EX5700 (MT7986)
  • Support for Wifi 6E (6GHz)
    • Acer Predator W6 (MT7986A), ZyXEL EX5700 (MT7986)
  • 2 Gbps WAN/LAN NAT Routing on ramips MT7621 devices (See OpenWrt forum)
  • Improved DSL statistics on ubus and in LuCI
  • Added Arm SystemReady (EFI) compliant target replacing the armvirt target
Switch from wolfssl to mbedtls as default

OpenWrt has transitioned its default cryptographic library from wolfssl to mbedtls. This shift brings several changes and implications:

  • Size Efficiency: mbedtls is considerably smaller, making it an optimal choice for systems where storage space is paramount.
  • LTS and ABI Stability: mbedtls consistently provides updates via its Long Term Support (LTS) branch, ensuring both security and a stable application binary interface (ABI). In contrast, wolfssl does not offer an LTS release, and its stable ABI is limited to a specific set of functions.
  • TLS 1.3 Support: Users should be aware that mbedtls 2.28 no longer supports TLS 1.3.

While mbedtls is now the default, users who have specific needs or preferences can still manually switch back to wolfssl or choose openssl.

Rust Package Support

This release introduces the ability to include rust-written programs into the OpenWrt package infrastructure. Examples are: bottom, maturin, aardvark-dns and ripgrep.

Core components update

Core components have the following versions in 23.05.0:

  • Updated toolchain:
    • musl libc 1.2.4
    • glibc 2.37
    • gcc 12.3.0
    • binutils 2.40
  • Updated Linux kernel
    • 5.15.134 for all targets
  • Network:
    • hostapd master snapshot from September 2023, dnsmasq 2.89, dropbear 2022.82
    • cfg80211/mac80211 from kernel 6.1.24
  • System userland:
    • busybox 1.36.1

In addition to the listed applications, many others were also updated.

Upgrading to 23.05.0

Sysupgrade can be used to upgrade a device from 22.03 to 23.05, and configuration will be preserved in most cases. Sysupgrade from 21.02 to 23.05 is not officially supported.

  • ipq40xx EA6350v3, EA8300, MR8300 and WHW01 require tweak to the U-Boot environment on update from 22.03 to 23.05. Refer to the Device wiki or the instruction on sysupgrade on how to do this change. Config needs to be reset on sysupgrade.
Known issues
  • lantiq/xrx200 target is not build because the DSA driver for the integrated GSWIP switch shows some error messages. (see: here)
  • bcm53xx: Netgear R8000 and Linksys EA9200 Ethernet is broken (see: here)

OpenWrt 19.07

Versienummer 23.05.0
Releasestatus Final
Website OpenWrt
Download https://firmware-selector.openwrt.org/
Licentietype GPL

Door Bart van Klaveren

Downloads en Best Buy Guide

13-10-2023 • 13:20

35

Submitter: Chris.nl

Bron: OpenWrt

Update-historie

Reacties (35)

35
35
25
2
0
10
Wijzig sortering
Weet iemand wat de beste methode is om op mijn r7800 van 22.03.5 naar 23.05.0 te gaan, met behoud van configuratie en packages?

Ik probeerde $ auc -b 23.05 -B 23.05.0 maar daarmee kreeg ik foutmeldingen helaas ...
Hiervoor kan je de volgende package installeren:

luci-app-attendedsysupgrade

Uitleg:

https://openwrt.org/docs/...ation/attended.sysupgrade
Dat klopt auc is de cli variant van attended-sysupgrade, maar daar krijg ik dus foutmeldingen. Waarschijnlijk omdat bepaalde packages niet meer in 23.05 zitten. Zal eens goed naar release notes kijken en die packages de-installeren voor de upgrade
Wss de wpad/SSL implementatie...?
Ik neem gewoon de sysupgrade firmware van het desbetreffende systeem.
Uploaden, behoud van configuratie aanvinken en flashen maar.
Werkte zonder probleem voor mijn netgear wndr3700
Dat wil zeggen dat de bestaande settings worden behouden. Echter als jij je router hebt voorzien van allerlei additionele packages, worden die bij een sysupgrade niet geïnstalleerd. Dat is gewoon een standaard image.
Ik heb alles van Ubiquiti, muv de router (Linksys WRT32X). Ik heb een Ubiquiti router en EdgeRouter gehad, maar die redden het niet wanneer SQM enabled is. Zeker met Teams en gamen had ik veel last van bufferbloat en ben daarom overgestapt naar OpenWRT. Werkt echt super en zonder problemen. Ik bouw wel custom versie met kernel 6.1 met deze config als basis: https://divested.dev/unof...wrt-builds/mvebu-linksys/. Overigens kan ik niet gebruik maken van de volledige bandbreedte met de huidige router vanwege SQM, dus ben ik alweer op zoek naar een alternatief. Wss wordt het een NanoPi (R6S), maar mocht iemand een goede tip hebben voor een alternatief, dan hoor ik dat graag. Ik wil alleen niets hebben draaien met alleen een SD.
Je bedoelt dat je niet vanaf SD kaart wil booten, om dat als zwakste schakel uit te sluiten?

Er zijn ook industriële SD kaartjes met specs als;
• Endurance Up to 1920 TBW 30K P/E cycles
en features als;
• Bad block management
• Strong ECC engine
• Power failure protection
• Wear levelling
• Auto-refresh read distribution protection
• Dynamic data refresh
• SiP – System in Package
• Garbage collection
• Health monitoring
Info pricewatch

Daarnaast doet OpenWRT vrijwel geen schrijfacties tijdens gebruik. Log en statistics staan default in /tmp/ werkgeheugen.

Ik gok dat je zo'n Kingston-Industrial kaartje simpelweg niet kapot krijgt door er slechts OpenWRT vanaf te draaien/booten, gedurende de levensduur van de NanoPi. Ik gebruik zelf de R4S met zo'n kaartje (zie screenshot bij dit artikel) overkill ten top :+

- edit.

Ik begrijp dat je >1.2Gb/s SQM wil doen, anders zou ik de R4S aanbevelen voor 943 Mbits/sec bron. Ik SQM er nu een 100/25 verbinding mee, resultaat.

[Reactie gewijzigd door Chris.nl op 22 juli 2024 14:18]

Kleine duit in dit zakje. Ik draai OPNSense op een of ander crap SD-kaartje uit de ballenbak uit 2015. Dat was eigenlijk bedoeld als heel erg tijdelijk want ik had even niks anders liggen en wilde toch internet, maar het ding doet het nog steeds eind 2023. Het is een 8GB kaartje. Nu verwacht ik dat OPNSense en OpenWRT min of meer gelijksoortige workloads zijn en dat ze (dus) alletwee niet heel veel raars met het kaartje doen.
Ja, verbaasd me niets (y) Gezien alleen configuratie en packages naar SD worden weggeschreven en het verder eigenlijk read-only is, kan er weinig misgaan.

Specs en relatieve meerprijs wegzetten tegen 'peace of mind' kan voor ieder een andere uitkomst hebben.
Kijk, dit is nog eens een reactie waar je iets aan hebt! Thanks @Chris.nl!

Ik denk dat ik dan toch maar eens de R4S ga verkennen met een industrieel SD kaartje.
Sowieso leuk om mee te spelen en voor de kosten hoef je het niet te laten.

Thanks!
Zou gaan voor een X86 systeem. De gemiddelde firewall box op ali expres of amazon presteert veel beter als een Android box. Tevens kan je er ook gewoon veel meer mee proxmox, openwrt, opnsense, pfsense en veel meer. Virtualiseer openwrt met proxmox en je kan je hardware voor veel meer gebruiken als alleen router. Draai pfsense of opnsense bare metal en kom erachter dat het ook veel gebruiksvriendelijker kan als openwrt (is mijn ervaring met pfsense als variant die ik het fijnst vind).
Zeg niet dat openwrt op een android sbc slecht is alleen zijn er andere krachtigere alternatieven.
X86 is idd koning voor sommige (gecombineerde) use-cases. NanoPi's wegzetten als Android box, vind ik wat kort door de bocht. Deze dingen worden toch echt gemaakt voor netwerktaken (al zijn er ook modellen met HDMI out en idd in te zetten als iets anders met Linux).

2,35watt idle van de R4S en qua SQM rondjes rennen om een ER-X maakt de R4S imo het overwegen waard. Er zijn ook images van opnsence beschikbaar voor de R4S.
Heeft iemand ervaring met 802.11s Mesh, dat wordt vanaf v19.07 ondersteund. https://openwrt.org/docs/guide-user/network/wifi/mesh/80211s

Als ik t goed begrijp is dit Mesh networking tussen routers/access points onderling, en heb je geen Mesh nodes nodig. Ik heb begrepen dat Mesh leverancier afhankelijk is. Ik kan volgens mij Geen TP-link mesh node kopen en samen laten werken met Asus.
Als het wel lukt om de router/AP's bedraad te verbinden, dan is 802.11r of fast roaming ook een prima alternatief voor mesh. Ik heb dat naar volle tevredenheid draaien op een router (woonkamer) en twee AP's (zolder en kelder).

OneMarcFifty heeft ook daarvoor een prima filmpje gemaakt.
https://youtu.be/kMgs2XFClaM?feature=shared

[Reactie gewijzigd door Falco op 22 juli 2024 14:18]

Ik dacht dat ik Mesh snapte, maar na t lezen van alle reacties hier, heb ik nog een hoop te leren :)

Ik heb nu 2 routers, 1 hoofd router en 1 die ik in AP modus heb gezet. Beide zijn bedraad en heb ze hetzelfde SSID gegeven.

Ik heb altijd begrepen dat deze opzet welk werkt, maar een telefoon toch niet altijd schakelt naar t sterkste signaal. Bij een mesh setup gebeurt het switchen wel.
Verschil is dacht ik, omdat ik nu 2 losse draadloos netwerken heb, en met mesh is t er 1 met verschillende nodes.

Wellicht heb ik inderdaad fast roaming nodig, dank, ga ik eens induiken.
Ik heb een 3-pack Zyxel M1: uitvoering: ZyXEL Multy M1 AX1800 (3-pack)

Alle 3 draaien ze als access point (AP) en heb tussen tussen AP 1 en 2 802.11s in gebruik zodat de 3e AP draadloos met het netwerk verbonden is zodat ik op die plek ook bekabeld internet heb.
Daar hangt o.a. een bekabelde IP-camera aan die 24/7 opgenomen wordt op een NVR, en die laat gaan gaten in de tijdbalk zien; dus de verbinding zal wel goed zijn over de mesh.
Ik heb hier goede ervaringen mee. Heb dit gebruikt om 2 wifi AP's met mekaar te verbinden via wifi omdat er geen UTP verbinding beschikbaar was. Voordeel is dat je dan niet achter dubbele NAT zit en dus wel roaming hebt. Voor meer uitleg zie deze youtube film (check ook zijn andere films, hebben me al veel geleerd over openWRT en netwerking in het algemeen)
Ondertussen overgeschakeld op BATMAN. Is iets moelijker om op te zetten, maar het grote voordeel is dat je ook VLAN's kunt gebruiken dan over de mesh.

Hopelijk is dit een antwoord op je vraag, want weet zelf niet zo goed wat je bedoelt met mesh nodes.
Ik heb al enige tijd 802.11s mesh draaien met openwrt in mijn netwerk met verschillende type routers/APs. Werkt zonder veel problemen. Of je ze kan koppelen aan routers die geen openwrt draaien weet ik niet maar als ze de standaard gebruiken, en dus niet een eigen soort mesh protocol, zie ik niet in waarom dat niet zou werken.

Het kan soms wel wat zoeken zijn om het juiste kanaal te vinden voor de performance die je wilt. Sommige kanalen hebben beperkte bandbreedte en 802.11s onder openwrt doet moeilijk op DFS kanalen. (Of je moet gaan klooien met landcodes, wat niet altijd even legaal is).
Ook als je een radio in openwrt als mesh node inschakelt kan je deze niet voor iets anders gebruiken. Maw als je router maar 2 radio's heeft en je stelt 1 radio als mesh node in kan je deze niet meer gebruiken om nog SSIDs uit te zenden waar client devices (gsm, laptop,...) mee kunnen verbinden.
Interessant! Ik heb 22.03 al enige tijd draaien en het werkt erg fijn moet ik zeggen.
Qua veiligheid vroeg ik me wel af toen recent in glibc een kwetsbaarheid ontdekt was (privilege escalation), hoe snel openwrt dan met een patch komt. Of is zo'n router dan sws nog niet kwetsbaar omdat je eerst op het systeem binnen moet komen om van deze kwetsbaarheid gebruik te kunnen maken? Waarschijnlijk is het antwoord ja, eerst binnen zien te komen op de router.
Sowieso is privilege escalation niet zo'n probleem op een OpenWrt router. Vrijwel alles draait als root, dus waar wil je het heen escaleren?
Goed punt, daar had ik even niet bij stilgestaan. Zo'n kwetsbaarheid heeft dus 0,0 impact op OpenWrt?
Zoals ik het begrijp is het door de vuist genomen idd zo dat je gebruik moet maken van die service of poorten open moet hebben staan in de firewall om dan exploitbaar te zijn.

Zo kunnen oudere firmwares (los van merk of OS) die alle inkomende connecties op 'reject' of beter 'drop' hebben staan, nog prima veilig zijn. Omdat er simpelweg geen kwetsbare services te bereiken zijn vanaf de WAN.

[Reactie gewijzigd door Chris.nl op 22 juli 2024 14:18]

Ligt aan de ernstigheid. Soms zijn ze best wel snel een bepaalde package geupdated kan worden via opkg, en anders wordt het opgelost in een nieuwe release (XX.01, XX.02 enz). Wat betreft die privilege escalation, OpenWRT gebruikt musl in de toolchain i.p.v. glibc.
ik wist niet dat dit op sommige fritzboxen ook gedraaid kon worden...blijkbaar dus wel
Heb nog een RT-AC68U, daar maar eens open-wrt op proberen.

Ik was vroeger altijd een dd-wrt fan }> }>
Als je onder openwrt iets simpels als een DHCP range moet instellen dan wordt je dat vanzelf weer ;)
2 Gbps WAN/LAN NAT Routing on ramips MT7621 devices (See OpenWrt forum)
Nice! Nu wordt het maximale uit mijn Edgerouter X gehaald. :*)
Zou jij OpenWRT aanraden boven de standaard firmware voor de Edgerouter-X?
Ik heb juist een Edgerouter X aangeschaft voor OpenWRT, heb de standaard firmware nooit gebruikt. Het apparaat is enorm zuinig en heeft geen moeite met Gbit internet. Ik gebruik de X puur voor het routeren en als DHCP server.
Ik heb dat ook gedaan met mijn Edgerouter X. In basis was ik er erg tevreden over, maar omdat ik SQM gebruik merk je wel dat het apparaat daar eigenlijk niet krachtig genoeg voor is. Is wel een tijd geleden dat ik de Edgerouter X met OpenWRT heb gebruikt. Wat is jouw ervaring met SQM, of gebruik je dat niet.

Ik had namelijk last van bufferbloat met mijn async ziggo verbinding: https://devina.io/speed-test
Ik gebruik geen SQM, heb KPN Gbit glasvezel en ik ervaar geen bufferbloat. Ik heb het echt heel simpel gehouden, paar vlan’s, paar firewall rules en één portforwarding.
Idem dito hier, muv dan dat ik dus voor mijn werk steeds haperingen ervaarde met Teams. Bufferbloat was daarvan de oorzaak. Helaas heb ik een zakelijk Ziggo abonnement van 3 jaar en zit ik er dus nog even aan vast. Het is niet anders...

Maar inderdaad, een super apparaat verder de Edgerouter X.

Op dit item kan niet meer gereageerd worden.