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.

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:

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.

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.