OpenWrt 18.06.0 final

Linux

Részletek a bejelentésben.

( apostroph3 | 2018. 08. 01., sze – 22:33 )

$ ssh router


BusyBox v1.28.3 () built-in shell (ash)

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 OpenWrt 18.06.0, r7188-b0b5c64c22
 -----------------------------------------------------
root@OpenWrt:~# uname -a
Linux OpenWrt 4.9.111 #0 Mon Jul 30 16:25:17 2018 mips GNU/Linux
root@OpenWrt:~# uptime
 22:25:15 up 39 min,  load average: 0.05, 0.02, 0.08
root@OpenWrt:~#

tl-wr1043nd
nem kellet újrakonfigolni, csak a luci-app-ddns feltelepíteni, majd újraindítani, és ment minden tovább. :))

Erdekes, nalam nem megy a package telepites szinten TL-WR1043ND v1-en. 17.01-es (vagy mi is volt) LEDE-rol upgradeltem.

LuCi-bol hiaba frissitem a package listet, ures marad az available es kezzel megadva a csomag nevet sem tudok telepiteni.
Command line-bol latszik, hogy out of memory error, bar onnan vegul felment a luci-app-ddns es - ujrainditgatasok kozepette - a ca-certificates es libustream-openssl, hogy a ddns update SSL-en at frissitse az IP-t.

opkg update utan a LuCi exception-re fut a ddns reszen, reboot utan OK a kovetkezo opkg-zasig. Ez is memoria hianynak tunik, bar nem irja.

Az ar71xx az 4.9-en van, mint a mellekelt abra is mutatja, a terv (eddig az volt), hogy az ath79-be lesz atmigralva mindegyik device supportja, az mar DTS-es, es az fog csak 4.14-et kapni. Ez persze qrvasok effort, lelkesedes meg csak kozepesen van hozza.

Az updatelt terv az, hogy a kovetkezo release-ben valoszinuleg me'g fel lesz huzva 4.14-re az ar71xx, de uj device supportja mar nem kerulhet be, csak az ath79-be.

-w-

forumon irtak hogy az offload sikeresen novelte a savszelesseget, ha jol ertem 4.14-es kernellel van csak lehetoseg offload-ra

# iperf3 -s

WITHOUT offload (option flow_offloading 0)
[ ID] Interval Transfer Bandwidth Retr
[ 5] 0.00-10.03 sec 597 MBytes 499 Mbits/sec 0 sender
[ 5] 0.00-10.03 sec 597 MBytes 499 Mbits/sec receiver

WITH offload (option flow_offloading 1)
[ ID] Interval Transfer Bandwidth Retr
[ 5] 0.00-10.03 sec 1.09 GBytes 931 Mbits/sec 0 sender
[ 5] 0.00-10.03 sec 1.09 GBytes 931 Mbits/sec receiver

--
neked aztan fura humorod van...

itt olvastam:
https://forum.openwrt.org/t/is-anybody-working-on-linux-4-14-for-ar71xx…

ha a forum cime helytallo akkor az ar71xx platformon csinaltak a tesztet,
(ami a mostani releaseben meg 4.9-es kernellel megy igy nincs benne az offload),
de en el tudom kepzelni hogy mas platformokon amik 4.14-es kernellel mennek szinten megnoveli a savszelesseget az offload.
remelem a kovetkezo releaseben az ar71xx platform tenyleg megkapja a 4.14-es kernelt, anno azert valtottam 1043nd-rol mert korlatozta a netet.

nem ismerem a teszt korulmenyeit, az ip cimek alapjan lokalis meres volt.

--
neked aztan fura humorod van...

( x-daemon | 2018. 08. 02., cs – 15:01 )

tp-link c2600-on mar a 17.01.4 -> 17.01.5 is problemas volt, nem tudta felcsatolni a rootfs-t, csak vart.
mtd -r erase rootfs_data "megoldotta"
17.01.5 -> 18.06.0 szinten ugyanaz a problema
mtd -r erase rootfs_data ujbol "megoldotta"
lehet hogy a 17.01.4 -> 18.06.0 pont jo lett volna, de mar nem tesztelgetem.
upgrade elott csinalni kell egy backupot a beallitasokrol.
ellenben az jo hogy megtalaltak es kijavitottak a hibat es mostmar ujra lehet inditani.

--
neked aztan fura humorod van...

( martonmiklos v | 2018. 08. 02., cs – 21:33 )

Hol marad a recept a loginscreenről?

( elod v | 2018. 08. 03., p – 08:38 )

Jól olvasom hogy az olcsó szappantartókat (4MB flash) lehet kiszórni a szemétdombra?

Mondok példát:
Van egy céges mobilstickem, rendes netelőfizuval. Van egy ilyen szappantartóm, és amikor nyaralni megy a család, akkor ezzel a kettővel oldható meg, hogy kap minden kütyü netet, nem pedig a szintén céges telefonommal osztom meg. (És mivel nem annyira onlány videó bámulása zajlik, ez a net elegendő is tud lenni.) Hm? Ez az eszköz már mind adott, tehát tetszőleges új eszköz megvásárlása "fölösleges" kiadás a meglevő készlethez képest.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Egyebkent annak mi az oka, hogy nincs device-external LuCi? A LuCi nem "csak" annyit csinal, hogy
- config filebol/parancs kimenetbol inputot olvas a device-rol,
- szepen megjelenit/user input validal,
- config fileba visszair/parancsot futtat a device-on?

Mert ezt az IO-t nem tunik bonyolultnak egy ssh csovon attolni es akkor futhatna a webszerver Lua-stul, LuCi-stul, html template-estul, mindenestul a device-on kivul. Pl. ha egy .deb csomagban benne lenne ez az egesz a jelenlegi formajaban (tehat tovabbi csomagfuggosegek nelkul), akkor is max par mega lenne az egesz, viszont a routeren ez mar sokat szamit ugy tarhely, mint RAM szempontjabol.

Nem hinnem, hogy csak nekem szokott ez par evente eszembe jutni, de sose talalom nyomat se errol szolo beszelgetesnek.

Amit felvetsz, az inkabb "cloud management" kicsiben, kotve hiszem h ne lenne ra valamilyen free felseggu megoldas, ami vagy mukodik, vagy nem. Igazabol ez foleg a 4M flash-es cuccokat erinti, 8M es folotte mar rohogve elfer egy LuCI, ha meg "egy helyrol tobb device-t" akarsz piszkalni, az mar a fizetos service kategoriaja.

Arra meg, hogy miert nincs ilyen "officially", a valasz az, hogy valoszinuleg nem erdekelt senkit ennyire. :) (de mint te is irod, nyomat se latod errol szolo beszelgetesnek.)

-w-

tegyuk fel azok kellenek amikben benne van a lua, luci vagy uhttpd
# opkg list-installed | egrep "(lua|luci|uhttpd)"

itt megneztem a file size-t:
https://openwrt.org/packages/table/start

libiwinfo-lua 7kB
liblua 65kB
liblucihttp 7kB
liblucihttp-lua 3kB
libubus-lua 6kB
lua 5kB
luci 0kB
luci-app-firewall 11kB
luci-base 122kB
luci-lib-ip 11kB
luci-lib-jsonc 4kB
luci-lib-nixio 29kB
luci-mod-admin-full 78kB
luci-proto-ipv6 4kB
luci-proto-ppp 3kB
luci-theme-bootstrap 11kB
uhttpd 24kB

osszesen 390kB, ami 4MB-nal a 84kB-os ures helyet megdobna a tobbszorosere.

--
neked aztan fura humorod van...

( BandiG v | 2018. 08. 07., k – 21:18 )

szerk: elvileg fixaltak 19 napja, ugy latszik a release-be nem kerult bele
https://github.com/openwrt/luci/commit/a68006245df16599145c00b949d2c8c9…

ujabb erdekes hiba(?):

Firefox 52.9.0-val a LuCi-ban a log file nezo boxok (pl. status > system log) teljesen statikusak (nem scrollozhatoak vizszintesen (nem mozog a csuszka), nem lehet copy-pastelni beloluk, nem lehet a jobb also sarok sraffozott reszevel atmeretezni).

Ja es a Network > Diagnostics reszen meg a lede-t emlegeti. :)

( SCOPE | 2019. 01. 10., cs – 14:29 )

Azé más is el lett baszkurálva ebben, az új kiadásban:

hiába állítod a txpowert nagyobbra, a /etc/config/wireless -ben, nem hajlandó felvenni, fixen marad 13dbm-en
TP-Link 740N v4: (AR9331 cpu, gyári adatlap szerint, HT20-ban 18dbm)

vi /etc/config/wireless
config wifi-device 'radio0'
option type 'mac80211'
option channel '11'
option hwmode '11g'
option path 'platform/ar933x_wmac'
option htmode 'HT20'
option disabled '0'
option country 'HU'
option txpower '18'

iw wlan0 info
Interface wlan0
ifindex 17
wdev 0xa
addr c4:ee:af:33:61:61
ssid OpenWrt
type AP
wiphy 0
channel 11 (2462 MHz), width: 20 MHz, center1: 2462 MHz
txpower 13.00 dBm

Ezen kívül a jelerősség (felteszem, a txpower) össze-vissza ugrál:
Szitu:
Routertől 5m-re ülök, asztalon androidos telefon, rajra: WiFiAnalyzer, a program kijelzi a jelerősséget,
ami -51dbm és -70dbm között mozog, "szinuszosan" 5perces periódusidővel.
Eközben, az ugyanilyen típusú router LEDE 17-tel, 2 emelettel lejjebbről, -86dbm és -82dbm között mozog,
ami normálisnak mondható.