Inlägg

Vet inte om Zyxel WSM-20 a.k.a Multy M1 går att få tag på fortfarande. Jag tror jag betalade 1100 kr för ett trepack. MT7621, så OK men relativt klen CPU. 2,4 GHz och 5 GHz, 2x2-radio på båda banden. Vit, interna antenner och vägghängning ingår. Dioderna går att stänga av när OpenWrt har bootat.

Jag tror att någon av Netgear-modellerna med 802.11ax uppfyller ditt krav, men de var svåra att hitta i EU sist jag kollade. Någon av dessa såldes från början som AP, men fick uppdaterad OEM-mjukvara så att den även kunde köras som router i stock.

Tyvärr har herrn som styrde upp OpenWrts databas över supportad hårdvara något annat för sig än att hantera Wikin, så många modeller som fått stöd på senare tid har inte fått egna sidor eller lagts in i ToH (table of hardware).

Du kan även titta på Teklagers AP:er av något kinesiskt märke som jag inte kommer ihåg. Jag tror den enklare är MT7621, så den bör kunna köras som router om man inte har för höga krav, den har två portar på bilderna. Den biffigare har bättre CPU och ballare radio. Dessa var sist jag tittade exempel på modeller fär man kunde hitta commits i stil med ”Mediatek: [Filogic]: Add support for [modell]”, men där modellerna inte fanns i ToH. Teklager finns på Sweclockers under det användarnamnet och brukar vara superhjälpsamma på mail. Ett tips kan vara att göra en sysupgrade (till samma version) direkt när man får prylen för att veta säkert vad man kör, men Teklager kan installera första gången åt dig, vilket är smidigt.

Har dom fixat något som motsvarar dist-upgrade än? Sist jag tittade (mååånga år sedan) så fanns det inte och då går det bort.

Jag håller mig i möjligaste mån ifrån IoT-prylar, men finns det verkligen skräp som funkar på det viset? 2,4 GHz, visst, men Wi-Fi? Du får det att låta som att IoT-grejen har en egen Wi-Fi AP som används bara för att appen ska ansluta och överföra inloggningsuppgifter till den riktiga AP:n. Hade jag designat ett IoT-system så hade jag kört hela det förfarandet över BLE i stället, för att slippa instruera användaren att koppla upp till en speciell AP. Finns det verkligen mobiler med OS där en app kan tvinga OS:et att koppla upp till en IoT-enhets AP?

Om det verkligen funkar så, är det därför tråden är fri från felmeddelanden? I så fall skulle ju IoT-prylen knappast kunna ge felmeddelande tillbaka eftersom den då skulle behöva koppla ner sin AP innan den försöker ansluta till drift-SSID:t (om den inte mot förmodan skulle kunna köra STA och AP på samma radio samtidigt).

Hur som, på trådens ämne: eftersom det är fritt att gissa så skulle jag tippa på någon inkompabilitet i autentiseringsförfarandet (WEP vs WPA vs WPA2 vs SAE) eller att IoT-prylen bara kan 802.11b/g medan routern kör som lägst 802.11n, eftersom de äldre protokollen sabbar prestandan.

Eftersom det går att logga i API:et är det tydligt att TLS-handskakningen och HTTPS-anropet från klienten till API:et lyckas.

Därmed är det TLS-handskakningen från API:et mot ”databasen” som misslyckas, ett exception kastas och propageras till klienten som ett status 500-fel.

Felsökning kan till exempel göras genom att göra anropet manuellt från servern med API:et, mot databasen. Här dyker det upp frågor om vilken databas med cert som Axios använder för att verifiera databasserverns cert. Eftersom det inte finns något bra felmeddelande så kan det även vara något simpelt fel - som nämnts ovan att namnen inte matchar. Eller att certet har gått ut. Tråkigast är alltså om klienten (API:et i det problematiska anropet) inte kan verifiera certifikatkedjan eftersom den saknar cert i sin certdatabas.

En webbläsare, curl eller openssl s_client bör gå att använda för den manuella felsökningen.

Kan inget om Unifis mjukvara, men det finns inget rent tekniskt som ska hindra det. Ubiquity använder vad jag har läst WDS a.k.a 4-address för funktionen du kallar ”mesh”. De fyra adresserna räcker för att åstadkomma det du vill, i alla fall om den AP den är kopplad till även är router. 802.11s, det som IEEE kallar mesh har sex adresser och klarar vad jag förstår fler hopp av den anledningen.

Oavsett behöver mjukvaran fixa bryggning mellan Wi-Fi och trådat och det kan möjligen vara där det brister. Wi-Fi och switch sitter ofta på olika chip, så CPU:n behöver blandas in - orkar inte kolla arkitekturen på din burk.

Så vi får se om någon som har fått det att fungera dyker upp i tråden, annars får du väl fråga den som sålt prylen?

LG verkar ha varit extremt sporadiska på att Wi-Fi-certifiera sina TV efter 2018. Jag kan inte hitta någon OLED alls som är senare än 7-serie, dvs 2017 som blivit certad.

Vad gäller Telia-toutern så finns det en certad enhet under cert-id WFA111505 där modellnamnet EWA1330TCS matchar det som google säger att F1-routern egentligen heter. Jag hade väntat mig att märket skulle vara Technicolor, men det är Vantiva, som dock har certat en hel del enheter med produktnamn Technicolor.

Så om jag skulle satsa pengar på att en av enheterna inte följer standard, så satsar jag på TV:n.

Det verkar tyvärr inte gå att länka till sökresultaten, så du får söka själv på https://www.wi-fi.org/product-finder-results?sort_by=certifie... om du är intresserad.

Eftersom båda enheterna är i kategorin nerdummad konsumentskit så är det tveksamt om det är värt att lägga tid på att hitta en workaround. Köp något certat nästa gång du bryr dig om resultatet.

Det luktar CG-NAT-burk som får slut på portar. Typiskt fel när gamla uppkopplingar fortsätter att fungera men det inte går att etablera nya uppkopplingar.

Kolla om du har CG-NAT-adresser på WAN-sidan av din router och/eller på din dator. Nej, "what is my IP" eller liknande fungerar inte, du behöver kolla faktiskt tilldelad IP-adress.

Om det är ett problem med NAT så kan du säkerligen provocera fram problemet genom att på ett eller annat sätt starta många uppkopplingar utåt. Normalt ska man kunna närma sig 65535-1024 uppkopplingar innan det tar stopp, ifall man har ett helt IP själv. Många routrar begränsar mer än så eftersom de har begränsat med minne och processorkapacitet för att hålla igång NAT:ade uppkopplingar.

Det beror på att den är en asgammal design med billig hårdvara (MT7621AT, 2014). Den kommer antagligen aldrig köra en modern Linux-kernel med OEM-mjukvaran eftersom den har två 3 MB-partitioner för detta och modern Linux tar mer plats än så.

Därmed inte sagt att den är dålig, men man ska veta att den antagligen inte kommer maxa ut 1 Gbit/s, men den kommer antagligen nästan dit.

Det går antagligen utmärkt. Det är dock mer tveksamt om det går att använda Google Wi-Fi som rena AP. Som jag tolkar manualen kan du bara köra en av dem. Jag kan inte förklara varför och då har jag ändå läst googles förklaring. Du kan installera OpenWrt på Google WiFi och då försvinner begränsningarna, men installationen ser halvbesvärlig ut och konfigurationen är inte direkt enkel heller.

Edit: De flestat "mesh"-systemen har den begränsningen. En enhet måste vara router och de fungerar bara tillsammans med det egna fabrikatet (rent tekniskt för att 4-adress, a.k.a WDS inte är standardiserat, i alla fall inte i en standard som slagit igenom än).

Det är en smaksak, men om brandväggen har stöd för brandväggsregler baserade på MAC-adress så kan man använda det i stället. Det funkar på iptables och nftables under Linux och jag tycker det borde vara möjligt även på FreeBSD/OPNSense. Baserar man regeln på IP så blir man beroende av att en andra regel finns för att tilldela en viss IP till viss MAC, så MAC kommer ändå i spel. Om TV:n får för sig att börja slumpa fram MAC-adress vid boot (ur locally administered-rangen) så är man körd oavsett.

Om fibern kunde komma in så går det antagligen att komma ut igen, som alternativ till att dra kabel inne i huset genom väggar och genom golv/tak. Dörrfoder, trösklar och fönsterkarmar som alternativ för att komma in igen, eller in på vinden och ner om det är enklare. Det finns speciell utomhuskabel som är fukt- och UV-beständig men ger ifrån sig otrevliga gaser när den brinner och därmed är olämplig för allt utom mindre sträckor inomhus.

Ska man dra inomhus så är det ju rätt tråkigt i ett sådant hus om det inte är i samband med renovering, när man kan byta trösklar, golv- tak- och dörrlister till sådana som har plats för kabel, eller dra i nygjord tilläggsisolering. Kabelkanaler kan bli rätt ok, men det är ett jäkla meck och tråkigt nästa gång man ska tapetsera.

Hur som helst är det ju helt beroende på hur huset ser ut i detalj och personlig smak på hur mycket åverkan man vill göra, samt vilket behov av uttag man anser sig ha.

Gissningen på sky2 verkar bra. Exakt din modell listas i och för sig inte.

lspci -k

Visar vilka PCIe-enheter du har i din burk och listar vilken driver som används. Om du kan verifiera på Ubuntu vilken driver som används så kan du kanske lösa problemet varför den inte finns i Mint.

Så här ser det ut på burken jag sitter på nu:

00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (2) I219-LM (rev 31)
	Subsystem: Lenovo Ethernet Connection (2) I219-LM
	Kernel driver in use: e1000e
	Kernel modules: e1000e

Drivrutinen för nätverkskortet finns alltså, i mitt fall, i en kernel-modul som heter e1000e.

Jag kan verifiera att drivrutinen har laddats från en modul, dvs den är inte inkompilerad i kerneln genom att köra kommandot:

find /lib/modules/$(uname -r) -type f -name *.ko* |grep e1000e

som tittar i mappen för drivrutiner/kernel-moduler som beror på den körande kernel-versionen (uname -r), letar efter filer som har .ko (kernel object) i namnet och som även matchar e1000e i namnet. Resultatet:

/lib/modules/6.5.0-27-generic/kernel/drivers/net/ethernet/intel/e1000e/e1000e.ko.zst

Där har vi alltså min drivrutin för ethernet. sky2 finns också där om jag söker på det i stället.

Normalt, på Linux på x86, så skickas alla drivrutiner med i distributionen och hamnar i mappen som nämns ovan. Linux kommer vid boot scanna hårdvaran och ladda den drivrutin som behövs. Det är dock upp till distributionen om de vill kompilera drivrutinen som modul (som visas ovan) för sin kernel.

Dessutom behövs ibland firmware, dvs mjukvara som behöver laddas över på ethernet-hårdvaran för att den ska fungera. Sådan firmware ligger i

/lib/firmware

Det är drivrutinens jobb att fundera ut vilken firmware-fil som behövs och ladda den. Om ingen firmware-fil finns tillgänglig så kommer drivrutinen misslyckas och hårdvaran kommer inte fungera. I så fall bör det finnas något form av felmeddelande i bootloggen.

sudo dmesg |less

Kan användas för att scrolla i bootloggen.

Edit: På Ubuntu är det typ:

cat /boot/config-$(uname -r) |grep CONFIG_SKY2

som letar efter strängen "CONFIG_SKY2" i den körande kärnans kompileringskonfiguration. Med resultatet

CONFIG_SKY2=m
# CONFIG_SKY2_DEBUG is not set

vilket inte är förvånande i och med att vi redan hittat modulen på disk, enligt ovan.

Omöjligt att ge ett bra svar om du inte ger motiveringar och detaljer. Det finns massor av alternativ. I slutändan måste du själv förstå exakt vad du vill åstadkomma och hur du gör det och inget annat.

Ett bra svar utgår från vad du har för prylar tillgängliga och budget för att köpa nytt och du säger inte något om det.

Ett alternativ är att sätta ett extra nätverkskort i bägge burkarna och tilldela statisk IPv4 i bägge ändar där IP-subnätet inte tillhör något av de andra nätverken. Den varianten bör vara i princip omöjlig att klanta till så länge man inte aktiverar routing i den yttre burken. Man behöver förstås testa så att den inre inte kommer åt internet genom den yttre. Här uppkommmer frågan om ”appen” ansluter till en viss domän (uppslag med port 53 DNS) eller IP, eller om den använder mDNS, eller någon annan variant för att hitta sin server. Är servern helt passiv eller broadcastar den något?

En annan variant är att sätta en router med lämpliga brandväggsregler mellan näten. Här uppstår direkt frågan vad det är för typ av trafik som egentligen ska kunna skickas. Behöver appen vara i samma broadcast-domän som sin server?

Om det redan finns en DHCP-server i det icke internetanslutna nätet så kanske det är den burken som även ska agera router/brandvägg mot det yttre nätet? Man får se upp med IPv6 så att det inte slipper igenom.

Annars kanske det är din normala brandvägg som ska agera brandvägg i alla riktningar mellan internet och de två lokala näten (tre brandväggszoner). I så fall gäller det att du har något som inte är för nerdummat för vanliga konsumenter och att du verkligen förstår vad du ska göra och hur. Den varianten plus några dumswitchar är det jag skulle säga är snyggast och flexiblast, men det är som sagt inget man gör med en generisk konsumentrouter och det är lätt att göra bort sig.

Jag tror du får svårt att hitta något som är speciellt bra om du söker en vanlig billig konsumentrouter med Wi-Fi.

Sådana burkar har lite och billigt NAND som duger till att skriva uppdaterad firmware till ett antal gånger per livstid och eventuellt till att skriva lite inställningar, om man inte har EEPROM/FRAM till det. Men om man försöker logga kontinuerligt så skrivs det fort sönder. Alternativet är att hålla statistiken i RAM och skriva den ytterst sporadiskt, men RAM är begränsat, förloras vid plötsliga omstarter och kostar pengar för en funktion få efterfrågar.

Jag kör luci-app-nlbwmon på OpenWrt, men det är inte speciellt sexigt, eftersom det är byggt för förutsättningarna som nämns ovan. Finns skärmdumpar att googla efter.

Om du vill ha något som inte är rundimentärt får du nog titta på någon produkt som är mer semiprofessionell och då får du antagligen inte WiFi i lådan. Jag gissar att OPNSense/pfSense/IPFire som går att köra på mindre x86-burkar har OK funktionalitet, men det är inget jag har testat. Teklager säljer sådana burkar med ditt val av OS förinstallerat.