Az előző részben kifejtettem fő problémáimat a WebOS rendszerrel kapcsolatban és eljutottam odáig, hogy frissült a tanúsítvány, emiatt ismét működött a Plex elérése, illetve a YouTube is reklámmentes lett.

A következő áthidalásra váró probléma nem közvetlenül a TV hibája, ugyanakkor nézhetetlenné teszi a médiafogyasztást Plexen. Konkrétan a TV beüzemelését követően kb két hónapig semmi baj nem volt a lejátszással, aztán egyszer csak elkezdett akadozni mindenféle lejátszás. Minden más tökéletesen ment, kivéve a Plex lejátszást.

Eleinte arra gyanakodtam, hogy egy szoftverfrissítéssel fogta vissza a gyártó a TV-t, nade ennyire, hogy egy 480p lejátszás se megy neki? Meg ugyanezt, sőt jobbat is tud Netflixen/YouTube-n teljesíteni?

Ekkor a hálózatra kezdtem gyanakodni, mivel valószínűtlen lett volna, hogy ennyire drasztikusan visszaesik a TV teljesítménye. A hálózati felállás nálam úgy néz ki, hogy Telekomos legnagyobb optikai csomag otthon, a TV az itthoni gigabites routeren kapcsolódik 5 GHz-en, a Plex szerver pedig a messzi Finnországban foglal helyet és gigabites uplinkkel rendelkezik. Elméletben nem kéne gondnak lenni, a gyakorlatban viszont valami nem kerek.

Mit tesz ilyenkor az egyszeri ember? Elkezd gondolkozni, hogyha bizonyos szolgáltatásokat rendben elér a készülék, akkor bizony vélhetően a szolgáltató oldaláról lehet routing probléma. Tehát az az útvonal, ahol a kéréseid jőnnek-mennek, túlzsúfoltak, mert a szolgáltató nem fizet eleget az adott külföldi ISP-vel, vagy szimplán misconfig van a rendszerben. Ezekről könnyen meg lehet győződni egy mtr teszt futtatásával (létezik windowsra is: [link]) először a szerver irányából az otthoni IP cím felé, majd fordítva, otthonról a távoli szerver IP címe felé. Én hagytam futni 1000 csomag erejéig, majd azt a meglepő eredményt kaptam, hogy a szerver felől otthoni irányba semmi gond nincs, viszont fordítva az 1000 csomagból ~330 elveszett. És nem csak egy routernél nem látszódott az a ~330 csomag, hanem egy bizonyos routertől kezdve lehetett látni, hogy egyik sem kapta meg ezeket a csomagokat, így a szerveremhez sem ért el nyilván. Nem kérdés, hogy akadozott az adás.

Majd indítottam egy mezei pinget otthonról a szerver irányába és nem meglepő módon ott is sok esetben soha nem érkezett meg a csomag. Ezek után készítettem egy mini webszervert egy 1 GB-os teszt fájllal a Finn szerveren és letöltöttem otthonról. Hát borzasztó lassan jött le. Bingó! Ez szolgáltatói hiba, mégpedig hatalmas.

Már készítettem is elő a telefont, hogy bejelentsem a hibát a Telekomnak. Az igazat megvallva már ekkor is voltak kétségeim, mivel a finnekhez látszólag a Telia nevű ISP-n keresztül routolna a Telekom minket, amiről köztudott, hogy egy Tier 1 szolgáltató, azaz a legdrágább tarifákkal dolgoznak. De nem úgy ismerem a Telekomot, mint aki ne foglalkozna rendesen a routejaival, így gondoltam egy próbát megér.

Vandán több lerázó kör után átverekedtem magam, majd végső elkeseredésében kapcsolt egy szimpatikus fiatalemberhez, akinek vázoltam a problémát. Hát, nem teljesen értette a routinggal kapcsolatos problémát, meg nem igazán tudta, mi az a routing, így elmagyaráztam neki a problémát, mert először azt hitte, hogy egyáltalán nincs internetem, majd azt, hogy minden irányba lassú az internet. Végül abban maradtunk, hogy mivel ez egy összetett probléma, írjam le az online bejelentő felületen a problémát, csatoljam az mtr logot és ők majd továbbítják a technikusok felé. Hát így is tettem.

Ez volt tavasz közepén. Azóta nem történt semmi... Egy ideig írogattak, hogy a hiba elhárítása folyamatban van, majd azt írták, hogy megoldották a dolgot, de az égvilágon semmi nem történt.

Gondolkoztam, hogy milyen egyéb opcióim vannak megszüntetni a problémát. A legkézenfekvőbb nyilván az lett volna, ha lemondom a finn szervert és átköltöztettem a vasat a németekhez, mivel oda a Deutsche Telekomnak hála remek peeringje van a Magyar Telekomnak is. Ugyanakkor kering az interneten egy vicces videó a finn szerverek előnyéről: [link]. Mégpedig az, hogy olcsó az áram és a hűtés és így jelentőset lehet vele spórolni Németországgal szemben. Nem akartam csak a Magyar Telekom miatt többet fizetni a szerverért.

Így a következő ötlet, hogy ruházzak be egy VPN szolgáltatásba, aminek van budapesti szervere és azon keresztül tegyem elérhetővé a szervert is hamar el lett vetve. Egyrészt ez is egy extra 5 eurót jelentett volna, illetve kipróbáltam és a budapesti szerverek általában igencsak le voltak terhelve. Nomeg nem csak Telekom irányból szoktam Plexezni, hanem ha kell külföldön is. Emiatt a Finnország -> Magyarország -> célország ugrás nem hangzik valami fényesen.

Utolsó megoldásnak maradt az, hogy valamilyen úton/módon az otthoni hálózattal kezdek valamit, hogy a finn szerverem irányába máshogy távozzon a forgalom. Ekkor jutott eszembe a Cloudflare egyik szolgáltatása, a Warp, ami lényegében pontosan erre a célra lett megalkotva. Van egy ingyenes csomagja, ami annyit ad, hogy wireguard protokollon keresztül kapcsolódsz a szervereikhez és rajtuk keresztül megy az internetes forgalmad. Általában ennek otthoni hálózaton nincsen létjogosultsága, meg vitatható, hogy egy amerikai adathörcsög számára mennyire célszerű az adatainkat kiadni, de ha nincs az embernek saját VPN-je, pl. egy repülőtéri wifin lógva nem rossz ötlet warpot használni.

Azt tudni kell róla, hogy nem tekinthető olyan szempontból teljes értékű VPN szolgáltatásnak, hogy míg egy átlagos VPN esetében minden meglátogatott szolgáltatás a VPN szerver IP címét látja, a warp esetében a szintén Cloudflare által hosztolt weboldalak ténylegesen a te IP címed fogják megkapni.

Számomra viszont tökéletes megoldásnak tűnt a dolog, mivel a Plex szerverem eleve titkosított HTTPS kapcsolatot használ, így a Cloudflare sem lát bele a forgalomba, ugyanakkor a legközelebbi warp szerver konkrétan a bixből elérhető, így konkrétan egyenesen Magyarországról, vagy ritkán Bécsből/Frankfurtból lépnék fel a Cloudflare hálózatára, amivel egyrészt nincs gondja a Telekomnak sem, másrészt a Cloudflare köztudottan egész normális peeringgel rendelkezik egy otthoni ISP-vel szemben.

Megvolt tehát a terv, ráadásul teljesen ingyenes is, így a warp mellett döntöttem. Felrakhattam volna a routerre is, de úgy döntöttem, hogy ha már van root a TV-n, felrakom közvetlenül arra.

Következzen tehát az írás lényegi része! A wireguard fordítása és beállítása a TV-n!

Természetesen mielőtt belevágtam volna a történetbe, elsőként átgondoltam, hogy mennyire bírná a TV a VPN témát, de arra jutottam, hogyha sikerül a wireguardot, mint kernelmodult betölteni, akkor vajmi kevés extra terhelés lesz a TV-n és mellette gyakorlatilag VPN-nel is képes lesz közel ugyanolyan netsebességet produkálni, mint anélkül.

Ezeket átgondolva, ugorhatunk a gyakorlati részre. Én a fordításhoz egy Fedora Szervert használok, de természetesen bármilyen más linuxos disztró megfelelő lehet, amennyiben x64 telepítés.

Elsőként szükségünk lesz a TV kernel forrásaira, amit az oldalukon keresztül tudunk letölteni: [link]. Fontos, hogy a pontos TV típusra keressünk rá és a megfelelő forrásokat töltsük le.

Ehhez hozzunk létre egy mappát:

mkdir ~/build/webos-kernel -p
cd ~/build/webos-kernel

Majd én a következőképp töltöttem le a fájlt (persze a kézzel letöltés és mappába másolás is működhet):

curl 'https://opensource.lge.com/fileMgr/downloadIdx/op/32LK6200PLA/508410/1' -X POST -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:94.0) Gecko/20100101 Firefox/94.0' -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8' -H 'Accept-Language: en-US,en;q=0.5' --compressed -H 'Content-Type: application/x-www-form-urlencoded' -H 'Content-Length: 0' -H 'Origin: https://opensource.lge.com' -H 'Connection: keep-alive' -H 'Referer: https://opensource.lge.com/osSch/list?types=NAME&search=LK6200PLA' -H 'Cookie: JSESSIONID=redacted; AWSELB=redacted' -H 'Upgrade-Insecure-Requests: 1' -H 'Sec-Fetch-Dest: document' -H 'Sec-Fetch-Mode: navigate' -H 'Sec-Fetch-Site: same-origin' -H 'Sec-Fetch-User: ?1' -H 'DNT: 1' -H 'Sec-GPC: 1' -o "webOS 4.0 GM_1.0.tar.gz"

A letöltés kicsi időbe fog telni, mivel a kiszolgáló nem éppen a leggyorsabb, de ha rendben lejött, csomagoljuk is ki (fájlnév eltérhet!):

tar xf webOS\ 4.0\ GM_1.0.tar.gz

Majd az ls parancs segítségével nézzünk körül a kicsomagolt állományban. Nekem egyetlen GM-r3201/ mappát hozott létre, azon belül pedig egy tucat csomag található:

[mrdini@hal-9000 GM-r3201]$ ls -la | wc -l
121
[mrdini@hal-9000 GM-r3201]$ ls -la | grep kernel
-rw-r--r--. 1 mrdini mrdini 146687748 Feb 6 2018 kernel-b153.tar.gz
-rw-r--r--. 1 mrdini mrdini 340944 Feb 6 2018 m3-mali-utgard-kernel.tar.gz

Innen lehet tippelni, hogy a kernel-b153.tar.gz lesz a kernel forrás, mivel jelentősen nagy csomag. Csomagoljuk ki:

tar xf kernel-b153.tar.gz; cd cd kernel-b153/

Itt találunk egy README.txt-t, ha minden igaz, hasonló tartalommal:

[mrdini@hal-9000 kernel-b153]$ cat README.txt
Kernel
******************

Compilation for webOS TV
========================

Compiler :
LGE provides the boot toolchain for webOS TV SW upon email request to opensource@lge.com.

How to compile :
$ Set the toolchain
$ cd kernel
$ make ARCH=arm m3_defconfig
$ make ARCH=arm modules -j8
$ make ARCH=arm MSTAR_UIMAGE=1 uImage -j8

Ahogy olvasható, felhívja a figyelmet, hogy a kernel forrás fordításhoz használatos toolchaint csak és kizárólag kérésre adják ki... Ugyanakkor a felesleges emailre várakozástól megkímél minket ez a közzétett toolchain projekt, mivel eddigi tapasztalataim alapján az összes LG WebOS TV armv7l soft float architektúrára épül, így ezt tökéletes lesz nekünk is: [link]

Telepítsük most ezt is. Fontos, hogy legyen python a hoszt gépen!

wget https://github.com/webosbrew/meta-lg-webos-ndk/releases/download/1.0.g-rev.4/webos-sdk-x86_64-armv7a-neon-toolchain-1.0.g.sh -O $HOME/webos-sdk-x86_64-armv7a-neon-toolchain-1.0.g.sh
chmod +x $HOME/webos-sdk-x86_64-armv7a-neon-toolchain-1.0.g.sh
$HOME/webos-sdk-x86_64-armv7a-neon-toolchain-1.0.g.sh

Várjuk meg, míg a telepítő végez, majd ahogyan az ő is ajánlja, adjuk ki a környezeti változók beállítására szolgáló shell parancsot:

. /opt/webos-sdk-x86_64/1.0.g/environment-setup-armv7a-neon-webos-linux-gnueabi

A $HOME/webos-sdk-x86_64-armv7a-neon-toolchain-1.0.g.sh fájl természetesen törölhető.

Most pedig térjünk vissza a kernelhez és kövessük az utasításokat a README-ből:

cd kernel/
make ARCH=arm m3_defconfig

Ezzel létrejött az a .config fájl, ami tartalmazza a TV-n futó gyári kernel összes opcióját.

Mindenekelőtt győződjünk meg arról, hogy a TV-n valóban pontosan ez a kernel verzió fut:

[mrdini@hal-9000 kernel]$ cat .config | head
#
# Automatically generated file; DO NOT EDIT.
# Linux/arm 4.4.84 Kernel Configuration
#
CONFIG_ARM=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_HAVE_PROC_CPU=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y

Azaz az itt látható esetemben 4.4.84-es verzió a tv-n futtatott uname -a kimenettel megyegyezik-e. Ha nem, akkor írni kell a gyártónak, hogy tessék kiadni a friss kernelt.

Megtehetnénk, hogy ezen a ponton továbbmegyünk a modulok fordítására, ahogy azt eredetileg én is tettem, de a későbbiekben felfedeztem, hogy esetemben két a wireguard modul számára elengedhetetlen kernel opciót nem tartalmaz a TV (elképzelhető, hogy más TV-k esetében ezzel nem lesz probléma, akkor lehet ugrani a wireguard fordításra):

[mrdini@hal-9000 kernel]$ cat .config | grep UDP_TUNNEL
# CONFIG_NET_UDP_TUNNEL is not set

A másik nagyon fontos dolog megnézni, hogy a gyári kernel képes-e modulok betöltésére:

[mrdini@hal-9000 kernel]$ cat .config | grep CONFIG_MODULES=
CONFIG_MODULES=y

Ha nem, akkor itt game over, ilyen esetben le kéne cserélni a TV-n a teljes kernelt. Esetünkben viszont egy y szerepel a sor mellett, tehát mehetünk tovább!

Tehát ezt is be kell majd állítanunk, amihez a legegyszerűbb, ha feltesszük a gépre az ncurses-dev(el) csomagot, majd kiadjuk a make menuconfig parancsot. Ezt követően egy viszonylag barátságos konzolos GUI tárul a szemünk elé, ahol számunkra a Networking Support menü lesz érdekes, azon belül pedig a Networking Options, majd a IP: Foo (IP protocols) over UDP opción állva nyomjunk egy M betűt, azaz érjük el, hogy betölthető modulként forduljon le.

Ha jól dolgoztunk, hasonlót kell látnunk:

[mrdini@hal-9000 kernel]$ cat .config | grep UDP_TUNNEL
CONFIG_NET_UDP_TUNNEL=m

Rendben, most térjünk vissza a readme lépéseihez, hiszen szükség lesz a kernelmodulok fordítására is az újonnan hozzáadott udp_tunnel miatt:

make ARCH=arm modules -j8

Pont beletrafáltak az LG-nél, mert 8 magos gépen fordítok, de ha kevesebb/több mag lenne a gépben, lehet a -j értékét a parancsban definiálni.

Ha szépen, hibamentesen lefutott a folyamat, nézzünk rá az eredményre:

[mrdini@hal-9000 kernel]$ readelf -h net/ipv4/udp_tunnel.ko
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: REL (Relocatable file)
Machine: ARM
Version: 0x1
Entry point address: 0x0
Start of program headers: 0 (bytes into file)
Start of section headers: 238328 (bytes into file)
Flags: 0x5000000, Version5 EABI
Size of this header: 52 (bytes)
Size of program headers: 0 (bytes)
Number of program headers: 0
Size of section headers: 40 (bytes)
Number of section headers: 33
Section header string table index: 32
[mrdini@hal-9000 kernel]$ readelf -h net/ipv6/ip6_udp_tunnel.ko
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: REL (Relocatable file)
Machine: ARM
Version: 0x1
Entry point address: 0x0
Start of program headers: 0 (bytes into file)
Start of section headers: 236180 (bytes into file)
Flags: 0x5000000, Version5 EABI
Size of this header: 52 (bytes)
Size of program headers: 0 (bytes)
Number of program headers: 0
Size of section headers: 40 (bytes)
Number of section headers: 31
Section header string table index: 30

Ha valaki nagyon biztosra akar menni, meg lehet nézni egy a TV-n betöltött modul esetén is, hogy egyezik-e a gyárilag a TV-n található kernel modul magic headerje a frissen forgatott modulokéval. Ehhez a TV-n kiadom az lsmod parancsot, majd találomra kiválasztom a listából a tfat modult például. Ezt követően megkeresem, hol található a fájlrendszerben ez a fájl:

root@LGwebOSTV:~# find / -name tfat.ko
/lib/modules/4.4.84-404.glacier.10/kernel/tfat.ko
/mnt/lg/res/lglib/tfat.ko

A TV-men nincs readelf parancs, de átmozgatva a gépre látható, hogy valóban megegyezik a magic header, tehát a kernelbe betölthető lesznek a moduljaink :

ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: REL (Relocatable file)
Machine: ARM
Version: 0x1
Entry point address: 0x0
Start of program headers: 0 (bytes into file)
Start of section headers: 378552 (bytes into file)
Flags: 0x5000000, Version5 EABI
Size of this header: 52 (bytes)
Size of program headers: 0 (bytes)
Number of program headers: 0
Size of section headers: 40 (bytes)
Number of section headers: 32
Section header string table index: 29

Jöhet a wireguard fordítása, ami ezen leírás alapján egy pofonegyszerű művelet: [link]

Telepítsük a cikk által említett függőségeket, ha még nem lennének fent, majd szedjük le a forrást gitről:

cd ~/buld/webos-kernel
git clone https://git.zx2c4.com/wireguard-linux-compat

Magát a modul fordító parancsot azonban egy kicsit módosítanunk kell, hogy figyelembe vegye a wireguard forrás, hogy mi a TV kernelére fordítanánk, nem pedig a hoszt géphez:

KERNELDIR=$HOME/webos-kernel/GM-r3201/kernel/kernel-b153/kernel make -C wireguard-linux-compat/src -j$(nproc)

Ha ez a parancs hibára futna, márpedig a cikk írása közbeni tesztelések közepette nekem hibára futott a fordítás, akkor a megoldás az, hogy 16 órája bekerült pár commit a modulba, ami miatt nem fordul le rendesen a modul. Ezeket visszafordítva menni fog:

cd wireguard-linux-compat/
git checkout 29747255f9672035ccf9cc310b7ff66b1f35f1d2
cd ..

Ezzel az utolsó modulunk is lefordult:

[mrdini@hal-9000 webos-kernel]$ readelf -h wireguard-linux-compat/src/wireguard.ko
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: REL (Relocatable file)
Machine: ARM
Version: 0x1
Entry point address: 0x0
Start of program headers: 0 (bytes into file)
Start of section headers: 4398352 (bytes into file)
Flags: 0x5000000, Version5 EABI
Size of this header: 52 (bytes)
Size of program headers: 0 (bytes)
Number of program headers: 0
Size of section headers: 40 (bytes)
Number of section headers: 47
Section header string table index: 46

Remek!

Már csak magát a wireguard-tools csomagot kell lefordítanunk. Ehhez adjuk ki:

git clone https://git.zx2c4.com/wireguard-tools
PREFIX="/tmp/usb/sda/sda1" make -C wireguard-tools/src -j$(nproc)

Ha ez is sikerrel lefutott, akkor hozzunk létre egy mappát, majd másoljuk bele a szükséges fájlokat:

mkdir pendrive/
cd pendrive/
cp ../GM-r3201/kernel-b153/kernel/net/ipv4/udp_tunnel.ko ../GM-r3201/kernel-b153/kernel/net/ipv6/ip6_udp_tunnel.ko ../wireguard-linux-compat/src/wireguard.ko ../wireguard-tools/src/wg .

Ezt követően szükségünk lesz még egy Cloudflare Warp konfigra is, amit a wgcf nevű projekttel tudunk a legegyszerűbben generálni: [link]

mkdir ~/build/wgcf
cd ~/build/wgcf
wget https://github.com/ViRb3/wgcf/releases/download/v2.2.10/wgcf_2.2.10_linux_amd64 -O wgcf
chmod +x wgcf
./wgcf register

Fogadjuk el a felhasználási feltételeket, aztán következhet is a config generálása:

./wgcf generate

Ez létrehoz az aktuális mappába egy wgcf-profile.conf fájlt, amire nekünk majd szükségünk lesz. Azonban ilyen formában csak a wg-quick lenne képes kezelni ezt a konfigot, így át kell alakítanunk wg kompatibilisre. Ezt nagyon egyszerűen meg tudjuk tenni, ha a build gépen fent van a wireguard-tools csomag (ne kérdezzétek, miért kell root a parancsnak):

sudo wg-quick strip wgcf-profile.conf > ~/build/webos-kernel/pendrive/wg.conf

Utolsó lépésként pedig térjünk vissza a ~/build/webos-kernel/pendrive mappába és készítsünk egy setup-vpn.sh fájlt a kedvenc szüvegszerkesztőnkkel és a következő tartalommal:

ip link add wgcf-profile type wireguard
$PWD/wg setconf wgcf-profile $PWD/wg.conf
ip -4 address add 172.16.0.2/32 dev wgcf-profile
ip -6 address add fd01:5ca1:ab1e:<Tölts ki a wgcf-profile.conf alapján>/128 dev wgcf-profile
ip link set mtu 1280 up dev wgcf-profile
ip -4 route add PLEXSZERVERIPCIME/32 dev wgcf-profile

Gyakorlatilag ez a pár parancs elegendő ahhoz, hogy létrehozza a wgcf-profile interfészt, beállítsa neki a konfigot, adjon neki IP címet és az MTU-t is megfelelően beállítsa. Az utolsó sorban pedig beállítom, hogy a Plex szerverem IP címét mindig a wgcf-profile interfészre routolja. Az összes többi forgalomhoz nem lesz használva a warp.

Ezek után a pendrive mappa tartalmát másoljuk egy tetszőleges pendrivera, és azt helyezzük a tv-be. Adjuk ki a következő parancsokat:

cd /tmp/usb/sda/sda1/
sh setup-vpn.sh

Ha minden jól megy és nem dob errort, akkor az ifconfig wgcf-profile parancs kiadását követően láthatjuk, hogy valóban működik az interfész és kapott IP-t:

root@LGwebOSTV:/tmp/usb/sda/sda1# ifconfig wgcf-profile
wgcf-profile Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:172.16.0.2 P-t-P:172.16.0.2 Mask:255.255.255.255
inet6 addr: fd01:5ca1:ab1e:redacted/128 Scope:Global
UP POINTOPOINT RUNNING NOARP MTU:1280 Metric:1
RX packets:6212264 errors:0 dropped:0 overruns:0 frame:0
TX packets:257262 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:8059346800 (7.5 GiB) TX bytes:26973504 (25.7 MiB)

Illetve a ./wg parancs is használható infók ellenőrzésére.

De a curl parancsot is használhatjuk tesztelni:

root@LGwebOSTV:/tmp/usb/sda/sda1# curl --interface wgcf-profile https://ifconfig.co/cdn-cgi/trace | grep warp
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 197 0 197 0 0 472 0 --:--:-- --:--:-- --:--:-- 474
warp=on

Sőt, a ping is működik:

root@LGwebOSTV:/tmp/usb/sda/sda1# ping -I wgcf-profile 1.1
PING 1.1 (1.0.0.1) from 172.16.0.2 wgcf-profile: 56(84) bytes of data.
64 bytes from 1.0.0.1: icmp_seq=1 ttl=64 time=11.8 ms
64 bytes from 1.0.0.1: icmp_seq=2 ttl=64 time=11.8 ms
64 bytes from 1.0.0.1: icmp_seq=3 ttl=64 time=10.7 ms
64 bytes from 1.0.0.1: icmp_seq=4 ttl=64 time=9.61 ms
64 bytes from 1.0.0.1: icmp_seq=5 ttl=64 time=9.83 ms
64 bytes from 1.0.0.1: icmp_seq=6 ttl=64 time=9.82 ms
^C
--- 1.1 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5008ms
rtt min/avg/max/mdev = 9.616/10.621/11.853/0.936 ms

Ezek után ha elindítunk egy filmet a Plexen, az valóban egy Cloudflare IP címet fog mutatni:

Egyelőre ez a megoldás még nem éli túl a rebootot, így olyankor mindig le kell futtatni a következő két parancsot:

cd /tmp/usb/sda/sda1/
sh setup-vpn.sh

De erre is lesz a közeljövőben megoldás. Illetve ha be van kapcsolva a gyors indítás+, vagy mifene, a TV soha nem kapcsol ki ténylegesen, csak a képernyőt pihenteti, illetve a hálózatot, a RAM marad aktív, tehát egész sokáig túléli a wireguard konfig. Hacsak persze nem rebootolunk kézzel, vagy húzzuk ki a TV-t.

Végezetül pedig szeretném felhívni a figyelmet, hogy NE próbálkozzunk meg egymással megosztott kernelmodulokat betölteni még ha azonos TV modellről van is szó, győződjünk meg róla, hogy azok minden szempontból kompatibilisek! Bár a kernel valószínűleg nem is fogja betölteni, ha más kernel verzióra lett fordítva, vagy épp a magic header nem egyezik, óvatosan!

Nade, mára ennyit! Így is picit hosszabb lett a cikk, mint terveztem.