Firmware-update: OpenWrt 19.07.4

Er is een vierde update voor versie 19.07 van OpenWrt 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 belangrijkste verbeteringen die in deze uitgave zijn aangebracht, zijn hieronder voor je op een rijtje gezet.

Main changes from OpenWrt 19.07.3

Only the main changes are listed below. See changelog-19.07.4 for the full changelog.

Security fixes

• Various security fixes

Note: security fixes for packages can also be applied by upgrading only the affected packages on running devices, without the need for a full firmware upgrade. This can be done with opkg update; opkg upgrade the_package_name or through the LuCI web interface. Nevertheless, we encourage all users to upgrade their devices to OpenWrt 19.07.4 or later versions whenever possible.

Major bug fixes

• libubox: fix regression that could cause procd to fail to start or restart some services (FS#3177)
• musl: fix locking synchronization bug
• kernel: fix hardware flow offload
• firewall: fix TCP MSS clamping that was only applied on one direction (FS#3231)

New devices

• Backported support for several 4/32 devices in ath79: TP-Link TL-WR802N v1/v2, TL-WR940N v3/v4/v6, TL-WR941ND v6, TL-MR3420 v2, TL-WA701ND v1, TL-WA730RE v1, TL-WA830RE v1, TL-WA801ND v1/v3/v4, TL-WA901ND v1/v4/v5
• Add new device in ath79: TP-Link TL-WR710N v2.1

Existing devices

• Fix wifi range and throughput for WNDR3700, WNDR3800 (FS#3088)
• Fix broken support for TP-Link TL-WR902AC v1 (FS#3118), Pirelli A226M-FWB, Linksys EA8500, brcm63xx (Huawei EchoLife HG556a, Livebox, BCM6348/BCM6358 FS#2202)
• Fix network hang for all ipq4018 and ipq4019 devices, caused by buggy TCP segmentation offload support for IPv6
• Fix factory installation for Ubiquiti WA/XC devices and for TP-Link Archer C6 v2
• Improve SATA stability on oxnas devices
• Fix USB detection on all rt305x devices
• Various fixes for ELECOM WRC-1900GST and WRC-2533GST, GL.inet GL-AR150, Netgear DGND3700 v1, Netgear DGND3800B, Netgear WNR612 v2, TP-Link TL-WR802N v1/v2, TP-Link TL-MR3020, TP-Link TL-WR841ND v8, TP-Link CPE210 v3, Linksys WRT610N v2, mt7621 devices, ZyXEL P-2601HN-Fx, Astoria Networks ARV7518PW and ARV7510PW22, Arcor 802, Pogoplug v4, Fritzbox 3370, Fritzbox 7360, Fritzbox 7362, Xiaomi MiWiFi Mini, ZyXEL NBG6616, WIZnet WizFi630S, ClearFog Base/Pro, Arduino Yun, UniElec U7623
• Disable build by default for TP-Link devices with 4 MB of flash, because the default package set is too large

Various fixes and improvements

• build: create JSON files containing image information. This is useful for firmware wizards or any other tool that needs to process the list of built firmware images (TODO: link to documentation)
• wolfssl: Fix very time-consuming bignum operations that could cause WPA3/SAE operations to timeout
• Fix locking issue when calling /etc/init.d/network with broadcom-wl

See addressed_bugs for a complete list of bug fixes.

LuCI web interface

• Reload ACL rules after installing LuCI packages
• Fix a regression in menu rendering, where a logout/login cycle or device reboot was required to make additional menu items appear after package installation (GH#4077)
• Allow themes to override the sysauth.htm template to customize authentication
• Update translations from weblate
• Several additional bug fixes and improvements

Core components

• Update Linux kernel from 4.14.180 to 4.14.195
• Update mac80211 from 4.19.120 to 4.19.137
• Update mbedtls from 2.16.6 to 2.16.8
• Update wolfssl from 4.3.0 to 4.5.0
• Update wireguard to 1.0.20200611
• Update ath10k-ct-firmware

Regressions

No known regression at the moment.

Known issues

• Transition to ath79: some devices that are supported in ar71xx are not yet supported in ath79: this is a community effort. Helping to port devices to ath79 to make them available in future releases is very welcome.
• Device support: images for some device became too big to support a persistent overlay, causing such devices to lose configuration after a reboot. If you experience this problem, please report the affected device in the forum and consider downgrading to OpenWrt 18.06 or using the Image Builder to pack a smaller custom image
• Device support: conversely, certain images for devices with small flash (4 MB) are no longer built for the release
• Device support: unstable Ethernet link with atheros switch for some users on some ath79 devices (such as TL-WR841N): FS#2216, FS#2730
• LuCI web interface: some optional GUI packages crash with an error about missing “cbi.lua”, install the luci-compat package to fix these

Versienummer	19.0.74
Releasestatus	Final
Website	OpenWrt
Download	https://downloads.openwrt.org/releases/19.07.4/
Licentietype	GPL

Reacties (36)

[Maurits van Baerle]

Even een kleine waarschuwing voor mensen die voorheen OpenWrt draaide met een versie voor het ar71xx target en die nu willen (en binnenkort moeten) overstappen naar het ath79 target. Maak een backup van je huidige instellingen, liefst nog aparte aantekeningen (ik maak meestal gewoon screenshots van de pagina's met belangrijkste instellingen) en update dan naar een versie uit de ath79 directory zonder je instellingen te bewaren of daarna je backup terug te zetten.

Die backup, aantekening of screenshots gebruik je daarna alleen om je te helpen alles handmatig opnieuw in te stellen.

Er is flink wat veranderd in de switch van ar71xx naar ath79 en het kan goed zijn dat verschillende hardwareonderdelen nu een nieuw nummer of naam hebben. Je kunt dan opgescheept zitten met spook devices die niet meer bestaan onder ath79, omgewisselde ethernetpoorten en dergelijke. Om allerlei vreemde effecten te voorkomen is het beter om deze overstap te maken met een schone lei.

[Reactie gewijzigd door Maurits van Baerle op 22 juli 2024 17:48]

[bbob]

Mijn comfast doet het er goed mee, bijkomend voordeel 2.4ghz vermogen kan naar 27db waardoor hier in huis ook signaal mooi door de betonvloer komt. (buren zitten op 100 meter, dus stoort verder niemand)

[GertMenkel]

Ik vind dat soort dingen altijd lastig. Naast dat het natuurlijk illegaal is, gaat het boosten van het vermogen vaak ook gepaard met slechtere performance als er een apparaat verbonden is dat ver weg is. Je router kan dan wel lekker hard zenden maar je telefoon kan echt niet zo hard terugstralen. Het gevolg is dat je minder lang met je accu kan doen en dat apparaten met goed bereik langer moeten wachten op apparaten met slecht bereik vanwege de onderhandeling die in het WiFi-protocol zit.

Voor een IoT-netwerk dat op een akker een apparaat van signaal voorziet snap ik dit soort maatregelen wel, maar voor stralen door een betonmuur vind ik het maar een matige oplossing.

[bbob]

Heb hier in huis getest, tp-link 225 met 20db = standaard, in midden van de hal.
Dan de comfast met openwrt en 27db.

Zit hier met betonnen vloeren en muren. Beton doet extreem veel met het signaal.
5ghz bijv, sta op 1e verdieping loodrecht boven wifi in de kelder, lees 2 betonvloeren en ca 5 meter afstand. Krijg ap nog te zien, kan verbinden maar doet verder niets.

(meetpunt 1 boven) 2.4 ghz, idem op 5 meter 2 betonvloeren krijg ik met wifi signaalmeter ca 75%.
Schuif ik 1 ruimte op dus betonvloeren en beton muur zak het signaal al naar 16%.

Neem ik de comfast die op meetpunt 1 boven sta, ga ik dan naar de kelder, lees muren en 2 betonvloeren heb ik toch 60-70% signaal.

Werkt in mijn situatie dus veel beter met sterk 2.4ghz verhaal. Gebruik wifi alleen op mobile telefoon, voor de rest ligt overal gewoon bedraad internet. Netwerk wordt dus ook niet overbelast. Daarnaast AP zit ook op 1 gb dus heeft ook genoeg capaciteit.

Wat betreft ver weg. Met je wifi ap versterk je zowel verzenden als ontvangen. Dus als je telefoon verder weg zit maakt dat niet veel uit voor zendvermogen van je telefoon, die ziet beter signaal en past zich daarop aan. Kijk op youtube maar eens testen met wifi ap en leuke antenne die op 10 km soms werken.

Maar gaf al aan in mijn situatie werkt het goed, buren hebben er ook geen last van.

[GertMenkel]

Als het goed werkt en je er niemand mee lastig valt, zal ik je niet tegenhouden om je setup zo te laten hoor. Ik vind het alleen wel storend om dit soort dingen op internet te lezen want ook mensen die niet de ruimte hebben, gaan dit soort dingen proberen. Als je zoiets in een flat opbouwt, maak je het probleem meteen tien keer erger voor iedereen in je flat en krijg je een wapenwedloop aan WiFi-apparatuur.

Wat betreft ver weg. Met je wifi ap versterk je zowel verzenden als ontvangen. Dus als je telefoon verder weg zit maakt dat niet veel uit voor zendvermogen van je telefoon, die ziet beter signaal en past zich daarop aan. Kijk op youtube maar eens testen met wifi ap en leuke antenne die op 10 km soms werken.

Als je het verzendvermogen van een AP opkrikt, versterk je alleen het verzenden; je antenne wordt er niet gevoeliger van. Natuurlijk versterk je beiden als je een extra AP dichtbij plaatst, maar als je in het AP gaat lopen boosten win je daar maar 1 kant op signaalsterkte mee. Je hebt er dus eigenlijk alleen wat aan als je antenne in de praktijk gevoeliger is dan dat hij kan bereiken met uitzenden op normale zendsterktes.

Een groot probleem met dit soort opstellingen is dat 60-70% bereik een nietszeggende statistiek is; de hoeveelheid balkjes geeft aan hoeveel straling je telefoon bereikt, maar niet hoe snel of efficiënt je kan communiceren (naast het feit dat de hoeveelheid streepjes die je apparaat laat zien compleet arbitrair zijn en streepjes in de software op handig gekozen thresholds worden geteld).
Vanwege het RTS/CTS-mechanisme in WiFi moet je bidirectioneel ontvangst hebben wil je data verzenden, dus als de verzendkant te sterk is, leidt dat tot enorme packet loss en onnodige timeouts op alle apparaten op het kanaal. Als je buitenaf woont veroorzaakt dat niet zoveel problemen, maar je hebt ze ertussen zitten die zo'n truc in een rijtjeshuis uitvoeren en daarmee iedereen in de buurt treffen met hun AliExpress-scam.

Met moderne WiFi-standaarden denkt je telefoon door je sterke signaal ook nog eens dat die dichterbij het access point is dan dat hij daadwerkelijk is en gaat deze minder hard zenden om stroom te besparen. Ik heb dat probleem op openbare WiFi-punten vaker gehad; 75% bereik maar geen enkel pakket bereikt de router.

De makers van WiFi-repeaters, en dan vooral de goedkope Chinese merken, adverteren altijd met hoe geweldig de ontvangst wel niet is door te laten zien hoeveel streepjes (en soms hoeveel dB) je op een bepaalde afstand kan houden. Dat soort opstellingen werken in de praktijk juist helemaal niet als je kijkt naar daadwerkelijke throughput, packet loss en storing, maar toch zie ik mensen om me heen die daarin trappen omdat ze hogere cijfers zien en meer vermogen is meer beter.

Kijk op youtube maar eens testen met wifi ap en leuke antenne die op 10 km soms werken.

Die 10km-ontvangst is natuurlijk alleen met een richtantenne, dat is heel anders dan je WiFi thuis. Zo niet overtreden ze zwaar de stralingsnorm.

[bbob]

Je hebt gelijk hoor in flat of met veel buren werkt het niet en zit je elkaar dwars.

Om de werkelijke snelheid te testen doe ik gewoon speedtest, zit op max 300 mbps, met 2.4 wifi haal je dat vaak niet op beetje afstand dus kijk idd gewoon naar de snelheid die speedtest geeft, dat zegt toch idd meer dan bereik% of db

Neem ik bovenstaand voorbeeld tel 1e verdieping AP kelder (met 20db wifi) met 2 vloeren en wat muren er tussen ca 12 mpbs. Ga ik in de kelder bij AP staan en neem dan de openwrt met sterker wifi signaal zit ik op 40 mbps (AP staat waar ik op 1e verdieping andere meting gedaan heb)
download is dan x 3.5 keer beter.
Ondanks dat zoals je zegt signaal misschien kan vervormen heb ik dus toch hogere download met sterker wifi signaal.
5ghz is met beetje beton gewoon kansloos en werkt op 1 verdieping maar verder naar beneden is het vaak al weg.

[Starck]

Voor mensen die OpenWrt draaien op hun Edgerouter X. In deze versie schijnt een fix te zitten voor de hardware offload. Deze geeft zo nu en dan een foutmelding in de kernel log (in OpenWrt 19.07.3).

[Ankh]

Welke offload heb jij precies aangezet? Heb zelf een 200Mbps PPPOE Glas verbinding maar zonder offloading werkt perfect. Als ik offloading aanzet heb ik juist last van meer jitter op de lijn..

[Borromini]

Je moet eerst 'software offloading' aanvinken voor je op ondersteunde platformen 'hardware offloading' kan aanvinken blijkbaar. Hardware offload komt van pas bij hogere snelheden, zie bv. deze thread op het OpenWrt-forum.

[Ankh]

I know, ik heb het getest met de SQM aan en uit. Maar uit eindelijk was mijn jitter hoger met dan zonder SQM. Voordeel is vooral als er heel veel pakketten moeten worden verwerkt, dat je er minder problemen hebt. Maar aangezien het om een thuis situatie gaat en er niet continu verkeer optreed, neem ik dat maar voor lief.

Maar des al niet te min ga ik wel upgraden.

[Reactie gewijzigd door Ankh op 22 juli 2024 17:48]

[Metalfreak]

Even nieuwsgierig: Wat is eigenlijk het voordeel van OpenWRT draaien op een Edgerouter? Ik vind de opties van Ubiquiti zelf eigenlijk al uitgebreid genoeg.

[Starck]

OpenWrt heeft een hele goede smart queue optie voor het verdelen van de bandbreedte en het beperken van bufferbloat.
De standaard ERX smart queue gebruikt FQ-Codel. Bij OpenWrt kan je de SQM package installeren en bij deze kan je CAKE gebruiken.

Zelfs bij heftige download snelheden varieert mijn ping maar ongeveer 5ms. Dus gamen, downloaden en streamen kan allemaal tegelijk, en niemand heeft last van elkaar op het netwerk.

[Harmen]

Bedank voor je reactie, voorheen ook Openwrt gedraaid op een TP-Link.
Hoe zit het met de stabiliteit op een Edgerouter X? Ding loopt nooit vast met de EdgeOS heb ik gemerkt. Vond de gui van luci fijner, mist vooral opties kwa dns en vpn instellingen. Veel moet via de cli.

[Starck]

Ik draai alleen de basis OpenWrt image + luci-sqm package. Dus een vrij kale setup. En daarmee heb ik nog geen gekke dingen meegemaakt.

Verder is EdgeOs in de basis wat completer idd. Maar mij ging het om de CAKE smart queue

[Hansie9999]

Heeft er iemand al een fix gevonden (als die er ooit komt) om in de routers met propierity (spelling ? ) hardware drivers het toch vlot te laten draaien met OpenWRT ? of een andere custom firmware,

Ik heb op mijn TP-Link Archer C7 een tijdje zowel OpenWRT als Gargoyle gedraaid (had op die moment echt gargoyle nodig om er voor te zorgen dat de kindjes niet steeds mijn debiele limiet van telenet van 150GB leegzogen zonder dat ik de juiste kon straffen )

Echter toen ik (met beetje hulp van mijn werk) mijn lijn dan maar geupgrade heb naar een 300mbps met unlimited (fair use) merkte ik dat via de WAN poort (getest met verbinding WAN - LAN los van het internet) ik nog maar een goede 60-70mbps had, zelfs met alle QoS, data loggin, access beheer, .... uitgeschakeld kwam ik met Gargoyle niet hoger dan 110mbps en met OpenWRT lag de maximum (met alle extras uitgeschakeld op 170-180mbps

Als ik dan terug de TP-link stock firmware er op zette had ik meteen terug 949mbps (maximum van een gigabit verbinding met overhead er af)

Na wat opzoekwerk lag dit dus blijkbaar aan het feit dat OpenWRT een software oplossing moet gebruiken omdat de hardware driver van deze TP-link door de chip fabrikant niet vrijgegeven is om gebruikt te worden zonder rechten

Ik vraag me af of daar ooit een oplossing voor komt (denk enkel met goodwill van de chip fabrikant ??)
en zijn er eventueel ergens lijsten van router hardware die ook op OpenWRT hun volle rekenkracht
hebben ? (en je dus niet met een trage WAN verbinding zit ?)

Ik vond de custom firmware echt geweldig tegenover de stock fabrikant firmware (ook opstarten ging veel sneller) maar ik heb wel echt die gigabit nodig (of toch minstens 300mbps op de WAN)


Groeten,

Hans

[Reactie gewijzigd door Hansie9999 op 22 juli 2024 17:48]

[hawaltie]

Welke release van OpenWRT draaide je? 18.x versie? De kernel van de nieuwste builds (en ik denk ook van de officiele 19.07.x releases) ondersteunt flow offloading (kernel >= 4.14). Dat is nog steeds geen hardwarematige oplossing, maar ozu wel moeten leiden tot betere performance. Ik gebruik de Archer C7 al jaren als Access point met Openwrt.

[Reactie gewijzigd door hawaltie op 22 juli 2024 17:48]

[Videopac]

Ik heb een C2600 en een R7800. Beide werken als toegangspunt probleemloos en snel, als router had ik wel de nodige (prestatie)problemen. Als ik het goed heb werkt NAT nog steeds niet goed i.c.m. een aantal chipsets.

[Hansie9999]

Dat was rond april 2019 , weet niet uit mijn hoofd welke versie dat was, daar moet ik thuis eens bij mijn downloads voor gaan kijken (zit momenteel op het werk)

Als je met je huidige firmware een echte WAN-LAN snelheidstest doet zoals hier
https://www.duckware.com/tech/router-wan-to-lan-throughput-test.html
Heb je dan de volle gigabit snelheid ? (949mbps)
Als het mogelijk zou zijn om het even te testen (of als uw internet verbinding 300mbps + is en je hebt meer dan 300mbps bij een gewone speedtest, dan weet ik ook al genoeg, mijn internet is toch maar 300mbps )
Dan weet ik of ik nog eens opnieuw moet proberen met de nieuwe firmware,

Alvast bedankt voor de info,

groeten,

Hans

[sjongenelen]

Ik had dat idd ook op 15 met m'n oude router. Probeer 19 eens opnieuw zou ik zeggen

[terradrone]

Het probleem wat je schets, een fabrikant die enkel een binary blob (binary driver) voor bepaalde functionaliteit levert, is niet op te lossen. Komt veel helaas veel voor. De opensource community is overgeleverd aan de goodwill van de SOC (system on chip) producent. Als atheros in dit geval voor de qca9558 soc geen opensource code vrijgeeft voor hardware offloading / hardware nat voor deze soc, dan houdt het daar op.

Er zijn alternatieve firmware's die toegang hebben gekregen tot bepaalde code, zoals ddwrt die een via een nda toegang hebben tot bepaalde broadcom sources, en dat daarom broadcom based routers meestal beter werken op ddwrt dan openwrt (openwrt heeft geen toegang tot deze code).

Ik meen dat tomato ook binary drivers gebruikt voor haar firmware, en daarom wat makkelijker zaken als hardware nat op sommige devices kan supporten.

https://openwrt.org/meta/infobox/broadcom_wifi

[feico.de.boer]

Dankjewel OpenWrt community, dankzij jullie heeft mijn oude TL-WDR3600 toch nog steeds recente firmware.

[ArnieNFW]

Al geupdate? Ik heb een 3600 gebricked met één van de vorige updates, dus ben blijven hangen op een oude versie...

[robbinwehl]

gebricked ? Krijg je bijna niet voor elkaar ....
weet je zeker dat hij niet te herstellen is ?
Wat doet hij nog wel ?


edit: https://www.youtube.com/watch?v=1hWT35w6sVI

[Reactie gewijzigd door robbinwehl op 22 juli 2024 17:48]

[proditaki]

Zo heb ik inderdaad mijn WNDR3700 ook unbricked.

De Netgear (weet zo het model niet meer) van een vriend van me was een paar jaar terug zo ver gebricked dat er een seriële verbinding op gesoldeerd moest worden om em te fiksen.

[robbinwehl]

Dat heb ik ook al eens voorbij zien komen, zou niet alleen tp link betreffen waar dit een optie is.
zelf nog niet mee van doen gehad gelukkig :-)

[proditaki]

Mja viel op zich mee zaten gewoon testpoints op de print was prima te solderen zonder vergrootglas of microscoop.

[feico.de.boer]

Met de 3600 nooit problemen gehad, ik heb wel een andere tplink gebricked maar dat was een buitenbeentje waar nog geen goede support op was.

[Motrax]

Heb jij nog gemerkt of je WDR3600 betere througput/performance heeft? Ik vind het verdacht dat de WDR3700/3800 specifiek genoemd worden.

Maar goed na 7 jaar trouwe dienst gaat mijn TL-WDR3600 naar een 2e plaats en misschien zelfs helemaal weg. Er komen 2 Ubiquiti UAP-AC-LITE aan. Altijd een el-cheapo wifi oplossing gehad, maar nooit echt goed geweest.

5 GHz was nooit gebruikt, zelfs een kamer verderop was geen optie.

OpenWRT was wel altijd de oplossing geweest. De firmware van TP-Link was niet stabiel, had met enige regelmaat vastlopers.

[feico.de.boer]

De WDR3600 is bij mij niet het primaire accesspoint, dat is een Mikrotik wAP ac opgesteld op een strategische locatie. De 3600 dient slechts als switch enerzijds en extra 5 GHz accesspoint voor de chromecast aan de TV. Aangezien de 3600 op minder dan een meter van het AP staat heb ik een dijk van een signaal op die 5 GHz, in elk geval voldoende om die van de buren aan de andere kant van de muur te overstemmen.

De originele TP-Link software heb ik niet lang gebruikt, maar het voornaamste bezwaar daarvan was het ontbreken van een echte AP mode in de firmware. Je moest dus of een poort opgegeven of in router modus met alle nadelen van dien werken. Openwrt gaf de mogelijkheid alles naar eigen inzicht in te stellen.

[Falco]

Fix wifi range and throughput for WNDR3700, WNDR3800

Dat zijn Netgear routers, de WDR3600 is van TP-Link...
Dus dat heeft weinig met elkaar te maken.

[Motrax]

Scherp! Had ik niet gezien, hartelijk dank voor je bijdrage. Dit is ook de kracht van de community!

[Falco]

Ha ha inderdaad.

Ik heb overigens de wndr3700v4 in gebruik met Openwrt, maar merk weinig verschil.
Volgens mij zag ik in de release notes overigens dat de fix voor de wndr3700v1 was.

Op het Openwrt forum werd de wndr3700v4 als een van de stabielere wndr3700 versies aanbevolen. Maar inmiddels wel wat bejaard. Als AP doet die het echter prima achter mijn Netgear r7800 hoofdrouter (ook met Openwrt erop).

[tom.cx]

Mijn wrt1900ac is weer zeer dankbaar voor deze update. Hopelijk draait het nu allemaal weer wat stabieler :-).

[Verwijderd]

@Bart: het is niet versie OpenWrt 19.0.74 maar OpenWrt 19.07.4.

[feico.de.boer]

Toch maar weer een downgrade naar 19.07.3 gedaan.
Na de upgrade deed KPN iTV het niet meer. Na de downgrade ook nog steeds niet trouwens. Ik heb de igmp proxy in mijn Mikrotik hex router een tik moeten geven om de boel weer aan de praat te krijgen.
Bij gebrek aan tijd laat ik het hier even bij.

[feico.de.boer]

Ok, het was dus niet Openwrt 19.07.4 die in de fout ging.
Ik heb de upgrade nogmaals uitgevoerd en het probleem was toch echt dat de igmp proxy van de Mikrotik vast was geslagen.