Inlägg

Kvantifiera "stabila" och "ostabila" områden i signalstyrka (dBm), uppnådd MCS-nivå, latens (ms) och överföringshastighet (bit/s).

De två första mäter du antagligen med en Android-app (sökord WiFi analyzer). Jag gillar wavemon till Linux.

De två sista mäter du med något verktyg som kan mäta latens under belastning, till exempel denna webbsajt.

Om du inte kan mäta skillnaderna så finns dom inte, eller så mäter du för dåligt/vid fel tidpunkt.

Använt frekvensband (2,4 GHz eller 5 GHz, möjligen 6 GHz) spelar roll. Använd kanal kontra vad grannarna använder kan spela roll. Kanalen styr hur starkt enheterna får sända (sökord regulatory database eller kommandot "iw reg get" på Linux). Vilken enhet man använder spelar roll, enheter har olika egenskaper varav hur mycket ström de sparar genom att sända svagare är en. Kanalbredd spelar roll. Vissa kanaler är DFS-kanaler och kan bidra till instabilitet om man har otur och råkar befinna sig vid en väderradar, se Wikipedias lista. Och så förstås alla miljarders buggar som finns i olika WiFi-implementationer och inkompabilitetsproblem som finns eftersom relativt få enheter är WiFi-certifierade.

Jag tycker den här sidan är bra för att skapa sig en förståelse om vad som spelar roll. Om jag minns rätt förklarar den varför enheter som har dålig mottagning förstör för andra enheter.

Lösningen är antagligen fler accesspunkter, trådade eller "mesh". Helst trådade och med anpassade kanaler, så de inte stör ut varandra - och anpassad signalstyrka, så att roaming funkar.

Inget är väl en överdrift, men oftast väldigt lite.

Båda servermjukvarorna (som du inte nämner) kan vara kompilerade mot samma bibliotek, till exempel OpenSSL. Så frågan är nog mest vad som hänt mer än att du bytte cert.

Om du har tillgång till konsoll så är det bara att titta i loggen varför ssh-uppkopplingen misslyckas. Oftast är klient och server olika gamla och accepterar inte samma krypton. Lite trist om WinSCP inte ger ett bättre felmeddelande på sin sida. Internetet säger att det finns en loggfil där också, men jag har aldrig behövt titta i den. Du kan köra en modern WSL och se om en sådan ssh-klient säger något vettigare.

Spelar ingen större roll. Se citatet nedan. Det är nästan alltid bättre att läsa lagtext och förarbeten än nerdummade populärvarianter. Edit: Praxis (ARN-beslutet ovan) är dock alltid bäst, notera dock att det gäller en gammal version av konsumentköplagen (vilket antagligen inte spelar någon roll mer än nummer på paragrafer).

Om näringsidkaren inte kan företa omleverans eller avhjälpande, dvs reparation, (vilket de har rätt till att genomföra) så kan du häva köpet.

I det läget har du rätt till skadestånd motsvarande prisskillnaden för ett täckningsköp. Om samma produkt finns på marknaden och inte säljs till ett överpris så bör det hela vara juridiskt så klart det kan bli. Du behöver inte ens genomföra täckningsköpet. Att faktiskt få ut ett skadestånd är en helt annan sak. Du kan behöva gå till ARN (och de är ett gäng klåpare) eller domstol för att faktiskt få pengar.

Du ska naturligtvis läsa konsumentköplagen själv och bilda dig en uppfattning hur den passar mot din situation. Du har antagligen inte gett en fullständig bild i tråden, så ingen här kan egentligen veta säkert vad som gäller. Om du häver köpet var noga med att använda det ordet och göra det skriftligt.

Två hushåll alltså, som antagligen inte ska vara i samma broadcast-domän (se varandras Chromecasts etc).

Om du får två IP-adresser
från ISP så är det antagligen trevligast att sätta två dumswitchar i skåpet med CTS:en. Patcha ut 2 x internet till en router var i respektive lägenhet och sedan tillbaka till switcharna som är till respektive lägenhet. Dubbeluttag på ett ställe i respektive lägenhet krävs för att kunna koppla tillbaka till respektive lägenhets switch. Strömförsörjningen till switcharna ser ut att bli knepig...

I den nedre lägenheten låter det som att det blir TV-rummet som får ha routern, 20 mm rör bör funka med minst två kablar.

Varje hushåll får administrativ kontroll över sitt nät, även om säkerheten är beroende på hushållet som har fysisk kontroll över inkommande anslutning. Sitter du bakom CG-NAT så kan du antagligen köra på den här lösningen.

Om du bara får en IP-adress
så är den enklaste lösningen en router som har två olika LAN (IP-subnät). Det går att fixa på routrar som har en inbyggd switch och där mjukvaran stödjer DSA i Linux. Alla routrar där det finns 3+ riktiga ethernet-interface (inte switch-portar) funkar definitivt.

Här blir frågan om man kan trycka in en router och två små dumswitchar i skåpet. Om inte så behöver man antagligen klabba med VLAN och en managerad switch, vilket suger komplexitetsmässigt. Om du får in allt i skåpet, koppla internet->router->två olika portar med olika LAN->två switchar->alla uttag i respektive lägenhet.

Jag hade tittat på om Edgerouter-X med stockmjukvara klarar att sätta upp detta utan VLAN. ER-X med OpenWrt bör klara det utan problem, men jag har inte testat så jag vet inte. Jag kör en APU2 med tre riktiga interface från Teklager med förinstallerat OpenWrt som enkelt hade fixat detta, men APU2/3/4 är end of life så kanske lite knepig att få tag på. Teklager tycks dock ha 4:or kvar. Både ER-X och APU:erna är tunna, så de kanske går att trycka in. Det finns ju även andra maskiner i ER-serien som är rätt tunna, men jag vet inget om dem.

Nackdelen med ett IP blir att den som har kontrollen över routern i skåpet har administrativ kontroll över hela nätverket (båda LANen).

Edit: Inser nu att skåpet på tredje våningen kanske är centrum i ett stjärnnät där. Det gör ju i så fall att man slipper en av switcharna i skåpet med CTS:en och kan ha den på tredje våningen i stället.

Det finns en hel yrkeskår av akademiskt utbildade människor (4+1 år) som gillar att diskutera den här typen av frågor. Du har antagligen någon relativt nära dig som gärna vill prata på tu man hand och har genomtänkta svar.

Som bonus kan du få insikt i andra intressanta frågor som talande brinnande buskar, flickor som blir påsatta av andeväsen, intressant matematik i stil med 1 + 1 + 1 = 1 och varför man ska utrota dem som inte skurits i snoppen.

Det är ISP:n som bestämmer hur många IP-adresser som ska delas ut och ISP:n äger inte alltid (ganska sällan) mediakonverteraren, det gör kommunikationsoperatören.

Vissa ISP:er vill antagligen ha kvar konkurrensfördelen att kunna låta kunder få fler än en publik IPv4-adress och en hel del kunder vill nog ha den möjligheten. En variant framkommer i trådar på Sweclockers om att dela ett och samma icke-företags-abb mellan två hushåll. Att kunna ha en server på ett IP och övrigt på ett annat är ju trevligt.

Om man bara har en fungerande port för internet i mediakonverteraren måste det till en helt onödig switch för att köra två routrar eller router+server. Ja macvlan existerar så att man kan ha mer än en publik IP på WAN-interfacet på en enda router, men det är inget alternativ för Svensson och är inte lika trevligt i flerhushållsscenariot.

Och gissa vad: folk som inte vet hur de ska koppla kommer koppla in en extra switch i den enda öppna porten porten på mediakonverteraren och sedan sina enheter rakt i switchen och då ändå inte ha en brandvägg.

Du menade antagligen inte att det skulle finnas en brandvägg i mediakonverteraren, men för tydlighetens skull: det är inte säkert att en CPU som sitter i en mediakonverterare/managerad switch klarar av att vara brandvägg. Dessutom vill man inte att KO/ISP ska kontrollera ens brandvägg (om man inte aktivt valt en ISp-router).

Har inte Intel lovat att stämma skiten ur dem om de använder x86-delen av AMD64 utan x86-licens?

Visade det sig att det inte var juridiskt möjligt?

Seriekabel för att veta vad den gör när den startar?

Edit: om du redan haft isär den borde du kunna mäta på pinnen som sänder UART och lista ut om den pratar eller inte och i så fall hur länge.

Här är en video från någon som visar hur man kan byta mellan de två olika firmware som ligger på hans maskin. Båda verkar funka i hans fall, vad som händer för dig är ju högst oklart.

Jag har aldrig förstått vad Ansuels GUI ersätter på de där maskinerna. Men jag antar att det bara är just GUI:et och att resten av mjukvaran fortfarande är en Thompson-hackad variant av OpenWrt från 2015 som modernast. Måttligt attraktivt och inget som känns rimligt att exponera mot internet, men kanske duger som AP. Om inte Ansuel har fixat omställning till ”dumb AP” så lär man få dras med dubbel NAT, oavsett om man kör hans grejer eller stock.

Om inget funkarr så är det väl bara att köra fabriksåterställning. Telia verkar dock ladda ner firmware från nätet i sin version av Thompson-firmware när man gör fabriksåterställning och jag gissar att chansen är noll att de servrarna är tillgängliga på det publika internet. Men vem vet.

Så illa är det antagligen inte. Manualen (som verkar allmänt trasig på vissa sidor) föreslår att man ska köra någon mjukvara som heter "Lacie Network Assistant". Den tycks dock inte finnas att ladda ner via hemsidan, men det finns andra ställen som jag inte tänker länka på grund av de uppenbara säkerhetsaspekterna. Jag skulle inte köra en sådan programvara utanför en virtuell maskin, men du gör dina egna val.

ERR_CONNECTION_TIMEOUT tyder på att ingen svarar alls på destinationen. Hade porten varit stängd hade det blivit "connection refused" i stället. Vilken IP-adress tror du NAS:en finns på och varför tror du det? Svarar den på ping?

Ett vanligt problem för folk som försöker komma åt äldre NAS:ar är att Microsoft har stängt av stödet för SMB1-protokollet, eftersom det är trasigt i sin design och ett allvarligt säkerhetshål. Det går att slå på. Detta används om man accessar vissa gamla NAS:ar via Windows filhanterare, se den andra manualen, avsnitt 2 nånting.

Du tycks ju dock använda webbläsaren. Ett vanligt problem med nya webbläsare och äldre hemma-servrar är att det endast går att komma åt servern via http, port 80. Nya webbläsare envisas dock med att det är osäkert och propsar på att försöka använda https, port 443 även om man sagt åt dem att använda http. Det felmeddelande du skriver tyder dock på att det inte är ditt problem.

Det verkar normalt gå att komma åt NAS:en via namnuppslagning genom namnen "LaCie-CloudBox" eller "LaCie-CloudBox.local". För det används en teknik som kallas mDNS. Det ska normalt fungera i allt utom riktigt gamla versioner av Windows, men viss nätverksutrustning, till exempel routrar, mellan dig och NAS:en kan hindra sådan namnuppslagning att fungera. Hur ditt nätverk ser ut spelar alltså roll. I den enklast möjliga uppsättningen av nätverk borde inte detta vara ett problem.

Slutligen så finns det hintar i manualen om att man kan ändra namn på NAS:en och sätta statisk IP-adress. Har du gjort det så fungerar naturligtvis inget i manualen. Manualen talar även om att NAS:en tar en självtilldelad IP, "169.254.xxx.yyy/24", om den är inställd på att få IP från en DHCP-server (default-inställningen, det funkar normalt utmärkt tillsammans med hemmaroutrar) om den inte kan få kontakt med en DHCP-server. Återigen beror det lite på hur ditt nätverk ser ut och hur du kopplat in NAS:en.

Suyu. Ja, påminner om klassiska fejkjapanskan sosumi, numera ett sätt att köra MacOS på Linux. Jag trodde att det var den koreanska spriten, men den stavas visst soju.

Om du ska köpa en laptop ”extra” så ska du ha en du kan köra ett OS du inte kör på jobbet. Med andra ord är det bäst att vänta och se om du kommer köra Mac på jobbet eller inte. Om du köper en ”PC” privat så ska det förstås vara en med bra stöd för Linux.

En del företag låter inte kodare administrera sina egna datorer. Dom jobbar man för som konsult, så har man två jobbdatorer varav man får administrera den ena. Och man låter förstås bli att bli anställd av ett konsultföretag som är så stort att man inte får administrera sin egen dator.

Som giplet är inne på är det nog lite halvsvårt svårt att få svar på frågan ”har jag några IP-adresskonflikter och i så fall vilka maskiner?”

Om du har en maskin med problem, stäng av den och se om du fortfarande kan pinga IP:t. Eller som föreslagits, scanna samtliga portar på det IP:t med nmap och se om något svarar. Om du får ett svar så har du i alla fall en MAC-adress (och kanske ett gäng öppna portar) att gå på. Maskinen med problem kommer antagligen ha loggposter där den identifierar MAC-adressen för den som konkurrerar om samma IP.

Några ideer för den generella problemställningen:

Wireshark har ett filter som heter arp.duplicare-adress-detected. Borde funka om man scannar hela LAN:et med nmap samtidigt som man fångar trafiken.

arping -d verkar enligt manualsidan kunna hitta svar från flera MAC-adresser. Verkar vara ont om script på nätet som loopar ett gäng IP-adresser och kör detta.

Man borde kunna scripta gratious ARPs (dvs ARP-svar som säger jag har denna kombination av IP och MAC) med arping och provocera fram svar från de maskiner som även de tycker att de har den berörda IP-adressen. Det finns mekanismer för självtilldelning av IP-adresser som undviker att ta samma som någon annan på det viset, kommer inte ihåg om det är i IPv4 eller IPv6.

ping -b 255.255.255.255 skulle kunna ge något om maskinerna är tillräckligt knäppa för att svara på ping till broadcast.

Jag orkar inte ställa till en konflikt och testa något av detta.

Grundproblemet är ju att de flesta verktyg bara kommer hantera en mappning mellan IP och MAC i taget. Möjligen är ping tillräckligt smart för att förstå att den får flera svar på samma paket och att förslaget från prez1z ovan funkar. Jag skulle gärna se en skärmdump i så fall. Problemet bör vara att man skickar ping till en viss MAC och att en nätverksstack inte nödvändigtvis svarar på ping till rätt IP men fel MAC.

Det bör rimligen vara ett ursprungligt fel när man sålt en produkt som av känd anledning kommer sluta fungera inom reklamationsperioden.

Mest ett fall av Hanlon tror jag.

Funkar säkert, men proxy-lösning som kräver tredje part är inte strikt nödvändigt, eftersom TS säger sig ha en publik IP. Om det är sant eller inte och om den är fast nog att lita på är för all del okänt.

TS: De protokoll du nämner är inte lämpliga att köra över internet. De är antingen okrypterade eller har en historik av säkerhetsproblem i implementationerna. Gör inte portöppningar i brandväggen för att exponera NASen över internet med de protokollen. FTP skickar lösenord i klartext och kan därför sniffas av någon som finns mellan dig och NASen. Över huvud taget kan det vara bra att minimera antalet använda protokoll för att minimera attackytan.

Lösningen är att sätta upp en VPN-server av något slag hemma och ansluta till den över internet. Då kommer NASen, om allt klaffar, vara tillgänglig som vanligt men över en krypterad tunnel vari det är någorlunda OK att köra osäkra protokoll.

Tailscale, nämnt ovan, använder Wireguard. Ett problem att lösa är att de två lokala subnäten hemma och där du ansluter ifrån inte kan ha samma IP-subnät, 192.168.0/24. Tailscale löser som sagt säkert problemet, men om du faktiskt har en publik någorlunda fast IP så kan du lika väl sätta upp Wireguard självständigt. Jag har haft samma publika IP i fem+ år trots att den inte officiellt är fast (Bahnhof).

Jag vet inget om Chromecast, men att sätta gateway till ditt hemnätverks publika IP är fel i alla lägen. Det kan möjligen fungera när du testar hemma, men det kommer inte att fungera från internet. En gateway, i IP-terminologi, är alltid en maskin (IP-adress), på det lokala IP-subnätet, via vilken man når ett annat nätverk, ofta internet. Det normala är att använda 192.168.x.1 ellet 10.y.z.1. Problemet löser sig självt när du kan accessa hemnätverket över VPN. Det tycks finnas en officiell Wieguard-klient för Chromecast.

Att låta en AI från kina övervaka ”barnen” verkar inte överdrivet attraktivt.

Men den stora fördelen med den här maskinen är att den har väldigt kompetent hårdvara och bara är en sysupgrade bort från att köra vanilla OpenWrt. Det finns stöd för hårdvaruacceleration både av routing/NAT och WiFi tydligen, vilket sammantaget gör maskinen rätt unik. Installationsinstruktion här.

Notera dock att man måste bygga en egen image med t. ex. firmware selector om man vill ha med ”luci”, det grafiska gränssnittet, fram tills en stabil version släppts med stöd för maskinen. Lägg till luci under Installed packages under customizations.

Asus TUF Gaming AX6000 (länkad ovan) har en krångligare officiell installation, men en enklare inofficiell. Instruktioner här. Snubben som gjort den inofficiella installationen påstår i forumet att kina-varianten TX-AX6000 ska ha exakt samma hårdvara men vara billigare (den har även en manual på kinesiska som ser ut som en serietidning). Ingen ska förväxlas med GT-AX6000 som är Broadcom-baserad i stället för MediaTek-baserad och därmed är körd för OpenWrt.

Du är fri att anta vad du vill. Jag hade inte antagit något om jag inte hade läst en övertygande spec om funktionen.

Unifi-burkarna är ju så nerdummade att de inte ens har fulla administrationsmöjligheter själva, de måste ha en extern controller. Det är dock inte för att de saknar hårdvara för att köra ett administrationssystem, hårdvaran brukar vara kompetent. Det handlar om att sälja på konsumenter onödig hårdvara.

Hur som helst måste AP:na koordinera sig för att den ena ska kunna kicka klienten (och rekommendera den andra BSSID:n) när det innebär en förbättring att byta. Gör de det utan en extern controller?

256 MB RAM? Produktsidan anger inget.

Om du litar på diktaturen i kina för att stå för säkerheten på ditt nät så kommer det sannolikt att fungera med det du har nämnt i trådstarten.

Mjukvaran är antagligen så handikappad att du inte kan göra något med den som använder mer RAM än den skeppas med.

Du har en switch, använd den, så elimineras i alla fall WiFi som felkälla. I nyare mainline-Linux-kärnor finns en hel del som tar ner latensen för WiFi, men normala konsumentroutrar kör inte nyare mainline-Linux. Och det vore ändå inte lika bra som ethernet. Situationer där routern behöver startas om beror inte sällan på att WiFi har kraschat.

Nästa grej är att börja fundera på att köra SQM, smart queue management. SQM ser till att olika flöden prioriteras mer rättvist. I flöden med små paket som kommer sällan så får dessa hoppa före i kön jämfört med ett större flöde som redan har hunnit köa upp en stor mängd paket.

Det finns många konsumentroutrar som har det besläktade QoS, som inte är identiskt och som är svårt att veta exakt vad det innebär eftersom det inte beskrivs av tillverkarna. SQM är ovanligare och det minst okända varumärket, IQrouter, har kursat. Det finns säkert på fler ställen (det är en funktion i mainline Linux), men den jag känner till är OpenWrt. ER-X kan köra OpenWrt, men dess CPU begränsar bandbredden till ca 150 Mb/s med SQM på. Länken tycks antyda att funktionen finns i ER-X:ens standardmjukvara och att du alltså inte behöver installera OpenWrt för att testa.

Och ja, att återupprepa ett fel som du inte vet vad det bestod av är rätt omöjligt.