Banana Pi BPI-R4 router "byggsats" - Wifi7 och 5G som tillbehör

Permalänk
Medlem
Skrivet av KAD:

Jag visste inte heller, så jag surfade lite… regulatory.h beskriver bittarna som beskriver hur en Linux-driver beter sig, vilket i det här fallet beror på hur firmware som kör på kortet beter sig.

Self-managed skiter i kärnans regdb och landsval och kör efter eget tycke. Vilket skiljer sig mellan dina olika kort.

Intels location-aware-regulatory verkar vara det mest diskuterade exemplet på detta. Jag killgissar att konceptet är mest använt på kort avsett att vara STA, inte AP, och att man då låter firmware titta på AP:ns beacon och AP:n får stå för juridiken (vilket är juridiskt tveksamt). I det här driver/firmware-fallet har man kanske varit pragmatisk och ansluter till allt (inkl 320 MHz) som AP:n erbjuder om det skulle bli lagligt i framtiden. Många Linux-system kommer ju aldrig uppdateras, så det där kan tänkas vara ett försök att vara framåtkompatibel.

Knäckfrågan är väl om 320 MHz AP är lagligt eller inte i EU och Sverige.

I så fall, är Linux nu aktuella wireless-regdb bara dåligt uppdaterad? I så fall borde så klart någon ta tag i att hitta juridisk grund och skicka in en patch.

Jag ägnade en timme åt PTS dokument, ETSIs beskrivningar av sina dokument och EU-förordningar, men hittar inte i gyttret.

* @REGULATORY_WIPHY_SELF_MANAGED: for devices that employ wiphy-specific * regdom management. These devices will ignore all regdom changes not * originating from their own wiphy. * A self-managed wiphys only employs regulatory information obtained from * the FW and driver and does not use other cfg80211 sources like * beacon-hints, country-code IEs and hints from other devices on the same * system. Conversely, a self-managed wiphy does not share its regulatory * hints with other devices in the system. If a system contains several * devices, one or more of which are self-managed, there might be * contradictory regulatory settings between them. Usage of flag is * generally discouraged. Only use it if the FW/driver is incompatible * with non-locally originated hints. * This flag is incompatible with the flags: %REGULATORY_CUSTOM_REG, * %REGULATORY_STRICT_REG, %REGULATORY_COUNTRY_IE_FOLLOW_POWER, * %REGULATORY_COUNTRY_IE_IGNORE and %REGULATORY_DISABLE_BEACON_HINTS. * Mixing any of the above flags with this flag will result in a failure * to register the wiphy. This flag implies * %REGULATORY_DISABLE_BEACON_HINTS and %REGULATORY_COUNTRY_IE_IGNORE

Edit: Du kan ju kolla efter tillverkarens dokumentation om CE-märkning. Det är ju inte säkert att kortet ens är avsett att säljas i EU. Och om det är det så är det väk inte säkert att en taiwanesisk ingenjör fått juridiken rätt. Vem som helst kan ju sätta CE på vad som helst och intyga att det är rätt gjort. Även om tillverkare anlitar ett externt testinstitut är det inte säkert att testerna körs med slutgiltig driver/firmware — så är det där jag jobbar.

Stort tack, det var inte meningen att sätta dig i arbete - men väldigt intressant information för både mig och andra som läser här

Qualcomm kortet är ett mottagarkort och jag tror inte det säljs löst i Sverige, jag köpte det via Gigabyte GC-Wifi7 - det sitter alltså löstagbart på pci-kortet. (bra pris förövrigt - på aliexpress kostar bara kortet ca 750:- och antennen lös går loss på ca 280:- ) men för den intresserade ska man veta att det kan sitta ett annat fabrikat på wifi-kortet om man köper Gigabyte GC-Wifi7 idag.

Förövrigt har jag numera samma kort i en laptop - Lenovo Yoga Slim 7x (Snapdragon Elite) som jag kör Ubuntu på - den ansluter jag med i 320MHz. Men jag har inte testat att sätta upp en AP på den (vet inte ens hur man skulle kunna göra det i 320MHz)

Men den visar samma sak med "iw reg get"

Permalänk
Medlem
Skrivet av Pulver:

Kan helt enkelt vara en miss från OpenWRT:s utvecklare.

För att vara övertydlig: OpenWrts utvecklare kommer inte göra något åt detta. De kommer propsa på att använda upstream wireless-regdb. Det är ditt problem att få in en patch i upstream och därmed att motivera patchen juridiskt, för att få den accepterad.

Permalänk
Medlem
Skrivet av Pulver:

Stort tack, det var inte meningen att sätta dig i arbete - men väldigt intressant information för både mig och andra som läser här

Jag följer inte trådar på Sweclockers och kollar inte på om jag citerats eller taggats, så om jag gör någon research så är det 100% när jag har gott om tid och av eget intresse av ämnet

Permalänk
Medlem
Skrivet av KAD:

För att vara övertydlig: OpenWrts utvecklare kommer inte göra något åt detta. De kommer propsa på att använda upstream wireless-regdb. Det är ditt problem att få in en patch i upstream och därmed att motivera patchen juridiskt, för att få den accepterad.

För mig är det inte viktigt, jag är mest intresserad av vad som fungerar och vilka inställningar och regler som gäller.

Har satt upp ett någorlunda komplicerat mesh-system (802.11s) nu och kommer med största sannolikhet köra 6GHz AX på 80 eller 160MHz

Permalänk
Medlem

Vet att det finns andra här som använder Banana Pi R4 med Wifi7 och fliker in tipset om att det går att få igång 320MHz genom att sätta JP (Japan) som landskod.

Är ansluten med min Snapdragon Yoga 7 som kör Ubuntu.

Permalänk
Medlem

Imorgon är det lite Black Friday rea på Aliexpress och några säljare sänker priset på Banana Pi BPI R4 och Wifi7 kortet.

Det är inga "tappa hakan" sänkningar, men om man vill ha det billigaste priset är det nog nu man ska slå till.

Det är faktiskt billigare att köpa delar från olika affärer och då slipper man även eventuell tullkostnad (tror gränsen ligger vid ca 2000:- ? )

Ett tips jag har är Chipboard Development store, de säljer olika Banana Pi R4 paket (med och utan låda mm) och kommer sänka priset från 1 617,79 till 1 391,30 för ett paket med moderkortet, lådan och en (liten) kylare - inklusive frakt. (Bundle 7)

Vill du dessutom ha Wifi7 kortet är det nästan bara Bipai butiken som säljer den på Black Friday erbjudande - men ha koll på fraktpriset här eftersom de inte säljer med gratis frakt. Sänks från 1071:- till 986:- men frakt på 100:- tillkommer.

Att köpa ett helt komplett paket med alla delar är ibland dyrare än att handla delarna separat av någon outgrundlig anledning - då lär man dessutom antagligen åka på tullkostnad.

Om någon undrar har jag handlat paketet från Chipboard Development store tidigare utan några problem.

Ursprungligen handlade jag enbart från de officiella (Banana pi) butikerna, men nu har jag handlat en hel del från andra butiker och det fungerar lika bra och blir oftast lite billigare.

Det enda som egentligen saknas är antennpaket med kablar och antenner samt en nätdel.

Man måste inte köpa det officiella antennpaketet (som är lite dyrt) - det går med andra billigare lösningar, jag ska exempelvis köra med 3st externa bordsantenner ett tag (en idé jag har-kommer bilder om det fungerar) men det behövs ändå interna antenn-kablar i lådan.

När det gäller nätdel/ström fungerar det fint med vanliga usb-c laddare som har lite mer kraft i sig när man kör moderkortet utan Wifi7.

Med Wifi7 kortet monterat rekommenderas en nätdel på 12V 2A, när jag kollade hemma hade jag flera sparade som fungerade.

Min plan i slutändan är att ha en Banana Pi R4 som router utan Wifi7 och 1-2 BPI-R4 med Wifi7 som accesspunkter/mesh-noder.

Rean inleds fredag morgon svensk tid.

Permalänk
Medlem
Skrivet av Pulver:

Det är faktiskt billigare att köpa delar från olika affärer och då slipper man även eventuell tullkostnad (tror gränsen ligger vid ca 2000:- ? )

Vad är det för tullkostnad du pratar om? Är det verkligen tull på elektronik från Kina?

Moms, vilket ofta är det som folk felaktigt kallar "tull" vid import från utanför EU, läggs på automatiskt av AliExpress och delklarationen och inbetalning av momsen hanteras av dem.

Visa signatur

Antec P280 | FSP Hydro Ti Pro 1000W | MSI X670E Carbon | Ryzen 7 9800X3D | Kingston Fury Beast 6000MT/s CL30 2x32GB | ASUS RTX 3080 TUF OC | 2x Samsung 990 Pro 4TB | Kingston KC3000 4TB | Samsung 970 Pro 1TB | 2x Samsung PM863a 3.84TB | 2x ASUS PG279Q

Permalänk
Medlem
Skrivet av blunden:

Vad är det för tullkostnad du pratar om? Är det verkligen tull på elektronik från Kina?

Jag har fått det vid ett enstaka tillfälle när en vara kostade mer än 2000:-

Säljaren hävdade att det var det högre värdet på det som skickades som avgjorde det.

Det är ju någon gräns vid 1800:- ?

"försändelser med ett deklarerat värde på 1 800 kronor eller högre." (från postens hemsida)

Permalänk
Medlem
Skrivet av Pulver:

Jag har fått det vid ett enstaka tillfälle när en vara kostade mer än 2000:-

Säljaren hävdade att det var det högre värdet på det som skickades som avgjorde det.

Det är ju någon gräns vid 1800:- ?

"försändelser med ett deklarerat värde på 1 800 kronor eller högre." (från postens hemsida)

Kollar man på tullverket så tillkommer som mest kemikalieskatt på några tior, utöver moms. Det som är lite förvirrande är att det nämns en gräns på 1800 kr för IOSS som vad jag vet är sättet som AliExpress hanterar inbetalning av svensk moms på köp. Samtidigt har jag köpt dyrare elektronik än så på AliExpress utan att åka på extra avgifter så vet inte hur det hanterades.

https://www.tullverket.se/foretag/internationellhandel/import...

Visa signatur

Antec P280 | FSP Hydro Ti Pro 1000W | MSI X670E Carbon | Ryzen 7 9800X3D | Kingston Fury Beast 6000MT/s CL30 2x32GB | ASUS RTX 3080 TUF OC | 2x Samsung 990 Pro 4TB | Kingston KC3000 4TB | Samsung 970 Pro 1TB | 2x Samsung PM863a 3.84TB | 2x ASUS PG279Q

Permalänk
Medlem

Såg att det pratades om antenner i en annan tråd och någon sa att det är en fördel med löstagbara varianter så att man kan välja själv- jag håller med. Routers med stora spretiga antenner är inte vackra enligt mig.

Har inhandlat en hel del varianter av externa antenner nu, men det är svårt att hitta "snygga" modeller, framförallt med 6GHz möjlighet.

Det här är ett litet test jag gjort för en av mina BPI-R4:

Det sitter en liten metallbit under hyllan som antennen fäster mot med magneter.

samtidigt bygger jag en lite mer avancerad lösning till min andra BPI-R4 station

Permalänk
Hedersmedlem

Det här är en fantastisk tråd!

Jag var intresserad av en sådan router när banana pi lanserades - men då var det lite oklart kring... ja ganska mycket. Specifikationer, stöd och allt möjligt.
Nu när dimman lagt sig ser det rätt bra ut alltså. Kul att routerupplägget här testas av folk här. Och dokumenteras!

Får erkänna att lättjan tagit över tlite bara. Tröskel av trassel när wifi7 inte hade inkluderat stöd i soc ;).

Visa signatur

🎮 → Node 304 • Ryzen 7 5700X3D • Nh-D14 • Gainward RTX 2070 • 32GB DDR4 • MSI B450I Gaming Plus AC
🖥️ → Acer Nitro XV273K Pbmiipphzx
💻 → Lenovo Yoga slim 7 pro 14" Oled

Permalänk
Medlem

Trevligt att tråden läses
Ibland känner jag mig lite ensam här, men vet att det finns fler som har den och läser

Angående mjukvarustöd så kan det vara intressant att veta att den första stabila utgåvan från OpenWRT med stöd för Banana Pi BPI-R4 är på gång nu snart 24.10 finns under OpenWRT Firmware selector och befinner sig just nu i version RC2 (Release Candidate 2) - annars är det under "snapshot" man tidigare laddat hem den senaste developer-versionen för BPI-R4.

Jag kör 24.10 RC2 på alla mina enheter här hemma och det fungerar bra

Permalänk
Medlem
Skrivet av Pulver:

Trevligt att tråden läses
Ibland känner jag mig lite ensam här, men vet att det finns fler som har den och läser

Angående mjukvarustöd så kan det vara intressant att veta att den första stabila utgåvan från OpenWRT med stöd för Banana Pi BPI-R4 är på gång nu snart 24.10 finns under OpenWRT Firmware selector och befinner sig just nu i version RC2 (Release Candidate 2) - annars är det under "snapshot" man tidigare laddat hem den senaste developer-versionen för BPI-R4.

Jag kör 24.10 RC2 på alla mina enheter här hemma och det fungerar bra

Jag läser fortfarande tråden också, även om jag inte svarar så mycket i tråden längre. Tycker fortfarande att det är en intressant produkt, så det är intressant att se hur mjukvaran förbättras till den, även om jag inte har något behov av den själv för tillfället.

Har de fått med all hårdvaru-offloading som folk testat i tråden på OpenWrt forumet i den officiella releasen också?

Visa signatur

Antec P280 | FSP Hydro Ti Pro 1000W | MSI X670E Carbon | Ryzen 7 9800X3D | Kingston Fury Beast 6000MT/s CL30 2x32GB | ASUS RTX 3080 TUF OC | 2x Samsung 990 Pro 4TB | Kingston KC3000 4TB | Samsung 970 Pro 1TB | 2x Samsung PM863a 3.84TB | 2x ASUS PG279Q

Permalänk
Medlem
Skrivet av blunden:

Har de fått med all hårdvaru-offloading som folk testat i tråden på OpenWrt forumet i den officiella releasen också?

Vet ej och även om jag aktiverat det så vet jag inte riktigt hur jag kan testa om det fungerar heller- skulle gissa på att det inte är med.

Jag la märke till att en annan router jag har (Acer W6) nyligen fått en funktion för att ställa in led-lampan i snaphot, men funktionen fanns inte med i 24.10, tyvärr.

Permalänk
Medlem
Skrivet av Pulver:

Vet ej och även om jag aktiverat det så vet jag inte riktigt hur jag kan testa om det fungerar heller- skulle gissa på att det inte är med.

Jag la märke till att en annan router jag har (Acer W6) nyligen fått en funktion för att ställa in led-lampan i snaphot, men funktionen fanns inte med i 24.10, tyvärr.

Misstänker att det syns som hardware offload i nftables. Sedan märks det väl lättast när man försöker routa i 10 Gbit/s, medan det vid lägre hastigheter lär spela mindre roll för annat än möjligen energiåtgång.

Visa signatur

Antec P280 | FSP Hydro Ti Pro 1000W | MSI X670E Carbon | Ryzen 7 9800X3D | Kingston Fury Beast 6000MT/s CL30 2x32GB | ASUS RTX 3080 TUF OC | 2x Samsung 990 Pro 4TB | Kingston KC3000 4TB | Samsung 970 Pro 1TB | 2x Samsung PM863a 3.84TB | 2x ASUS PG279Q

Permalänk
Medlem
Skrivet av blunden:

Misstänker att det syns som hardware offload i nftables. Sedan märks det väl lättast när man försöker routa i 10 Gbit/s, medan det vid lägre hastigheter lär spela mindre roll för annat än möjligen energiåtgång.

Jag tror att det är ett gäng olika HW-offload-problem runt BPi-R4.

Vad jag förstår behövs någon form av TCP-magi för att nå norr om ca 2,5 Gbit/s. Halvtydlig info om problemet finns nog i något dangowrt-inlägg på BPi-forumet. Sinovoips skräp-”OpenWrt” tror jag har fullt blås.

Den vanliga kryssrutan i LuCI löser bara routing och NAT? Om nu CPU:n faktiskt fått stöd.

Sedan finns WO/WED, avlastning mellan WiFi och trådat. Info om det finns på BPi-R4 sidan på OpenWrt-wikin.

Hur det hänger ihop med bridger-paketet och Eric Woulds kernel-ändringar för att accelerera bryggade interface är jag inte klar över. Bridger-paketet är som allt Felix åstadkommer komplett odokumenterat. Woulds tråd finns på BPi-forumet och som RFC på någon mailinglista.

I somras försökte jag göra en lista över alla OpenWrts hårdvaru- och mjukvaruaccelerationer av nätverk och hur de påverkar andra funktioner (SQM) samt hur de kan användas tillsammans eller inte. Men det var över min förmåga.

Permalänk
Medlem
Skrivet av KAD:

Jag tror att det är ett gäng olika HW-offload-problem runt BPi-R4.

Vad jag förstår behövs någon form av TCP-magi för att nå norr om ca 2,5 Gbit/s. Halvtydlig info om problemet finns nog i något dangowrt-inlägg på BPi-forumet. Sinovoips skräp-”OpenWrt” tror jag har fullt blås.

Den vanliga kryssrutan i LuCI löser bara routing och NAT? Om nu CPU:n faktiskt fått stöd.

Sedan finns WO/WED, avlastning mellan WiFi och trådat. Info om det finns på BPi-R4 sidan på OpenWrt-wikin.

Hur det hänger ihop med bridger-paketet och Eric Woulds kernel-ändringar för att accelerera bryggade interface är jag inte klar över. Bridger-paketet är som allt Felix åstadkommer komplett odokumenterat. Woulds tråd finns på BPi-forumet och som RFC på någon mailinglista.

I somras försökte jag göra en lista över alla OpenWrts hårdvaru- och mjukvaruaccelerationer av nätverk och hur de påverkar andra funktioner (SQM) samt hur de kan användas tillsammans eller inte. Men det var över min förmåga.

Jag tycker mig ha sett att folk i tråden implementerat praktiskt taget full offloading med hjälp av kod från Mediatek, men är osäker på hur mycket av den koden som faktiskt integrerats officiellt i OpenWrt ännu. Den TCP-magi du pratar om är troligen hardware flow offloading via nftables som helt enkelt kringgår kernel-processningen för alla paket i samma flow.

Har inte kört OpenWrt på en mer kraftfull router de senaste åren så jag vet inte exakt vad kryssrutan i LuCi gör. Skulle spontant gissa på att den kanske aktiverar software flow offloading åtminstone.

Visa signatur

Antec P280 | FSP Hydro Ti Pro 1000W | MSI X670E Carbon | Ryzen 7 9800X3D | Kingston Fury Beast 6000MT/s CL30 2x32GB | ASUS RTX 3080 TUF OC | 2x Samsung 990 Pro 4TB | Kingston KC3000 4TB | Samsung 970 Pro 1TB | 2x Samsung PM863a 3.84TB | 2x ASUS PG279Q

Permalänk
Medlem
Skrivet av KAD:

Sedan finns WO/WED, avlastning mellan WiFi och trådat. Info om det finns på BPi-R4 sidan på OpenWrt-wikin.

Har varit lite förvirrad över alla olika termer och olika builds, det som står på BPI-R4 Wikin:

https://openwrt.org/inbox/toh/sinovoip/bananapi_bpi-r4#wirele...

Har jag inte testat och vet inte riktigt om det finns i vanliga snapshot builds.

I Wifi7 tråden på OpenWRT:s forum postas det dagligen olika builds, nu senast med MLO och WO, men jag väntar nog tills dessa funktioner finns i OpenWRT:s snapshots

Permalänk
Medlem

Fixade lite med min andra BPI-R4 idag, den här kylaren är inte den största - men passar fint på processorn

finns här (20x20x7mm - köpte 3st för 90:- när det var rea)

Även om jag gjort det några gånger nu är det inte lätt att få alla kablarna rätt när man monterar eftersom man måste vrida och vända på kortet några gånger

Permalänk
Medlem

Vill slänga in ett tips som inte berör Banana pi R4 specifikt utan är mer för OpenWRT generellt.

Vi har ju diskuterat "Mesh" (802.11s) i tråden tidigare och jag har efter många misslyckade försök fått igång ett fungerande system som dock inte varit helt perfekt.

Det som inträffar om man inte gör alla inställningar korrekt är att det skapas loops som överbelastar routern vilket resulterar i en förlorad internet-uppkoppling - vill det sig riktigt illa kommer man inte åt routern alls via nätverket, även efter en omstart.

Det finns olika guider man kan följa för att göra alla inställningar rätt, men ingen har varit riktigt bra (enligt mig) och det är mycket hopp mellan saker som enbart kan utföras genom kommando i en ssh-ansluten konsoll och inställningar i web-gränssnittet Luci.

Nu råkade jag hitta en guide som föll mig i smaken: https://github.com/benkay86/openwrt-batman-tutorial

Under rätt förutsättningar gör man alla inställningar i Luci och guiden som är från 2024 visar tydligt med bilder hur man ska ställa in.

Det är fortfarande onödigt komplicerat (enligt mig) och lite förvirrande att det finns flera olika protokoll (batman mfl), men denna passade iallafall min kunskapsnivå bra

Permalänk
Medlem

Upplever att de medföljande antennerna till BPI-R4 inte fungerar så bra för 6Ghz bandet. Med dina nya antenner har du märkt någon skillnad?

Permalänk
Medlem

Jag har märkt av att det är sämre signal på 6GHz, ja.
Har tolkat det som om att det kan vara sämre signal på 6GHz än 5GHz pga högre hastighet, att OpenWRT inte är riktigt färdiga med stödet för Bananapi/Wifi7 mm men det kan säkert bli bättre med en riktigt bra antenn.

Har flera nya (6GHz) antenner (och några påväg) och har tänkt göra ett ordentligt test med alla för att se om det blir bättre signal med någon av dem.

Har även införskaffat några "märkliga" antenner

Tror dock att jag lovat många tester här som inte riktigt blivit av, men det här ska göras snart.
Jag har dock många saker jag vill testa och har fastnat med en annan router de senaste dagarna

Permalänk
Medlem

Jag gjorde trots allt ett litet test, men nej - jag kan inte rekommendera just den här antennen, tyvärr.

Den går att köpa från ca 70-80kr från Aliexpress men modellen finns även från Alfa och Comfast (som kanske är originaltillverkaren)

Jag har tagit bort ett mjukt material under antennen för att komma åt skruvarna och öppna upp den - mycket mer spännande än såhär är det inte därinne.

Har fått 2 olika modeller, med något annorlunda antenner - har ingen aning om någon av dem är mer "original" än den andra - eller om den ena bara är en uppgraderad version.

Men det lilla snabba test jag gjorde idag visade att den presterar sämre än de som följer med Wifi7 kortet från Banana Pi.

Originalantenn

Originalantenn

6E Antennen

6E Antennen

(titta inte på retries och failed eftersom det ökade hela tiden när jag bytte antenner )

Nu ser det ovanligt dåligt ut på dessa bilder och det återspeglar inte hela sanningen, men generellt ligger den lägre än antennerna från Banana Pi.

Förhoppningsvis kan jag rekommendera någon annan antenn inom kort.

Jag kopplade förövrigt även in den märkliga "silverantennen" på bild ovan och den presterade klart bäst resultat

Men jag tror det är en riktad antenn som egentligen är avsedd för att styra drönare mm.

Permalänk
Medlem
Skrivet av blunden:

Den TCP-magi du pratar om är troligen hardware flow offloading via nftables som helt enkelt kringgår kernel-processningen för alla paket i samma flow.

Har inte kört OpenWrt på en mer kraftfull router de senaste åren så jag vet inte exakt vad kryssrutan i LuCi gör. Skulle spontant gissa på att den kanske aktiverar software flow offloading åtminstone.

TCP-magin jag försökte komma ihåg handlar nog om hur många ramar (ethernet-data-enhet) man plockar ur hårdvaran per läsning. Så inte så mycket TCP egentligen, utan något som av en eller annan anledning behövs för att TCP-strömmar upp mot 10 Gbit/s ska fungera. Att hantera en ram i taget är helt enkelt för slött.

Det finns två kryssrutor, en för software offload och en för hardware offload. I 23.05 var de hierarkiskt ordnade (hardware kommer fram när man kryssar software), vilket är fel om jag fattar rätt-- man ska bara ha en åt gången, de bör vara radiobuttons. Jag tror det är fixat i 24.10 men jag har inte installerat den versionen än. Jag har experimenterat med båda sorterna offload på MT7621 som har stöd för hardware offload och det gör skillnad. Men det är bara några få CPU:er som har stöd för hardware offload och det är knepigt att läsa sig till vilka det är.

Buggig screenshot från 23.05:

Skrivet av Pulver:

Det som inträffar om man inte gör alla inställningar korrekt är att det skapas loops som överbelastar routern vilket resulterar i en förlorad internet-uppkoppling - vill det sig riktigt illa kommer man inte åt routern alls via nätverket, även efter en omstart.

[...]

Det är fortfarande onödigt komplicerat (enligt mig) och lite förvirrande att det finns flera olika protokoll (batman mfl), men denna passade iallafall min kunskapsnivå bra

Jag trodde poängen med mesh11sd var att det bara var att installera och köra, den fattar om enheten är gateway mot internet eller inte och fixar all komplexitet med > 2 noder. Men det funkade alltså inte för dig? (Nej, jag har aldrig testat mesh11sd själv).

Skrivet av Pulver:

Jag har märkt av att det är sämre signal på 6GHz, ja.
Har tolkat det som om att det kan vara sämre signal på 6GHz än 5GHz pga högre hastighet, att OpenWRT inte är riktigt färdiga med stödet för Bananapi/Wifi7 mm men det kan säkert bli bättre med en riktigt bra antenn.

Det pågår en diskussion på BananaPi-forumet där man hävdar att det saknas sköldar över radiokretsarna på BE14-kretskortet och att det gör att man får dålig SNR. Folk experimenterar med att sätta folie runt kretskortet och att dra antennerna långt från PCIe-bussen för att se hur det påverkar. Jag kan väldigt lite om radio, men jag konstaterar att prylen jag jobbar med har en sköld över sin radiokrets och att väldigt många av FCCs bilder också har det. Potentiellt kass hårdvara helt enkelt, vilket inte känns otroligt med tanke på hur usla kyllösningar Sinovoips "produkter" har. I mitt tycker verkar det verkligen vara utvecklingskort, något man köper för att köra naket på skrivbordet och utveckla mot. Tyvärr hittar jag inte tråden nu när jag letar.

Apropå tidigare diskussioner. 320 MHz kanalbredd @ 6 GHz i EU. Jag dumpar nedanstående här för vem som helst att ta vidare utan att ge mig någon cred. Jag orkar nog helt enkelt inte ta tag i det, det var som synes två månader sedan jag gjorde researchen och detta har legat och skräpat sedan dess. Granska, byt ut "From:" och "Signed-off-by:" och kolla att patchen fortfarande går att applicera:-)

From 280e6d6e01c1e31f2349a623bfd33aef195fa170 Mon Sep 17 00:00:00 2001 From: KAD <kad@sweclockers.com> Date: Sun, 10 Nov 2024 19:48:06 +0100 Subject: [PATCH] wireless-regdb: Allow 320 MHz channels on 6 GHz for EU ETSI EN 303 687 V1.1.1 (2023-06) allows use of two non-adjecent 160 MHz channels (option 1) or two adjecent channels (option 2) according to section 4.3.6.3.2.3 [1]. Add 320 MHz channels to the 6 GHz spectrum for all EU countries. The European parliament delegated power to the European Commission to enact rules for radio spectrum use (Article 3) in Article 44 of 2014/53/EU [2]. The Commission, in their implementing decision C(2015) 5376 final called on ETSI to provide the technical framework [3]. The Commission, in their decision 2021/1067 of 17.6.2021 decided to allocate 5945-6425 MHz to WAS/RLANs [4]. ETSI has issued EN 303 687 [1] to provide the technical framework here too, citing C(2015) 5376 final [2] as the legal basis. The use of 320 MHz channels for Wi-Fi on the 6 MHz band is therefor permitted within the European Union, which as of 2024 consists of 27 countries with the following country codes: BE, BG, CZ, DK, EE, IE, GR/EL, ES, FR, HR, IT, CY, LV, LT, LU, HU, MT, NL, AT, PL, PT, RO, SI, SK, FI, SE [5]. 6 GHz/WiFi 6E for most EU countries was added in commit 7a6ad1a, "wireless-regdb: Unify 6 GHz rules for EU contries" [1] https://www.etsi.org/deliver/etsi_en/303600_303699/303687/01.... [2] https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX... [3] https://ec.europa.eu/transparency/documents-register/api/file... [4] https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX... [5] https://ec.europa.eu/eurostat/statistics-explained/index.php?... Signed-off-by: KAD <KAD@sweclockers.com> --- db.txt | 54 +++++++++++++++++++++++++++--------------------------- 1 file changed, 27 insertions(+), 27 deletions(-) diff --git a/db.txt b/db.txt index a9a9ba4..143665a 100644 --- a/db.txt +++ b/db.txt @@ -125,7 +125,7 @@ country AT: DFS-ETSI # short range devices (ETSI EN 300 440-1) (5725 - 5875 @ 80), (25 mW) # 6 GHz band - (5945 - 6425 @ 160), (23), NO-OUTDOOR, wmmrule=ETSI + (5945 - 6425 @ 320), (23), NO-OUTDOOR, wmmrule=ETSI # 60 GHz band channels 1-4 (ETSI EN 302 567) (57000 - 66000 @ 2160), (40) @@ -224,7 +224,7 @@ country BE: DFS-ETSI # short range devices (ETSI EN 300 440-1) (5725 - 5875 @ 80), (25 mW) # 6 GHz band - (5945 - 6425 @ 160), (23), NO-OUTDOOR, wmmrule=ETSI + (5945 - 6425 @ 320), (23), NO-OUTDOOR, wmmrule=ETSI # 60 GHz band channels 1-4 (ETSI EN 302 567) (57000 - 66000 @ 2160), (40) @@ -275,7 +275,7 @@ country BG: DFS-ETSI # I.43 of the List, BDS EN 300 440-2, BDS EN 300 440-1 (5725 - 5875 @ 80), (25 mW) # WiFi 6E - (5945 - 6425 @ 160), (23), NO-OUTDOOR, wmmrule=ETSI + (5945 - 6425 @ 320), (23), NO-OUTDOOR, wmmrule=ETSI # 60 GHz band channels 1-4 (ETSI EN 302 567) # II.H03 of the List, BDS EN 302 567-2 (57000 - 66000 @ 2160), (40) @@ -486,7 +486,7 @@ country CY: DFS-ETSI # short range devices (ETSI EN 300 440-1) (5725 - 5875 @ 80), (25 mW) # 6 GHz band - (5945 - 6425 @ 160), (23), NO-OUTDOOR, wmmrule=ETSI + (5945 - 6425 @ 320), (23), NO-OUTDOOR, wmmrule=ETSI # 60 GHz band channels 1-4 (ETSI EN 302 567) (57000 - 66000 @ 2160), (40) @@ -506,7 +506,7 @@ country CZ: DFS-ETSI # short range devices (ETSI EN 300 440-1) (5725 - 5875 @ 80), (25 mW) # 6 GHz band - (5945 - 6425 @ 160), (23), NO-OUTDOOR, wmmrule=ETSI + (5945 - 6425 @ 320), (23), NO-OUTDOOR, wmmrule=ETSI # 60 GHz band channels 1-4 (ETSI EN 302 567) (57000 - 66000 @ 2160), (40) @@ -550,7 +550,7 @@ country DE: DFS-ETSI # short range devices (ETSI EN 300 440-1) (5725 - 5875 @ 80), (25 mW) # WiFi 6E - (5945 - 6425 @ 160), (23), NO-OUTDOOR, wmmrule=ETSI + (5945 - 6425 @ 320), (23), NO-OUTDOOR, wmmrule=ETSI # 60 GHz band channels 1-4 (ETSI EN 302 567) (57000 - 66000 @ 2160), (40) @@ -571,7 +571,7 @@ country DK: DFS-ETSI # short range devices (ETSI EN 300 440-1) (5725 - 5875 @ 80), (25 mW) # 6 GHz band - (5945 - 6425 @ 160), (23), NO-OUTDOOR, wmmrule=ETSI + (5945 - 6425 @ 320), (23), NO-OUTDOOR, wmmrule=ETSI # 60 GHz band channels 1-4 (ETSI EN 302 567) (57000 - 66000 @ 2160), (40) @@ -623,7 +623,7 @@ country EE: DFS-ETSI # short range devices (ETSI EN 300 440-1) (5725 - 5875 @ 80), (25 mW) # 6 GHz band - (5945 - 6425 @ 160), (23), NO-OUTDOOR, wmmrule=ETSI + (5945 - 6425 @ 320), (23), NO-OUTDOOR, wmmrule=ETSI # 60 GHz band channels 1-4 (ETSI EN 302 567) (57000 - 66000 @ 2160), (40) @@ -649,7 +649,7 @@ country ES: DFS-ETSI # short range devices (ETSI EN 300 440-1) (5725 - 5875 @ 80), (25 mW) # WiFi 6E - (5945 - 6425 @ 160), (23), NO-OUTDOOR, wmmrule=ETSI + (5945 - 6425 @ 320), (23), NO-OUTDOOR, wmmrule=ETSI # 60 GHz band channels 1-4 (ETSI EN 302 567) (57000 - 66000 @ 2160), (40) @@ -673,7 +673,7 @@ country FI: DFS-ETSI # short range devices (ETSI EN 300 440-1) (5725 - 5875 @ 80), (25 mW) # 6 GHz band - (5945 - 6425 @ 160), (23), NO-OUTDOOR, wmmrule=ETSI + (5945 - 6425 @ 320), (23), NO-OUTDOOR, wmmrule=ETSI # 60 GHz band channels 1-4 (ETSI EN 302 567) (57000 - 66000 @ 2160), (40) @@ -699,7 +699,7 @@ country FR: DFS-ETSI # short range devices (ETSI EN 300 440-1) (5725 - 5875 @ 80), (25 mW) # WiFi 6E low power indoor - (5945 - 6425 @ 160), (23), NO-OUTDOOR, wmmrule=ETSI + (5945 - 6425 @ 320), (23), NO-OUTDOOR, wmmrule=ETSI # 60 GHz band channels 1-6 (ETSI EN 302 567 v2.2.1) (57000 - 71000 @ 2160), (40) @@ -777,7 +777,7 @@ country GR: DFS-ETSI # short range devices (ETSI EN 300 440-1) (5725 - 5875 @ 80), (25 mW) # 6 GHz band - (5945 - 6425 @ 160), (23), NO-OUTDOOR, wmmrule=ETSI + (5945 - 6425 @ 320), (23), NO-OUTDOOR, wmmrule=ETSI # 60 GHz band channels 1-4 (ETSI EN 302 567) (57000 - 66000 @ 2160), (40) @@ -846,7 +846,7 @@ country HR: DFS-ETSI # short range devices (ETSI EN 300 440-1) (5725 - 5875 @ 80), (25 mW) # WiFi 6E - (5945 - 6425 @ 160), (23), NO-OUTDOOR, wmmrule=ETSI + (5945 - 6425 @ 320), (23), NO-OUTDOOR, wmmrule=ETSI # 60 GHz band channels 1-4 (ETSI EN 302 567) (57000 - 66000 @ 2160), (40) @@ -874,7 +874,7 @@ country HU: DFS-ETSI # short range devices (ETSI EN 300 440-1) (5725 - 5875 @ 80), (25 mW) # 6 GHz band - (5945 - 6425 @ 160), (23), NO-OUTDOOR, wmmrule=ETSI + (5945 - 6425 @ 320), (23), NO-OUTDOOR, wmmrule=ETSI # 60 GHz band channels 1-4 (ETSI EN 302 567) (57000 - 66000 @ 2160), (40) @@ -900,7 +900,7 @@ country IE: DFS-ETSI # short range devices (ETSI EN 300 440-1) (5725 - 5875 @ 80), (25 mW) # 6 GHz band - (5945 - 6425 @ 160), (23), NO-OUTDOOR, wmmrule=ETSI + (5945 - 6425 @ 320), (23), NO-OUTDOOR, wmmrule=ETSI # 60 GHz band channels 1-4 (ETSI EN 302 567) (57000 - 66000 @ 2160), (40) @@ -966,7 +966,7 @@ country IT: DFS-ETSI # short range devices (ETSI EN 300 440-1) (5725 - 5875 @ 80), (25 mW) # 6 GHz band - (5945 - 6425 @ 160), (23), NO-OUTDOOR, wmmrule=ETSI + (5945 - 6425 @ 320), (23), NO-OUTDOOR, wmmrule=ETSI # 60 GHz band channels 1-4 (ETSI EN 302 567) (57000 - 66000 @ 2160), (40) @@ -1152,7 +1152,7 @@ country LT: DFS-ETSI # short range devices (ETSI EN 300 440-1) (5725 - 5875 @ 80), (25 mW) # 6 GHz band - (5945 - 6425 @ 160), (23), NO-OUTDOOR, wmmrule=ETSI + (5945 - 6425 @ 320), (23), NO-OUTDOOR, wmmrule=ETSI # 60 GHz band channels 1-4 (ETSI EN 302 567) (57000 - 66000 @ 2160), (40) @@ -1171,7 +1171,7 @@ country LU: DFS-ETSI # short range devices (ETSI EN 300 440-1) (5725 - 5875 @ 80), (25 mW) # 6 GHz band - (5945 - 6425 @ 160), (23), NO-OUTDOOR, wmmrule=ETSI + (5945 - 6425 @ 320), (23), NO-OUTDOOR, wmmrule=ETSI # 60 GHz band channels 1-4 (ETSI EN 302 567) (57000 - 66000 @ 2160), (40) @@ -1190,7 +1190,7 @@ country LV: DFS-ETSI # short range devices (ETSI EN 300 440-1) (5725 - 5875 @ 80), (25 mW) # 6 GHz band - (5945 - 6425 @ 160), (23), NO-OUTDOOR, wmmrule=ETSI + (5945 - 6425 @ 320), (23), NO-OUTDOOR, wmmrule=ETSI # 60 GHz band channels 1-4 (ETSI EN 302 567) (57000 - 66000 @ 2160), (40) @@ -1330,7 +1330,7 @@ country MT: DFS-ETSI # short range devices (ETSI EN 300 440-1) (5725 - 5875 @ 80), (25 mW) # 6 GHz band - (5945 - 6425 @ 160), (23), NO-OUTDOOR, wmmrule=ETSI + (5945 - 6425 @ 320), (23), NO-OUTDOOR, wmmrule=ETSI # 60 GHz band channels 1-4 (ETSI EN 302 567) (57000 - 66000 @ 2160), (40) @@ -1421,7 +1421,7 @@ country NL: DFS-ETSI # short range devices (ETSI EN 300 440-1) (5725 - 5875 @ 80), (25 mW) # WiFi 6E - (5945 - 6425 @ 160), (23), NO-OUTDOOR, wmmrule=ETSI + (5945 - 6425 @ 320), (23), NO-OUTDOOR, wmmrule=ETSI # 60 GHz band channels 1-4 (ETSI EN 302 567) (57000 - 66000 @ 2160), (40) @@ -1544,7 +1544,7 @@ country PL: DFS-ETSI # short range devices (ETSI EN 300 440-1) (5725 - 5875 @ 80), (25 mW) # 6 GHz band - (5945 - 6425 @ 160), (23), NO-OUTDOOR, wmmrule=ETSI + (5945 - 6425 @ 320), (23), NO-OUTDOOR, wmmrule=ETSI # 60 GHz band channels 1-4 (ETSI EN 302 567) (57000 - 66000 @ 2160), (40) @@ -1576,7 +1576,7 @@ country PT: DFS-ETSI # short range devices (ETSI EN 300 440-1) (5725 - 5875 @ 80), (25 mW) # 6 GHz band - (5945 - 6425 @ 160), (23), NO-OUTDOOR, wmmrule=ETSI + (5945 - 6425 @ 320), (23), NO-OUTDOOR, wmmrule=ETSI # 60 GHz band channels 1-4 (ETSI EN 302 567) (57000 - 66000 @ 2160), (40) @@ -1626,7 +1626,7 @@ country RO: DFS-ETSI # short range devices (ETSI EN 300 440-1) (5725 - 5875 @ 80), (25 mW) # 6 GHz band - (5945 - 6425 @ 160), (23), NO-OUTDOOR, wmmrule=ETSI + (5945 - 6425 @ 320), (23), NO-OUTDOOR, wmmrule=ETSI # 60 GHz band channels 1-4 (ETSI EN 302 567) (57000 - 66000 @ 2160), (40) @@ -1688,7 +1688,7 @@ country SE: DFS-ETSI # short range devices (ETSI EN 300 440-1) (5725 - 5875 @ 80), (25 mW) # 6 GHz band - (5945 - 6425 @ 160), (23), NO-OUTDOOR, wmmrule=ETSI + (5945 - 6425 @ 320), (23), NO-OUTDOOR, wmmrule=ETSI # 60 GHz band channels 1-4 (ETSI EN 302 567) (57000 - 66000 @ 2160), (40) @@ -1733,7 +1733,7 @@ country SI: DFS-ETSI # short range devices (ETSI EN 300 440-1) (5725 - 5875 @ 80), (25 mW) # 6 GHz band - (5945 - 6425 @ 160), (23), NO-OUTDOOR, wmmrule=ETSI + (5945 - 6425 @ 320), (23), NO-OUTDOOR, wmmrule=ETSI # 60 GHz band channels 1-4 (ETSI EN 302 567) (57000 - 66000 @ 2160), (40) @@ -1754,7 +1754,7 @@ country SK: DFS-ETSI # short range devices (ETSI EN 300 440-1) (5725 - 5875 @ 80), (25 mW) # 6 GHz band - (5945 - 6425 @ 160), (23), NO-OUTDOOR, wmmrule=ETSI + (5945 - 6425 @ 320), (23), NO-OUTDOOR, wmmrule=ETSI # 60 GHz band channels 1-4 (ETSI EN 302 567) (57000 - 66000 @ 2160), (40) -- 2.40.1

Dold text
Permalänk
Medlem
Skrivet av KAD:

Jag trodde poängen med mesh11sd var att det bara var att installera och köra, den fattar om enheten är gateway mot internet eller inte och fixar all komplexitet med > 2 noder. Men det funkade alltså inte för dig? (Nej, jag har aldrig testat mesh11sd själv).

Det är så enkelt jag önskade att det var.

Scrollar man snabbt genom guiden jag länkade ovan (som visserligen börjar så tidigt som med att installera OpenWRT) så inser man ändå hur många steg det är man måste göra.

Jag har även gjort det med mesh11sd paketet som finns att ladda hem från System/Software som ska sköta allt automatiskt efter lite grundinställningar i filen, men även där får jag överbelastning.

Jag börjar dock misstänka att det kan vara någon enhet i mitt nätverk (server etc) som orsakar problemen eftersom det inträffat även efter jag följt guiden ovan till punkt och pricka.

Nu kom det helt nyligen en commit som ska rätta till någonting med felaktiga rates med 802.11s/Mesh - ska testa om jag märker någon skillnad.

Det jag saknar är en överblick i Luci där man kan se info om delarna i mesh-nätverket och kanske även belastningen, nu tittar jag på Status/Realtime Graphs men det hjälper mig inte så mycket.

Permalänk
Medlem
Skrivet av KAD:

Det pågår en diskussion på BananaPi-forumet där man hävdar att det saknas sköldar över radiokretsarna på BE14-kretskortet och att det gör att man får dålig SNR. Folk experimenterar med att sätta folie runt kretskortet och att dra antennerna långt från PCIe-bussen för att se hur det påverkar. Jag kan väldigt lite om radio, men jag konstaterar att prylen jag jobbar med har en sköld över sin radiokrets och att väldigt många av FCCs bilder också har det. Potentiellt kass hårdvara helt enkelt, vilket inte känns otroligt med tanke på hur usla kyllösningar Sinovoips "produkter" har. I mitt tycker verkar det verkligen vara utvecklingskort, något man köper för att köra naket på skrivbordet och utveckla mot. Tyvärr hittar jag inte tråden nu när jag letar.

https://forum.banana-pi.org/t/bpi-r4-wifi-range/
Denna tråd?

Permalänk
Medlem
Skrivet av KAD:

Jag visste inte heller, så jag surfade lite… regulatory.h beskriver bittarna som beskriver hur en Linux-driver beter sig, vilket i det här fallet beror på hur firmware som kör på kortet beter sig.

Self-managed skiter i kärnans regdb och landsval och kör efter eget tycke. Vilket skiljer sig mellan dina olika kort.

Intels location-aware-regulatory verkar vara det mest diskuterade exemplet på detta. Jag killgissar att konceptet är mest använt på kort avsett att vara STA, inte AP, och att man då låter firmware titta på AP:ns beacon och AP:n får stå för juridiken (vilket är juridiskt tveksamt). I det här driver/firmware-fallet har man kanske varit pragmatisk och ansluter till allt (inkl 320 MHz) som AP:n erbjuder om det skulle bli lagligt i framtiden. Många Linux-system kommer ju aldrig uppdateras, så det där kan tänkas vara ett försök att vara framåtkompatibel.

Knäckfrågan är väl om 320 MHz AP är lagligt eller inte i EU och Sverige.

I så fall, är Linux nu aktuella wireless-regdb bara dåligt uppdaterad? I så fall borde så klart någon ta tag i att hitta juridisk grund och skicka in en patch.

Jag ägnade en timme åt PTS dokument, ETSIs beskrivningar av sina dokument och EU-förordningar, men hittar inte i gyttret.

* @REGULATORY_WIPHY_SELF_MANAGED: for devices that employ wiphy-specific * regdom management. These devices will ignore all regdom changes not * originating from their own wiphy. * A self-managed wiphys only employs regulatory information obtained from * the FW and driver and does not use other cfg80211 sources like * beacon-hints, country-code IEs and hints from other devices on the same * system. Conversely, a self-managed wiphy does not share its regulatory * hints with other devices in the system. If a system contains several * devices, one or more of which are self-managed, there might be * contradictory regulatory settings between them. Usage of flag is * generally discouraged. Only use it if the FW/driver is incompatible * with non-locally originated hints. * This flag is incompatible with the flags: %REGULATORY_CUSTOM_REG, * %REGULATORY_STRICT_REG, %REGULATORY_COUNTRY_IE_FOLLOW_POWER, * %REGULATORY_COUNTRY_IE_IGNORE and %REGULATORY_DISABLE_BEACON_HINTS. * Mixing any of the above flags with this flag will result in a failure * to register the wiphy. This flag implies * %REGULATORY_DISABLE_BEACON_HINTS and %REGULATORY_COUNTRY_IE_IGNORE

Edit: Du kan ju kolla efter tillverkarens dokumentation om CE-märkning. Det är ju inte säkert att kortet ens är avsett att säljas i EU. Och om det är det så är det väk inte säkert att en taiwanesisk ingenjör fått juridiken rätt. Vem som helst kan ju sätta CE på vad som helst och intyga att det är rätt gjort. Även om tillverkare anlitar ett externt testinstitut är det inte säkert att testerna körs med slutgiltig driver/firmware — så är det där jag jobbar.

Angående den här frågan om 320MHz i Sverige råkade jag se en länk till en patch idag:

https://patchwork.kernel.org/project/linux-wireless/patch/202...

Permalänk
Medlem
Skrivet av Pulver:

Angående den här frågan om 320MHz i Sverige råkade jag se en länk till en patch idag:

https://patchwork.kernel.org/project/linux-wireless/patch/202...

Ah, någon annan som kom till samma slutsats (som diverse tillverkare) och som faktiskt orkade göra slag i saken.

Då behöver snart bara någon uppdatera till senaste regdb i OpenWrt också.

Permalänk
Medlem