Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
eko.one.pl → Posty przez marek
EDIT: Czy w tym stylu? https://www.zigbee2mqtt.io/advanced/rem … apter.html
Tak, dokładnie. Trzeba tylko ręcznie skompilować ser2net w wersji 4 (albo spróbować ze snapshota).
Zaopatrzyłem się w "SONOFF Zigbee 3.0 USB Dongle Plus", czyli CC2652. Istotnie lepszy zasięg od CC2531. W nowym openwrt jest ser2net w wersji 4.3.5, który naprawia problemy z DTR/RTS. Dzięki temu można połączyć z zigbee2mqtt pracującym zdalnie.
U mnie działa to bardzo sprawnie z zigbee2mqtt w chmurze i wireguard. Nawet przy częstym rozłączaniu internetu zigbee2mqtt zawsze grzecznie przywraca połączenie.
Jeśli to CC2652 jest na USB, to chyba pozostaje Ci kompilacja nodejs i zigbee2mqtt (jeśli masz openwrt na sprzęcie z FPU):
https://forum.openwrt.org/t/howto-setup … nwrt/31856
lub USBIP czy coś w tym stylu...
A jeśli masz płytkę bez USB, to powinna działać tasmota:
https://github.com/arendst/Tasmota/discussions/12457
Używam cały czas, działa całkiem stabilnie (4 termometry, 2 przyciski). Jedynym problemem jest zasięg sieci zigbee. Na openwrt mam zigbee-lua i mosquitto, a reszta w chmurze. Po co marnować 10W na terminal...
@marek, dzięki za informację, robiłem upgrade inwertera dwa dni temu, czy to trzeba firmware do dongla?
Do dongla.
https://forum.huawei.com/enterprise/en/ … 885-100027
Jestem w tej samej sytuacji. Na forum Huawei piszą, że w kolejnej aktualizacji firmware dla modułu (SDongleA-05) jest to poprawione i będziemy mieli dostęp do modbusa przez moduł/dongle. Jest potrzebna wersja 120. Ja obecnie mam wersję 119 (V100R001C00SPC119). Podobno odkryli jakiś błąd i nie chcą jeszcze udostępniać publicznie. Napisałem do supportu, dam znać jeśli mi coś odpowiedzą.
Zdecydowanie, nie trzeba zmieniać nazw plików...
Sorry, nie wszystko pamiętam jak to ustawiałem, ale jedną różnicę widzę - ja używam luajit nie lua.
Zobacz tu - będzie potrzebna kompilacja luajit: https://github.com/hwhw/zigbee-lua/issu … -459982167
Może sprawdź też czy masz zainstalowane:
libiwinfo-lua - 2019-08-28-a9f95570-1
liblua5.1.5 - 5.1.5-3
liblucihttp-lua - 2019-07-05-a34a17d5-1
libubus-lua - 2018-10-06-221ce7e7-1
libuci-lua - 2019-05-17-f199b961-3
lua - 5.1.5-3
luabitop - 1.0.2-1
luajit - 2.1.0-beta3-1
libffi - 3.2.1-3
(trochę starsze wersje powinny być też OK)
Przesłałem Ci też źródła jakich używam na priv. Mogę przesłać luajit jeśli też używasz xiaomi 3G.
A robisz to jak autor przykazał?
$ git submodule init
Submodule 'lib/ffi_libmicrohttpd' (https://github.com/hwhw/ffi_libmicrohttpd.git) registered for path 'lib/ffi_libmicrohttpd'
Submodule 'lib/ffi_libmosquitto' (https://github.com/hwhw/ffi_libmosquitto.git) registered for path 'lib/ffi_libmosquitto'
Submodule 'inspect.lua' (https://github.com/kikito/inspect.lua.git) registered for path 'lib/inspect-lua'
Submodule 'json.lua' (https://github.com/rxi/json.lua) registered for path 'lib/json-lua'
Submodule 'ljsyscall' (https://github.com/justincormack/ljsyscall) registered for path 'lib/ljsyscall'
$ git submodule update
Cloning into '/mnt/src/src/zig2/zigbee-lua/lib/ffi_libmicrohttpd'...
Cloning into '/mnt/src/src/zig2/zigbee-lua/lib/ffi_libmosquitto'...
Cloning into '/mnt/src/src/zig2/zigbee-lua/lib/inspect-lua'...
Cloning into '/mnt/src/src/zig2/zigbee-lua/lib/json-lua'...
Cloning into '/mnt/src/src/zig2/zigbee-lua/lib/ljsyscall'...
Submodule path 'lib/ffi_libmicrohttpd': checked out '3bbf1c96dc99eab21cc70bae2a8b474a3ec1082c'
Submodule path 'lib/ffi_libmosquitto': checked out 'da2d707f29e8e1e6c108e4797385d3f823286a2f'
Submodule path 'lib/inspect-lua': checked out 'b611db6bfa9c12ce35dd4972032fbbd2ad5ba965'
Submodule path 'lib/json-lua': checked out 'bee7ee3431133009a97257bde73da8a34e53c15c'
Submodule path 'lib/ljsyscall': checked out 'e587f8c55aad3955dddab3a4fa6c1968037b5c6e'To repo zawiera git 'submodules'. Upewnij się, że je wszystkie zebrałeś (jest o tym w README).
Ja miałem problem z modułem ljsyscall. Musiałem jedną łatkę nałożyć:
diff --git a/syscall/linux/fcntl.lua b/syscall/linux/fcntl.lua
index 67567c25..3fab4930 100644
--- a/syscall/linux/fcntl.lua
+++ b/syscall/linux/fcntl.lua
@@ -22,7 +22,7 @@ local fcntl = {
[c.F.GETLK] = t.flock,
[c.F.SETLK] = t.flock,
[c.F.SETLKW] = t.flock,
- [c.F.ADD_SEALS] = function(arg) return c.F_SEAL[arg] end,
+-- [c.F.ADD_SEALS] = function(arg) return c.F_SEAL[arg] end,
},
ret = {
[c.F.DUPFD] = function(ret) return t.fd(ret) end,
@@ -34,7 +34,7 @@ local fcntl = {
[c.F.GETSIG] = function(ret) return tonumber(ret) end,
[c.F.GETPIPE_SZ] = function(ret) return tonumber(ret) end,
[c.F.GETLK] = function(ret, arg) return arg end,Jeśli masz CC2531 to zajrzyj na: https://github.com/hwhw/zigbee-lua Używam od kilku miesięcy i działa stabilnie (2 termometry i 2 przyciski aquara). Zigbee-lua generuje komunikaty mqtt a dalej gbridge.io łączy z google home.
Tutaj prawie-poradnik jak zainstalować na openwrt: https://github.com/hwhw/zigbee-lua/issu … -459982167
(obecnie może być jakiś problem (issue #3) po reorganizacji kodu, ale zapewniam, że commit b0ed770b499ecdb6c1d8c6875a326b7bd7dc6d86 działa ok)
Chciałbym Wam polecić projekt Zigbee-lua (https://github.com/hwhw/zigbee-lua). Jest to 'koordynator' Zigbee (dla urządzeń Xiaomi Aqara/Mijia, sprzęt smart od Ikei, Philipsa, OSRAM itp). Chyba jedyny serwer, który ma tak małe wymagania, że działa na ruterach z openwrt.
Osobiście używam go na Xiaomi Router 3G (snapshot), ale na tyle na ile potrafię ocenić powinno dać się uruchomić także na sprzęcie z mniejszą ilością RAMu.
Dzięki właśnie doddanemu mostkowi MQTT można w zasadzie używać go jako zamiennik zigbee2mqtt (który wymaga node.js).
Projekt jest młody, ale autor dostarcza dobrą dokumentację i przykłady. Dzięki nim nawet bez znajomości Lua (jak w moim przypadku) można łatwo dodać własne rozwiązania.
Problem z wgrywaniem przy błędach ubi:
https://bugs.openwrt.org/index.php?do=d … sk_id=1710
Cezary napisał/a:marek napisał/a:Cezary, proszę zbuduj kirkwooda (Linksys EA4500) przy następnej okazji. Spróbowałem 18.06.0-rc1 i nie mogę dojść do ładu z E3372 (ncm).
Tzn co Ci nie działa?
Modem połączy się raz po restarcie routera a potem jakby jest kłopot z wysyłaniem komend:
Mon Jun 25 11:30:53 2018 kern.info kernel: [50157.529405] usb 1-1.4: new high-speed USB device number 11 using orion-ehci Mon Jun 25 11:30:53 2018 kern.info kernel: [50157.742682] usb-storage 1-1.4:1.0: USB Mass Storage device detected Mon Jun 25 11:30:53 2018 kern.info kernel: [50157.764871] scsi host1: usb-storage 1-1.4:1.0 Mon Jun 25 11:30:53 2018 kern.info kernel: [50158.002773] usb 1-1.4: USB disconnect, device number 11 Mon Jun 25 11:30:54 2018 kern.info kernel: [50158.809490] usb 1-1.4: new high-speed USB device number 12 using orion-ehci Mon Jun 25 11:30:54 2018 kern.info kernel: [50159.072988] option 1-1.4:1.0: GSM modem (1-port) converter detected Mon Jun 25 11:30:54 2018 kern.info kernel: [50159.079572] usb 1-1.4: GSM modem (1-port) converter now attached to ttyUSB0 Mon Jun 25 11:30:54 2018 kern.info kernel: [50159.087002] option 1-1.4:1.1: GSM modem (1-port) converter detected Mon Jun 25 11:30:54 2018 kern.info kernel: [50159.093532] usb 1-1.4: GSM modem (1-port) converter now attached to ttyUSB1 Mon Jun 25 11:30:55 2018 kern.info kernel: [50159.248043] huawei_cdc_ncm 1-1.4:1.2: MAC-Address: 00:1e:10:1f:00:00 Mon Jun 25 11:30:55 2018 kern.info kernel: [50159.254612] huawei_cdc_ncm 1-1.4:1.2: setting rx_max = 16384 Mon Jun 25 11:30:55 2018 kern.info kernel: [50159.296788] huawei_cdc_ncm 1-1.4:1.2: NDP will be placed at end of frame for this device. Mon Jun 25 11:30:55 2018 kern.info kernel: [50159.305395] huawei_cdc_ncm 1-1.4:1.2: cdc-wdm0: USB WDM device Mon Jun 25 11:30:55 2018 kern.info kernel: [50159.312009] huawei_cdc_ncm 1-1.4:1.2 wwan0: register 'huawei_cdc_ncm' at usb-f1050000.ehci-1.4, Huawei CDC NC Mon Jun 25 11:30:55 2018 kern.info kernel: [50159.359684] usb-storage 1-1.4:1.3: USB Mass Storage device detected Mon Jun 25 11:30:55 2018 kern.info kernel: [50159.373901] scsi host1: usb-storage 1-1.4:1.3 Mon Jun 25 11:30:55 2018 kern.info kernel: [50159.383729] usb-storage 1-1.4:1.4: USB Mass Storage device detected Mon Jun 25 11:30:55 2018 kern.info kernel: [50159.398763] scsi host2: usb-storage 1-1.4:1.4 Mon Jun 25 11:30:56 2018 daemon.notice netifd: Interface 'ply' is setting up now Mon Jun 25 11:30:56 2018 kern.notice kernel: [50160.432616] scsi 2:0:0:0: Direct-Access HUAWEI TF CARD Storage 2.31 PQ: 0 ANSI: 2 Mon Jun 25 11:30:56 2018 kern.notice kernel: [50160.442499] scsi 1:0:0:0: CD-ROM HUAWEI Mass Storage 2.31 PQ: 0 ANSI: 2 Mon Jun 25 11:30:56 2018 kern.notice kernel: [50160.465154] sd 2:0:0:0: [sdb] Attached SCSI removable disk Mon Jun 25 11:30:56 2018 daemon.notice netifd: ply (29205): Stopping network ply Mon Jun 25 11:30:57 2018 daemon.notice netifd: ply (29205): sending -> Mon Jun 25 11:31:01 2018 daemon.notice netifd: Interface 'ply' is now down
Podejrzewam, że skypty netifd/ncm dobierają się za szybko do modemu. W systuacji jak powyżej ifstatus pokazuje błąd NO_DEVICE. Pomaga zmiana "device" z /dev/ttyUSB0 na coś innego (np /dev/cdc-wdm0) potem network reload, zmiana z powrotem na ttyUSB0 i ponownie reload.
Będę jeszcze się temu przyglądał i jak się upewnię to zgłoszę błąd.
Na razie mam dwa pytania:
1. czy będzie kirkwood "od Cezarego" w niedalekiej przyszłości (bardzo proszę 
)
2. czy pakiety ncm z eko mają jakieś łatki?
Ogólnie wifi na EA4500 dalej jest kapryśne. Problemy ze sterownikiem mwl8k dyskutowane od lat na linux-wireless nie znalazły rozwiązania. Chyba czas na przesiadkę na "jedynie słuszny" w swojej klasie cenowej xiaomi 3g.
marek napisał/a:Cezary, proszę zbuduj kirkwooda (Linksys EA4500) przy następnej okazji. Spróbowałem 18.06.0-rc1 i nie mogę dojść do ładu z E3372 (ncm).
Tzn co Ci nie działa?
Modem połączy się raz po restarcie routera a potem jakby jest kłopot z wysyłaniem komend:
Mon Jun 25 11:30:53 2018 kern.info kernel: [50157.529405] usb 1-1.4: new high-speed USB device number 11 using orion-ehci
Mon Jun 25 11:30:53 2018 kern.info kernel: [50157.742682] usb-storage 1-1.4:1.0: USB Mass Storage device detected
Mon Jun 25 11:30:53 2018 kern.info kernel: [50157.764871] scsi host1: usb-storage 1-1.4:1.0
Mon Jun 25 11:30:53 2018 kern.info kernel: [50158.002773] usb 1-1.4: USB disconnect, device number 11
Mon Jun 25 11:30:54 2018 kern.info kernel: [50158.809490] usb 1-1.4: new high-speed USB device number 12 using orion-ehci
Mon Jun 25 11:30:54 2018 kern.info kernel: [50159.072988] option 1-1.4:1.0: GSM modem (1-port) converter detected
Mon Jun 25 11:30:54 2018 kern.info kernel: [50159.079572] usb 1-1.4: GSM modem (1-port) converter now attached to ttyUSB0
Mon Jun 25 11:30:54 2018 kern.info kernel: [50159.087002] option 1-1.4:1.1: GSM modem (1-port) converter detected
Mon Jun 25 11:30:54 2018 kern.info kernel: [50159.093532] usb 1-1.4: GSM modem (1-port) converter now attached to ttyUSB1
Mon Jun 25 11:30:55 2018 kern.info kernel: [50159.248043] huawei_cdc_ncm 1-1.4:1.2: MAC-Address: 00:1e:10:1f:00:00
Mon Jun 25 11:30:55 2018 kern.info kernel: [50159.254612] huawei_cdc_ncm 1-1.4:1.2: setting rx_max = 16384
Mon Jun 25 11:30:55 2018 kern.info kernel: [50159.296788] huawei_cdc_ncm 1-1.4:1.2: NDP will be placed at end of frame for this device.
Mon Jun 25 11:30:55 2018 kern.info kernel: [50159.305395] huawei_cdc_ncm 1-1.4:1.2: cdc-wdm0: USB WDM device
Mon Jun 25 11:30:55 2018 kern.info kernel: [50159.312009] huawei_cdc_ncm 1-1.4:1.2 wwan0: register 'huawei_cdc_ncm' at usb-f1050000.ehci-1.4, Huawei CDC NC
Mon Jun 25 11:30:55 2018 kern.info kernel: [50159.359684] usb-storage 1-1.4:1.3: USB Mass Storage device detected
Mon Jun 25 11:30:55 2018 kern.info kernel: [50159.373901] scsi host1: usb-storage 1-1.4:1.3
Mon Jun 25 11:30:55 2018 kern.info kernel: [50159.383729] usb-storage 1-1.4:1.4: USB Mass Storage device detected
Mon Jun 25 11:30:55 2018 kern.info kernel: [50159.398763] scsi host2: usb-storage 1-1.4:1.4
Mon Jun 25 11:30:56 2018 daemon.notice netifd: Interface 'ply' is setting up now
Mon Jun 25 11:30:56 2018 kern.notice kernel: [50160.432616] scsi 2:0:0:0: Direct-Access HUAWEI TF CARD Storage 2.31 PQ: 0 ANSI: 2
Mon Jun 25 11:30:56 2018 kern.notice kernel: [50160.442499] scsi 1:0:0:0: CD-ROM HUAWEI Mass Storage 2.31 PQ: 0 ANSI: 2
Mon Jun 25 11:30:56 2018 kern.notice kernel: [50160.465154] sd 2:0:0:0: [sdb] Attached SCSI removable disk
Mon Jun 25 11:30:56 2018 daemon.notice netifd: ply (29205): Stopping network ply
Mon Jun 25 11:30:57 2018 daemon.notice netifd: ply (29205): sending ->
Mon Jun 25 11:31:01 2018 daemon.notice netifd: Interface 'ply' is now downCezary, proszę zbuduj kirkwooda (Linksys EA4500) przy następnej okazji. Spróbowałem 18.06.0-rc1 i nie mogę dojść do ładu z E3372 (ncm).
Dzięki, może i tak... "tx rings drained", "Remove stream for", "Failed to start stream for" się pojawiają u mnie także przy innych urządzeniach/klientach ale nie powoduje to zauważalnych problemów. Pojawiały się zawsze a zaczynałem od pierwszych, nieoficjalnych wersji openwrt na EA4500.
Tylko czemu drukarka po pół godzinie pinga już wzorowo? Właśnie testuję ponownie i jest to samo: pół godziny problemów, potem stabilnie już ponad godzine. Drukarka nie drukuje w tym czasie. Stoi i tylko ją pinguję.
Mam sieć domową z dwoma routerami na LEDE:
1. "główny" Linksys EA4500 (17.01.1, r3316-7eb58cf109)
2. "dodatkowy" TP-LINK WDR3600 (17.01-SNAPSHOT, r3794-dca4dfa, z eko.one.pl)
Routery połączone są kablem. Udostępniają sieć WIFI (na różnych kanałach). Działam tak od wielu lat. Wszystkie urządzenia (laptopy, telefony) gładko przełączają się pomiędzy routerami zależnie od zasięgu, wszystko działa szybko i stabilnie... oprócz nowego nabytku - drukarki Epson L386.
Drukarka była początkowo skonfigurowana przez WPS, potem zalogowana ręcznie. Dnsmasq przyznaje jeden, stały adres drukarce. Firmware drukarki zaktualizowany.
Kłopot jest taki, że drukarka łączy się z EA4500 bardzo niestabilnie pomimo, że EA4500 jest bardzo blisko.
Pingi z WDR3600 są stabilne (wifi na WDR3600 włączone, wifi na EA4500 wyłączone, drukarka pokazuje zasięg 'Fair' i ma rację bo WDR3600 jest dość daleko):
64 bytes from 192.168.0.22: seq=0 ttl=64 time=26.905 ms
64 bytes from 192.168.0.22: seq=1 ttl=64 time=62.578 ms
64 bytes from 192.168.0.22: seq=2 ttl=64 time=73.309 ms
64 bytes from 192.168.0.22: seq=3 ttl=64 time=96.783 ms
64 bytes from 192.168.0.22: seq=4 ttl=64 time=120.592 ms
64 bytes from 192.168.0.22: seq=5 ttl=64 time=116.290 ms
64 bytes from 192.168.0.22: seq=6 ttl=64 time=168.934 ms
64 bytes from 192.168.0.22: seq=7 ttl=64 time=192.204 ms
64 bytes from 192.168.0.22: seq=8 ttl=64 time=11.129 msPingi z EA4500 są bardzo dziwne, jakby drukarka zasypiała i budziła się co chwilę (wifi na WDR3600 wyłączone, wifi na EA4500 włączone, drukarka pokazuje zasięg 'Excellent'):
64 bytes from 192.168.0.22: seq=0 ttl=64 time=4082.501 ms
64 bytes from 192.168.0.22: seq=1 ttl=64 time=3082.824 ms
64 bytes from 192.168.0.22: seq=2 ttl=64 time=2082.702 ms
64 bytes from 192.168.0.22: seq=3 ttl=64 time=1082.649 ms
64 bytes from 192.168.0.22: seq=4 ttl=64 time=82.512 ms
64 bytes from 192.168.0.22: seq=5 ttl=64 time=1130.795 ms
64 bytes from 192.168.0.22: seq=6 ttl=64 time=131.111 ms
64 bytes from 192.168.0.22: seq=7 ttl=64 time=2173.160 ms
64 bytes from 192.168.0.22: seq=8 ttl=64 time=1173.533 ms
64 bytes from 192.168.0.22: seq=9 ttl=64 time=173.424 ms
64 bytes from 192.168.0.22: seq=10 ttl=64 time=9207.877 ms
64 bytes from 192.168.0.22: seq=11 ttl=64 time=8208.759 ms
64 bytes from 192.168.0.22: seq=12 ttl=64 time=7208.757 ms
64 bytes from 192.168.0.22: seq=13 ttl=64 time=6208.643 ms
64 bytes from 192.168.0.22: seq=14 ttl=64 time=5208.521 ms
64 bytes from 192.168.0.22: seq=40 ttl=64 time=14985.750 ms
64 bytes from 192.168.0.22: seq=41 ttl=64 time=13986.836 ms
64 bytes from 192.168.0.22: seq=42 ttl=64 time=12986.721 ms
64 bytes from 192.168.0.22: seq=43 ttl=64 time=11986.601 ms
64 bytes from 192.168.0.22: seq=44 ttl=64 time=10986.480 ms
64 bytes from 192.168.0.22: seq=55 ttl=64 time=1.910 ms
64 bytes from 192.168.0.22: seq=56 ttl=64 time=4070.282 ms
64 bytes from 192.168.0.22: seq=57 ttl=64 time=3071.023 ms
64 bytes from 192.168.0.22: seq=58 ttl=64 time=2070.923 ms
64 bytes from 192.168.0.22: seq=59 ttl=64 time=1070.794 ms
64 bytes from 192.168.0.22: seq=60 ttl=64 time=70.659 ms
64 bytes from 192.168.0.22: seq=90 ttl=64 time=15776.290 ms
64 bytes from 192.168.0.22: seq=91 ttl=64 time=14776.898 ms
64 bytes from 192.168.0.22: seq=92 ttl=64 time=13776.997 ms
64 bytes from 192.168.0.22: seq=93 ttl=64 time=12776.864 ms
64 bytes from 192.168.0.22: seq=94 ttl=64 time=11776.749 ms
64 bytes from 192.168.0.22: seq=95 ttl=64 time=10776.635 ms
64 bytes from 192.168.0.22: seq=97 ttl=64 time=8777.370 ms
64 bytes from 192.168.0.22: seq=98 ttl=64 time=7777.266 ms
64 bytes from 192.168.0.22: seq=99 ttl=64 time=6777.148 ms
64 bytes from 192.168.0.22: seq=100 ttl=64 time=5777.091 ms
64 bytes from 192.168.0.22: seq=103 ttl=64 time=2777.179 ms
64 bytes from 192.168.0.22: seq=104 ttl=64 time=1777.170 ms
64 bytes from 192.168.0.22: seq=105 ttl=64 time=777.058 ms
64 bytes from 192.168.0.22: seq=106 ttl=64 time=37.020 msOczywiście drukowanie przy takim połączeniu to loteria...
I teraz najciekawsze. Zostawiam sprzęt w spokoju, a po około pół godzinie Epson z EA4500 łączy się już stabilnie:
64 bytes from 192.168.0.22: seq=531 ttl=64 time=1945.346 ms
64 bytes from 192.168.0.22: seq=532 ttl=64 time=945.216 ms
64 bytes from 192.168.0.22: seq=533 ttl=64 time=2.025 ms
64 bytes from 192.168.0.22: seq=552 ttl=64 time=19062.279 ms
64 bytes from 192.168.0.22: seq=553 ttl=64 time=18063.702 ms
64 bytes from 192.168.0.22: seq=554 ttl=64 time=17063.595 ms
64 bytes from 192.168.0.22: seq=555 ttl=64 time=16063.472 ms
64 bytes from 192.168.0.22: seq=556 ttl=64 time=15063.349 ms
64 bytes from 192.168.0.22: seq=572 ttl=64 time=4140.463 ms
64 bytes from 192.168.0.22: seq=573 ttl=64 time=3140.959 ms
64 bytes from 192.168.0.22: seq=574 ttl=64 time=2140.847 ms
64 bytes from 192.168.0.22: seq=575 ttl=64 time=1140.707 ms
64 bytes from 192.168.0.22: seq=576 ttl=64 time=140.582 ms
64 bytes from 192.168.0.22: seq=577 ttl=64 time=6730.443 ms
64 bytes from 192.168.0.22: seq=578 ttl=64 time=5731.066 ms
64 bytes from 192.168.0.22: seq=579 ttl=64 time=4730.981 ms
64 bytes from 192.168.0.22: seq=580 ttl=64 time=3730.858 ms
64 bytes from 192.168.0.22: seq=581 ttl=64 time=2730.725 ms
64 bytes from 192.168.0.22: seq=613 ttl=64 time=15189.317 ms
64 bytes from 192.168.0.22: seq=614 ttl=64 time=14190.603 ms
64 bytes from 192.168.0.22: seq=615 ttl=64 time=13190.499 ms
64 bytes from 192.168.0.22: seq=616 ttl=64 time=12190.378 ms
64 bytes from 192.168.0.22: seq=617 ttl=64 time=11190.243 ms
64 bytes from 192.168.0.22: seq=629 ttl=64 time=4269.543 ms
64 bytes from 192.168.0.22: seq=630 ttl=64 time=3270.082 ms
64 bytes from 192.168.0.22: seq=631 ttl=64 time=2269.971 ms
64 bytes from 192.168.0.22: seq=632 ttl=64 time=1269.840 ms
64 bytes from 192.168.0.22: seq=633 ttl=64 time=269.703 ms
64 bytes from 192.168.0.22: seq=634 ttl=64 time=624.078 ms
64 bytes from 192.168.0.22: seq=691 ttl=64 time=3.596 ms
64 bytes from 192.168.0.22: seq=692 ttl=64 time=2.047 ms
64 bytes from 192.168.0.22: seq=693 ttl=64 time=2.071 ms
64 bytes from 192.168.0.22: seq=694 ttl=64 time=5.895 ms
64 bytes from 192.168.0.22: seq=695 ttl=64 time=2.615 ms
64 bytes from 192.168.0.22: seq=696 ttl=64 time=2.078 ms
64 bytes from 192.168.0.22: seq=697 ttl=64 time=2.129 ms
64 bytes from 192.168.0.22: seq=698 ttl=64 time=3.224 ms
64 bytes from 192.168.0.22: seq=699 ttl=64 time=2.054 ms
64 bytes from 192.168.0.22: seq=700 ttl=64 time=2.132 ms
64 bytes from 192.168.0.22: seq=701 ttl=64 time=2.044 ms
64 bytes from 192.168.0.22: seq=702 ttl=64 time=2.100 ms
64 bytes from 192.168.0.22: seq=703 ttl=64 time=4.014 ms
64 bytes from 192.168.0.22: seq=704 ttl=64 time=2.177 ms
64 bytes from 192.168.0.22: seq=705 ttl=64 time=2.056 ms
64 bytes from 192.168.0.22: seq=706 ttl=64 time=2.105 ms
64 bytes from 192.168.0.22: seq=707 ttl=64 time=2.128 ms
64 bytes from 192.168.0.22: seq=708 ttl=64 time=2.060 ms
64 bytes from 192.168.0.22: seq=709 ttl=64 time=2.109 ms
64 bytes from 192.168.0.22: seq=710 ttl=64 time=2.035 ms
64 bytes from 192.168.0.22: seq=711 ttl=64 time=2.051 ms
64 bytes from 192.168.0.22: seq=712 ttl=64 time=2.131 ms
64 bytes from 192.168.0.22: seq=713 ttl=64 time=2.159 ms
64 bytes from 192.168.0.22: seq=714 ttl=64 time=2.071 ms
64 bytes from 192.168.0.22: seq=715 ttl=64 time=2.148 ms
64 bytes from 192.168.0.22: seq=716 ttl=64 time=2.121 ms
64 bytes from 192.168.0.22: seq=717 ttl=64 time=2.116 ms
64 bytes from 192.168.0.22: seq=718 ttl=64 time=2.262 ms
64 bytes from 192.168.0.22: seq=719 ttl=64 time=2.177 ms
64 bytes from 192.168.0.22: seq=720 ttl=64 time=2.050 ms
64 bytes from 192.168.0.22: seq=721 ttl=64 time=2.368 ms
64 bytes from 192.168.0.22: seq=722 ttl=64 time=2.134 ms
64 bytes from 192.168.0.22: seq=723 ttl=64 time=2.153 ms
64 bytes from 192.168.0.22: seq=724 ttl=64 time=3.955 ms
64 bytes from 192.168.0.22: seq=725 ttl=64 time=2.125 ms
64 bytes from 192.168.0.22: seq=726 ttl=64 time=2.154 ms
64 bytes from 192.168.0.22: seq=727 ttl=64 time=2.339 ms
64 bytes from 192.168.0.22: seq=728 ttl=64 time=2.132 ms
64 bytes from 192.168.0.22: seq=729 ttl=64 time=2.051 ms
64 bytes from 192.168.0.22: seq=730 ttl=64 time=2.148 ms
64 bytes from 192.168.0.22: seq=731 ttl=64 time=2.171 ms
64 bytes from 192.168.0.22: seq=732 ttl=64 time=2.054 ms
64 bytes from 192.168.0.22: seq=733 ttl=64 time=2.784 ms
64 bytes from 192.168.0.22: seq=734 ttl=64 time=2.173 ms
64 bytes from 192.168.0.22: seq=735 ttl=64 time=2.059 ms
64 bytes from 192.168.0.22: seq=736 ttl=64 time=2.436 ms
64 bytes from 192.168.0.22: seq=737 ttl=64 time=2.043 ms
64 bytes from 192.168.0.22: seq=738 ttl=64 time=2.060 ms
64 bytes from 192.168.0.22: seq=739 ttl=64 time=2.116 ms
64 bytes from 192.168.0.22: seq=740 ttl=64 time=2.061 ms
64 bytes from 192.168.0.22: seq=741 ttl=64 time=2.071 ms
64 bytes from 192.168.0.22: seq=742 ttl=64 time=2.132 ms
64 bytes from 192.168.0.22: seq=743 ttl=64 time=2.131 ms
64 bytes from 192.168.0.22: seq=744 ttl=64 time=2.098 ms
64 bytes from 192.168.0.22: seq=745 ttl=64 time=2.124 ms
64 bytes from 192.168.0.22: seq=746 ttl=64 time=2.670 msTak jakby drukarka przestała zaspiać albo skończyła jakiś proces... może logowanie do 'chmury'? Tylko czemu z WDR3600 działa stabilnie od razu?
Plik wireless EA4500:
config wifi-device 'radio0'
option type 'mac80211'
option hwmode '11g'
option path 'mbus/mbus:pcie-controller/pci0000:00/0000:00:01.0/0000:01:00.0'
option country '00'
option htmode 'HT20'
option channel '6'
config wifi-iface
option device 'radio0'
option network 'lan'
option mode 'ap'
option ssid 'test'
option encryption 'psk2'
option key 'test'
option wps_pushbutton '1'
option wpa_disable_eapol_key_retries '1'wireless na WDR3600:
config wifi-device 'radio0'
option type 'mac80211'
option channel '11'
option hwmode '11g'
option path 'platform/ar934x_wmac'
option htmode 'HT20'
option country 'PL'
config wifi-iface 'default_radio0'
option device 'radio0'
option network 'lan'
option mode 'ap'
option ssid 'test'
option encryption 'psk2'
option key 'test'
option wpa_disable_eapol_key_retries '1'W logach cisza. Nie wiem co mogę zmienić w konfiguracji wifi na EA4500. Przełączałem kanały, tryby g/n, opcję disable_eapol...
Macie jeszcze jakiś pomysł?
Udało mi się zmusić mwan3 do pracy z ncm ale musiałem trochę wyrzeźbić. Piszę z nadzieją, że ktoś wskaże jak można to było zrobić lepiej.
Wcześniej próbowałem używać funkcji network_find_wan zamiast dodawania "_4" ale funkcja działała sensownie tylko przy podniesionym interfejsie inaczej zwraca "wan".
Patch dla /lib/mwan3/mwan3.sh:
--- mwan3.sh_org 2016-08-28 22:35:11.187322358 +0200
+++ mwan3.sh 2016-08-28 22:35:11.180655688 +0200
@@ -122,16 +122,22 @@
mwan3_create_iface_iptables()
{
- local id family src_ip src_ipv6
+ local id family src_ip src_ipv6 if_main if_proto
config_get family $1 family ipv4
mwan3_get_iface_id id $1
[ -n "$id" ] || return 0
+ network_get_protocol if_proto $1
if [ "$family" == "ipv4" ]; then
+ if [ "$if_proto" == "ncm" ]; then
+ if_main=$1"_4"
+ else
+ if_main=$1
+ fi
- network_get_ipaddr src_ip $1
+ network_get_ipaddr src_ip $if_main
$IPS -! create mwan3_connected list:set
@@ -231,16 +237,22 @@
mwan3_create_iface_route()
{
- local id route_args
+ local id route_args if_proto if_main
config_get family $1 family ipv4
mwan3_get_iface_id id $1
[ -n "$id" ] || return 0
+ network_get_protocol if_proto $1
if [ "$family" == "ipv4" ]; then
-
- network_get_gateway route_args $1
+ if [ "$if_proto" == "ncm" ]; then
+ if_main=$1"_4"
+ else
+ if_main=$1
+ fi
+
+ network_get_gateway route_args $if_main
route_args="via $route_args dev $2"
$IP4 route flush table $idPodobna zmiana potrzebna w /etc/hotplug.d/iface/15-mwan3
--- 15-mwan3_org 2016-08-29 15:42:45.727976375 +0200
+++ 15-mwan3 2016-08-29 15:42:02.888413194 +0200
@@ -22,14 +22,21 @@
[ -x /usr/sbin/ip6tables ] || exit 7
[ -x /usr/bin/logger ] || exit 8
-local family gateway
+local family gateway if_proto if_main
config_get family $INTERFACE family ipv4
+network_get_protocol if_proto $INTERFACE
+
+if [ "$if_proto" == "ncm" ]; then
+ if_main=$INTERFACE"_4"
+else
+ if_main=$INTERFACE
+fi
if [ "$family" == "ipv4" ]; then
- network_get_gateway gateway $INTERFACE
+ network_get_gateway gateway $if_main
elif [ "$family" == "ipv6" ]; then
- network_get_gateway6 gateway $INTERFACE
+ network_get_gateway6 gateway $if_main
fi
[ -n "$gateway" ] || exit 9Nie dodawałem obsługi ipv6 bo nie używam i wyglądałoby jeszcze gorzej.
W miare świeży trunk lede (r418). Mam dwa łącza. Drugie, zapasowe to E3372 w trybie ncm. Plik /lib/netifd/proto/ncm.sh poprawiany ręcznie aby wspierać metric itd. W configu network:
config interface 'ply'
option proto 'ncm'
option device '/dev/ttyUSB0'
option apn 'internet'
option metric '20'
option dns '8.8.8.8 8.8.4.4'
option peerdns '0'
option family 'ipv4'
option ipv6 '0'Co dziwne aby mwan3 widział interfejs 'ply' musze w jego configu zdefiniować 'ply_4':
config interface 'ply_4'
option enabled '1'
list track_ip '8.8.4.4'
list track_ip '8.8.8.8'
list track_ip '208.67.222.222'
list track_ip '208.67.220.220'
option reliability '1'
option count '1'
option up '8'
option timeout '4'
option interval '10'
option down '6'Kłopot jest taki, że mwan3 nie potrafi takiego 'ply_4' podnieść jak się rozłączy. Jak się domyślam _4 i _6 to jakieś 'ukryte' interfejsy ipv4 i ipv6 więc kombinowałem z różnymi ustawieniami family, ipv6 '0' itp.
Pierwszy interfejs - wan (eth1) nie ma tego problemu - mogę w mwan3 używać 'wan'.
Czy mwan3 stał się niekompatybilny z lede/ncm?
Dokładniejszy opis extroot na EA4500 i LEDE trunk. Użyjemy partycję syscfg, czyli /dev/mtd7. Na początek format:
root@lede:~# ubiformat /dev/mtd7
ubiformat: mtd7 (nand), size 77594624 bytes (74.0 MiB), 592 eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 2048 bytes
libscan: scanning eraseblock 591 -- 100 % complete
ubiformat: 592 eraseblocks have valid erase counter, mean value is 0
ubiformat: formatting eraseblock 591 -- 100 % completePodłączamy nowe urządzenie ubi:
root@lede:~# ubiattach -m 7
UBI device number 1, total 592 LEBs (76382208 bytes, 72.8 MiB), available 568 LEBs (73285632 bytes, 69.9 MiB), LEB size 129024 bytes (126.0 KiB)Tworzymy wolumen:
root@lede:~# ubimkvol -N extroot -m /dev/ubi1
Set volume size to 73285632
Volume ID 0, size 568 LEBs (73285632 bytes, 69.9 MiB), LEB size 129024 bytes (126.0 KiB), dynamic, name "extroot", alignment 1Teraz, żeby utworzyć filesystem ubifs, najłatwiej jest go po prostu zamontować:
root@lede:~# mkdir /mnt/mtd7
root@lede:~# mount -t ubifs ubi1:extroot /mnt/mtd7
root@lede:~# umount /mnt/mtd7Jescze dodajemy do /etc/config/fstab
config mount
option target '/overlay'
option device '/dev/ubi1_0'
option fstype 'ubifs'
option enabled '1'i dodajemy do /etc/rc.local linijkę z ubiattach
# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.
export PREINIT=1; /usr/sbin/ubiattach -m 7; mount_root
exit 0Teraz wystarczy restart. Router po restarcie wystartuje z taką samą konfiguracją jak przed extrootem. Nie trzeba konfigurować wszystkiego od zera.
Nie podam Ci teraz wszystkich komend krok po kroku z pamięci, ale to co powyżej powinno wystarczyć. Poczytaj o ubi i mtd.
Pewnie spróbuję niedługo zrobić upgrade na lede bo naprawili już generowanie obrazów. Postaram się spisać kroki dokładnie.
Jeśli koniecznie chcesz mieć 128MB to tylko CC, które możesz zainstalować przez serial.
Na trunku musiałbyś samodzielnie coś wyrzeźbić - łatki, kompilacja itp. Czyli możesz sobie odpuścić
W/g mnie CC to ślepa uliczka i nie warto instalować jeśli jedynm powodem jest '128MB'. Co innego jeśli by Ci coś nie działało na trunku...
Jak widzisz można na trunku zrobić wewnętrzny extroot z partycji syscfg. Będziesz miał 64MB więc chyba Ci starczy. I masz rozwiązanie przyszłościowe - łatwy upgrade przez sysupgrade.
128MB będziesz miał tylko w CC. CC zabiera cały NAND dla siebie.
W trunku zrobili tak, że openwrt jest instalowany jako alternatywny system do standardowego. W ten sposób instalacja openwrt nie narusza standardowego podziału partycji. W rezultacie masz około 15MB na root.
Ale, pozostaje ostatnia partycja - syscfg, którą podobno standaradowy system używa do zapisywania 'zmiennych'. Jeśli standardowy soft nie jest Ci potrzebny możesz zrobić z syscfg extroot i będziesz miał 64MB.
W ten sposób sysupgrade powinien dalej działać (nie sprawdzałem) a miejsca jest i tak całkiem sporo.
Cezary, można prosić o Makefile? O kompilację dla kirkwooda nie śmiem prosić...
Trunk nie taki straszny. Są pakiety z feeds które się nie kompilują (mam problem z yate, libncurses/libncursesw sprawia problemy) ale główne repo jest ok.
Udało mi się zrobić extroot na dużej partycji syscfg. ubiformat, ubimkvol, potem fstab:
config mount
option target '/overlay'
option device '/dev/ubi1_0'
option fstype 'ubifs'
option enabled '1'reboot i... df -h:
Filesystem Size Used Available Use% Mounted on
/dev/root 2.0M 2.0M 0 100% /rom/rom
tmpfs 60.6M 1.2M 59.4M 2% /tmp
/dev/ubi0_1 15.2M 13.2M 1.2M 92% /rom/overlay
overlayfs:/overlay 15.2M 13.2M 1.2M 92% /rom
tmpfs 512.0K 0 512.0K 0% /dev
/dev/ubi1_0 63.9M 13.3M 47.3M 22% /overlay
overlayfs:/overlay 63.9M 13.3M 47.3M 22% /eko.one.pl → Posty przez marek
Forum oparte o PunBB, wspierane przez Informer Technologies, Inc