Ha volna rá lehetőség, hogy a gyári firmware update felületről FreeBSD-t telepítsek az otthoni routeremre...

 ( gergelykiss | 2018. július 2., hétfő - 8:25 )
...maradnék a gyári firmware-nél, nem zavarnak az ebben található esetleges sechole-ok és/vagy gyárilag beépített backdoorok
5% (15 szavazat)
...maradnék a jelenlegi, Linux-alapú (ddwrt/openwrt stb) firmware-nél, mert meg vagyok elégedve vele
26% (74 szavazat)
...kipróbálnám, de nem használnám tartósan, mert nem ismerem eléggé a BSD-t, félek tőle, a Linux jobb mint a BSD stb.
6% (16 szavazat)
...ha stabilan működik és tartalmaz minden szükséges feature-t, telepíteném és használnám hosszú távon is
53% (153 szavazat)
...nem érdekel a téma / értelmetlen a szavazás / hagyjuk már a szakmázást, irány a Balcsi!!!444
11% (31 szavazat)
Összes szavazat: 289

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ő.

A szavazás kiírója írta:

"A szavazás egyik apropója a közelmúltban megismert, otthoni router-ek ezreit megfertőző VPNFilter, a másik pedig, hogy (ettől függetlenül is) szeretnék FreeBSD-t telepíteni az otthoni router-emre, több okból is kifolyólag, melyeket itt részleteztem. Próbálkoztam már többféle eszközzel, míg végül egy TP-LINK WR-1043ND doboznál kötöttem ki, amivel már sikerült egészen bíztató eredményeket elérnem a napokban.

Amint sikerül ehhez a modellhez összeraknom egy stabilan működő firmware binárist, elkezdenék más modellekkel is foglalkozni, ezzel is kicsit kiszélesítve a most még elég szűkös hardvertámogatási listát.

Hosszabb távon az a terv, hogy létrehozok egy weboldalt, ahol bináris formában le lehet tölteni a különféle, támogatott modellekhez tartozó firmware-t, kiegészítve egy wiki-vel, nagyjából úgy, mint az openwrt, csak FreeBSD-re kihegyezve. Ezt aztán később, ha már átkerült a MIPS "Tier1" besorolás alá (vagyis, ha már teljes mértékben támogatott architektúra lesz), be lehet majd olvasztani a FreeBSD projekt alá.

Kifejtős válaszok jöhetnek bátran kommentben, ezeket előre is köszönöm!"

--
trey @ gépház

https://opnsense.org/about/about-opnsense/ amúgy érdekes alternatíva lenne, de ha nem akarok valami miatt freebsd-t tanulni nagyobb mélységekben marad az opnsense.

Nem túl sok routert lehet kapni, ami az i386-os, vagy amd64-es platformra épül.

Miért érdekes ez? Van van alá szépen.

https://hup.hu/cikkek/20170327/opnsense_teszt

Van olyan ebből, ami több mint egy éves uptime-mal megy.

--
trey @ gépház

Ha a 1043-as egy yacht, akkor a linkelt hardware egy anyahajó. Teljesen más kategória. Nekem úgy tűnt („ha már átkerült a MIPS "Tier1" besorolás alá”), hogy inkább a yachtokra koncentrál.

Az anyahajo csupan 100 eve avult el (1918-ban vontak hadrendbe a HMS Argus-t). A yachtok maig teljesitik a feladatukat.

--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

100 éve avult el? inkább 100 éve épült az első igazi full-deck anyahajó.
Akkor a számítógépek a szilikonréteges térvezérlésű tranzisztorok megjelenésével avultak el a 60-as években, vagy 1981-ben az IBM PC bemutatkozásával?

Nem, a FET-ek megjelenesevel az elektroncsoves szamitogepek avultak el, az elektroncsovekkel meg a relesek. Azzal meg a mechanikusok.

Az anyahajok vizirepulokkel voltak felszerelve, nagyobb hullamzas eseten nem tudtak sem fogadni, sem inditani repulogepeket. Inditashoz megalltak, daruval letettek a vizre a repulot, az onnan felszallt, aztan fogadashoz megint megalltak, es visszaemeltek a hajora. Kesobb katapulttal el tudtak inditani a gepet, de fogadashoz akkor is meg kellett allniuk.
A repulogep-hordozo (aircraft carrier) elonye pont az, hogy a fedelzeten van egy kifutopalya, ami menet kozben tud inditani es fogadni erre felkeszitett repuloket. Raadasul sokkal jobbakat, mert nem kell rajuk uszotalp, ami nem valami aramvonalas. Ez egy felderitogep eseten meg nem olyan nagy problema, de egy vadasznal kritikus. Raadasul nem volt olyan nagy aldozat, onnantol egy ideig csak ilyen felderito (meg persze tuzvezeto) gepek indultak hajorol katapultrol (pl. csatahajokon volt ilyen). Aztan a helikopterek elterjedesevel (meg a VTOL gepekkel) ez a feladat is megszunt (illetve dronok is vannak ugyanerre, pl. MQ-8 Fire Scout).

--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

Próbáltam rávilágítani, hogy mennyire sántít a hasonlatod, úgy látom nem jött le, akkor kifejtem(amúgy az enyém is sántít, pont ezért):

Bár a repülőgéphordozók számos előnnyel rendelkeznek, amiket szépen le is írtál és nagyobb erőprojekció hatékonyabban hajtható végre velük, gyakorlatilag az alapötletből teljesen más lett és felfelé skálázódott a repülőgép-hordozó, de mégsem váltak az anyahajók elavulttá 1918-ban, és még a fénykoruk is bőven messze volt, hanyatlásuk pedig csak a második világháborútól kezdődött, de akkor is inkább egyszerűen csak módosították a feladatkörüket. Az anyahajók a második világháborúban még torpedóhordozó repülőket harci célokra is, majd a hidegháború alatt járőrözési/felderítési és expedíciós feladatokra bőven ez volt a legalkalmasabb technológia. Bár a feladatköre folyamatosan szűkült, igazán csak a hajófedélzetről alkalmazható helikopterek megjelenésével vált elavult technológiává minden célra, nem 1918-ban. Vannak országok, ahol a partiőrség még mindig anyahajókat használ. Az anyahajók modern utódjai nem a repülőgép-hordozók, hanem minden olyan úszó alkalmatosság ami kisjavításra alkalmas helikopter-hangárral bír. Gyakorlatilag önálló hajótípusból majdnem bármilyen osztályon egy modullá vált.

Igaz, hogy az anyahajók továbbfejlesztéséből jöttek a repülőgéphordozók, de akkor is apples to oranges.

[IMHO]
Jogos, de azt egy valószínűbb verziónak tartom, hogy valaki az OPNSense-ét akarja finomhangolni olyan szinten, hogy a GUI már nem elég, na nekik akár elég lehet egy bare freebsd is, de az, hogy a szomszéd srác, akinek én hegesztem a winjét néha, hogy ő a routere firmware update felületén felnyomja a legújabb freebsd-t ... ez vagy brick lesz, vagy használhatatlan, default settingssel.

Aki pedig ért hozzá, és szeretne freebsd-t feltenni, az szerintem egy wikinek jobban örülne, hogy hogyan csináltad a feltöltendő image-t - aki ennyire szeretne kézzel telepítgetni/konfigurálgatni alap freebsd-t.

Egy szűkebb script kiddie réteg aki nem ért mélységében hozzá, de firmware update felületen elnavigál, szerintem nekik nem való bare freebsd. Valszeg kipróbálná, mert coolnak tűnik, de szerintem pár óráig tartana a dolog és utána a fő gondolat a visszaflashelés lenne.

Amúgy szerintem tök jó dolgot csináltál, elnéznék egy előadást belőle egy open source confon, meg elolvasnám a wikit, de én nem látom értelmét, hogy egy-két demo példányon túl energiát fektess bele. Nem tudom freebsd-nek van-e ilyenje, de debianban a debian howto-k között lenne a helye, freebsd dokumentációk között nem tudom hol lenne a helye.

Aztán ha marha sok időd van ezt csinálni és mégis specifikus binárisokat fogsz gyártani én nem külön weboldalra pakolnám - kivéve ha a freebsd-sek nem biztosítanak helyet neked az installing freebsd oldal környékén. (az lenne az igazi ha oda felkerülne ez a lehetőség legalább link vagy említés szintjén)
[/IMHO]

Nem is kell megtanulni. Az a tervem, hogy az openwrt-féle luci-t portolom FreeBSD-re. Aki használt már openwrt-t, az már ismeri, és így nekem sem kell kétszer feltalálnom a spanyolviaszt. A fontosabb konfigurációs kategóriákhoz (IP-címek, routing, wireless, netkapcsolat paraméterei, tűzfal) megcsinálom a modult, így már egy power user is simán fel tudja majd konfigurálni, nem kell hozzá semmi komplexebb tudás vagy *BSD-ismeret.

Az opnSense-zel sajnos nincs tapasztalatom, csak hallomásból ismerem, de a linkelt oldalon olvasottak alapján egy SOHO router-re eléggé overkillnek tűnik.

Ez egy jó terv!
pfSense hardverkövetelményei alapján egyáltalán nem való soho routerekre.
Minimum
CPU - 500 Mhz
RAM - 512 MB
Recommended
CPU - 1 Ghz
RAM - 1 GB
https://www.pfsense.org/products/
opnSense szvsz semmivel sem jobb mint a pfSense. Hardver követelményei azonosak.


Normális HUP-ot használok!

Ha nincs a routerre *wrt, akkor bsd alapú cucc, ha lenne mindkettő akkor a hw támogatottságtól, funkcióktól, és teljesítménytől függően választanám ki.

Nem lesz egy kicsi hely problema?

En pfSense-t (is) hasznalok, de mar az se frissul 1 GB flash-el (sem). Ugye NanoBSD deprecated lett szep csendben..

NetBSD kisebb es egyszerubb is a portolasa.

A NetBSD-t nem ismertem, köszi a tippet! Igazság szerint csak pár hónapja váltottam BSD-re és egyelőre le vagyok ragadva a FreeBSD-nél. :)

Az igaz, hogy a FreeBSD alapesetben tárhelyigényes, de voltak (vannak?) törekvések arra, hogy embedded eszközökön is használható legyen. Ezek közül talán a bsdbox az egyik leghasznosabb. Ez egy nagy, all-in-one bináris, ami nettó ~6 MB-ba belesűrít egy komplett BSD rendszert.

Referenciaképp, egy teljesen működőképes, kernelt, kernelmodulokat (wifi, ethernet, tűzfal, NAT) és a legalapvetőbb utility-ket (cat, gzip, dmesg, cd, mv, cp stb.) tartalmazó rendszert tegnap sikerült egy ~5.8MB-os image-be összecsomagolnom. Ez ráadásul még kisebb is lehetne, ha sikerülne az egészet LZMA-val betömöríteni (egyelőre a kernel gzip-be, a rootfs sima zip-be van tömörítve).

Kösz a munkát, engem érdekelne
A VPNFilter megtudja fertőzni az OpenWRT, LEDE firmware-et is?

En VM-en hasznalok Router/firewall OS-t (VyOS), Igazabol ha van otthon valami 7/24 vas, legalabb 2 halokarival, (nem is kell erogep, valami 100 dollaros Celeron kinai miniPC is boven eleg, ha nem virtualizalsz) akkor szerintem ez a legjobb megoldas. Lenyegeben barmit ratehetsz, nincs megkotes.

Ha a router támogatja, mindenképp feltolnék rá egy BSD-alapú megoldást. Akkor is, ha nem a gyári update felületről lehet megtenni, hanem hekkelni kell.


No keyboard detected... Press F1 to run the SETUP

Úgyis a WL driver a lényeg, az meg linux 2.6-ra van fordítva, szóval értelmetlen a szavazás.

Egyéb, leírom: a NetBSD-t preferálnám.

----
„Kb. egy hónapja elkezdtem írni egy Coelho-emulátort, ami kattintásra generál random Coelho-kompatibilis tartalmat.”

Melyik neves vagy elismert hálózatos cég használ ma NetBSD-t? Nem néhány NetBSD eredetű kódot hanem magát a NetBSD-t. FreeBSD bizonyít a Juniper termékein.


Normális HUP-ot használok!

Korrekt referenciák, de vajon mekkora a felhasználói bázisa a NetBSD-nek? Van annyira kiforrott mint a FreeBSD?

Úgy vélem, kevesebben használják, mint a FreeBSD-t.
A NetBSD közel egyidős a FreeBSD-vel, tehát ő se mai gyerek. Az igen sok támogatott architektúra szerintem igen komoly háttérre utal.

Szerintem meg porhintés az egész ma már. A Linux is támogat mindenféle értelmes és jópár értelmetlen architektúrát. NetBSD-nél a sok architektúrából nem kevés annyit jelent, hogy van egy virtuális terminálod, X gui nélkül és sok más hardverkomponens sem támogatott. Az a bizonyos Tier II tele van ilyenekkel. Nagy részük különben is elavult, múzeumba való platform.
Mára rendesen megfogyatkoztak az architektúrák. Ezért sem nagy érv ez. Anno amikor külön vált a FreeBSD és NetBSD ág még nyilván más volt a helyzet. De szerintem az idő inkább az akkor csak egy egy archra koncentráló FreeBSD elképzeléseit igazolta.


Normális HUP-ot használok!

Nem feltétlen porhintés. A NetBSD-ben sokkal hamarabb volt támogatottak a RaspberryPi-szerű kütyük, mint FreeBSD-ben (FreeBSD-n a legrégebbi ARM-os hír 2014. szeptemberi (bár tegyük hozzá, már legalább 2013. januárja óta voltak nemhivatalos build-ek, NetBSD-n meg 1996. óta - nem tudom, konkrétan az RPi mióta támogatott teljesen, hirtelen nem találtam forrást). Sőt, FreeBSD-n sokáig nem is volt támogatott (értsd: nem működött) az RPi hangkártyája (NetBSD-n meg úgy emlékszem, a leírások szerint csont nélkül), valamint csomagok se voltak (ld. korábbi blogbejegyzésem), azaz kb. ez is X gui nélküli volt (megjegyezném, sokszor nem is kell X meg GUI).

Szóval bír előnye is lenni a széles (porhintésnek tűnő) támogatottságnak, és nem egy arch van a világon, amire koncentrálni kell(het) - ahogy a FreeBSD példája is mutatja.

Juniper switchek úgy tudom ARM-osak, azokon jól teljesít a FreeBSD, ha RPi nem is tökéletes.
A "porhintést" arra értettem, hogy a valóban nagyszámú NetBSD által támogatott architektúra túlnyomó része múzeumi darab. Ami arch ma számít, azt mind fullosan támogatja a Linux.
Volt itt a hup-on is pár fórumtéma gigabites switchek otthoni összerakásáról, persze PC alapon. Ott is olyan tapasztalatokról írtak, hogy ugyanaz a hardver ami valamilyen Linux router rendszerrel hozza a gigabitet, pfSense és egyéb BSD alapú router rendszerrel már csak 500 mbps vagy alatta teljesített. Ha csak inteles részegységekből épül a router, ethernet kártyák is intelesek akkor jól teljesít a FreeBSD is. Szerintem amelyik hardveren lemaradt a FreeBSD Linux mögött ott a NetBSD sem szerepelt volna jobban. Mert hosszú és rögös út vezet onnantól, hogy elindul az os egy archon addig, amíg maximálisan optimalizált is az adott hardverre.
Szerintem nem vezet jóra egy Linux monokultúra, ami a korábbi és nem is igazi Windows monokultúránál is sokkal szélesebb körű és PC szerverektől kezdve okostévéken és okostelefonokon át routerekig és az apró beágyazott rendszerekig mindent dominál.
Ezért is lenne jó egy FreeBSD alapú soho router firmware ami OpenWRT egyszerűséggel telepíthető és a megszokott LUCI felületet hozza. Ha az OpenWRT sok száz vagy már inkább ezres router típus támogatottsága lenne megcélozva az egy eléggé reménytelen feladat lenne. Ha néhány népszerű és nagy számban elterjedt router típus támogatás van megcélozva az egy reális elérhető cél.
Szóval ezért is tartom általánosságban jobbnak a FreeBSD-s szemlélelet. Kevesebb hardvert támogat de azt tényleg jól támogatja. Az RPi példád ennek ellent mond de az szvsz kívül esik a FreeBSD fókuszán és inkább "hobbiprojekt" kategória. Tier2 az egész Arm FreeBSD-n. Akinek ez üzlet mint a Junipernek, megoldja magának hogy az Armos termékein professzionális szinten működjön.


Normális HUP-ot használok!

ugyanaz a hardver ami valamilyen Linux router rendszerrel hozza a gigabitet, pfSense és egyéb BSD alapú router rendszerrel már csak 500 mbps vagy alatta teljesített
Azt el kell ismerni, hogy a BSD-k hardvertámogatottsága lényegesen elmarad a Linuxétól. A Linuxé meg a Windowsétól :)
Szerintem amelyik hardveren lemaradt a FreeBSD Linux mögött ott a NetBSD sem szerepelt volna jobban.
A legfontosabb szót kiemeltem :) Nem ugyanaz a kód a FreeBSD és a NetBSD esetén, így teszt híján kb. semmit sem tudunk mondani.
inkább "hobbiprojekt" kategória
Szerintem azon már rég túllépett. Van hivatalos csomagtároló is, amennyire tudom, kb. minden működik (legalábbis az én B+-os verziómmal). Még annyi kellene, hogy a freebsd-update ezen a platformon is működjön, ne pedig állandóan az új lemezképet kelljen a memóriakártyára másolgatni (és egy-két apróságot beállítani).

"A Linuxé meg a Windowsétól"

Nem. A Linux már bőven a Windows előtt jár. PC platformon kívül a Windows szinte nem is létezik. Persze Itanium de ott meg a platform nem létezik már lassan. :-) Windows routert nem igen szokás építeni, talán nem véletlenül. Valószínű, hogy egy windows router is Linux mögött teljesítene. ARM-on meg alig támogat valamit a Windows. Van aki Odroid és más ARM-os boardokkal épít routert. Szerintem ez annyira nem jó ötlet viszont Linuxszal valóban működnek. Windows el sem indulna rajta, nemhogy a részegységeit és a rá csatlakoztatott hardvereket kezelje.

"A legfontosabb szót kiemeltem :) Nem ugyanaz a kód a FreeBSD és a NetBSD esetén, így teszt híján kb. semmit sem tudunk mondani."

Az a "szerintem" sajnos 99% feletti valószínűséget jelent :-) De ha csinálsz egy tesztet NetBSD-vel és megírod, olvasott cikk lesz.
A FreeBSD inteles hardvereken mutatott jó eredménye az Intel közreműködésének is köszönhető.

"Szerintem azon már rég túllépett"
Én itt nem látom a Raspberry Pi-t sem az ARM platformot:
https://www.freebsd.org/releases/11.2R/hardware.html

Amíg ez nem változik hobbi, vagy ha ezt dehonesztálónak érzed akkor geek kategória RPi-n. Ez nem azt jelenti, hogy nem működik rajta, elég munkaórát beleölve egy production ready eszköz faragható belőle ahogy a Juniper is csinálja a saját ARM hardverén. De az nem azonos a hivatalos mindenki számára elérhető kiadással.


Normális HUP-ot használok!

a hivatalos mindenki számára elérhető kiadással
Tessék:
"FreeBSD 11.2-RELEASE is now available for the amd64, i386, powerpc, powerpc64, sparc64, armv6, and aarch64 architectures."

Na jó hát te érveltél azzal, hogy FreeBSD-n az RPi hangkártyája sem működött meg csomagok sem voltak, bezzeg netBSD-n. Erre vetettem fel, hogy hivatalosan nem is támogatott. Most akkor melyik freebsd.org-os forrást kell elfogadnunk? :-) Illetve miért nem szerepel az általam linkelt freebsd oldalon az rpi?


Normális HUP-ot használok!

"sem működött...sem voltak"
Múlt idő.

"melyik forrás"
Az image letölthető, és működik. Hogy miért nincs a listában, azt nem tudom.

Ezek többsége már elavult tech. Ami említésre méltó az Apple AirPort cuccok, bár azokat épp mostanában lőtte le az Alma miután már öt éve nem fejlesztett semmit rajtuk.
Így ma a Dell Force10 az egyetlen aktuális példa. Azt el kell ismerni, hogy ez is valami.


Normális HUP-ot használok!

Akkor eddig 1:1? Vagy inkább 2:1?

1:1 mert az Apple AirPort éppen kiesett a VB-n :-)


Normális HUP-ot használok!

Nem a NetBSD ellen, hanem a FreeBSD mellett kampányolva egy kicsit: mi 2012-ben vásároltunk két SRX210H tűzfalat az irodába, melyek közül az első a normál, "mindenes" tűzfalunk, a második eszközt pedig cold spare-ként üzemeltük be, ahová szkriptelve töltögetjük át az éles konfigot. Ez azért jó, mert egy váratlan leállás esetén csak átdugjuk a kábeleket és megy tovább az élet. Mivel munkaidőben úgyis bent van valamelyikőnk és éles, netről elérhető szolgáltatás nem üzemel az irodában, ez vállalható kompromisszumnak tűnt és emlékeim szerint így lényegesen olcsóbban is jöttünk így ki a cluster-elt megoldáshoz képest licencköltségben.

Jelentem, eddig még egyszer sem volt szükség failoverre a beüzemelés óta eltelt 6 év alatt, újraindítani is csak áramszünet vagy firmware frissítés miatt kellett. Fagyást, instabil műkődést vagy teljesítmény-problémákat sosem tapasztaltunk, ezek alapján bátran ki merem jelenteni, hogy egy kiemelkedően jól összerakott, stabil rendszer a JunOS (és vele együtt a FreeBSD is), ráadásul a jelek szerint a hardvert is hosszú távra tervezték a Juniper mérnökei.

egyéb: nem érdekel, hogy linux vagy FreeBSD alapú. Olyan firmware-t használnék, ami tudja azokat a szolgáltatásokat, amik nekem kellenek, aktívan karbantartják, és a felhasználói közösség nagy része megelégedéssel használja.

Ha két vagy több olyan lehetőség is van, ami ezeket mind hozza, akkor a UI felhasználóbarátsága alapján döntenék.

Ezek kozul van barmi, ami az OpenWRT-re nem igaz?

ilyet nem mondott, de nem is sejtetett. annyit mondott, hogy neki mindegy mi, csak tudja azt ami az elvárása. ez innentől lehet akár az openwrt is.


"I'd rather be hated for who I am, than loved for who I am not."

Így van.

Lehet akár OpenWRT is, vagy FreeBSD is, vagy más.

A feltételes módból nekem ez a sejtés jött le.

"Lenne, kellene, volna, -nák, -nék"

Van.