OpenWRT

Fixat i main/master nu: https://github.com/openwrt/openwrt/commit/5501a502e499e0202bd...

Tycks ha varit Felix som patchat kärnan i jakt på prestanda och glömt UDP, vilket då gjort att paket kunnat ta sig förbi brandväggen. Som vanligt när det gäller honom verkar koden inte ha granskats publikt. Rätt illa och det verkar inte vara utrett exakt vilka konsekvenser det fått.

Fixen tycks vara mer patchning, inte att använda upstream Linux och förlora prestanda. Får väl se om detta resulterar i en CVE. Jag är i alla fall måttligt imponerad och tänker definitivt inte använda 24.10.0 eller 24.10.1.

Då var kvällen kommen när flash skulle ske. Får massa fel när jag ska "begär bygge", typ

Error: Impossible package selection
STDERR
STDOUT

Försöker installera luci via ssh men inte helt lätt det heller.

-sh: apk: not found
-sh: opkg: not found

Vi ser om jag hinner grotta här mer eller fortsätter imorgon

Edit: Ok, verkar som att jag ska in med factory.bin först av allt, sedan funkar såklart ssh kommandona

Edit2: Fick igång OpenWRT rätt snabbt, men ganska så brant inlärningskurva. Sätta upp SSID-Guest etc var inte helt enkelt (missade att öppna portar för DCHP/dns)

partition@0 {
              label = "u-boot";
              reg = <0x0 0x30000>;
              read-only;
};

partition@0 {
              label = "u-boot";
              reg = <0x0 0x30000>;
              read-write;
};

Flashade imagen från ovanstående operation, funkade utmärkt att i sin tur flasha Breed från den. Ett par noteringar:

- Dokumentationen i OpenWRT-wikin är inte up to date. I aktuella versioner av OpenWRT heter kommandot för att hantera mtd-partitioner rätt och slätt mtd. Det använder dessutom partitionernas faktiska namn snarare än löpnummer (om de inte hade löpnumren som namn tidigare dvs). Körde med andra ord:

mtd unlock u-boot
mtd erase u-boot
mtd -r write breed-mt7620-reset1.bin u-boot

...istället för det som föreslogs på den länkade sidan. Oklart om det hade gått att låsa upp från en officiell image också, problemet kan ha varit att jag pekade på mtd0 enligt dokumentationen när jag försökte, som ju inte finns.

- Build system-dokumentationen föreslår att bygga med "make -j1 defconfig download clean world". Varför -j1? Enda gången jag kan se någon nytta i det är väl om man vill köra kompileringen i "bakgrunden" utan att den käkar upp all tillgänglig cputid typ. Kanske trevligt om man vill göra annat på datorn samtidigt. Personligen skippade jag det för att spara tid, och det funkade utmärkt ändå. Undrar dock om det är något jag missar?

Parallella byggen ger sämre felmeddelanden vill jag minnas. Andra versioner av bygginstruktionerna har sagt att man ska köra med antalet trådar och om det går fel byta till 1 tråd. Det har väl kanske genererat för mycket frågor på forumet eller något.

Ah, ja, är det på det viset är det ju fullt rimligt att ha med -j1 i de officiella instruktionerna. Den där sortens ständigt återkommande frågor kan bli rätt störiga i längden...

----

Projektet är avslutat med lyckat resultat i övrigt

Byggde en image för Nexx WT3020 med 128MBit EEPROM över natten. Några smärre mods av källkoden för att definiera den nya EEPROM-storleken krävdes. Infon på wikisidan för WT3020 var väl inte helt up to date, men var lätt att bena ut hur man skulle gå tillväga trots förändringarna.

Lödde loss och dumpade originalchipet, en 64Mbit EEPROM ur 25-serien. Skrev dumpen till första halvan av en 128Mbits motsvarighet. Lödde i det i routern, bootade upp, och flashade 16M sysupgrade-imagen som vilken sysupgrade som helst bortsett från undantaget att jag förstås fick bocka i Force flash i och med att modellinfon av naturliga skäl inte stämde överens.

Up & running:

På tal om WT3020, har du också haft problem med att den återställer sig till default någon gång ibland, med ganska långa mellanrum? Har hänt mig 2 eller 3 gånger. Använder den bara då och då så har inte lyckats lista ut något eventuellt mönster.

Nä, det har aldrig hänt mig. Å andra sidan använder jag den inte jätteofta heller längre, så kan ju vara en fråga om det att det helt enkelt inte hunnit hända i mitt fall.

Kör du OpenWRT på din också?

Lite spekulation kring de spontana resetsen förresten. Orkar inte pilla upp WT3020:an igen och eventuellt råka slakta de clips som överlevde gårdagens öppning - ett av dem gick sönder - så har inte mätt mig till något, men kan ge mig på att resetknappen är direktkopplad till nån gpio på SOCen, som mycket sannolikt är någon högimpedansvariant. Noterade även att det inte finns något som helst EMI-skydd.

Antingen kan ingången vara konfigurerad active low med intern pullup över en större resistans, säg > 10 kOhm i alla fall, eller så är den konfigurerad som active high. I det första fallet drar brytaren den från början höga ingången låg genom att jorda den vid påverkan. I det andra fallet dras den från början låga ingången hög genom att brytaren kopplar den till en spänningskälla vid påverkan.

I det första fallet kan resetknappen ha ganska stort övergångsmotstånd och ändå dra ingången låg. Man kan betrakta det som en spänningsdelare med den interna pullupresistansen som Z1 och brytaren som Z2, med ingången i mittnoden. Skulle knappens övergångsresistans exempelvis vara densamma som den interna pullupresistansen, så halveras spänningen i mittnoden. Det är inte helt orimligt att tro att ingången skulle kunna dras låg om det någon gång kommit något som inte ska vara i brytaren, och det råkar vara lite fuktigt i luften, tillräckligt för att ev gegga ska börja leda. Avstånden i en såndär brytare är små.

Är ingången active high kan avsaknaden av EMI-skydd ställa till det. Ledarna på kretskortet kommer agera antenn, och har man otur räcker den inducerade spänningen från någon källa i närheten för att dra ingången hög. Det är väl dock lite av en hypotetisk möjlighet, man brukar köra active low om det inte finns särskilda skäl att inte göra det. En vanlig knappbrytare medför inga sådana.

Möjligheten att det blivit något fel på flashminnet kan man nog förkasta. Det hade märkts på andra sätt också, det vore ju en jäkla slump om det skulle ha tappat datan i just den region som håller konfigurationen, men inget annat.

Ja, kör OpenWrt på den. Kan nog vara som du säger i ditt andra inlägg.

Det händer tillräckligt sällan för att jag inte tyckt att det är värt att gräva mer i.

Nu är väl mitt underlag kanske inte det bästa, mest bara surfat runt lite som test efter modifikation och installation av 24.10.1, men jo, det är rätt slött. Bredbandskollen ger bara 6.5Mb/s ner och 15.7Mb/s upp. Får liknande hastigheter vid lokala transfers av komprimerade filer till och från filservern. (Tillägg: kopplade upp den mot lokala nätverket via WAN-porten, så är väl NATat mot filservern i vad mån det påverkar prestandan).

Latencyn är inget uppseendeväckande, att surfa runt känns rappt och sådär. Någon millisekund eller två i ping mot lokala maskiner över wifi.

Vad har du för siffror på din router med 19.07? Hoppas fan inte det här slutar i att jag nedgraderar och att 16MB-modifikationen i praktiken blir meningslös

Ett enkelt test kunde ju vara att plocka bort resetknappen och se om det upphör att ske. Behöver du reseta kan du bygla lödöarna med ett gem eller nåt

Det är inte värt att modifiera den.

Herregud att sätta upp VLAN - sammanhanget mellan bridge devices, interfaces, devices, firewall zones... blir fort rörigt både i UI och skallen. Igår kväll kände jag mig trögare än på länge och mycket hjälp är från äldre versioner av OpenWrt

Så här har jag förstått proceduren nu men är något jag missat då jag inte kunde få kontakt på portarna jag knöt till min vlan bridge device. Mitt mål är att alla fysiska portar på router ska vara på VLAN10, sedan tillkommer VLAN 20 (main wifi), VLAN 30 (IOT), osv över trådlöst.

1. Devices > Default br.lan > ta bort lan 1, lan 2, lan 3 från bridge ports. (låter dock lan1 vara kvar som conf-port och tar över den när jag kommer åt luci från lan 2 på vlan från min pc tänker jag)
2. Skapa ny bridge device "vlans", binda lan 1, lan 2, lan 3, eth0, wan. Dessa två senare funderar jag över då dom ej är valda i min def. br.lan men alla verkar ta med.
3. Fortfarande på min nya bridge device, under bridge vlan filtering > add vlan (id 10, 20, 30) och tagga/untagga, gör local, primary vlan osv (nu börjar det göra ont i huvudet). Detta skapar software vlan 10, 20, 30...
4. Save/apply någonstans här för att komma vidare, gå till interfaces, knyta till standard br.lan och fortsätta med att confa dessa vlan med ip, dhcp osv.

En del menar på att man behöver ett vlan1 för att få det att fungera, en del menar på att man ska ha ett extra otaggad, obundet vlan som ett "black hole vlan" var ej taggad trafik hamnar... fungerar bättre och säkrare.

Tillsv vill jag bara ha 2 portar på routern som jag kan skriva in mina statiska IP på enheterna som ansluter dit och få kontakt. Säkerhet och bra filtering, routing, regler kan jag bry mig om senare och testa en ändring i taget... så är det bäst att köra allt otaggat först?

v1 har OpenWrt-stöd, men inte v2, än i alla fall. Så det gäller att veta vad man köper. Att utnyttja ångerrätt för en misslyckad OpenWrt-installation är ju inte en fantastisk ide.

Prisvärd trådad AP skulle jag säga, inte så sexig mesh-nod eftersom den bara har en 5GHz+-radio. Men det beror på användningsfall.

Jag har klurat på en bra ntp-server hemma, och den där har stöd för PTP-stämpling i hårdvara (gissningsvis på 2,5Gbps-porten) och kostar typ femhundra spänn. Och RISCV vilket är intressant pga anledningar.

Spännande här idag när jag skulle ändra lite. Är 99% säker på att jag inte rörde LAN-porten jag var ansluten till men något var säkert fel vid save/apply - fick inte tillbaka länk och inte heller revert-meddelandet som brukar komma när den märker att länk är bort kom. Alla portar verkade stendöda förutom i recovery mode. - återfick aldrig länk med routern efter flash av firmware igen som jag varit tvungen att göra några gånger tidigare.

Fick till slut in standardfirmware med ubi cleaner som @Pulver nämnde i ett av hans inlägg.

Nytt försök med OpenWRT senare.

Vad är det som är svårt med OpenWrt? Tycker gränssnitt är ganska enkelt och normalt får man fungerande standardinställningar redan från början, med undantag för WiFi som man måste aktivera och konfigurera upp själv.

DD-WRT förknippar jag personligen med Broadcom-baserade routrar med Linux-kärna från stendåldern (på grund av Broadcom). Misstänker att situationen är betydligt bättre med enheterna byggda på plattformar från andra tillverkare som faktiskt släpper fungerande källkod, men det är inget jag någonsin undersökt närmare då OpenWrt fungerat väldigt bra på prylar jag behövt det.

Att gå utöver standardinställningarna kräver ju dock en del kunskap, alternativt att man är tillräckligt bra på att följa skriftliga instruktioner. Ett exempel är ”dumb AP”, det är inte direkt ett enda musklick, vilket det borde kunna vara (jo jag förstår utmaningarna med det). AP med separata VLAN är förstås ännu roligare. Enkla inställningar för den här typen av grejer är förstås mycket enklare att utveckla på proprietära mesh-system som inte behöver stödja 1700 produkter och inte behöver kunna underhållas över tid. Samma sak (och annat) har hittills satt stopp för helautomatiska uppdateringar, vilket en noob-vänlig lösning förstås ska ha.

DD-WRT verkar officiellt ha övergett Broadcom för nyutveckling och verkar vara på väg mot kernel 6.1 med fokus på Qualcomm och deras SDK. Jag skulle inte sätta pengar på att Flint 2 får kärlek snabbt eftersom den är Mediatek, Flint 3 däremot kommer vara Qualcomm. Men vem vet.

Jag har svårt att tycka att DD-WRT är en bra ide eftersom Brainslayer tycks vara ”single point of failure”. Han verkar i och för sig vara grymt kompetent. Oklart om de kanske kan få fler utvecklare nu när de slipper Broadcoms NDA.

Ja, det väl i och för sig sant att mer specialiserade konfigurationer kan vara lite knöligare. Jag har sällan använt OpenWrt vid sådana tillfällen, även om jag skulle räkna med att det fungera stabilt. Att använda det som en AP är ju dock rätt så enkelt om man förstår principen. Undvik att använda WAN-porten (eftersom du i det fallet inte vill NAT:a trafik) och stäng av DHCP. Det är egentligen allt som behövs.

Jag föredar att inte ha automatiska uppdateringar då jag föredrar att läsa på om vilka förändringar som kommer ske, samt styra när de sker. Jag förstår att många helst vill slippa tänka på det dock.

Ja, Brainslayer gör nog det mesta på DD-WRT. Trodde att det kanske fanns en del annat folk också, men har inte hållt koll på projektet eftersom jag inte använder det. Låter dock bra att de fokuserar mer på att stödja plattformar där tillverkarna faktiskt gör det mer gångbart att underhålla enheterna.

Mediatek har ganska bra stöd i OpenWrt, och de släpper ju till skillnad från Broadcom källkod som inte kräver en urgammal Linux-kärna. Det kanske inte är en plattform DD-WRT fokuserar så mycket på dock, särskilt om det mesta görs av en person. Fullt förståeligt.