[OpenWRT] Ervaringen & Discussie

root@WDR3600:~# cd /tmp
root@WDR3600:/tmp# opkg install dnsmasq-full_2.73-1_ar71xx.ipk
Installing dnsmasq-full (2.73-1) to root...
Collected errors:
 * satisfy_dependencies_for: Cannot satisfy the following dependencies for dnsmasq-full:
 *      libnettle *     kmod-ipt-ipset *
 * opkg_install_cmd: Cannot install package dnsmasq-full.
root@WDR3600:/tmp#

[Voor 77% gewijzigd door ThinkPad op 12-09-2015 16:01]

ThinkPadd schreef op zaterdag 12 september 2015 @ 15:37:
Ik heb geprobeerd om de tutorial opnieuw te volgen, maar OpenWRT kan door het gebrek aan DNS geen adressen herleiden en dus werken de stappen uit de tutorial ook niet
Hoe krijg ik nu DNS weer werkend? Pingen van 8.8.8.8 werkt wel, maar 'ping nu.nl' niet.

Compizfox schreef op zaterdag 12 september 2015 @ 16:05:
[...]

Even 8.8.8.8 in /etc/resolv.conf zetten in plaats van 127.0.0.1? Daarmee omzeil je de lokaal geïnstalleerde DNS-server (unbound/dnsmasq).

[b]ThinkPad schreef op zaterdag 12 september 2015 @ 15:37:
Net geprobeerd om de package handmatig te installeren (.ipk van dnsmasq-full gedownload via PC op wifi in de buurt), maar wil niet:

[Voor 4% gewijzigd door Maurits van Baerle op 12-09-2015 16:21]

ThinkPadd schreef op zaterdag 12 september 2015 @ 15:37:
Ik heb rc3 nu draaien, zal ook even upgraden naar de final. Dat zal niet zo spannend zijn dan inderdaad.
Heb RC3 al een paar weken draaien op m'n pricewatch: TP-Link TL-WDR3600, werkt als een trein

Edit: Oh crap, net klaar met updaten maar nu werkt internet niet meer, omdat ik met 15.05rc3 dit gebeuren had gedaan i.v.m. DNSSEC.
Ik heb geprobeerd om de tutorial opnieuw te volgen, maar OpenWRT kan door het gebrek aan DNS geen adressen herleiden en dus werken de stappen uit de tutorial ook niet
Hoe krijg ik nu DNS weer werkend? Pingen van 8.8.8.8 werkt wel, maar 'ping nu.nl' niet.

Net geprobeerd om de package handmatig te installeren (.ipk van dnsmasq-full gedownload via PC op wifi in de buurt), maar wil niet:

root@WDR3600:~# cd /tmp
root@WDR3600:/tmp# opkg install dnsmasq-full_2.73-1_ar71xx.ipk
Installing dnsmasq-full (2.73-1) to root...
Collected errors:
 * satisfy_dependencies_for: Cannot satisfy the following dependencies for dnsmasq-full:
 *      libnettle *     kmod-ipt-ipset *
 * opkg_install_cmd: Cannot install package dnsmasq-full.
root@WDR3600:/tmp#

Misschien maar een clean install doen en dan de config terugzetten, dat gaat sneller dan dit geklier

list server '/pool.ntp.org/208.67.222.222'

[Voor 7% gewijzigd door Borromini op 12-09-2015 17:02]

Dennis schreef op zaterdag 12 september 2015 @ 16:43:
[...]

Als je internetsnelheid 30mbps is kun je een kaart van 1400mbps hebben, maar je internet wordt er uiteraard niet sneller van. Het is wel zo dat .ac op de 5GHz band werkt en de meeste andere versies op 2.4GHz. Die 2.4GHz werkt in principe beter door muren heen en op grotere afstanden, maar omdat de band redelijk vol is, zeker bij appartementen, kan een 5GHz Wi-Fi soms betere performance geven.

Op korte afstanden (dus bijvoorbeeld: laptop en router in dezelfde fysieke ruimte) werkt 5GHz sowieso beter.

Borromini schreef op zaterdag 12 september 2015 @ 16:59:
[...]


Je moet zorgen dat NTP werkt, als de tijd van je router teveel afwijkt dan gaat het niet werken. Zet daarom bv. 0.openwrt.pool.ntp.org in /etc/config/dhcp:

list server '/pool.ntp.org/208.67.222.222'

Dit hier is met een OpenDNS IP.

Oh en mocht je je bedenken over dnsmasq, ik heb ondertussen Unbound draaien als primaire DNS-server (en dnsmasq voor mijn LAN). Instructies op mijn blog

[Voor 7% gewijzigd door ThinkPad op 12-09-2015 18:07]

[Voor 75% gewijzigd door Maurits van Baerle op 12-09-2015 18:57]

ThinkPadd schreef op zaterdag 12 september 2015 @ 18:04:
[...]
Ander vraagje, er staan wat traffic rules nu default in: http://i.imgur.com/FRzpgIP.png
Maar zijn die echt nodig? Het zegt mij helemaal niks namelijk, en ik wil geen onnodige gaten in m'n beveiliging hebben natuurlijk.

Maurits van Baerle schreef op zaterdag 12 september 2015 @ 18:21:
Ik zie daar niets eigenaardigs in staan. Die Ping, DHCP en ICMP rules heb je sowieso nodig en die IGMP is voor Multicast ondersteuning lijkt me.

Mithrildor schreef op zondag 13 september 2015 @ 20:12:
[...]


Waar is die ping regel voor nodig dan? Wat heb je er aan dat mensen van buiten af jouw router kunnen pingen? Naar mijn mening is het toch net iets veiliger omdat uit te schakelen (tenminste als je ongewenste pakketjes van WAN ook dropt, anders heb je er vrij weinig aan). Veel scheelt het ook niet hoor, maar het is toch net iets veiliger als het van buitenaf lijkt alsof er niets aan jouw ip-adres verbonden is.

[Voor 9% gewijzigd door Koldur op 13-09-2015 22:46]

Koldur schreef op zondag 13 september 2015 @ 22:45:
[...]


Zonder die regel kan je zelf niets pingen, komt dan niets door je firewall heen en zullen alle pings TO's geven.

strandbal schreef op zondag 13 september 2015 @ 10:51:
Zo, net m'n Archer C5 geupgrade naar de 15.05 final (ik draaide een oude trunk versie). Via VPN die van m'n schoonouders ook geupgrade (ik weet het, spelen met vuur, remote firmware upgrades ) en ook deze kwam netjes weer up

MarcoC schreef op maandag 14 september 2015 @ 00:00:
Ik krijg de 5GHz-verbinding niet hoger dan 15dBm met Chaos Calmer op mijn WDR3600 . Iemand een idee?

johnkeates schreef op maandag 14 september 2015 @ 00:03:
[...]
Kan de radio van de WDR3600 überhaupt harder? Volgens mij zat daar een atheros in, en die kan je niet tweaken op die manier, om dat die z'n settings uit ART trekt van NVRAM en je alleen 'lager' kan gaan en niet hoger dan wat daar in staat.

[Voor 17% gewijzigd door Maurits van Baerle op 14-09-2015 08:53]

Dennis schreef op maandag 14 september 2015 @ 08:35:
[...]

Ja, maar als de networksettings niet juist worden overgenomen kun je er remote niet meer bij .

RutgerM schreef op maandag 14 september 2015 @ 09:51:
[...]


Dat valt lokaal te testen

en in principe wordt er gewoon een backup terug gezet na de flash

[Voor 94% gewijzigd door ThinkPad op 14-09-2015 18:46]

strandbal schreef op maandag 14 september 2015 @ 17:21:
[...]


Wet van Murphy he, je zal ook altijd zien dat van de 10x dat je 'm flasht, er eentje mis gaat, en dat is dan precies die ene die je remote gedaan hebt

[Voor 29% gewijzigd door Borromini op 17-09-2015 09:12]

Borromini schreef op donderdag 17 september 2015 @ 09:12:
Waarom zou het niet zo zijn? Proberen die handel

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

root@OpenWrt:~# opkg update
Downloading http://downloads.openwrt.org/chaos_calmer/15.05/ar71xx/generic/packages/base/Packages.gz.
Updated list of available packages in /var/opkg-lists/chaos_calmer_base.
Downloading http://downloads.openwrt.org/chaos_calmer/15.05/ar71xx/generic/packages/base/Packages.sig.
Signature check passed.
Downloading http://downloads.openwrt.org/chaos_calmer/15.05/ar71xx/generic/packages/luci/Packages.gz.
Updated list of available packages in /var/opkg-lists/chaos_calmer_luci.
Downloading http://downloads.openwrt.org/chaos_calmer/15.05/ar71xx/generic/packages/luci/Packages.sig.
Signature check passed.
Downloading http://downloads.openwrt.org/chaos_calmer/15.05/ar71xx/generic/packages/packages/Packages.gz.
Updated list of available packages in /var/opkg-lists/chaos_calmer_packages.
Downloading http://downloads.openwrt.org/chaos_calmer/15.05/ar71xx/generic/packages/packages/Packages.sig.
Signature check passed.
Downloading http://downloads.openwrt.org/chaos_calmer/15.05/ar71xx/generic/packages/routing/Packages.gz.
Updated list of available packages in /var/opkg-lists/chaos_calmer_routing.
Downloading http://downloads.openwrt.org/chaos_calmer/15.05/ar71xx/generic/packages/routing/Packages.sig.
Signature check passed.
Downloading http://downloads.openwrt.org/chaos_calmer/15.05/ar71xx/generic/packages/telephony/Packages.gz.
Updated list of available packages in /var/opkg-lists/chaos_calmer_telephony.
Downloading http://downloads.openwrt.org/chaos_calmer/15.05/ar71xx/generic/packages/telephony/Packages.sig.
Signature check passed.
Downloading http://downloads.openwrt.org/chaos_calmer/15.05/ar71xx/generic/packages/management/Packages.gz.
Updated list of available packages in /var/opkg-lists/chaos_calmer_management.
Downloading http://downloads.openwrt.org/chaos_calmer/15.05/ar71xx/generic/packages/management/Packages.sig.
Signature check passed.
root@OpenWrt:~# opkg install cups
Unknown package 'cups'.
Collected errors:
 * opkg_install_cmd: Cannot install package cups.

[Voor 3% gewijzigd door oohh op 17-09-2015 10:27]

Maurits van Baerle schreef op donderdag 17 september 2015 @ 11:00:
Kun je wel probleemloos andere packages installeren?

1
2
3
4

root@OpenWrt:~# opkg install luci
Upgrading luci on root from git-15.245.46763-b179283-1 to git-15.248.30277-3836b45-1...
Downloading http://downloads.openwrt.org/chaos_calmer/15.05/ar71xx/generic/packages/luci/luci_git-15.248.30277-3836b45-1_all.ipk.
Configuring luci.

Ik denk dat CUPS gewoon broken is, moet nog maar even wachten op een goede versie

OpenWrt release 14.07 got "oldpackages" feed which got packages from http://git.openwrt.org/?p=14.07/packages.git;a=summary
OpenWrt 15.05 uses "packages" feed which has packages from https://github.com/openwrt/packages/tree/for-15.05
As you may find, noone moved cups from http://git.openwrt.org/?p=packages.git;a=summary to the https://github.com/openwrt/packages , so it's not available anymore. If you need it, you have to find someone who cares about cups and who is ready to maintain its package.
Unfortunately cups didn't receive too much love in general, see the log:
http://git.openwrt.org/?p...istory;f=net/cups;hb=HEAD

Ga wel even kijken of ik die van Barrier Breaker werkt

[Voor 6% gewijzigd door oohh op 17-09-2015 20:06]

strandbal schreef op zondag 13 september 2015 @ 10:51:
Zo, net m'n Archer C5 geupgrade naar de 15.05 final (ik draaide een oude trunk versie). Via VPN die van m'n schoonouders ook geupgrade (ik weet het, spelen met vuur, remote firmware upgrades ) en ook deze kwam netjes weer up

/etc/init.d/uhttpd stop
/etc/init.d/uhttpd start

[Voor 22% gewijzigd door ThinkPad op 24-09-2015 09:13]

Enable and start user-installed packages

Finally, the newly installed packages should be enabled and started (if they need this; many do)

/etc/init.d/snmpd enable
/etc/init.d/snmpd start

[Voor 17% gewijzigd door Nonstop decay op 25-09-2015 16:24]

Nonstop decay schreef op vrijdag 25 september 2015 @ 17:18:
Ik heb net geüpdatet naar 15.05 en tot nu toe lijkt het helemaal goed te zijn gegaan!
Ik moest wel even m'n zelf toegevoegde packages opnieuw downloaden, maar dat ging heel makkelijk met de webinterface. Ik heb zelfs een vaag probleem met m'n draadloze netwerk op kunnen lossen na deze update. (M'n smartphone wou ineens niet meer verbinden, dus had ik voor mezelf een tweede WiFi-netwerk opgezet.)

Het duurde trouwens wel even tot ik erachter kwam dat je moet/kunt updaten met de "squashfs-sysupgrade.bin" file, in plaats van de "squashfs-factory.bin". Die informatie had best wat makkelijker te vinden mogen zijn. (Hoewel het redelijk voor zich spreekt, met zo'n naam.)

Koldur schreef op vrijdag 25 september 2015 @ 23:55:
[...]
Wat betreft updaten, maakt niet zoveel uit of je de factory of the sysupgrade gebruikt, enige verschil is als je van een bepaalde build naar een andere build gaat je echt de factory moet gebruiken. Is sowieso aan te raden te gebruiken om problemen te voorkomen en het verschil merk je niet want ook dan kan je gewoon je settings houden.

a factory image is one built for the bootloader flasher or stock software flasher
a sysupgrade image (previously named trx image) is designed to be flashed from within openwrt itself

Alleen is het erg onverstandig om je settings te behouden doordat er dingen veranderd kunnen zijn welke je huidige settings incompatible kunnen maken en je router overhoop kunnen helpen.

Makkelijkst om na een upgrade je settings terug te krijgen is een UCI script te maken met al je persoonlijke aanpassingen en je packages downloaden.

Compizfox schreef op zaterdag 26 september 2015 @ 00:26:
[...]

Dat is niet waar. Je moet altijd de sysupgrade-image gebruiken als je vanuit OpenWRT flasht. De factory-image is enkel en alleen voor de eerste keer flashen.


[...]

bron: http://wiki.openwrt.org/doc/faq/before.installation

[...]

Daar zie ik het nut niet echt van in, want exact die functionaliteit die je beschrijft, wordt gedaan door de "settings behouden"-feature.

Koldur schreef op zaterdag 26 september 2015 @ 07:53:
[...]
Dan snap je het helaas echt niet helemaal, de factory image heeft alles en kan je ook gebruiken als je wil upgraden met settings behouden.
Als je van de ene custom build naar de andere custom build gaat en gebruik je de upgrade versie, dan kan je dus een soft/hard brick krijgen in het slechtste geval, een factory image flashen heeft geen enkele extra risico's of nadelen behalve het feit dat de image iets groter is (wat met de huidige internetsnelheden geen probleem is lijkt me ).

En over het settings verhaal, misschien dat je OpenWRT niet helemaal goed kent, maar het verandert met de dag en daarin kan het zijn dat de opzet van bepaalde config files dergelijk veranderen dat deze met de nieuwe firmware incompatible zijn door bepaalde opmaak o.i.d.
Als je dan je settings behoudt kan het gebeuren dat je settings in het minst vervelende geval niet werken, maar kan je router in het ergste geval soft/hard bricken (hangt ervan af of je router een TFTP fail safe heeft of niet, bij TFTP fail safe heb je in principe nooit een hard brick).
Het gebeurt niet altijd dat config files incompatible zijn, maar als het wel gebeurt dan kan je dus echt met vervelende problemen zitten

Zo werkt het nu eenmaal bij OpenWRT en is het het slimst om dus gewoon voor de zekerheid de factory image en UCI script te gebruiken om ellende te voorkomen.

Compizfox schreef op zaterdag 26 september 2015 @ 13:32:
[...]

Dus de OpenWRT-wiki heeft het verkeerd? Hoe zou het flashen van een andere build überhaupt een brick moeten veroorzaken? Ik zie dat nog niet helemaal voor me.

[...]

Ik zie niet in hoe dat zou moeten gebeuren. Ik draai al jaren OpenWRT trunk en behoud altijd mijn settings. Er is nog nooit iets verkeerd gegaan.

Ik het ergste geval zal je oude configuratie een niet-werkende networking setup opleveren, waardoor de router na het flashen niet meer bereikbaar is via de webinterface of SSH. Maar dat is geen "hard brick", en dat valt simpel op te lossen met behulp van OpenWRT failsafe.

Hoe dan ook, dat was niet eens mijn punt. Mijn punt is het volgende:

OpenWRT behoudt bij het flashen überhaupt niet je oude settings. Dat is niet eens mogelijk aangezien de flashprocedure alles wist. In plaats daarvan maakt OpenWRT bij het "behouden van settings" achter de schermen een backup van je config files (in principe alle uCI-files, in /etc/config/) en zet die na het flashen weer terug. En dat is toch precies hetzelfde als wat jij aanraadt?

Koldur schreef op zaterdag 26 september 2015 @ 14:08:
[...]
Gelukkig heb je het probleem nog nooit gehad, maar ik zou er echt mee op passen.

Wat ik aanraad om te doen om je configuratie te behouden (het klopt inderdaad dat je met flashen dan zettingen behouden aan moet klikken, dit staat dan ook standaard uit omdat het kan zijn dat zettingen behouden dus problemen kan geven) niet de optie aanklikt om dat te doen, die behoud simpelweg de oude configuratie bestanden.
Het kan zijn dat er in de standaard opties die normaal gesproken zelf niet aanpast, wel aanpassingen aan gemaakt zijn en je deze dus ongedaan maakt door je oude configuratie bestanden te bewaren.

Een UCI script voegt simpelweg je custom regels toe na de installatie zonder de standaard configuratie rules aan te passen.

Als er echt een problematische verandering is, kan het zijn dat je niet kan inloggen in je router en je dus ook geen fail safe kan uitvoeren.

Dit verhaal gaat ook op voor custom huilde om dezelfde redenen.

[Voor 11% gewijzigd door Compizfox op 26-09-2015 14:51]

dv505 schreef op dinsdag 22 september 2015 @ 17:54:
Ik heb een probleem met SQM, na het volgen van de installatie hier: http://wiki.openwrt.org/doc/howto/sqm Alleen geen idee of ik iets verkeerds heb gedaan of dat het een bug is. Probleem is dat wifi naar lan verkeer ook geknepen wordt, en dus niet de maximale snelheid heeft.

Allereerst, ik gebruik de final van Chaos Calmer 15.05 op een TP-Link TL-WDR4300. Ik heb SQM geïnstalleerd en ingesteld op interface eth0.2 (eth0 is alles, eth0.1 is lan, eth0.2 is wan/wan6). De maximum download is 60000 kb/s en de upload is 3000 kb/s. Voor verkeer van/naar het internet werkt dit perfect. Beide wifi netwerken (2.4 GHz en 5 GHz) zijn toegewezen aan de lan interface.

Als ik echter een bestand van mijn laptop (op wifi) wil kopiëren naar mijn NAS (wired aan de router) dan wordt dit geknepen naar 3000 kb/s (de upload speed). Als ik als test de max upload of 0 (=onbeperkt) zet, dan wordt het kopiëren geknepen op 60000 kb/s (de download speed). Als ik SQM helemaal uit zet dan gaat het kopiëren weer op volle snelheid.

Ik zou graag willen dat SQM alleen van toepassing is op verkeer via de wan poort, en niet op lan/wifi verkeer. Is dit mogelijk? Zijn mijn instellingen verkeerd of is het een bug in SQM?

Compizfox schreef op zaterdag 26 september 2015 @ 14:23:
[...]

Waarom? Het klink als bangmakerij, want je hebt nog steeds geen concreet voorbeeld gegeven van een situatie waarin dat een brick oplevert.

[...]

Mij veel te veel werk. Al helemaal als je een non-standard setup gebruikt, wat ervoor zorgt dat je router met de default config onbruikbaar is in je normale netwerksetup . In zo'n geval levert het upgraden van de firmware zonder het behouden van settings allerlei problemen op in je netwerk (denk aan dubbele DHCP-servers, verkeerde VLAN-configs, dat soort dingen) en moet je de router uit je netwerk halen om de goede instellingen handmatig terug te zetten. Nee dankje.

[...]

Snap je wel hoe failsafe werkt? Je hoeft niet op je router te kunnen inloggen om een failsafe uit te voeren.

OpenWRT failsafe is een manier om de router te booten met de default config (zonder je overlay-FS gemount). Het maakt dan dus niet uit wat jij in je config plempt, je zult je router altijd kunnen booten met OpenWRT failsafe.

[...]

Wat bedoel je hiermee?

Koldur schreef op maandag 28 september 2015 @ 13:50:
[...]
Heb het zelf al meermaals meegemaakt, na settings behouden en teveel veranderingen in de trunk versie, kon ik niet in mijn router (ook niet met SSH) en fail safe werkte niet, met TFTP opgelost, maar vind het hele TFTP verhaal heel irritant, dus als het even niet hoeft liever niet. Was voorheen zelf te lui een UCI script te maken, maar nu ik die wel heb, maakt het het upgraden van OpenWRT zoveel meer aangenaam.

[...]
Te veel werk? UCI script maak je één keer met al je persoonlijke settings en die draai je elke keer na een flash en je settings zijn verwerkt. Als je je certificates mee wil nemen dan backup je die met bijvoorbeeld WinSCP.

[...]
Ik heb dus al een aantal keer de failsafe niet werkend gehad, maar al zou dit al werken is een failsafe nogal wat gedoe tegenover de nette manier van upgraden (met UCI een UCI script). Het is een algemeen bekend verhaal dat flashen naar verschillende OpenWRT versies het niet wordt aangeraden settings te behouden.

[...]
Omdat custom builds (mijn vorige post met telefoon gemaakt, wat slechte autocorrectie gehad zie ik ) af kunnen wijken met settings vergeleken met de stock builds en andere custom builds kan je met settings behouden problemen krijgen en een failsafe of misschien dus zelfs wel een TFTP oplossing nodig is.

Dat jij het niet gezien hebt dat failsafe niet werkt, betekent helaas (was het maar zo ) niet dat failsafe in alle gevallen gewoon werkt.

Compizfox schreef op maandag 28 september 2015 @ 14:56:
[...]

Vreemd, in zo'n geval zou failsafe altijd moeten werken. Het enige dat failsafe doet is het terugzetten van de default instellingen, dus logischerwijs betekent dat, dat als het probleem veroorzaakt is door het behouden van oude settings, dat altijd opgelost kan worden door failsafe.

Weet je zeker dat er niet iets anders aan de hand was waardoor failsafe niet werkte?

[...]

In dit geval is het niet het draaien van het script wat veel werk is, maar alles eromheen. Als je router een niet-standaard config draait, zorgt reverten naar default settings ervoor dat je router niet meer werkt in z'n normale netwerkomgeving. Interfaces staan dan verkeerd, VLANs van de switchpoorten worden incorrect geïnterpreteerd, DHCP-servers en IP-adressen staan niet goed... You get the point.

Dat betekent dus, dat je na elke upgrade de router moet isoleren uit het netwerk om met een kabel tussen de router een een laptop (oid) de goede config weer terug te zetten. En ja, dat is nogal veel werk.

[...]

Failsafe heeft bij mij anders altijd nog gewerkt. Ik blijf ook bij mijn punt dat failsafe in dit soort gevallen altijd zou moeten werken.

Hoe dan ook is er bij mij bij een upgrade nog nooit iets verkeerd gegaan. Het ergste wat ik heb meegemaakt is dat OpenWRT de laatste tijd nogal veel heeft geswitched van default router advertisement server: van radvd naar 6relayd naar odhcpd. Dat heeft er bij mij wel eens voor gezorgd dat ik dubbele, of juist geen, router advertisement servers had draaien na een upgrade. Maar dat was het dan ook wel qua problemen na een upgrade.

[...]

Custom builds hebben misschien andere configs, maar dat maakt toch toch niets uit? Integendeel juist, want die custom config vervang je juist als je jouw settings behoudt bij een upgrade.

Zolang de interpretatie van de uCI-files niet verandert (en als het goed is gebeurt dat niet) is er niets aan de hand.

Als de interpretatie van de uCI-files wél verandert, er komen bijvoorbeeld opties bij of oude optie raken deprecated, dan kan dit natuurlijk wel voor problemen zorgen bij een upgrade. Maar dat gebeurt hoogstens bij een upgrade naar een nieuwe versie van OpenWRT, en dit kan niet gebeuren als je van de ene build naar een andere build (van dezelfde versie) gaat.

Hoe dan ook zorgt dat er hoogstens voor dat de netwerkconfiguratie van je router niet werkend is en je je router niet meer kunt gebruiken. In dat geval kun je gewoon failsafe gebruiken om de default config terug te zetten.

[...]

Dat is wel een beetje het idee van een failsafe systeem... Hoe dan ook zou het niet mogelijk moeten zijn dat jouw custom config de werking van failsafe aantast. Zolang de router kan booten, zou failsafe ook moeten werken.

Als jouw aanpassingen aan de config worden op een aparte overlay-FS partitie opgeslagen. Er worden nooit aanpassingen gemaakt aan het originele (ROM)-filesystem. Door het systeem in 'failsafe mode' te booten, wordt dat overlay-FS simpelweg niet gemount en heeft de router dus geen last van jouw aanpassingen.

[Voor 12% gewijzigd door Koldur op 28-09-2015 19:54]

Ultraman schreef op maandag 28 september 2015 @ 18:51:
Voor de geïnteresseerden: so far so good. Barrier Breaker was voor mij niet beter dan Attitude Adjustment, vandaar dat daar geen enkele release uit is voortgekomen. CC lijkt stabieler te draaien... maar dat is gebaseerd op ervaring van 4 dagen

Koldur schreef op maandag 28 september 2015 @ 17:38:
[...]
Ja, weet dat zeker en weet dat het een zeldzaam probleem is. Toch kan het dus gebeuren.

[...]
Ik snap je punt hierin en is in principe persoonlijk, maar een router even los aansluiten aan een laptop/PC is niet veel werk, het failsafe/TFTP verhaal toepassen is dan veel meer werk en natuurlijk, als je dit bijna nooit nodig hebt gehad dan lijkt het meer werk.
Wel kan je met foutjes zitten die dan niet als groot naar boven komen, maar door oude config bestanden er wel inzitten en dan vrijwel onmogelijk te achterhalen zijn.

Mithrildor schreef op maandag 28 september 2015 @ 19:55:
[...]
Zit er in Chaos Calmer inmiddels een fix voor de WiFi problemen van de 1043ND? Eens in de zoveel tijd hoor ik een hoop geklaag omdat het WiFi er weer een paar minuten uit ligt (en dat was veel vaker voordat ik het WiFi elke nacht opnieuw opstartte). Ook als CC niet veel stabieler is zou een update mooi zijn (voelt toch altijd weer wat veiliger aan en ik ben te lui om zelf de boel te updaten, zeker omdat jouw builds out-of-the-box bijna perfect draaien).

[Voor 24% gewijzigd door Compizfox op 28-09-2015 20:43]

Compizfox schreef op maandag 28 september 2015 @ 20:34:
"De WiFi-problemen" is nogal een vage omschrijving Er is een heeele tijd geleden eens een probleem geweest met WiFi op de TL-WR1043ND, het zogenaamde "ath: Failed to stop TX DMA"-probleem. Dat is al jaren opgelost.

Of doel je op iets anders? Ik heb op mijn router nergens last van in elk geval.

Compizfox schreef op maandag 28 september 2015 @ 20:34:
[...]

Ja, maar hoe dan?

No offense, maar een anecdote dat het jou eens gebeurd is, is niet van zo heel veel waarde. Het zou best kunnen dat het veroorzaakt wordt door een ander probleem (ongerelateerd aan het behouden van settings).

Ik zeg niet dat het failsafe-systeem feilloos is, er kunnen zeker dingen zo stuk zijn dat failsafe niet meer werkt. Dat zijn ook dingen die kunnen gebeuren door problemen met het flashen. Voorbeeldje: je flasht een corrupte image (je hebt de checksum niet gechecked) en je router boot niet meer. In dat geval gaat failsafe je niet meer redden.

Maar wat ik wel probeer te zeggen is dat een fout in je config (in je uCI-files dus) simpelweg niet als gevolg kan hebben dat OpenWRT niet boot. Zo zit het systeem simpelweg niet in elkaar. Als jij een werkende OpenWRT-installatie in / (je ROM) hebt staan, dan kun je ook failsafe booten, wat er ook voor crap op /overlay (het overlay-FS) staat. Kun je dat niet, dan moet er gewoon iets anders aan de hand zijn.

Vergelijk het bijvoorbeeld met het volgende statement: Door een fout in mijn Windows-installatie kan ik niet meer in mijn BIOS komen.
Dat is een beetje vergelijkbaar met wat je probeert te zeggen. Ook dit is gewoon niet mogelijk, omdat het wel of niet in je BIOS kunnen geraken niets te maken heeft met wat er op je HDD staat. Om niet meer in de BIOS te kunnen komen, moeten er grotere, meer low-level problemen spelen.

[...]

Tja, ik heb inderdaad dat standpunt omdat er bij mij nog nooit iets mis is gegaan. Sterker nog: er kunnen alleen maar dingen misgaan als er aangrijpende, non-backwards-compatible dingen in het uCI-systeem veranderd worden. Dat komt gelukkig niet zo vaak voor, en als het al voorkomt, zullen de OpenWRT-devs je daarvoor wel waarschuwen lijkt me.

Tja, niet echt een anecdote hoor, dezelfde FW file daarna geflashed via TFTP en toen werkte de router gewoon weer.
Heb het ook vaker gelezen op het OpenWRT forum, maar dat zijn dan weer wel anecdotes aangezien ik dat niet heb kunnen verifiëren.

Koldur schreef op maandag 28 september 2015 @ 23:39:
[...]
Jouw BIOS vergelijking gaat dan ook totaal niet op, is niet met elkaar te vergelijken.

OpenWRT is wat dat betreft een beetje als Android, een schone install is altijd beter dan een dirty flash, alleen is het daarbij lastiger een mooi scriptje te maken om instellingen en apps terug te zetten dan bij OpenWRT.

[Voor 22% gewijzigd door Compizfox op 28-09-2015 23:54]

Koldur schreef op maandag 28 september 2015 @ 19:53:
Ja, het kan allemaal netjes gebeuren, maar dat is verreweg van gegarandeerd.

Ik heb het dus ook vaak gedaan, maar nu ik het zo doe als aangeraden merk ik dat het sneller gaat, maar ik draai dan ook niet mijn eigen builds, maar die van Arokh en heb wel een hoop aanpassingen daarop.

Alleen zo lang op de oude AA zitten is niet zo heel slim geweest met alle security breaches

laatste tijd zijn deze gelukkig allemaal gepatched, maar daarvoor moest je dan ook trunk versies installeren

[Voor 43% gewijzigd door Ultraman op 29-09-2015 17:15]

Ultraman schreef op dinsdag 29 september 2015 @ 17:10:
[...]
Ik garandeer ook niks.
Het laten resetten van de configuratie en daarna weer herstellen met een UCI changes script is een prima manier. Dat heb ik ook wel eens met build configs gedaan nadat ik een keer mijn builddir helemaal gereset had. Config behouden, indien mogelijk, is voor veel gebruikers echter vele malen makkelijker.

[...]
Voor mij is dit ook de snelste weg

[...]
Kun je er één of een paar noemen waar ik vatbaar voor ben geweest?

[...]
Belangrijke patches worden doorgaans gebackport naar de stable branches, dit gebeurt bijvoorbeeld met OpenSSL.

[Voor 5% gewijzigd door Koldur op 29-09-2015 17:23]

Koldur schreef op dinsdag 29 september 2015 @ 17:21:
Waarschijnlijk dom van mij, maar was niet op de hoogte van het feit dat de belangrijke patches gebackport werden naar de stable branches, wel goed om te weten! Ik doelde daarbij inderdaad op de SSL problemen.

Ik ga er altijd vanuit dat dergelijke patches in de trunk worden opgenomen en dus niet gebackport werden. Weet jij hoe dit gedaan wordt? Worden de oude builds meteen verwijderd en geupdate met de patches?

gekkie schreef op zondag 04 oktober 2015 @ 14:51:
Lang leve het gedoe met regulatory domains.
Wat heb je ingesteld staan als country code ?

Als je wifi chips werken met ath9k driver, zou je een reghack kunnen toepassen waardoor op US en het world domain alle kanalen beschikbaar komen.

[Voor 15% gewijzigd door Rubén89 op 04-10-2015 15:37]

Rubén89 schreef op zondag 04 oktober 2015 @ 15:34:
[...]
Ik heb - uiteraard - NL geprobeerd, daarrnaast heb ik US geprobeerrd Russia en hij staat nu op DE, maar is dit wel een probleem met regulatory domains. Ik bedoel met m'n Netgear R7000 (zowel Stock firmware als DD-WRT waren ook hogere kanalen gewoon beschikbaar.

Het lijkt wel of de WRT1900AC-V2 met OpenWRT al kanalen met DFS gewoon blokkeert....

Hier overigens een thread over een OpenWRT gebruiker met een TL-WDR4300 met hetzelfde issue:
https://forum.openwrt.org/viewtopic.php?id=51395

[Voor 4% gewijzigd door gekkie op 04-10-2015 15:45]

[Voor 20% gewijzigd door Rubén89 op 04-10-2015 21:10]

Rubén89 schreef op zondag 04 oktober 2015 @ 13:24:
Goedemorgen middag mede-tweakers,

Ik heb eerder deze week een WRT1900AC-V2 aangeschaft deze heb ik gistermiddag in ontvangst mogen nemen.

[Voor 21% gewijzigd door Compizfox op 06-10-2015 16:31]

[Voor 21% gewijzigd door fjskmdl2 op 06-10-2015 16:46]

[Voor 3% gewijzigd door Mithrildor op 15-10-2015 16:14]

Rubén89 schreef op maandag 05 oktober 2015 @ 16:54:
[...]


Ik ga er nog eens in duiken het vreemde Is dat volgens Wikipedia Russia geen gebruik maakt van DFS/TPC maar dat ondanks dat OpenWRT ook wanneer ik ik her Regulatory-Domain instell op Russia DFS-channels niet werken.

Op het OpenWRT forum heeft vanmiddag iemand melding gemaakt van hetzelfde probleem:
https://forum.openwrt.org/search.php?action=show_user_posts&user_id=144580

Misschien is het wel gewoon een bug in OpenWRT, wordt vervolgd....

[Voor 0% gewijzigd door sl1000 op 15-10-2015 16:18. Reden: Spelling]

sl1000 schreef op donderdag 15 oktober 2015 @ 16:17:
[...]


als je "China" als domein in stelt, werkt het wel, en kun je wel op de hogere frequenties werken.
Dit is een bug in (closed source) wifi driver.

verder loop ik zelf nog tegen een aantal stabiliteits en performance issues aan met deze driver. Helaas is er al twee maanden geen update meer geweest door Marvell

[Voor 9% gewijzigd door Rubén89 op 15-10-2015 20:08]

Mithrildor schreef op donderdag 15 oktober 2015 @ 16:07:
De wiki heeft een hoop informatie maar ik heb nog een paar vraagjes. Als ik het goed begrijp moet gewoon de build van CC voor de 1043ND van de website van OpenWRT plukken. Wat is dan handiger? Eerst mijn router terug naar de originele firmware zetten en dan een verse installatie van OpenWRT er op zetten of gewoon upgraden en de configuratie zelf niet bewaren?

Wat moet ik nog zelf doen nadat ik de firmware heb geïnstalleerd? Ik neem aan dat de default firewall configuratie voldoende is. Dus dan moet ik alleen nog maar even het WiFi aanzetten en zorgen dat de router niet van buitenaf toegankelijk is via ssh (of zit die poort al achter de firewall), toch? Als het goed is, is dat mogelijk via LuCI, dus dat zou geen problemen moeten opleveren.

Rubén89 schreef op donderdag 15 oktober 2015 @ 19:17:
[...]


Dat van China als domain instellen daar was ik al achter heb het ook al gemeld bij als issue bij de repo op Github:
https://github.com/kaloz/mwlwifi/issues/37

Overigens hoeft het geen bug te zijn hoor, ik geloof dat in China een aantal hogere channels (149 t/m 165) gebruikt kunnen worden zonder DFS. Het zou dus alsnog kunnen dat de WRT1900AC geen DFS ondersteunt en dat Luci / OpenWRT de de bechikbare channels in de WebIF niet goed weergeeft.

Die WIFI driver van Marvell is toch open-source? Het hele probleem waarom er lange tijd geen OpenWRT voor de WRT1900AC(V1) was was toch het feit dat Marvell haar drivers niet wilde opensourcen???:

This software file (the "File") is distributed by Marvell International
* Ltd. under the terms of the GNU General Public License Version 2, June 1991
* (the "License"). You may use, redistribute and/or modify this File in
* accordance with the terms and conditions of the License, a copy of which
* is available by writing to the Free Software Foundation, Inc.

Ook ik ervaar structureel prestatieproblemen, de snelheid is absoluut niet wat het was met de Netgear R7000, soms is het zelfs belabberd. Wel vind ik het enorm tof dat ik nu kan kiezen tussen stock-firmware DD-WRT OpenWRT

Welke versie van de WRT1900AC bezit u eigenlijk?

The FCC documentation (pictures of the WRT1900AC-V2) revealed that at least that WRT1900AC-V2 was using a Marvell "88F6820-A0 C160" CPU, mind you, that's the 1.6Ghz variant.
(FCC documents regarding WRT1900ACV2 can be found here: https://fcc.io/Q87/-WRT1900ACV2 )

The FCC-ID of the WRT1900AC-V2 is: "Q87-WRT1900ACV2" and the FCC ID of the WRT1900ACS is also " Q87-WRT1900ACV2".

The WRT1900ACS was never certified as a different model / hardware-version but as the WRT1900ACV2.
So both routers must be identical, otherwise they would have to get the new hardware certified and it would have gotten a different FCC-ID.

[Voor 10% gewijzigd door rens-br op 21-10-2015 11:49]

Dennis schreef op woensdag 21 oktober 2015 @ 11:41:
Wat wil je precies?

Als je een netwerkkabel tussen de twee routers hebt, dan moet je juist beide VLAN's als TAGGED instellen op de betreffende netwerkpoorten. Dat is eigenlijk het enige, het zou dan moeten werken.