LTE modem typu EC25-E MINIPCIE

Turris 1.x hardware [CZ] Turris HW help [CZ]
23

Nastaveni prostrednictvim openwrt skriptu jsem napred zkousel primo s protokolem qmi takhle:

config interface 'lte'
	option ifname 'wwan0'
	option proto 'qmi'
	option apn 'internet'
	option device '/dev/cdc-wdm0'
	option delay '90'

Ted jsem tedy jeste doinstaloval wwan (i kdyz ho podezrivam, ze to stejne nakonec nastavuje take prostrednictvim uqmi) a zkousel jsem to s nim takto:

config interface 'lte'
	option device '/dev/cdc-wdm0'
	option proto 'wwan'
	option apn 'internet'
	option ifname 'wwan0'

V obou pripadech se vlastne dostanu do stavu, kdy je modeme pripojeny, ale rozhrani wwan0 se nenastavi. Zustanou tu bezet dhcp klienti, kteri proste adresu neziskaji/nenastavi:

19466 root      1080 S    udhcpc -p /var/run/udhcpc-wwan0.pid -s /lib/netifd/dhcp.script -f -t 0 -i wwan0 -C
19472 root       736 S    odhcp6c -s /lib/netifd/dhcpv6.script -P0 -t120 wwan0

Popravde mi ani neni moc jasne, proc se vlastne dhcp klient spousti, kdyz IP adresu od operatora uz ma modem vyjednanou a pridelenou. Dokonce vidi i pridelene DNS servery. To take rozptyluje pochybnosti o nastaveni z pohledu LTE site, o PINu, vadne SIM, tarifu bez datovych sluzeb a podobne. Ten modem je jiz do site pripojeny, SIMku pouziva. Smerem do LTE to IMHO funguje. Co nefunguje, je ta strana do omnie.

Firewall mam vypnuty:

root@turris:~# iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
24

Tak horor pokracuje. Vsiml jsem si, ze kdyz omnia/openwrt nahazuje ten port, tak vola neco jako uqmi -d /dev/cdc-wdm0 --wda-set-data-format 802.3.

Jenze kdyz pak zavolam wda-get-data-format, tak dostanu:

root@turris:~# uqmi -d /dev/cdc-wdm0 --wda-get-data-format
"raw-ip"

Jakoby ten modem jiz neumel encapsulovat do ethernetovych ramcu a posilal to proste vzdy jako raw ip, bez l2 hlavicek. Jenze rozhrani wwan0, jak je videt ve vypisech vyse, je prepnute na Link encap:Ethernet. Zkusil jsem ho prepnout prostrednictvim /sys/class/net/wwan0/qmi/raw_ip (vubec netusim, jestli je to legalni) do raw ip modu, coz proslo. DHCP stale nedokazalo ziskat adresu, ale videl jsem, ze jiz naskakuji nejake RX packety. Zkusil jsem tedy IP adresy ziskane z uqmi -d /dev/cdc-wdm0 --get-current-settings nastavit na rozhrani rucne. Rozhrani tedy ted vypada takto:

wwan0     Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:100.74.62.152  P-t-P:100.74.62.152  Mask:255.255.255.240
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:22 errors:0 dropped:2 overruns:0 frame:0
          TX packets:87 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2206 (2.1 KiB)  TX bytes:8040 (7.8 KiB)

No a nyni to zabavne. Kdyz pres to rozhrani neco prostrednictvim ip route nasmeruju a zkusim pingnout, tak mi ten ping normalne projde az na druhou stranu, tam se vygeneruje odpoved, ta se objevi na tom wwan0 rozhrani, ale packet neni vyhodnecny jako odpoved na ping. tcpdump spusteny na omnii to vidi nasledovne. Tohle je request:

0000  45 00 00 54 46 57 40 00 40 01 08 32 64 4a 3e 98   E..TFW@.@..2dJ>.
0010  59 66 ef d7 08 00 c6 f6 37 0b 00 00 5b da 9e 23   Yf......7...[..#
0020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0040  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0050  00 00 00 00                                       ....

a tohle je pres Internet a pres LTE prijata odpoved od protejsku:

0000  ef d7 64 4a 3e 98 00 00 ce f6 37 0b 00 00 5b da   ..dJ>.....7...[.
0010  9e 23 00 00 00 00 00 00 00 00 00 00 00 00 00 00   .#..............
0020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0040  00 00 00 00 00 00                                 ......

Kde je videt, ze hned prvni a druhy byte jsou vlastne druhe dva byty zdrojove adresy, 64 4a 3e 98 je cilova adresa modemu v siti O2. Takze schazi prvnich 14 bytu packetu. Jakoby si stale neco myslelo, ze by tam mela byt ethernet hlavicka, ktera se musi odstranit a proto to dal posle bez tech prvnich 14 byte. Co to muze delat?

25

Tak modem uz mi funguje. Bylo potreba aplikovat jeste patch spojeny s commitem 81e0ce79 pro usbnet.c od Bjørna Morka.
Pokud nekdo take omylem narazite na kombinaci Quectelu EC25-E a Omnie, tak je potreba mit (alespon k dnesnimu datu) opatchovane jadro. Patche, ktere jsem aplikoval jsou tady - http://www.atack.cz/omnia-ec25-patches.tgz .

Dale je nutne wwan rozhrani prepnout do raw IP modu. To delam timto startup skriptem:

root@turris:~# cat /etc/init.d/rawip 
#!/bin/sh /etc/rc.common

START=19
STOP=00

boot() {
	echo Y > /sys/class/net/wwan0/qmi/raw_ip
}

Modem zatim pouzivam v autoconnect rezimu, takze jsem jej pripojil:

uqmi -d /dev/cdc-wdm0 --start-network internet --autoconnect

Modem si nastaveni pamatuje a po restartu se sam opet pripoji.

Pro konfiguraci site na strane OpenWRT pouzivam jen:

config interface 'lte'
	option proto 'dhcp'
	option ifname 'wwan0'
	option delay '15'

A takhle to pak vypada :slight_smile:

Screen Shot 2017-01-30 at 13.41.40 .png1088×1089 123 KB

26

tomk: Díky za analýzu… Patche zařadíme do kernelu. Pokud jde o init.d skript, tak se nad tím zamyslíme a zkusíme to zobecnit.

(Just to comment on this in English: We will merge the patches into the kernel and will try to generalize the user-space support. Many thanks to tomk.)

27

Diky, budu rad, kdyz se na to podiva nekdo, kdo tomu opravdu rozumi :slight_smile: Pokud se to dostane do standardniho releasu, tak to bude super. Umozni mi to zapnout automaticke aktualizace, coz povazuji za velkou vyhodu Omnii.
Ten modem mi prijde jako prilis pokrokovy. Svet na nej pravdepodobne jeste neni pripraveny. To, ze nejde prepnout do 802.3 modu asi jeste neni moc obvykla vlastnost, ale vypada to, ze se to bude objevovat stale casteji…
Diky.

28

Tak vyzkoušeno s naším exemplářem modemu. Zdá se, že s patchem pro qmi_wwan.c to nejde rozchodit se SIMkou s PINem. uqmi pokusy o zjištění i nastavení pinu odmíte:

root@turris:/# uqmi -d /dev/cdc-wdm0 --get-data-status
"disconnected"
root@turris:/# uqmi -d /dev/cdc-wdm0 --get-imsi
"Not supported"
root@turris:/# uqmi -d /dev/cdc-wdm0 --get-imei
"861107030033006"
root@turris:/# uqmi -d /dev/cdc-wdm0 --get-imsi
"Not supported"
root@turris:/# uqmi -d /dev/cdc-wdm0 --get-pin-status
"Not supported"

(Teď koukám, že tu nemám to nastavení, ale vyfailovalo to taky, co jsem zkoušel a to bylo pravděpodobně --verify-pin1.)

Nicméně, povedlo se mi to rozběhat (bez jakýchkoliv patchů) v režimu PPP. Chtělo to jen následující hack:

echo "2c7c 0125" > /sys/bus/usb-serial/drivers/generic/new_id

A pak už standardní konfigurák:

config interface 'wan2'
        option ifname 'ppp0'
        option proto '3g'
        option device '/dev/ttyUSB2'
        option pincode 1234
        option apn 'internet'
        option keepalive 10
        option delay 20

Jdu to ještě zkusit rozběhat s QMI driverem a porovnat rychlost.

29

Tak rychlost s PPP je problém. Narychlo jsem srovnal dosaženou rychlost downloadu se dvěma kartama (EC20 a EC25-E) v síti Vodafone a v obou režimech - PPP a QMI:

EC20 ppp:
3.25MB/s

EC20 qmi:
7.68MB/s

EC25-E ppp:
1.89MB/s

EC25-E qmi (bez PINu):
7.6MB/s
30

Mám stejný problém. Verze Turris OS: 3.6.1, Verze jádra: 4.4.51-627f0117679bc72ef5e58881035f567a-3. LTE modem EC25-E. lsusb ukazuje Bus 001 Device 002 (občas 003): ID 2c7c:0125, v LuCI při přidávání rozhraní vidím jen /dev/ttyS#, kde # je číslo od 0 do 15. Příkaz echo “2c7c 0125” > /sys/bus/usb-serial/drivers/generic/new_id nepřináší žádné výsledky. Modem se prostě nechytne. uqmi -d /dev/cdc-wdm0 --get-data-status obvykle udělá to, že se konzole „zasekne”. Zkoušel jsem přeflashovat, žádná změna. Nezáleží, co dělám, jaký návod zde následuji, nefunguje nic.
Edit: o pár minut později se to rozjelo (po zadání příkazu echo “2c7c 0125” > /sys/bus/usb-serial/drivers/generic/new_id). Což nechápu: jednou to jede, jednou ne.
Jede to v PPP režimu, jak moc „špatný” tento režim je? Z libovolného hlediska.