PC Engines APU2C4 Small Board Computer tűzfal

Kezdetnek egy érdekes anomália:
az APU rúter és a DIGI szolgáltatói ONT optikai<-->RJ45 doboza között eddig közvetlen UTP volt. Régóta terveztem egy menedzselt szviccset közbeiktatni, amin egyszerűbben láthattam volna az APU rúter ki/bemenő forgalmát. Viszont valami pppoe protokoll furmányosság miatt, ha a szviccs-en keresztül kellene mennie a forgalomnak, a pppoe kapcsolat nem épül fel. Erre itt van a másik fórum szál:
https://hup.hu/node/158836

Illetve a legnagyobb gond ezzel az eszközzel, hogy pppoe típusú internet kapcsolaton elvérzik 100 megabit fölött (pl. DIGI 1 gigabit-et nem bírja kezelni):
https://hup.hu/node/159928

Néhány kiindulási oldal:
https://forum.netgate.com/topic/95148/pc-engines-apu2-experiences
https://www.reddit.com/r/networking/comments/6upchy/can_a_bsd_system_re…
https://github.com/ocochard/netbenches/blob/master/README.md

Serial port paraméterek a csatlakozáshoz konzolon
bitrate:115200
8-N-1 --> azaz (8) data bits, no (N) parity bit, and one (1) stop bit, no HW flow control

Maga a hardver
https://pcengines.ch/apu2c4.htm
(de 2018.10 óta van újabb PCB revision-je: https://pcengines.ch/apu2d4.htm)
2020 óta meg van már "E" revision is: https://pcengines.ch/apu2e4.htm

3 i210AT LAN (4 TX&RX hardware queue) / AMD GX-412TC CPU / 4 GB DRAM (ECC-t tudja a hardware!)

van APU3/APU4 modell is, bár mindegyiken tökugyanaz az AMD embedded CPU van:
https://pcengines.ch/apu3c4.htm
https://pcengines.ch/apu4c4.htm

Mi a különbség APU2 és 3,4 között:
https://github.com/pcengines/apu2-documentation/blob/master/docs/apu2_v…
https://github.com/pcengines/apu2-documentation/blob/master/docs/apu2_v…

power/reset/watchdog header changed
LPC header changed to debug
RXD3/TXD3 wired to PCIe x1 expansion
SIM switch added
use of mPCI slots explicitly specified
fan control removed
SIMSWAP pin added
APU straps changed
I'm not sure about mSATA changes, but it looks something is different
internal us2.0 header added
some PCIe connections removed (page 5)

Egy kis fővállalkozó-alvállalkozó kavarás svájci módra:
A nyákot a PCENGINES.CH tervez(tet)te és gyárt(at)ja. De FIRMWARE/BIOS-t nem írtak hozzá! Minek az, ugye?! Helyette kiszervezték a melót egy lengyel cégnek (3MDEB), akik a pcengines logó mögé állva a tényleges szoftver munkát csinálják. Tehát a pcengines-től veszel egy nyákot, ami valójában használhatatlan bármiféle BIOS nélkül. Felmész githubra letölteni a pcengines nevű tárolóból a BIOS-t, amit valójában egy 3rd party cég tart karban, a pcengines megbízásából. Ha fagy a board pl. rebootkor, akkor mehetsz a githubra szupportért, a (valójában 3mdeb alkalmazottak) github SZOFTVERkarbantartók majd azt mondják ez egy hardverhiba és ők azért nem felelősek. Ugye papíron a pcengines-sel beszélsz, de ha baj van akkor ők nem is pcengines alkalmazottak. A pcengines meg szarik a vevők fejére, emailre nem válaszolnak, githubon nem ők képviselik a saját terméküket, csak ledelegálták egy külsős cégnek, ők meg bújkálnak a háttérben Glattbrugg-ban.
Az alap órajel 1Ghz -> Turbo 1.4 Ghz váltás sem működik sehogy! Pedig ilyen alacsony órajelnél jól jönne minden extra erő (akár +40%!) amit a CPU-nak papíron tudnia kellene, szó nincs itt semmilyen overclock-ról! Kit hibáztatsz? A nyáktervező pcenginest, mert a CPU nem hozza a gyártói specifikációt, vagy a 3mdeb-et, akik nem tudnak hozzá firmware-t írni h. bekapcsolják a turbo módot? Az ECC támogatás detto: nem működött a nyák piacra dobásától számítva kb. másfél évig (más okok miatt megbízhatóan még a mai napig sem). A nyáktervező pcengines a hibás, mert a CPU nem hozza a specifikációban leírt tulajdonságot, esetleg valamilyen szükséges komponenst nem terveztek a board-ra? Vagy a 3mdeb a hibás, akik nem tudnak hozzá firmware-t írni h. bekapcsolják a fícsört? Vagy mindkettő hibás a saját felében az egész össze nem álló megoldásnak? Na ezért nem szabad ilyen cuccot megvenni ilyen simlis felállásban! Egyetlen cég tartsa a hátát az összes hw+sw hibákért, ne a szerencsétlen vásárlót pingpongoztassák a 2 cég melósai egymás között mindig a másikra mutogatva! Ez kb. hasonló felállás, mint amikor elszaródik a gyári eredeti GPS az új kocsidban, és az audi/bmw/mercedes/stb. mutogat majd a bosch-ra v. más random beszállítóra, h. rajta verjem le a garanciális panaszomat. Holott nekem ugye a bosch-al semmilyen jogi kapcsolatom nincs, az autógyártónak fizettem egy általuk készregyártott és értékesített egyben-termékért, nem részegységek tételesen megkülönböztetett kupacáért. Szóval megvan ez a cigánykodás máshol is sajnos.

Update 2023.04.21: a PCENGINES lehúzta a rolót. Az APU2-3-stb. boardok EndOfLife-ba kerültek, az AMD '23 H2 után már nem szállít több ilyen procit. Mivel (mondásuk szerint) megfelelő Zen-es utódot nem találtak embedded és passzív hűtésű kivitelben, felhagynak a további termékekkel. https://pcengines.ch/eol.htm

Haladjunk tovább!

BIOS (Firmware): az opensource Coreboot-ot futtatja (https://doc.coreboot.org/releases/index.html)
a coreboot payload-ját pediglen SeaBios-nak hívják: https://www.seabios.org/Releases

Update 2019.07.12: közeleg az UEFI támogatás a TianoCore nevezetű project segítségével

innen lehet letölteni az APU2/höz igazított mindenkori legutolsót: https://pcengines.github.io/
- mainline release: v4.9.x.y (ahol x a coreboot verzió, y pedig a PC engines APU specifikus release)
Changelog: https://github.com/pcengines/coreboot/blob/release/CHANGELOG.md
- legacy release: 4.0.z (ez most 4.0.24-nél jár, hamarosan meg akarják szüntetni, és áttérni végleg a mainline release-re).
Changelog: https://github.com/pcengines/coreboot/blob/coreboot-4.0.x/CHANGELOG.md
Valami régi bug miatt ezt (=legacy) ajánlják BSD alapú (pfSense, Opnsense) OS-hez a mainline-al szemben: http://pcengines.ch/howto.htm#bios
kérdés így 2018 H2-ben ez még érvényes-e: http://www.pcengines.info/forums/?page=post&id=6D2EEC40-5928-463B-8BAE-…

Update 2018.11.09: úgy tűnik még mindig érvényes a legacy ajánlás, elég sok issue jött ki az új 4.8.0.5 környékén (fagyások, reboot hang, cpu underclocking stb), azaz lesznek még további 4.0.x-ek.
Update: 2019.07.12: már pár hónapja mainline 4.9.x-et használok, nincs vele gond, szerintem tesztelés után át lehet térni nyugodtan a legacy-ról.

Seabios payload changelog:
https://github.com/pcengines/seabios/blob/apu_support/CHANGELOG.md

Sortbootorder payload changelog:
https://github.com/pcengines/sortbootorder/blob/master/CHANGELOG.md

Pfsense install guide: https://github.com/pcengines/apu2-documentation/blob/master/docs/pfSens…

BIOS flash-eléshez Tinycore Linux-al érdemes: http://pcengines.ch/howto.htm#TinyCoreLinux --> itt van windows alá PCengines által összeállított tinycore bootolható image
a fentebb letöltött APU_X.Y.Z.rom BIOS-t odamásolni Tinycore mellé pl. egy USB pendrive-ra, bebootolni a pendrive-ról, majd a futó tinycore OS CLI-ből a következő parancsot futtatni:
apu2-board:~/apu2 # flashrom -w apu2_v4.x.y.rom -p internal
Note1: előtte érdemes lehet lementeni az aktuális BIOS-t backup céljából, ennek a szintaxisát a flashrom mindenféle paraméterek nélkül futtatva megmondja
Note2: a legacy szériából a 4.0.15-től régebbi v. mainline szériából a 4.6.7-től régebbi BIOS-t NE tegyél fel rá, mert vmit elbarmoltak a vendor string-ben, és nem ismerte fel az alaplapot helyesen. Az említett verzióktól újabbakban már javítva lett ez a hiba. Ha mégis ilyen régi BIOS-od fut,akkor force-olni kell az update-t, így:

flashrom -w apu2_v4.x.rom -p internal:boardmismatch=force

Note3: 4.8.0.4-ig bezáróan bugos a dinamikus freq. állítás, pl. Freebsd-n boot után rővid idővel beáll 600Mhz-re, nem emeli fel 1Ghz-re terheléskor sem. 4.8.0.5 óta elismert bug, a known issue-nál már szerepel, de 4.9.0.1 javította végre!
https://github.com/pcengines/coreboot/issues/196

Update 2021: de aztán megint visszatér: https://github.com/pcengines/coreboot/issues/457

Az AMD nem ad ki ehhez a platform-hoz hivatalosan semmilyen CPU microcode update-et:
https://github.com/pcengines/apu2-documentation/issues/75

Update 2018.12.07 de most valami történni látszik:
https://github.com/pcengines/apu2-documentation/blob/master/docs/microc…
úgy néz ki "DIY fordítsd magadnak" módban lesz csak lehetséges, kész binárisba nem teszik bele, mert vmi ruszki lopta össze és publikálta a bináris blob-ot

További kapcsolódó baljós microcode update háttér infrastruktúra bajok Freebsd alatt:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192487
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225173
https://forums.freebsd.org/threads/introducing-cpupdate-a-microcode-too…
https://www.thomas-krenn.com/en/wiki/Update_Intel_Microcode_on_FreeBSD

Update 2019.07.12 Freebsd12.0-tól van már OS támogatás a kernel boot előtt betöltetni a microcode update fájlt. Ld. feljebbi linkek. Mivel ez még a kernel boot előtt történik, a CPU feature flag detektálás helyes lesz (látható lesz a Meltdown és Spectre nevű hibáknak a CPU-szintű workaroundja). Nem úgy, mint amikor már a futó kernel után tölti be egy service az új microcode-ot, és ez elvileg már nem látszik (nembiztos h. ez igaz).

CPU
papíron ez a CPU van benne:
AMD GX-412TC

dmesg-ben ez jön át belőle:
CPU: AMD GX-412TC SOC (998.15-MHz K8-class CPU)

az AMD állítása szerint ezt tudja (de ez csak valami marketing promó anyag, nem technikai specifikáció):
https://www.amd.com/Documents/AMDGSeriesSOCProductBrief.pdf --> 1.0Ghz/1.4Ghz

(Úgy tűnik "Alap/Turbó" órajel a megfejtés. Sakkozza ki a hülye ügyfél mi az igazság!)

Egy specification lista van még gugli szerint, ahol szerepel:
https://www.amd.com/en/products/specifications/embedded/

Model: GX-412TC
Product Type: CPU
Family: AMD Embedded G-Series Processors
Line: 2nd Generation G-Series SOC
OPN: GE412TIYJ44JB
TDP: 6W
CPU Type: Jaguar+
CPU Base Freq.: 1GHz
CPU Max Freq.: 1.4GHz
# of CPU Cores: 4
Security Processor: No
Total L2 Cache: 2MB
System Memory Type: DDR3
DDR3 Rate (Max): 1333 MHz
ECC: Yes

vagy itt: https://www.amd.com/en/product/7426

A BIOS írói (3mdeb) sem tudják pontosan, a pcengines fórumán a szokásos maszatolás megy:
http://www.pcengines.info/forums/?page=post&id=7D3ECCD1-AFFB-441C-9527-…
-->
"Yes, in theory the CPU should be able to boost speed when not all cores are loaded.

In practice we have not been able to achieve this. No meaningful help from AMD, I'm afraid."

A netgate/pfsense fórumán is csak találgatja mindenki:
https://forum.netgate.com/topic/133656/did-i-just-overclocked-my-apu2c4…

Update 2018.11.08: Valami haladás már látszik, a coreboot 4.8.x-ben előjött CPU downclock bug kapcsán született egy elemzés, ebben már szerepel 1.4 Ghz, mint Turbo boost órajel.
https://github.com/pcengines/apu2-documentation/blob/master/docs/debug/…

Update 2019.02.10: úgy tűnik hamarosan lesz "core performance boost (CPB)" == turbo clock support 4.0.24 / 4.9.0.2-től:
https://github.com/pcengines/coreboot/blob/coreboot-4.0.x/CHANGELOG.md
https://github.com/pcengines/coreboot/blob/release/CHANGELOG.md

Update 2019.02.18: Végre felraktam a múlt heti 4.9.0.2 BIOS-t. A turbo hozott egy szép +40% növekedést az 1-szálú openssl speed testben (280 mb vs 205mb). De a PPPOE-letöltési sebesség továbbra se megy 20-25 mb/sec fölé. Hát ez ennyit tud. Az meg eleve agyhalál, h. intelnél a turbo simán látszik az órajelben. AMD-éknél meg nem, ugyanúgy csak az 1000 Mhz-et írja ki, mint előtte, de a valóságban 1 mag 1400-on pörög! Aki a kódjának a futásidejét v. időzítését az órajelhez igazítja, nagyokat fog lesni.

A hivatalos benchmarkolók is hasonló vegyes eredményekre jutottak:
https://teklager.se/en/knowledge-base/apu-pfsense-throughput-bios-compa…
https://3mdeb.com/firmware/amd-cpu-boost/

Hyper-Threading: papíron úgy tűnik tudja a HyperThreading-et, legalábbis dmesg szerint ez látszik:

CPU: AMD GX-412TC SOC (998.15-MHz K8-class CPU)
Origin="AuthenticAMD" Id=0x730f01 Family=0x16 Model=0x30 Stepping=1
Features=0x178bfbff FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT

Akkor ez azt jelenti h. a CPU 4 core == 8 thread? Úgy tűnik nem. Az AMD úgy értelmezi a HTT-t, hogy ha single core CPU, akkor HTT flag=0, ha multi-core a CPU, akkor HTT flag=1. Itten van az Intel féle értelmezés:
https://www.intel.com/content/www/us/en/architecture-and-technology/64-…
Table 3.8, 3.11

ECC RAM: a pcengines bekamuzta az egész ECC támogatást az elején. Az igazság h. 2018 októberig valójában deaktivált volt az ECC
http://pcengines.ch/apu2.htm --> DRAM 2 or 4 GB DDR3-1333 DRAM, with optional ECC support
ha viszont elmész ide: http://pcengines.ch/apu2c4.htm -->
"apu2c4 = 3 i210AT LAN / AMD GX-412TC CPU / 4 GB DRAM "

ill. lejjebb:
Specification: "DRAM: 2 or 4 GB DDR3-1333 DRAM"

itt már 1 szó nem esik semmilyen ECC támogatásról. A hivatalos fórumon is megy a maszatolás róla már 2 éve:
http://www.pcengines.info/forums/?page=post&id=E35B5D34-262B-480E-9887-…

Update: 4.8.0.5-ben végre megjelent az ECC támogatás, és talán már működik is. Itt a blog hogyan lehet róla meggyőződni saját szemmel:
https://3mdeb.com/firmware/enabling-ecc-on-pc-engines-platforms/

Update: legacy 4.0.23-ba is végre backportolták az ECC-t.

Fontos: a 2GB RAM-os APU2C0,APU2D0/ APU2C2,APU2D2 board-ok nem tudnak ECC-t már a hardver miatt sem, csak a 4GB RAM-os APU2C4 / APU2D4 boardra szerelték az extra modult. Természetesen ezt is csak vmi eldugott helyen írják, sehol máshol nincs megemlítve ez az "apróság".

Opnsense: a tűzfalszoftver amit a vasra végül feltelepítesz
Note: ez nem egy tisztán GENERIC kernel-t futtató FreeBSD disztrib, hanem inkább egy buherált HardenesBSD. Azaz a FreeBSD levlistákon elhajtanak ha OS issue-kat akarsz bejelenteni ott.

Update 2021.04.30: úgy tűnik észhez tértek, 2022 januártól visszatérnek standard Freebsd-re: https://forum.opnsense.org/index.php?topic=22761.0

Opnsense verziószámozás: évente 2 main release jön ki, ÉV.HÓNAP főverzió formátumban
pl. 18.1 --> 2018 januári
18.7 --> 2018 júliusi
minor verzió pedig kb. 2-hetente, ÉV.HÓNAP.buildnumber, pl. 18.1.13, ez a legutolsó 2018 július végén a 18.1 production-ből, ezt követi majd a 18.7.0.
Letölteni ált. csak a buildnumber=".0"-t lehet telepítő ISO-ban, a .1, .2 stb. azt mindig online internetes upgrade formájában tölti le (CLI-ből v. web GUI-ból)

Opnsense release announcements:
https://forum.opnsense.org/index.php?board=11.0

Opnsense changelog: több helyen is van, nem mindig vannak szinkronban...
Ezeken a helyeken fordul elő Opnsense changelog: https://docs.opnsense.org/manual/how-tos/changelog.html
Ez tűnik a leginkább hitelesnek: https://github.com/opnsense/changelog/tree/master/community
Ez elmaradozik, és hiányos is: https://docs.opnsense.org/releases.html

--- MEMÓRIA/RAM stats, OS-en belül ---

Mennyi memóriát lát a freebsd, mire használja, mennyi maradt szabadon?
https://www.cyberciti.biz/faq/freebsd-command-to-get-ram-information/

--> innen ez tűnik a legpofásabbnak:
fetch https://raw.githubusercontent.com/ocochard/myscripts/master/FreeBSD/fre…

--- DISZK, FÁJLRENDSZER , LOGGING ---
Diszk aktivitás statisztika

gstat -p -I 1s
iostat -d -t da -h
systat -iostat

TRIM support (SSD-hez)

az SSD támogatja?
camcontrol identify /dev/ada0

--> a kimenetben:
Data Set Management (DSM/TRIM) yes

De az FS is használja-é?
tunefs -p /

--> a kimenetben:
tunefs: trim: (-t) enabled

kézzel force-olni a TRIM/kipucolás lefuttatását: nincs rá külön util, csak FSCK részeként tudja (annak minden következményével, pl. sokáig fut / singleuser módban érdemes / mountolatlan FS-en stb.)
fsck_ffs -E /

Tmpfs: Memory File System (MFS)

Mivel SSD-n van a rendszer, a /var/log-ba folyamatosan írkál, ezért jó volna nem kinyírni idő előtt az SSD-t. Megoldás: a /var és a /tmp (akár egymástól függetlenül is!) mehet RAMDISK-re ("tmpfs" típusú fájlrendszert fog neki létrehozni, reboot is kell hozzá első alkalommal), ezáltal végig a memóriában lesz írás-olvasás, szélsebes és nem az SSD-t gyilkolja. Természetesen a /var + /tmp osztottan használja a RAM-ot, mindkettő azt fogja hinni a teljes szabad RAM felett rendelkezik.
A "df -h" teljes méretnek/elérhető szabad területnek mindig az aktuális szabad RAM függvényében fogja mutatni az értéket, azaz dinamikusan nő/csökken a filerendszer teljes/szabad mérete.

Hátrányok:
- mivel RAM-ban tárolja az összes itt létrehozott fájlt, reboot-kor a TELJES tartalom elpárolog, azaz minden history és régi log megszűnik létezni.
- ha valami logging v. tmp-be író szkript elszabadul, tele tudja írni végsősoron a RAM-ot, így akár crashelhet is az egész OS. Elvileg lehetséges a "tmpfs" teljes méretét korlátozni pl. fstab-ból, de ehhez nincs opció opnsense-ben, kézzel piszkálni meg rizikós, nem derült ki nekem h. a következő update felülcsapja-e a kézi módosításomat.

Üres file létrehozása tetszőleges mérettel:
dd if=/dev/zero of=/tmp/testfile bs=1m count=100 --> pl. 100Mb fájl létrehozása, a tartalma csupa 0

LOGGING
Melyik logfájl hol bújik a GUI-n, ill. a filerendszerben:
https://docs.opnsense.org/manual/logging.html

Update 2020.11: a v20.7 óta a Circular Logging (CLOG) rákerült a kilövési listára, deprecated, a jövőben bármikor megszűnhet. A syslog-ng-t tolják 20.7 óta a CLOG helyett. Ennek köszönhetően az 1 sorral fentebbi wiki cikkből is szó nélkül eltüntették az ott korábban hasznosan szereplő logfile-ok nevét, és elérési útját. Szóval muszáj vagyok kikopizni h. archiválva legyen későbbiekre:

/var/log/*.log, a nevéből kell kideríteni melyik mit tartalmazhat.

Plain View   :menuselection:`Firewall --> Log Files --> Plain View`   *Just the plain contents how **pf** logs into **filter.log** *
Log files on file system:
/var/log/filter.log (clog)

Wireless         :menuselection:`Interfaces --> Wireless --> Log File`         *When using wireless features of OPNsense you find the logs here*
Point-to-Point   :menuselection:`Interfaces --> Point-to-Point --> Log File`   *PPP dialup logs like PPPoE are found here*
Log files on file system:
/var/log/wireless.log (clog)
/var/log/ppps.log (clog)

 

Unbound DNS           :menuselection:`Services --> Unbound DNS --> Log File`           *Unbound resolver logs can be found here*
Web Proxy             :menuselection:`Services --> Web Proxy --> Log File`             *Squid access.log, store.log and cache.log*
Log files on file system:
   /var/log/portalauth.log (clog)
   /var/log/dhcpd.log (clog)
   /var/log/dnsmasq.log (clog)
   /var/log/haproxy.log (clog)
   /var/log/ntpd.log (clog)
   /var/log/suricata.log (clog)
   /var/log/resolver.log (clog)
   /var/log/squid/access.log (text)
   /var/log/squid/cache.log (text)
   /var/log/squid/store.log (text)

Gateways                  :menuselection:`System --> Gateways --> Log File`   *Lists Dpinger gateway tracking related log messages*
Routing                   :menuselection:`System --> Routes --> Log File`     *Routing changes or interface events*
Log files on file system:
   /var/log/system.log (clog)
   /var/log/configd.log (clog)
   /var/log/lighttpd.log (clog)
   /var/log/pkg.log (clog)
   /var/log/gateways.log (clog) Note: By default gateway monitoring is disabled, so the log will be empty.
   /var/log/routing.log (clog)

Ha a Circular Logging be van kapcsolva, akkor CLOG paranccsal lehet CLI-ből olvasni a logfájlokat, nem CAT-al:

You can view the CIRCULAR logfile contents via CLI with:

clog /path/to/log

or follow the contents (a.k.a TAIL) via:

clog -f /path/to/log

--- Network interfészek, tűzfal, egyéb network service-ek --
LAN LED:
intel igb driver támogatja a vizuális azonosítását az egyes fizikai LAN interfészeknek (villog a státusz LED az RJ45 csatlakozónál sárgán)
https://www.freebsd.org/cgi/man.cgi?query=igb&apropos=0&sektion=4&manpa…
villogás bekapcsol: echo f2 > /dev/led/igb0
villogás kikapcsol: echo 0 > /dev/led/igb0

Network interfészek forgalmi statisztika
systat -ifstat

Default gateway availability tracking
Jelez, ha nem tudja elérni (gyk. pingelni == csak ICMP ECHO-t tud perpill használni, TCP SYN v. más metódust nem) a default gateway-t, vagy más tetszőleges alternatív IP címet. Régen "apinger" csinálta, 19.1 óta lecserélték "dpinger"-re. By default nem aktivált, ilyenkor a dashboard-on hazudik a mindig zöld ONLINE felírat, és a 0 msec RTT statisztika. Bekapcsolni itt kell:
System \ Gateway \ Single -> select my PPPOE gateway -> edit properties -> Disable gateway monitoring : This will consider this gateway as always being "up". Itt kell kiszedni a pipát, innentől valódi monitoringon alapul az ONLINE/OFFLINE státusz a dashboardon. Illetve mellélhatásként a /var/log/gateways -ben gyűlik a dpinger üzenetei.

Opnsense beépített tűzfal: Packetfilter (pf)
egy dummy guide: http://srobb.net/pf.html
https://www.freebsd.org/doc/handbook/firewalls-pf.html
https://www.cyberciti.biz/faq/how-to-set-up-a-firewall-with-pf-on-freeb…
https://calomel.org/pf_config.html

https://forum.opnsense.org/index.php?topic=5789.0
-> pf rule "quick" : ez jelenti az exception-t, azaz ilyen típusú szabály esetén itt megáll a kiértékelés. Amúgy meg az utolsó matching rule érvényesül (ez a "last matching rule wins" tényleg igaz?)

"pfctl -s info" --> megmutatja a state lookup-ok számát forgalom közben

pfctl -d --> disable pf
pfctl -e --> enable pf
Note: a pf végzi a NAT-olást, így a "pf disable" kinyírja a NAT-ot is azonnal!

GUI-n: Firewall\Settings\Advanced\Disable all packet filtering
(Warning This will convert into a routing-only platform!)

Kikapcsolni csak-NAT (pf enabled marad):
Firewall\NAT\Outbound\Disable outbound NAT rule generation (outbound NAT is disabled)

Interfaces \ WAN \ Block private networks | Block bogon networks:
itt lehet pf-ben blokkolni olyan IP subnet-eket, amikről biztos nem fogsz legitim forgalmat kapni. Pl. publikus WAN IP esetén minimum gyanús ha egy privát IP tartomány akar WAN-on keresztül kommunikálni. A bogon pedig olyan kategória, amibe fenntartott (de nem RFC1918 == 10/8, 172.16/12, 192.168/16) vagy még senkinek ki nem osztott IP tartományok tartoznak.
Ha a "block private" be van kapcsolva, akkor a CGN IP tartományokat is blokkolja! Pl. DIGI-nél bele lehet futni, ld. itt hup-on is volt téma DIGI hálózaton futtatott szervert DIGI-s előfizetők nem érnek el, ha CGN mögül jönnek.

A defult deny, block private, block bogon rule-ok loggingját a Settings\Logging alatt lehet állítani, nem a "Firewall" menu alatt!

Routing
https://www.freebsd.org/doc/handbook/network-routing.html

"netstat -r" --> kiírja a route táblát

"route add default 192.168.1.1" --> default gw megadása. Note that manually added routes will not survive a reboot!

Enable IP forwarding:
in /etc/rc.conf, add this line:
gateway_enable="YES" # Set to YES if this host will be a gateway
Fontos: opnsense alatt NINCS /etc/rc.conf fájl. Helyette /etc/rc.conf.d/ könyvtár van, alatta a különböző service-k saját alkönyvtárai. Van olyan, hogy /etc/defaults/rc.conf de ezt nem szabad szerkeszteni! Szóval ez itt inkább csak jótudni infó, mintsem gyakorlati megoldás.

To enable routing now, set the sysctl(8) variable "net.inet.ip.forwarding" to 1. To stop routing, reset this variable to 0.

DHCP
DHCP kliens lease fájl (ha WAN = igb0 = a rúter maga DHCP kliens az internetszolgáltató felé):
cat /var/db/dhclient.leases.igb0
DHCP szerver lease fájl (a rúter DHCP szerver a LAN kliensek felé):
cat /var/dhcpd/var/db/dhcpd.leases

Nézd meg ezt: /var/dhcpd/etc/dhvpd.conf hogy a "conflict detection" true vagy false. Ha be van kapcsolva, megpróbálja pingelni azt az IP-t amit utána kiosztana, hogy  iztosan szabad-e. Ez pár mp. késleltetést okoz a dhcp kliens oldalán mielőtt megkapná a kért IP használati jogát a válasz üzenetben a dhcp szervertől.

 

DNS/name lookup
https://forums.freebsd.org/threads/solved-freebsd-10-sysinstall-nslooku…

névfeloldás helyben tesztelésére "nslookup" nincs --> helyette freebsd 10 óta "host" van: "host google.hu"
Kézzel megadva egy non-default DNS szervert: "host google.hu 8.8.8.8"

"dig" helyett --> "drill"

Unbound
Alaptelepítés része az "unbound" rekurziv name server, ezért esélyes h. az /etc/resolv.conf-ban első helyen a szerver önmaga szerepel (127.0.0.1). Ekkor az unbound konfigjából ("cat /var/unbound/unbound.conf") kell kideríteni h. melyik forwarder-nek küldi tovább a kérést, vagy jólnevelt rekurziv nameserver módjára rohan a root nameserverekhez, és maga jár utána mindennek, a szolgáltatótól kapott name serverekkel nem foglalkozik (biztos nem?).

lokális Unbound példányhoz hozzáférés (statisztika/konfigurálás)
-> "unbound-control -c /var/unbound/unbound.conf stats_noreset" // -c után meg kell adni az unbound config fájl elérhetőségét, különben vmi default-ra hivatkozva azt mondja a remote access nem elérhető, és timeout után kihajint a shell-be
// a sima "stats" reseteli az összes countert!

loggolni melyik kliens küldte a request-et? unbound.conf-ba:
log-queries: yes
// így nem kell felesleges verbosity szint növelés

-> "unbound-control -c /var/unbound/unbound.conf dump_cache" --> kilistázza milyen rekordok vannak a lokális cache-ben

DNS blacklist hosts file importálás unbound-ba:
fájlt letölteni: "http://pgl.yoyo.org/adservers/serverlist.php?hostformat=unbound&showint…"
bemásolni WinSCP-vel (protokoll "SFTP" legyen NEM pedig "SCP"!) ide --> /var/unbound/unbound_advertisement_serverlist.txt
ezt a sort bekopizni Services\Unbound\ "custom options" alá:
include: /var/unbound/unbound_advertisement_serverlist.txt
-> fontos: valószínűleg chroot miatt az include fájl-nak direktben ugyanabban a könyvtárban kell lennie (symlink-el se mutathat ki chroot gyökérből!) mint az unbound root (/var/unbound) v. alatta levő szinten
-> fontos2: ha a /var tmpfs -> nem lesz ott az include fájl reboot után. Akkor pedig az unbound nem fog elindulni. Szóval syshook script kell bemásolja a txt fájlt tmpfs mountolás után, de még unbound service start előtt.

Bridge interface
Bridge virtuális interface létrehozása LAN-on több fizikai interface (pl. igb1+igb2) összefogásával:
https://docs.opnsense.org/manual/how-tos/lan_bridge.html
hátrány: a bridge interface-i között folyó forgalom mind átmegy a CPU-n, még ha nem is érinti sem source sem destination az opnsense dobozt (csak transit forgalom) --> kb. ugyanakkora terhelést rak az opnsense-re mintha ténylegesen fel kellene dolgoznia (pl. routing / NAT / firewalling). Ez a hátrány a HW-ból L2-switchinghez képest.

show MAC address table: "ifconfig bridge0 addr"

Óránkénti / napi / heti / havi forgalmazott adatmennyiség
--> "vnstat" plugin lett 18.7.7 óta!
note: csak tx/rx/total bontás van, busy-est host v. részletes statisztika per IP nincs
-> /var alatt tárolja a statisztikát, tmpfs esetén reboot eltünteti mindet.

Update 2019.03.08: 19.1.3-al megjött a perzisztens vnstat database!
Valamint ha vnstat db megkurvul (nálam 19.1.7 óta konzisztensen minden reboot után), lett a Services\vnstat alatt egy Reset gomb, ez törli a db-t. Ezután vnstat service restart, és eséllyel újra életre kel. A következő reboot-ig..

Long story short, ki kellett kapcsolnom a tmpfs-t a /var -on, át kellett állítanom a figyelt interfészt igb0 (ezen jön a DIGI net pppoe-n) helyett igb2-re (ez meg a LAN interfész, semmi dinamikus pppoe baszkódás nincs itt). Mert azt gyanították h. a pppoe felépülés túl lassú és emiatt nem tud a vnstat a bootolás során kötődni a még nemlétező pppoe0 virtuális pszeudo interfészhez. Ezt a 2 dolgot variáltam 3-4x, töméntelen reboot volt közte, és 1xcsak elkezdett működni. Na azóta inkább nem basztatom.

Ki milyen távoli host-okkal kommunikált, mikor és mennyit?

"netflow" export és "insight" elemző
-> 100 MB-nyi adatot tárol max, /var/log alatt, és korlátlanul felduzzadhat a /var/netflow alatti adatbázis!!! -> reboot MENTI ezt a history-t automatikusan (/var tmpfs esetén hasznos!)

 

IPSEC Site-to-Site VPN

https://hup.hu/node/171549

 

--- Egyéb HW&SW, máshova nem tartozó ---
DMIDECODE
CLI-ből: pkg install dmidecode
aztán: "dmidecode" --> kidumpolja az alaplap SMBIOS tábla tartalmát

"dmidecode -t memory" --> kilistázza, h. a RAM tud-e ECC-t vagy sem (ha a BIOS ACPI táblázatokat a gyártó kitöltötte helyesen, APU2 esetén v4.9.0.3 BIOS óta jó a helyzet)
(width=64bit noECC vs. 72bit ECC):

dmidecode -t memory

# dmidecode 3.2
Scanning /dev/mem for entry point.
SMBIOS 2.7 present.

Handle 0x0005, DMI type 16, 23 bytes
Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Error Correction Type: Multi-bit ECC
Maximum Capacity: 4 GB
Error Information Handle: Not Provided
Number Of Devices: 1

Handle 0x0006, DMI type 17, 40 bytes
Memory Device
Array Handle: 0x0000
Error Information Handle: Not Provided
Total Width: 72 bits
Data Width: 64 bits
Size: 4096 MB
Form Factor: DIMM
Set: None
Locator: Channel-0-DIMM-0
Bank Locator: BANK 0
Type: DDR3
Type Detail: Synchronous
Speed: 1333 MT/s
Manufacturer: Unknown (100)
Serial Number: 00000000
Asset Tag: Not Specified
Part Number: None
Rank: Unknown
Configured Memory Speed: 1333 MT/s
Minimum Voltage: Unknown
Maximum Voltage: Unknown
Configured Voltage: Unknown

Update 2019.02: opnsense 19.1 óta lett beépített os-dmidecode plugin (nem kell a pkg install dmidecode), így már dashboard-ra is kirakható "hardver information" néven.

beep: az APU2 pittyeg a beépített speaker-en, ha sikeresen bebootolt az Opnsense disztrib (azaz network stack UP és a login is lehetséges), 2 eset van: system start-kor és system shotdown-kor fut le automatikusan a szkript
használata kézzel:
/usr/local/sbin/beep.sh start vagy
/usr/local/sbin/beep.sh stop
--> módosítás: "/usr/local/sbin/beep.sh"-t kell szerkeszteni

https://www.freebsd.org/cgi/man.cgi?query=beep&apropos=0&sektion=0&manp…

/usr/local/bin/beep -p 500 $NOTELENGTH # ezeket a sorokat kell átírkálni, -p HERTZ MILLISECOND formátumban

Note: a következő opnsense software update (akár csak egy minor is!) szó nélkül felülírja a módosítást!
Megoldás: syshook szkriptet csinálni! (TODO a részletek)

System LED:
APU2-n van az előlapon 3 db LED +1 programozható kapcsoló, ezeket elvileg lehet(ne) szabadon programozni
jelenleg broken, Opnsense 19.1-ben ígérik h. megint működni fog (https://github.com/opnsense/core/issues/2114)
Nem megy pfsense-ben sem: https://forum.netgate.com/topic/115270/apu2-led-control
FreeBSD-ben sem: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189772
Update: 2019.02.01 19.1-be bekerült a LED driver:
"kldload apuled"

Fontos: a kézi kldload-os betöltés csak következő reboot-ig él. Állandósítani úgy lehet, ha /boot/loader.conf-ba kézzel beírod a következő sort:
apuled_load="YES"

De!!! Opnsense alatt a loader.conf (is) autogenerálódik minden konfig módosítás után, és felülírja ami kézzel beleszerkesztettél, szóval a kézzel konfigfájlt szerkesztést itt is felejtsd el! Helyette GUI: System -> Settings -> Tunables: itt add meg tunable name=apuled_load value=YES

--> utána az igb NIC led-ekhez hasonlóan manuálisan villogtatható (az elvárható automatizált / szkriptelhető framework még sajnos a jövő zenéje)
villogás bekapcsol: echo f2 > /dev/led/led1
villogás kikapcsol: echo 0 > /dev/led/led1

Update: 2019 augusztusi Coreboot BIOS v4.10.0.0 óta elbaszódott az APULED driver, 1 éve nem akarják kijavítani, workaround-olni kell kézzel: https://github.com/pcengines/apu2-documentation/blob/master/docs/gpios…

AMD temp sensor:
van a 4 db core-ra 4 db szenzor (Note: nem igazi hőmérsékletet mutat, hanem vmi referenciaértékhez képesti pszeudo-eltérés maszlagot, a földön senki nem tudja pontosan hány fokot jelent az érték amit kiolvasol belőle)

https://www.freebsd.org/cgi/man.cgi?amdtemp(4)
for Family 10h and later processors, ``(the reported temperature) is a
non-physical temperature measured on an arbitrary scale and it does not
represent an actual physical temperature like die or case temperature.
Instead, it specifies the processor temperature relative to the point at
which the system must supply the maximum cooling for the processor's
specified maximum case temperature and maximum thermal power
dissipation

ellenőrzése:
$ sysctl dev.amdtemp| grep core0
vagy
$ sysctl dev.cpu | grep temperature
--> ha nem jön vissza semmi:

1) manuálisan (reboot elfelejti):
kldload amdtemp
aztán
kldstat |grep amdtemp

vagy 2) GUI-ból (permanens reboot után is megmarad):
System \ Settings \ Misc \ Thermal sensors

powerd
Powerd-t érdemes engedélyezni, és a power profile "hiadaptive"-re  célszerű állítani. Ez kezeli a CPU órajel növelését csökkentését a terhelés függvényében.
Lekérdezni interaktívan mennyi éppen most a CPU órajele:
powerd -v

powerd++ alternatíva jobbnak tűnik (csak hát sajna nem része az opnsense-nek, így megintcsak hekkelni kéne)
http://angryswarm.blogspot.com/2016/04/powerd-better-cpu-clock-control-…

AES-NI támogatás bekapcsolása: kernel modul betöltése
1) manuálisan (reboot után elfelejti)
kldstat | grep aesni -> ha nincs találat, akkor
kldload aesni

vagy 2) GUI-ból: System\Settings\Miscellaneous: Hardware acceleration

AES-NI speedtest:
https://calomel.org/aesni_ssl_performance.html

1) AES-NI HW-es gyorsítás hiányában (default eset): openssl speed -elapsed aes-128-cbc
--> eredmény (OpenSSL 1.0.2k-freebsd 26 Jan 2017):
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-128 cbc 14210.73k 14629.12k 15524.69k 40276.31k 40674.43k
--> 8k blokkméret alapján kb. 40 Mbit/sec-re képes bruteforce CPU-ból

2) AES-NI bekapcsolt HW-es gyorsítás: openssl speed -elapsed -evp aes-128-cbc
--> eredmény:
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-128-cbc 109850.66k 157501.93k 194130.64k 205928.11k 210187.46k
--> 8k blokkméret alapján kb. 210 Mbit/sec-re képes AES-NI HW támogatással

és végül:
3) AES-NI bekapcsolt HW-es gyorsítás helyes működésének ellenőrzése (környezeti változó letiltja az AES-NI használatát, akkor is ha amúgy elérhető lenne):
-> env --> by default nincs ilyen változó
-> setenv OPENSSL_ia32cap "~0x200000200000000"
-> env --> látszik a változó
ezután: openssl speed -elapsed -evp aes-128-cbc # a -evp nélküli eset eredményén értelemszerűen nem változtatott semmit

-->eredmény:
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-128-cbc 22161.48k 23795.14k 24434.09k 24912.21k 24746.39k
--> kb. 24 Mbit/sec, azaz még lassabb is lett, mint akár a HW-gyorsítás nélküli esetben

végül visszacsinálni az AES-NI deaktiválást:
-> unsetenv OPENSSL_ia32cap

Openssl release notes: https://www.openssl.org/news/openssl-1.0.2-notes.html

FONTOS !! Kettő (2!) féle Openssl is létezik párhuzamosan 1 Opnsense rendszeren belül:

FreeBSD requires an embedded base system OpenSSL library for bootstrap reasons, but this version cannot be changed on the fly without reinstalling the whole base system. That's why we use a package on top to allow quick updates and also the possibility to use LibreSSL.

Azaz a korrekt Openssl verzió futtatása (pl. a fentebbi speed teszt-hez) innen kell indítani:

# which openssl
/usr/bin/openssl // ez a NEMJÓ openssl bináris!!

azaz innen futtasd ez a jó elérési útvonal : # /usr/local/bin/openssl speed -elapsed -evp aes-128-cbc

Multi-core (pl. core=4) speed teszt esetén: # /usr/local/bin/openssl speed -elapsed -evp aes-128-cbc -multi 4

Update mióta FreeBSD 13.x lett az alaprendszer: az AESNI a GENERIC kernel része lett, nem kell többé modulként betölteni. Automatikusan használni fogja a kernel ezek után, ha úgy detektalja h. a CPU ismeri az AESNI v. az SHA instruction set extension-ből LEGALÁBB az egyiket. Továbbá kozmetikai változások is történtek ennek hatására, pl. GELI nem azt fogja írni AESNI esteben h. "hardver accelerated" crypto-t használ, hanem azt h. "software accelerated". Cseppet(!) megtévesztő lesz ennyi év után ha egyszer csak azt látja az ember h. software-es gyorsítast használ a crypto engine a régen hardware-esnek hazudott állapot után. https://forums.freebsd.org/threads/kldload-of-aesni-ko-fails-in-13-rele…

Top / HTOP: CPU használat kijelzése

menj le parancssorba: indítsd el a TOP-ot, gépeld be "o", utána "cpu" vagy "size" vagy "res" (rezidens memória felhasználás) utána nyomj enter-t - voila, sorbarendezés 1 pillanat alatt! Nyomd le "h" a teljes help-hez.

vagy installáld a HTOP package-t a Freebsd repository-ból (Opnsense-nek nem része)

pkg add https://pkg.freebsd.org/FreeBSD:12:amd64/quarterly/All/htop-3.0.4_1.txz

AMD CCP (Crypto Co-processor) támogatás
https://reviews.freebsd.org/D12723?id=34215
ezek alapján maga a driver még experimental, és gyengén is szerepel (mostmég?)
így értelme sincs benchmarkolni az APU2-n

TODO:
- DHCP static mapping-ot nem lehet a lease range-be létrehozni -> Update 2021.03.30: A 21.1.4-ből végre kivették ezt a bennragadt limitet (dhcp: remove obsolete subnet validation for static entries)
- nem tud kezelni DHCP-relay-t!!!
- NAT \ "port forward" helyes beállítása