Inlägg

Kan vara bra att länka manualerna till dina enheter. Du kommmer ändå behöva läsa dem.

Det känns som du har krånglat till det i onödan genom att köpa en 4G-router, men det borde inte vara olösbart om det ens är ett problem med nuvarande konf.

Som ovanstående inlägg är inne på så kan du få problem med dubbel (eller trippel) NAT: varje router måste ha olika IP-subnät på de olika sidorna. Det är rätt vanligt att konsumentroutrar har 192.168.1.1/24 som default, om det är så på båda routrarna så har du antagligen ingen internetaccess alls på den inte routern.

En vanlig, billig, modern laptop duger antagligen. Om det är en mediaburk så är det praktiskt att kunna byta SSD, så undvik fastlödda grejer.

Jag gillar inte RPi eftersom de har en tendens att skriva sönder minneskorten. Jag föredrar enheter med bättre kvalitet på lagringen än vad man får med minnseskort.

Men det är en jäkla djungel att navigera i vilka codecs som stöds i hårdvara, vilka HDMI- och DisplayPort-funktioner som stöds osv. Om man ska göra ett informerat köp krävs många timmars studier. Man måste så klart kontrollera mot GPU:n/CPU:n vilka codecs som stöds. Här är till exempel Intels matris.

Laptopar (AMD/Intel) och likaledes x86-baserade smådatorer har generellt mycket bättre Linux-stöd än ARM-baserade enkortsdatorer (kinesiska, icke RPI-alternativ alltså). För Windows är ju x86 i stort sett en nödvändighet fortfarande.

Själv har jag kört på äldre Thinkpad-laptops som TV-dator de senaste ~10 åren. Jag är inne på min tredje nu, avlagda jobbdatorer. Så det går bra att köra äldre laptops också, om man inte är för känslig mot att inte ha stöd för precis alla codecs i hårdvara. Enklast är att köpa något (nytt eller begagnat) på Ubuntus kompatibilitetslistor om man vill ha något med bra Linux-stöd.

kad@localhost:~$ sudo lshw -C display |grep resolution
       configuration: depth=32 resolution=3840,2160
kad@localhost:~$ sudo lshw -C display |grep product
       product: GM107GLM [Quadro M2000M]
kad@localhost:~$ lscpu |grep "Model name"
Model name:  Intel(R) Xeon(R) CPU E3-1505M v5 @ 2.80GHz

4K @ 60 Hz på nVIDIAs proprietära drivrutiner på Ubuntu 23.10 med en CPU släppt Q3 2015 (6th gen Skylake-H).

Drar jag igång Youtube i Firefox 4K@30Hz/VP9 så går fläktarna igång hörbart men inte irriterande om jag stänger av ljudet. 4K@60 (VP9) är klart irriterande med ljudet avstängt, med ljud på funkar det. På 4K @ 60 Hz är samtliga 8 CPU-trådar på ca 50%, så nVidia-kortet är uppenbarligen för gammalt för att hjälpa till med avkodningen. Hade CPU:n varit en generation nyare så hade jag kunnat köra den inbyggda grafiken och fått hårdvaruacceleration, men med denna CPU går det inte.

Fördelen med en riktig HTPC är att det är enklare med kylningen. Nackdelen är strömförbrukningen och storleken. Bara du kan göra det valet.

MT7621, vilken ER-X bygger på, är eller var den enda processorn som har fullt stöd för NAT/routing hårdvaru-offload i vanilla Linux, vilket OpenWrt i stora drag kör. Det är möjligt att det har kommit stöd för ytterligare någon Mediatek-processor nu, jag är inte uppdaterad på det. Det finns inofficiella träd även för någon Qualcomm-processor, men då får man kompilera själv och det är inget som är kvalitetsgranskat.

När jag har kört hårdvaruacceleration på MT7621 (ZyXEL WSM20) i OpenWrt så har jag kommit upp i någonstans 800-900 Mbit/s med ca 0% CPU load. Det man tappar i det läget är annan funktionalitet som SQM, men MT7621 är ändå en smula vek för att köra det.

Så för just ER-X borde det finnas rätt goda chanser att uppgradera kärnan. Om de verkligen vill, man kan ju tänka sig att de hellre säljer ny hårdvara.

Kan inget om Sonos.

Men ja, det är inte helt ovanligt att sämre IoT-enheter har så billiga/gamla WiFi-chip att de inte stödjer 802.11n, dvs Wi-Fi 4, som standardiserades någon gång 2008-2009.

Klistrar in en skärmdump från OpenWrt nedan. OpenWrt valde att stänga av stödet för dessa standarder i versionen som kom 2019 om jag minns rätt. Anledningen framgår av skärmdumpen.

Leta under 2.4 GHz-radions inställningar i din router.

Du kan läsa en kort sammanfattning här om i vilka situationer som RST-flaggan skickas. Med tanke på felmeddelandet så kan vi nog sluta oss till att det har hänt, frågan blir då varför.

Jag har inga direkta ideer. Jag kan inte ge någon trovärdig förklaring på det, men eventuellt kan NAT kan vara inblandat. Du kör IPv4 NAT lokalt och inte IPv6? CG-NAT? Går det lika dåligt om du stänger av alla andra enheter och bara kör din (omstartade) dator efter att övriga hushållet gått och lagt sig (och blivit avplockade mobiltelefoner som kan användas för sängsurf)?

Det där tyder på någon form av exotisk uppsättning. Om du gör något utöver det vanliga så är det läge att nämna det.

När en router på vägen i trafikflödet inte kan skicka data i samma takt som den tar emot data kommer den börja buffra upp data. När buffern är full kommer paketen som blir över slängas. Ovanstående kan göras per flöde, per destination, per källa, globalt eller på något annat vis, beroende på vilken taktik tillverkaren valt.

Der som händer när buffring uppstår är att variansen i round-trip-time ökar. När paket slängs måste de skickas om.

TCP reagerar på båda sakerna genom att minska utestående oACKat data, vilket i praktiken minskar hastigheten. Det kallas ”congestion avoidance” och implementeras inte bara i TCP, utan i alla transportlagerprotokoll av dignitet. Protokollen skyddar varandra och internet från att haverera och delar upp bandbredden mellan sig.

Routrarna hjälper till genom att göra val om vilka paket som ska slängas, eller markerar paket med information om att buffrarna håller på att bli fulla.

Allt ovanstående finns dokumenterat (men utspritt) i IETFs RFC:er. Att analysera congestion avoidance i ett TCP-flöde med till exempel Wireshatk är fullt görbart.

Slutsatsen är i vilket fall som helst att paket blir fördröjda eller tappas och att det sker i olika grad beroende på tidpunkt, samt på en lägre nivå än förväntat för att det ska bero på medveten begränsning till 100 Mbit/s. Troligen är nätet överbelastat någonstans mellan dig och målet. Beteendet kan ändras om du byter mål, men troligtvis finns problemet nära dig.

Kul

Där fick man för att man läste datablad för länge. Nåja, det var väl värt att öva på.

Här var vad jag kom fram till i teorin. Praktik är ju bättre!

Tveksamt men inte omöjligt.

Statusregistren skiljer sig en del, men det behöver ju inte nödvändigtvis vara ett problem. Kommandouppsättningen skiljer sig en del, men inte heller det behöver ju vara ett problem.

Storleken skiljer sig, men det tycks ju vara på rätt håll.

Orginalchippet tycks vara snabbare på programmering, serieklocka och radering, vilket skulle kunna vara problematiskt.

Prylen som jag jobbar med frågar över SPI/I2C om vad som finns på andra sidan som ett själv-test och jämför den returnerade datan med känt värde för att se om bussen är OK. Den vägrar jobba om inte självtestet går igenom, eftersom det i den applikationen är olyckligt att köra med halvt fungerande hårdvara. Det kan ju finnas sådan kod även i ett grafikkort.

If you can't find the root cause, it seems like you have already found a solution: Run Linux in a VM.

If a VM really is a solution, we can probably draw the conclusion that there is a performance problem in the Windows network stack on layer 3 or above, in the application layer or in the file system access. Perhaps some anti-virus or firewall.

If a VM is not a desireable solution, it seems like you may want to get a dedicated server for Plex+Nextcloud, or switch bare metal OS:s on the current box, since your Windows install seems messed up.

Because you're not giving any details about what kind of network traffic you are measuring against the server 2000 km away, it seems pointless to put effort into thinking about how you can analyze that traffic.

It really does not make sense that you can get full speed in a Linux VM on the Windows host through the switch, but get faster speed on the Windows host without the switch. What you seem to imply about getting full speed inside+outside Sweden in the VM but only inside Sweden on the Windows host does not make sense either. Your measurements simply does not seem trustworthy for whatever reason - maybe you have just not repeated each test case enough times to rule out random glitches, or other consumers of the network running at the same time causes results that are hard to interpret.

Nya lagar har nästan alltid övergångsbestämmelser kopplade till sig. Jag ska iväg till jobbet och har inte tid att hitta dem, men om du hittar riksdagsbeslutet så kommer det stå i klartext vad som gäller. Den gällande lagen har ett gäng övergångsregler som är lätta att hitta och som kan tjäna som exempel på vad du letar efter.

Antag att du på PC:n har satt ett statiskt IP (172.16.3.x) och en fast DNS-server.

Berätta för tråden vilken switch-port som är kopplad till pfSense.

För att du själv ska förstå vad som händer:

- Berätta steg för steg vad som händer med ett paket som skickas från PC:n till pfSense, med avseende på switch-portar, VLAN-taggar och brandväggsregler.

- Berätta steg för steg vad som händer med ett paket som skickas från pfSense till PC:n, samma sak.

Jag tror jag kan se problemet i switch-konfigurationen, men det är rätt svåröverskådligt. Jag gissar att du vid någon tidpunkt hade fungerande DHCP utan VLAN eftersom pfSense enligt skärmdumpen vid någon tidpunkt hade tilldelat den lokala sök-domänen .home.arpa till Windows och PC:n är listad med ett annat subnät i pfSense lease-lista.

Windows och alla vettiga operativsystem defaultar till IPv6 ibland, föremål för ett rätt komplext regelverk. Jag tror dock inte det spelar in här.

Du får nog bättre hjälp om du beskriver hur det tar stopp.

Jag tvivlar på att smbpasswd är beroende av smbclient, så det är nog inte problemet.

Men det är just smbclient paketet för Samba-klienten brukar heta. Jag har dock inte Raspberry Pi OS (som jag förutsätter att du kör) tillgängligt och kan bekräfta det.

sudo apt-get install smbclient

hjälper alltså knappast.

Jag antar det inte riktigt är vad du är ute efter, men om du vill ta reda på om hårdvaran är i fungerande skick så kan du testa att boota OpenWrt. Firmware finns här.

I installationsinstruktionerns Finns varianten ”Flashing via uBoot” där man kopplar på en seriekabel och bootar en initramfs som i det steget inte gör några förändringar på routern. Men det bör gå att testa basala funktioner i det läget (skapa upp ett WiFi-nät). Bryts strömmen så är man tillbaka med orginalmjukvaran. Installationen permanentas inte förrän man kör sysupgrade från det RAM-bootade läget (går att göra genom webbgränssnittet).

Om du inte har ett problem med att inte kunna lämna tillbaka produkten så kan du köra den enklare installationen, ”Flashing via Recovery Web Interface”, men då installeras OpenWrt direkt. Mjukvaran tycks vara anpassad för en A1-hårdvarurevision, så kör man den här varianten så bör man nog titta på etiketterna först.

Om det är ett tvåpack så går det kanske att försöka göra installationen av orginalmjukvaran mot den andra enheten?

Varför har du återgett just punkt 2 av de 14 punkterna i den paragrafen? Hur kom du till slutsatsen att det är den punkten som företaget åberopar?

Jag vet inte hur alla Tradera-auktioner någonsin gått till, men punkt 10 medger undantag från ångerrätten om det även går att lägga bud som inte är på distans.