PC Engines APU2C4 Small Board Computer tűzfal

 ( ricsip | 2018. július 30., hétfő - 16:03 )

Úgy gondoltam 2018 tavaszán, eljött az idő, hogy az ezeréves linksys rútert lecseréljem valami táposabb és modernebb cuccra. Mivel a Tplink/asus és tsai blackbox-backdoor-buta_mint_a_tök megoldásai nem voltak szimpatikusak, elhatároztam h. rendes tisztességes PC-x86 tűzfalam lesz. Elvárás volt, h. hangtalan passzív hűtésű alacsony fogyasztású célhardver legyen, aminek elég a teljesítménye a Gigabithez. Némi keresgélés után a PCENGINES nevű cég APU2C4 embedded platformjára esett a választás.
Ez a blogposzt egy lista azokról az apró (lefordítom magyarra: orbitálisan nagy) szívásokról, amiket a címben említett SBC beállítás / konfigurálás közben tapasztaltam.

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_replicate_the_performance_of/
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)

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_vs_apu3.md
https://github.com/pcengines/apu2-documentation/blob/master/docs/apu2_vs_apu4.md

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. 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-7C74A46B2060&fid=DF5ACB70-99C4-4C61-AFA6-4C0E0DB05B2A

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/pfSense-install-guide.md

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

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/microcode_patching.md
ú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-tool-for-freebsd.64588/
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

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-78A0B0E53074&fid=DF5ACB70-99C4-4C61-AFA6-4C0E0DB05B2A
-->
"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-amd-gx-412tc-soc/21

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/cpu_frequency.md

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-comparison/
https://3mdeb.com/firmware/amd-cpu-boost/

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-F7F2A292E02F&fid=DF5ACB70-99C4-4C61-AFA6-4C0E0DB05B2A

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.

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

--- 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/freebsd-memory.sh

--- DISZK, FÁJLRENDSZER ---
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

--- 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 sárgán)
https://www.freebsd.org/cgi/man.cgi?query=igb&apropos=0&sektion=4&manpath=FreeBSD+11.2-RELEASE+and+Ports&arch=default&format=html
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-freebsd-to-protect-a-web-server/
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 = DHCP kliens):
cat /var/db/dhclient.leases.igb0
DHCP szerver lease fájl (LAN kliensek felé):
cat /var/dhcpd/var/db/dhcpd.leases

DNS/name lookup
https://forums.freebsd.org/threads/solved-freebsd-10-sysinstall-nslookup.45143/

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&showintro=0&mimetype=plaintext&useip=0.0.0.0"
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.

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!)

--- 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&manpath=FreeBSD+11.2-RELEASE+and+Ports&arch=default&format=html

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

Note: a következő opnsense update (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 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

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 engedélyezni, power profile "hiadaptive" a célszerű.
Lekérdezni interaktívan mennyi a CPU órajele:
powerd -v

powerd++ alternatíva jobbnak tűnik (csak sajna nem része az opnsense-nek)
http://angryswarm.blogspot.com/2016/04/powerd-better-cpu-clock-control-for.html

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

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
- nem tud kezelni DHCP-relay-t!!!
- NAT \ "port forward" helyes beállítása

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Ez ez?:
http://www.mini-box.com/ALIX-APU-2C4-AMD-G-Series-GX-412TC?sc=8&category=1361

Olyan 80-100eFt-ra jön ki.
(alapgép 170$, doboz: 15$, tápegység: 10$, mSATA: 65$, wifi: 30$, antenna: 2*5usd)

Az ár-érték arányban nem vagyok biztos...

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Majdnem.

Erről van szó:
https://hup.hu/cikkek/20170322/lk_pfsense_ala_hw

http://wireless-bolt.hu/25606-alix-alaplapok --> APU2C alaplapokat nézd meg. Különbség h. 2 v. 3db NIC, ill. 2 v. 4 GB RAM.
--

Kíváncsi leszek a tapasztalataidra ha eljutsz ide: https://wiki.opnsense.org/manual/netflow.html

Bekapcsoltam ma, és látszólag teszi a dolgát, gyűjti a statisztikát. Mire vagy kíváncsi?
--

Tulajdonképpen csak annyira, hogy bekapcsoltad és gond nélkül ellátja a feladatát. :) Köszi.

Annyi tapasztalat gyűlt azóta, h. a netflow fájlok akár 600-700 MB-ot elfoglalnak, és mióta be lett kapcsolva+lokális exportja, azóta valami PHP szkript periódikusan 10 mp-ként megeszik egy magot kb. 3-4 mp-ig. A load grafikonon szépen látszanak a tüskék.

Ha nem életfontosságú a netflow adatok megőrzése (és a /var tmpfs-en van), akkor érdemes lehet kikapcsolni a reboot-kori backup, boot-kori restore funkciót, mert eléggé megakasztja a 2 folyamatot + mellékesen terheli az SSD-t ezen fajta adatmozgatás.
--

kar, hogy beleronditottal... :) Olyan ket honap mulva akartam rakerdezni, hogy mi lesz ebbol kiskonyv? :)

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Kb. 2 hónap múlva pont megjön az opnsense 19.1, amibe már talán belekerül az a pár hiányzó dolog ami még nagyon kellene. Addigra talán a coreboot-ban levő hibákat is kijavítják. Az ECC még csak bosszantó, tudna nélküle élni az ember, ahogy eddig is tette. De a turbo defektje már elég konkrétan visszafogja gigabitnél az átvitelt.
Talán annyira nem volt haszontalan az iromány, ha 1200-an már megnézték.
--

naprol napra egyre durvabb. Mar egy emberhonap tuti bennevan.

Csak hozzaszolasok nelkul senkinel se flagelodik, igy konkretan olyan mintha magadnak irnal egy jegyzetet.
(mondjuk nalam flagelodott, igy en minden frissitest megneztem).

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Benne van abban több meló is, ne félj! :) Windowsos embernek BSD-ben minden lépéshez gugli kell.
Valamikor májusban vettem a gépet, miután láttam trey-nek volt róla egy rövid blogposztja. Utána kisebb megszakításokkal szeptemberig próbáltam tuningolni h. alkalmas legyen gigabitre, de minden próbálkozással falnak mentem. Akkor döntöttem úgy h. leszarom, és élesbe rakom ilyen gyatra teljesítmény mellett is.

Amúgy pontosan, saját használatú naplónak készült. Ha más is hasznát veszi, annak csak örülök. Mivel veterán vagyok, tudom szerkeszteni a fő posztot, és így tudom bővítgetni azokat a részeket amikkel jutottam valamire. Arra nincs ötletem, h. lehetne jelezni a jónépnek ha történt frissülés, ill. hol. Ahhoz még vmi wiki compare v. diff kellene.
--

Hi,

Akkor most mi van?
Szar vagy nem szar?
Gigás Digihez gondoltam beszerezni egyet + ipfire (vhol mintha az lett volna hogy opnsense/pfsense nem hajtja ki a gigát vmi FreeBSDs fícsör miatt).

Valahol 200-250 mbit környékén vérzik el opnsense-el a gigás digi pppoe. Ipfire talán vitte 300-350 mbit-ig. Ha ennyi elég neked, akár jó is lehet. Próbáld ki magadnak, úgy a tuti :) Én már beletörődtem, így is gyorsak a letöltések.
--

Ahhoz drága, hogy csak úgy (teljesen)hobbiból vegyek egyet. :)
De köszi az infót.

Nem akarod a frissítéseket inkább kommentbe írni?

Gondoltam rá, de sajnos én 1 helyen szeretem látni az összeillő dolgokat, nem össze-vissza komment thread-ekben. Amúgy elhiszem h. annak aki olvassa, idegesítő lehet keresni a szövegben a változásokat. Ígérem már nem lesz sok update, számomra mostanra nagyjából "elkészült" a product, belekerült minden amit hiányoltam.
--

legalabb egy-egy sor changelogot a vegere vagy kommentbe: datum, micsoda lett beleirva...
:)

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

a mai bővítésnél már megtörtént :)
--

Túl hosszú már a thread. :)

Sima home router-nek érdemes használni vagy már a beizzítása is aránytalanul nagy szívás és csak hobbinak jó?

(ui: keresek vmi kisfogyasztású gigabit-es WAN-os cuccot ami netto router-nek elmenne és mondjuk menne rajta ipfire v. vmi FBSD alapú cucc.)