Vet ikke om det er noen interesse for å fikle med alternativ software (LEDE/OPenWrt) for "Wifi+" her? Jeg begynte så smått, men må bare innse at jeg ikke har tid til den slags. Det har heller ikke noe særlig potensiale for å virke med 5Ghz-modulen fra Quantenna. Denne kjører sin egen Linux-installasjon på og booter via tftp fra hoved-CPUen. Kunne jo være et kult ekstra-prosjekt å kjøre opp OpenWrt på den også, men jeg innbiller meg at du i så fall sliter ganske mye med drivere...

Men bortsett fra 5Ghz så er det meste ganske rett frem. Wifi+ er jo egentlig en ZyXEL WAP6805, som riktignok ikke ser ut til eksistere noe annet sted i verden. Men innmaten er så og si den samme som ZyXEL WAP6806, så det er mulig å bruke WikiDevi siden der som referanse angående innmat: https://wikidevi.com/wiki/ZyXEL_WAP6806_(Armor_X1)

Hardwaren er altså basert på en Mediatek MT7621 med en 5GHz modul basert på Quantenna QT3840 (QV840). MT7621 har jo blitt veldig godt støttet i OpenWrt i det siste, så det gjør denne dingsen absolutt interessant. Ihvertfall hvis du ikke bryr deg så mye om det trådløse. Det er mer enn nok minne (64MB), flash (128MB - ja, jeg ser det står 16MB på den wikidevi-siden. det tror jeg muligens er feil. Det er NAND flash) og CPUer (ja, dual core) her til kreative prosjekter.

ZyXEL vil også gi deg en relativt brukbar GPL-pakke med det aller meste av kildekode, så lenge du kan oppgi et gyldig serienummer som matcher det du spør etter. Inkludert en toolchain som faktisk virker så lenge du tilpasser miljøet til fortiden den stammer fra. Dette er basert på Mediatek sitt SDK for MT7621. Jeg har bygd image vha denne koden og det virket helt helt tilsvarende den originale firmwaren det var oppgitt å skulle matche. De imkluderte faktisk også en tilsvarende pakke for Quantenna-modulen. Denne har jeg ikke sett så nøye på, men den inneholder nok større mengder binære bober.

Det er relativt lett å åpne boksen uten å ødelegge noe. De har ikke engang satt på noen klistremerker som plombering. Du fjerner bare dekselet over skruefestet for veggmontering, løsner de to skruene bak dette, lirker av den buede plastbiten på den ene enden (noe klips), og så kan du bare forsiktig hekte de to delene av kabinettet fra hverandre. Det er plastklips langs kantene, men de er ganske snille og du kan til og med se innsiden etter å ha tatt av det første buede dekselet så det er lett å løsne dem.

På innsiden finner du to serieport (TTL) headere som ZyXEL har vært greie nok til å lodde på for deg. Begge to har "standard" ZyXEL/Mitrastar pinout:

1 - NC (VDD)
2 - TX
3 - RX
4 - NC (no pin)
5 - VCC

Bruk gjerne dette bildet som referanse: https://openwrt.org/_media/media/zyx...02n_serial.jpg

Ikke samme router/ap, men samme produsent og eksakt samme pinout.

Den ene serieporten (merket RRJ1) er koblet til konsollet på 5GHz-modulen! Så du kan faktisk se den boote. Det er jo underholdende, men ikke så veldig nyttig før du evt har noe annet å boote på den. Denne porten er satt opp med 115200 8N1.

Den andre porten (merket J1) er koblet til konsoll for MT7621. Den er satt opp som 57600 8N1

Vel, hvis du har lest så langt så brenner du sikkert etter å få vite at du slett ikke trenger å åpne kabinettet. Wifi+ kjører dropbear (ssh server) per default, lyttende på default port (22). Brukernavn er 'root' og passord er 'Wi9cXkg5Hse2K'. Ihvertfall var begge boksene jeg har konfigurert med dette. Ingen av dem har noensinne vært tilkoblet Altibox-nettet, så jeg tar forbehold om at de kan finne på å endre dette ved første gangs oppkobling. Kunne vært interessant å høre andres erfaringer her..

Hvis du ikke lar den få adresse fra en DHCP-server, så ser den ut til å bare plukke en LL-adresse (dvs fra 169.254.0.0/24). Det er altså enklest å finne adressen om du har en DHCP-server.


Men om du vil fikle, så er det gode grunner til å ha konsoll. ZyXEL/Mitrastar har som vanlig linket inn sin egen "Z-LOADER" modul i bootloaderen, men i utgangspunktet er det bare u-boot. Og du kan faktisk switche til en litt hemmet u-boot-utgave vha ATGU i Z-LOADER, helt uten noen passord-triks eller noe slikt! Dessverre har de herket det litt til så du får ikke noe prompt. Den booter bare direkte videre til default etter en kort timeout (ca 1 sekund elns). Men i dette sekundet kan du velge mellom en del andre interessant alternativer (blindt - det kommer ingen meny, men du får tilbakemelding om valget den har oppfattet). De to definitivt mest interessante er:
Dessverre fikk jeg aldri den første til å virke. Den laster et image helt fint via tftp, men henger alltid når den skal boote. Den oppfører seg slik med ZyXELs firmware også, og den oppfører seg faktisk slik etter flash også. Skulle da ha bootet det nye image, men henger i stedet. Så jeg har konkludert med at de har tullet til noe i u-boot. Dette er jo neppe noen funksjon de har lagt krefter i å teste. Helst ville de vle fjernet den helt :-)

Men flashing virker ihvertfall fint, bortsett fra lille quirken at du må ta strømmen etter på for å reboote.

Merk dog at flashing via dette grensesnittet skriver over den installerte firmwaren. Boksen er satt opp med to separate partisjoner for firmware, og ved normal oppgradering vil den veksle frem og tilbake mellom dem slik at du alltid skriver til en annen partisjon enn den de booter fra. Men bootloaderen skriver alltid til den første partisjonen. Og her kan du komme opp i en interessant bivirkning av hvordan de har implementert dette: De bruker en teller i image-headeren på de to partisjonene. Imaget med den høyeste verdien blir bootet. Imaget med den laveste verdien blir erstattet ved flashing. Og det nye imaget blir skrevet med en teller som er 1 høyere enn den forrige høyeste verdien. Men bootlloaderen skriver altså uansett bare til den første partisjonen, og den oppdaterer heller ikke telleren. Dvs at dersom du har et gydlig image på partisjon nummer 2 så får du i utgangspunktet ikke erstattet det vha denne metoden. Det vil alltid bli foretrukket. Det ser heller ikke ut til at de har lagt inn noen failsafe der de booter fra det andre imaget dersom det foretrukne feiler et gitt antall ganger. Dette ser jeg på som en graverende bug. Det betyr jo at du har en murstein dersom du har et ikke-fungerende image med en gyldig heder...

Heldigvis går det an å lure systemet: Når du flasher via bootloaderen så skriver den eksakt det image du gir den via tftp, inkludert headeren der denne boot-telleren er. Alt du trenger å gjøre er altså å endre headeren slik at telleren har en høy nok verdi til å "vinne".

Apropos headeren: De kjører altså u-boot, og headeren er som forventet "uimage". Men ikke helt. De har vært så "smarte" at de har lagt til en del, bla den nevnte telleren, slik at headeren har vokst fra default 64 byte til 224 byte! Ingenting av dette ser ut til å spille noen trille, bortsett fra nevnte teller, heller ikke modell-nummeret som er inkludert (0x8008). Jeg brukte feil nummer en stund uten å legge merk til det, og den bootet like fint for det. Den booter også helt fint et image for WAP6806 (som har ID 0x800a). Men det idiotiske er jo at de ikke bare har lagt til noen data, men utvidet headeren sett fra u-boot og systemet sin side. Dvs at header-sjekksummen kalkuleres over alle 224 bytes, og u-boot forventer å finne imaget som skal bootes etter 224 bytes. Det betyr at du må modifisere eksisterende verktøy for å generere headeren. Dette er slik den ser ut i original firmware:

Alt fom 0x40 er altså ekstra. Som du ser så er det stort sett meningsløst. Definisjonen av headeren (fra ZyXELs GPL-pakke) er slik:

tih_sequence er den magiske telleren du trenger å endre dersom du ønsker å tvinge et image som flashes via bootloader til å foretrukket. Merk at sjekksummen uansett alltid beregnes med dette feltet nullet ut! Sjekksummen blir aldri endret ved flashing, og bootloaderen nuller feltet før den verifiserer.

Jeg disablet USB siden jeg ikke kan se noen måte å bruke det uten en USB-port (men det virker ellers per default i OpenWrt). Og så har jeg slått sammen de to firmware-partisjonene til en stor (64MB) "firmware". Enklest slik, men selvsagt inkompatilbelt med original firmware. De andre partisjonen er som originalt.

Merk at MRD-partisjonen inneholder serienummer osv, og at Factory inneholder "eeprom" for både wifi og ethernet med bla mac-adresser (som du også ser referert ovenfor - dette virker med driverene i OpenWrt/Linux v4.14+). Du vil nok prøve å unngå å overskrive disse partisjonene... Jeg anbefaler en backup. Du kan åpenbart ikke gjenopprette disse fra noen andres image. Jeg tror også at det gjør livet enklere å la Booloader være i fred. Det går helt fint å leve med de quirkene den har, og da er det lett-plett å flashe tilbake til original firmware. Hvis du har da... Jeg har, så gi meg et hint om noen trenger. Det gjelder forsåvidt også et OpenWrt image. Men det ser jeg som mindre nyttig å distribuere. Det eneste poenget med å boote denne med OpenWrt per nå er å utvikle og fikse det gjenværende, og da bygger du jo uansett ditt eget.

Basert på den DTSen så virker knapper (reset og wps), ethernet inkludert switch, minne, flash, to cpu-kjerner, konsoll og wifi (kun MT7603)

Når det gjelder det gjenværende. så er det:

• Quantenna-modulen (lite sannsynlig at den noensinne vil virke)
• LED. GPIO 4 har noe med dette å gjøre, men den endrer bare oppførselen og resultatet er avhengig av verdien fra før. Det er ikke konsisten rød, grønn eller gul av eller på. Jeg lurer derfor på om det ikke sitter en smart controller mellom her. GPIO 4 er også en av I2C-pinnene, og det kan jo gi mening. Det er grunnen til at jeg ikke har i2c med i "pinctrl"
• Ethernet interface nummer to. Hvis noen aner hvordan man enabler dette, så gi lyd! Jeg innbiller meg at dette kan være grensesnittet mot Quantenna-modulen og jeg tror det brukes i RGMII modus. Men her er jeg på tynn is....

Må kutte her pga freak-limit.