Openwrt 18.06???

Hálózati eszközök

Tegnap ota van egy ilyen konyvtar: https://downloads.openwrt.org/releases/packages-18.06/

Lehet lesz lassan uj release?

  • 5654 megtekintés

( Zsugabubus | 2018. 05. 26., szo – 21:30 )

Én nem upgradelek akkor sem, van egy ilyen 15.05-m:

21:30:07 up 968 days, 4:23, load average: 0.00, 0.01, 0.04

Ugyan az utóbbi időben is javítottak a kernelben egy rakás CVE-t, de mit számít mindez, ha van szép nagy uptime. :) Ezzel szemben nekem ezt mondja az OpenWrt/LEDE router-em:

uptime
21:40:23 up 11:12, load average: 0.01, 0.01, 0.00
uname -r
4.9.102

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

1000 alatt már tuti nem bootolom meg akárhány CVE is van javítva :) Meg nem is lenne egyszerű, mert ez egy cégnél van, ha lehal, akkor mehetek oda, amit nem szeretnék.
Egyébként mennyi lehet, amelyik érint is? Mert gyanítom, hogy nem sok (gyorsan átfutottam a 2018-as listát, abból egy sem).

( hrex | 2018. 06. 23., szo – 23:01 )

Most már tényleg úgy tűnik, hogy lesz. 18.06-RC1 már van!

Tplink Archer C7. Úgy döglött meg félig a Wifi, hogy a oneplus telóm nem tudott felmenni a wifire, de más eszközöm meg fel volt csatlakozva. Újraindítottam a routert és a telót is, de semmi. Aztán nem volt kedvem bénázni vele, majd felrakom az RC2-t vagy a végleges verziót. System log tele volt egyébként, ha jól emlékszem hostap hibákkal.

Visszaraktam a 17.01.4-t, azzal nincs semmi gondom.

Feltettem most a 18.06 Final-t. Na ezzel ugyanúgy jártam (oneplus-on nem ment a wifi, minden máson amúgy igen), de most legalább volt időm troubleshootolni.

Nekem be volt kapcsolva a MAC filtering és úgy tűnik valami olyasmiből van a probléma, hogy az Oneplus-on eléggé friss az OS és az új androidok (amúgy iOS is) elvileg privacy okokból csinálnak MAC address randomizációt a Wifin. Emiatt viszont tele nyomja az új OpenWrt logját ilyenekkel:
daemon.notice hostapd: Station MAC ADDRESS not allowed to authenticate

Amikor kikapcsoltam a MAC filteringet az adott radió alatt, elkezdett működni a OnePlus is. Amit nem értek miért, mert a korábbi Openwrt-n is be volt kapcsolva a MAC filtering és már akkor is így működött a OnePlus. Szóval valamit vagy most csináltak meg az OpenWrt-ben vagy rontották el. Még olvasok majd a témában.

Minden más jónak tűnik. Szóval én ne tartsalak vissza az upgrade-től :)

A MAC randomizacio (ha jol tudom) nem ugy mukodik, hogy minden reconnectnel random a MAC, hanem elmentett wifi kapcsolatonkent general egy uj MAC addresst. Valszeg a frissitesnel valtozott valami, ami miatt ugy dontott a telefon, hogy ez egy uj wifi kapcsolat es generalt hozza egy ugy MAC addr-t. Mentsd az ujat is a listadba es jo vagy a kovetkezo frissitesig.

Elvileg.

Dettó, csak itt egy Redmi Note 4 mellett nem értem a dolgot mert mint írtad, korábban is be volt kapcsolva a MAC filtering és nem volt ilyen probléma.
Azt megnézhetnéd még, hogy ha a hide ESSID ki van kapcsolva, viszont a MAC filteringet hagyod, akkor sem tud csatlakozni? Nálam furcsa mód így működik, de amint rejtem a SSID-t megszűnik a kapcsolat.

--
Debian GNU/Linux

Na úgy tűnik mindkettőtök hozzászólására megvan a válasz. Itt találtam egy részletesebb leírást és persze azt is leírják, hogy miért nem ér ez a randomizáció sokat.

Amikor fel van már csatlakozva a telefon a wifi-re, akkor már az egyedi MAC címet használja, amit a telefon menüjében is megtalálsz. (Csatlakozás után már titkosított a kapcsolat és akkor szerintem már a MAC sem látszik.) Viszont a csatlakozás előtt amikor próbálja kideríteni, hogy a közelben van-e valamelyik ismert/elmentett hálózat, akkor random MAC címmel próbálkozik, hogy ne lehessen a csatlakozási kérésekből következtetéseket levonni.

Kipróbáltam, nem rejtett SSID és bekapcsolt MAC cím szűréssel is működik a dolog. Gondolom azért, mert ilyenkor a telefonnak nem kell kitalálnia, hogy a közelbe van-e az ismert/mentett hálózat.

Lehet korábban a MAC filtering része csak akkor volt érdekes, amikor már authentikálni próbáltak a készülékek, de most már a MAC filter megfogja amikor még csak keresik a készülékek a hálózatot. Majd megpróbálok valamit írni erről az OpenWRT-nek, aztán mondják meg, hogy bug vagy feature. :)

( Alucard | 2018. 08. 01., sze – 18:49 )

Időközben megérkezett a Final release. A Wi-Fi nálam Hide ESSID mellett nem működik, a MAC szűrés, és minden egyéb más viszont (eddig) tökéletes. Korábban soha nem volt ilyen gondom, csak szépen frissítettem a cuccot és hasított minden a régi beállításokkal. Remélem idővel javítják ezt a csúnya bugot. (lehet bekavar vmi régi settings)

--
Debian GNU/Linux

Én a devel ágat használom, sohasem volt még vele bajom. Van, hogy napjában több build is készül, van, hogy egy sem, de ez a ritkább. A magam részéről akkor csinálok új image-et az aktuális devel snapshotból, ha van újabb kernel verzió.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( trn | 2018. 08. 05., v – 21:14 )

Hat en nem tudom, a wifi biztonsagi mizeria utani frissites ota a wl drivert uzembehelyezve (hogy ki lehessen hasznalni a N szabvany adta lehetosegeket egy broadcom chipes Asus RT N16- on) ugy viselkedik, hogy megy egy darabig a wifi barmilyen eszkozzel, majd gondol egyet es ledobja az eszkozt. Az eszkoz lehet OnePlus, BlackBerry, Samsung, Dell laptop, HP laptop, Lenovo vagy Samsung laptop. Remenykedtem, hogy a 18- as megoldja, de ez meg rosszabbul viselkedik, ez a Blackberry- t fel sem engedi kapcsolodni. A tobbi eszkozzel ua. csak most a wifi kapcsolat korabban szakad. Mergemben visszaraktam az elso 17- est. Tokeletesen mukodik vele a wl driver, de a sebezhetoseg igy megvan. Vajon mi tortenhetett?

( thomasrc | 2018. 08. 07., k – 15:22 )

Más is tapasztal olyat, hogy a Luci-t megnyitva és afk-olva a főoldalon elkezd felmenni a load? 5 perc alatt eddig 14-es loadnál (1 min) tartok és csak emelkedik. Ha bezárom a lapot, akkor szépen lassan visszaesik 0.1 környékére, ahogy lenni szokott.

Archer C7 v2, sqm, miniupnp, p910nd.