1 (edytowany przez Przmus 2015-12-14 08:49:03)

Temat: Problem z częstym rozłączaniem się modemu E3276 na WNDR4300

Mam nietypowy problem z utrzymaniem stabilnego połączenia w routerze WNDR4300, z modemem Huawei E3276 (chyba nie HiLink, bo po podłączeniu do komputera instaluje jakieś sh*tware).
Może od początku:
- Mam wgrane LuCI Chaos Calmer 15.05. Z Internetem łączę się przez NCM (inaczej się chyba nie da). Sieć: Cyfrowy Polsat, LTE.
- Problem występował przy bezpośrednim podłączeniu modemu do routera, więc zakupiłem aktywny HUB USB 3.0, z zasilaczem 2A. Wydaje mi się, że modem jest dostatecznie zasilany.
- Prędkość internetu, podczas połączenia jest bardzo satysfakcjonująca: http://www.speedtest.net/my-result/4913517048

Problem polega na tym, że często podczas normalnego przeglądania Internetu nagle strony przestają się wczytywać. Modem jest cały czas połączony (dioda). Po ~1 minucie połączenie jest wznawiane, używam przerobionego ping_watchdog.sh (część pliku):

logger -t $0 "WAN Restart"
            (ifdown wan; sleep 2; CurDevice=$(uci get network.wan.device); logger -t $0 "Current device: $CurDevice"; echo -e "AT^RESET\r" > $CurDevice; usbreset "HUAWEI Mobile"; ifup wan) &
            ;;

Ale to akurat mało istotne, gdyż te połączenie jest "zawieszone" już przed wywołaniem ping_watchdog'a.

Czasami odłączam modem od HUBa, czasami restartuję router, ale problem znowu się pojawia, średnio po ok. 3 godzinach, ciężko to dokładnie stwierdzić. Te zawieszenia zdarzają się bardzo losowo. Z tego co zauważyłem, częściej połączenie zawiesza się podczas przeglądania stron www, rzadziej podczas grania w gry multiplayer. Dla jasności: mój ping_watchdog bez problemu wznawia połączenie, daję tylko przykład że rebooty, ręczne odcięcie zasilania od modemu nie naprawiają problemu na długo.

Na wcześniejszym routerze, "od operatora" (DWR-116), problem raczej nie występował. Jedynie restarty połączenia co 24h, ale wg. operatora "tak ma być".

Próbowałem samemu wykryć co powoduje te zawieszenia, niestety w logach nie ma nic sensownego.
Ostatnim razem, kiedy to się stało:

Mon Dec 14 07:44:03 2015 daemon.info dnsmasq-dhcp[2406]: DHCPREQUEST(br-lan) 192.168.1.101 MAC-zmieniony:91 
Mon Dec 14 07:44:03 2015 daemon.info dnsmasq-dhcp[2406]: DHCPACK(br-lan) 192.168.1.101 MAC-zmieniony:91 Przemek-I9300
Mon Dec 14 07:45:00 2015 cron.info crond[1669]: USER root pid 7136 cmd /przemek/ping_watchdog.sh 240 3 8.8.8.8 wan
Mon Dec 14 07:45:05 2015 user.notice /przemek/ping_watchdog.sh: WAN Restart

Tak, jakby te "DHCPREQUEST" miało z tym jakiś związek.

Jeszcze wcześniejsze logi jakie udało mi się skopiować, zaraz po zawieszeniu (niestety zapomniałem skopiować ping_watchdog.sh który był wykonany mniej niż minutę po tym):

Sun Dec 13 18:19:38 2015 daemon.info dnsmasq-dhcp[2426]: DHCPREQUEST(br-lan) 192.168.1.112 MAC-zmieniony:d4 
Sun Dec 13 18:19:38 2015 daemon.info dnsmasq-dhcp[2426]: DHCPACK(br-lan) 192.168.1.112 MAC-zmieniony:d4 Note3
Sun Dec 13 18:19:38 2015 daemon.warn dnsmasq-dhcp[2426]: not giving name Note3.lan to the DHCP lease of 192.168.1.112 because the name exists in /tmp/hosts/dhcp with address 192.168.1.196
Sun Dec 13 18:19:38 2015 daemon.warn dnsmasq-dhcp[2426]: not giving name Note3 to the DHCP lease of 192.168.1.112 because the name exists in /tmp/hosts/dhcp with address 192.168.1.196
Sun Dec 13 18:36:01 2015 daemon.info hostapd: wlan1: STA MAC-zmieniony:d4 IEEE 802.11: disassociated
Sun Dec 13 18:36:02 2015 daemon.info hostapd: wlan1: STA MAC-zmieniony:d4 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Sun Dec 13 18:36:13 2015 daemon.info hostapd: wlan0: STA MAC-zmieniony:d4 IEEE 802.11: authenticated
Sun Dec 13 18:36:13 2015 daemon.info hostapd: wlan0: STA MAC-zmieniony:d4 IEEE 802.11: associated (aid 3)
Sun Dec 13 18:36:13 2015 daemon.info hostapd: wlan0: STA MAC-zmieniony:d4 WPA: pairwise key handshake completed (RSN)
Sun Dec 13 18:36:18 2015 daemon.info hostapd: wlan0: STA MAC-zmieniony:d4 IEEE 802.11: disassociated
Sun Dec 13 18:36:19 2015 daemon.info hostapd: wlan0: STA MAC-zmieniony:d4 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Sun Dec 13 18:36:22 2015 daemon.info hostapd: wlan1: STA MAC-zmieniony:d4 IEEE 802.11: authenticated
Sun Dec 13 18:36:22 2015 daemon.info hostapd: wlan1: STA MAC-zmieniony:d4 IEEE 802.11: associated (aid 3)
Sun Dec 13 18:36:22 2015 daemon.info hostapd: wlan1: STA MAC-zmieniony:d4 WPA: pairwise key handshake completed (RSN)

Nie wiem czy to jakiś przypadek, czy nie (nie znam się na tym), natomiast raz zanotowałem zawieszenie i reconnect bez żadnych dodatkowych logów, czyli coś w stylu:

Mon Dec 14 07:54:00 2015 cron.info crond[1669]: USER root pid 8158 cmd /przemek/ping_watchdog.sh 240 3 8.8.8.8 wan
Mon Dec 14 07:55:00 2015 cron.info crond[1669]: USER root pid 8200 cmd /przemek/ping_watchdog.sh 240 3 8.8.8.8 wan
Mon Dec 14 07:56:00 2015 cron.info crond[1669]: USER root pid 8242 cmd /przemek/ping_watchdog.sh 240 3 8.8.8.8 wan
RESET

(ten ostatni log to zrobiony "z ręki", nie zawiesiło się po tym nic, daje tylko przykład jak to raz wyglądało kiedy sprawdzałem, ale zapomniałem skopiować hmm).

Na wszelki wypadek podaję jeszcze konfigurację z pliku network:

config interface 'loopback'
    option ifname 'lo'
    option proto 'static'
    option ipaddr '127.0.0.1'
    option netmask '255.0.0.0'

config globals 'globals'
    option ula_prefix 'JAKIŚKOD::/48'

config interface 'lan'
    option ifname 'eth0.1'
    option force_link '1'
    option type 'bridge'
    option proto 'static'
    option ipaddr '192.168.1.1'
    option netmask '255.255.255.0'
    option ip6assign '60'
    option macaddr 'JAKIŚKOD:cf'

config interface 'wan6'
    option ifname 'eth0.2'
    option proto 'dhcpv6'

config switch
    option name 'switch0'
    option reset '1'
    option enable_vlan '1'

config switch_vlan
    option device 'switch0'
    option vlan '1'
    option ports '0t 1 2 3 4'

config switch_vlan
    option device 'switch0'
    option vlan '2'
    option ports '0t 5'

config interface 'wan'
    option proto 'ncm'
    option apn 'internet'
    option mode 'lte'
    option device '/dev/ttyUSB0'

Mam nadzieję, że za bardzo nie zamieszałem i zrozumiale opisałem problem.
Byłbym wdzięczny za jakieś rady, sposoby które umożliwiłyby dokładniejsze wykrycie problemu smile
Miłego dnia.

2

Odp: Problem z częstym rozłączaniem się modemu E3276 na WNDR4300

dhcp to przypadek - możesz ustawić sobie dzierżawę na 24h.

Zawieszanie - nie mam rozwiązania. Czasami trzyma sesję tygodniami, czasami rozłącza co chwilę.

Masz niepotrzebny router, uszkodzony czy nie - chętnie przygarnę go.

3

Odp: Problem z częstym rozłączaniem się modemu E3276 na WNDR4300

Dzięki za odpowiedź. Dla testu ustawiłem sobie czas dzierżawy na 48h.

Czyli rozumiem, że nie da się tego wykryć w żaden inny sposób? sad To zazwyczaj leży po stronie sterownika, protokołu (NCM), czy operatora? Domyślam się, że ciężko to jednoznacznie stwierdzić, ale może gdybym wiedział na czym się skupić, to w wolnym czasie popróbowałbym jakichś opcji itp.

4

Odp: Problem z częstym rozłączaniem się modemu E3276 na WNDR4300

Operatora i modemu łatwo sprawdzisz zmieniając jedno lub/i drugie. Protokół w sumie tez możesz zmienić. Ale jedno na raz, żebyś wiedział co było ew. przyczyną.

Masz niepotrzebny router, uszkodzony czy nie - chętnie przygarnę go.

5 (edytowany przez build000 2015-12-14 12:08:51)

Odp: Problem z częstym rozłączaniem się modemu E3276 na WNDR4300

Czyli potwierdza się w nieskończonej ilości postów, że trzyma połączenie jak skała tylko u jednego operatora:
Orange-Freenet (LTE lub niżej) na abonament z usługą apn: vpn.
Dodatkowo widzę, że na dowolnym modemie w trybie ncm, albo przynajmniej na modemach f-my Huawei (sprawdzałem w sumie na 4-ech popularnych modelach, m.in. na tym co w temacie w sieciach Play,Orange,Plus - Play i Plus na starterach, Orange na starterze/abonamencie).

6 (edytowany przez pepe2k 2015-12-14 12:14:52)

Odp: Problem z częstym rozłączaniem się modemu E3276 na WNDR4300

Przmus napisał/a:

[...]
- Problem występował przy bezpośrednim podłączeniu modemu do routera, więc zakupiłem aktywny HUB USB 3.0, z zasilaczem 2A. Wydaje mi się, że modem jest dostatecznie zasilany.
- Prędkość internetu, podczas połączenia jest bardzo satysfakcjonująca: http://www.speedtest.net/my-result/4913517048[...]

Przy takim DL, to UL trochę niski. Pokaż parametry sygnału na modemie.
Jesteś w stanie przetestować sobie DL/UL w tej samej lokalizacji na PC (modem w PC)?

7 (edytowany przez jarek7714 2015-12-14 17:17:07)

Odp: Problem z częstym rozłączaniem się modemu E3276 na WNDR4300

Przmus napisał/a:

Na wcześniejszym routerze, "od operatora" (DWR-116), problem raczej nie występował. Jedynie restarty połączenia co 24h, ale wg. operatora "tak ma być".

Trochę to dziwne że na tej samej sieci jest tak różne zachowywanie adresów IP-używam Plusa i odnawia mi co 2-3 tygodnie, więcej na dodatkowym pakiecie Aero2 (również działa na sieci LTE-poza opcją free), takie odnowienia adresu nie występowały (też jesteś pierszą osobą w sieci, która się spotkałem że zgłasza taką niedogodność). Jednakże czy to stary sterownik NCM, czy nowy nigdy pod tym względem nie miałem zastrzeżeń do działania pod OpenWRT.                                                                                                               

Przmus napisał/a:

Jeszcze wcześniejsze logi jakie udało mi się skopiować, zaraz po zawieszeniu (niestety zapomniałem skopiować ping_watchdog.sh który był wykonany mniej niż minutę po tym):

Watchdog w tym przypadku służy jedynie do "kosmetyki"- modem ma ciągle przerzucać dane i do tego celu używamy

 Podtrzymania połączenia HSPA+
Dodajemy do pliku /etc/rc.local jako pierwszą linię:


    (while true; do ping google.com > /dev/null; sleep 3; done) &

(bez obaw nic mu się nie stanie-mój E398 działa 24h/24h już 4 lata). Ciekawi mnie jaki masz wskaźnik sygnału na modemie (jak z jego stabilnością?)? Bo może tutaj jest problem (coś zastanawiająco niski masz upload).                                                             

build000 napisał/a:

Czyli potwierdza się w nieskończonej ilości postów, że trzyma połączenie jak skała tylko u jednego operatora:
Orange-Freenet (LTE lub niżej) na abonament z usługą apn: vpn.
Dodatkowo widzę, że na dowolnym modemie w trybie ncm, albo przynajmniej na modemach f-my Huawei (sprawdzałem w sumie na 4-ech popularnych modelach, m.in. na tym co w temacie w sieciach Play,Orange,Plus - Play i Plus na starterach, Orange na starterze/abonamencie).

Co za bzdury piszesz-czy to stary czy nowy sterownik NCM, w przypadku utrzymywania połączenia oba działają dobrze (stary ma kiepskie parametry połączenia z siecią-ping, stabilność transferu). Jak się chce stabilności, to też należy zapewnić takowe warunki modemowi aby działał prawidłowo (zasilanie, poziom sygnału LTE, wymuszony ruch w sieci). W tej chwili używam 3 modemów Huawei do LTE: E398,E3276, E3372 i z żadnym nie mam problemu (pracują na sieci Plus/Play).

8

Odp: Problem z częstym rozłączaniem się modemu E3276 na WNDR4300

Dziękuję za zainteresowanie się tematem. Właśnie modem rozłączył mi się ponownie, wywalając z gry big_smile

3G Info wskazuje:

# 3ginfo
Status: Połączony
Czas polaczenia: 0d, 00:12:51
Przeslano danych: 102.6 MiB / 5.1 MiB
Operator: Plus
Tryb pracy: LTE
Sila sygnalu: 67%
Urzadzenie: huawei E3276
MCC MNC: 260 01
LAC: 7D06 (32006)
LCID: 00863801 (8796161)
RNC: - (-)
eNB: 008638 (34360)
CID: 0001 (1)
CSQ: 21
RSSI: -71 dBm
RSCP: -145 dBm
Ec/IO: -32 dB
RSRP: -103 dBm
RSRQ: -13 dB

Ta prędkość wysyłania od kiedy pamiętam zawsze była taka sama. W każdym razie, modem potrafił utrzymać stabilne połączenie przez te 24 godziny.

Trochę to dziwne że na tej samej sieci jest tak różne zachowywanie adresów IP-używam Plusa i odnawia mi co 2-3 tygodnie, więcej na dodatkowym pakiecie Aero2 (również działa na sieci LTE-poza opcją free), takie odnowienia adresu nie występowały (też jesteś pierszą osobą w sieci, która się spotkałem że zgłasza taką niedogodność). Jednakże czy to stary sterownik NCM, czy nowy nigdy pod tym względem nie miałem zastrzeżeń do działania pod OpenWRT.

Też mnie to dziwi własnie, bo nikt jeszcze nie potwierdził że ma tak samo, natomiast ja wysyłałem zgłoszenia techniczne do operatora w tej sprawie, najpierw upierali się, że to zależy od ustawień routera, potem "instruowali" jak zmienić czas dzierżawy DHCP, bo to niby od tego zależy, potem wysłali odpowiedź, że w umowie jest coś takiego że mogą w celu "podliczenia" zerwać połączenie po 24h i zasugerowali mi ręczny reconnect, przed upływem 24h, jeśli mam robić coś ważnego... pozostawię to już bez zbędnego komentarza. W każdym razie jakoś nie przeszkadzało to, kiedy modem zawieszał się i łączył ponownie w środku nocy.

Czyli potwierdza się w nieskończonej ilości postów, że trzyma połączenie jak skała tylko u jednego operatora:
Orange-Freenet (LTE lub niżej) na abonament z usługą apn: vpn.

Mam złe wspomnienia z czasów Orange, jeszcze z HSDPA+DC. Połączenia może i były stabilne, ale za to nie potrafili normalnie zliczać połączeń, zwłaszcza w "(nie)szczęśliwych godzinach". Tak więc z zadowoleniem przyjęliśmy rozstanie się z nimi smile

Jesteś w stanie przetestować sobie DL/UL w tej samej lokalizacji na PC (modem w PC)?

Niestety nie mam możliwości dłuższego testowania samego modemu podpiętego do laptopa (brat i rodzice korzystają z Internetu w tym samym czasie), natomiast w przeszłości robiłem testy prędkości na komputerze i wyniki były niemal identyczne. Upload nigdy nie przekraczał ~12Mb/s.
Nie mam również możliwości przetestowania na innym modemie (mam inne modemy, które działają tylko w 3G, a "lte bez limitu" uniemożliwiałoby korzystanie z... nazwijmy to minimalną prędkością, potrzebną do normalnego korzystania z Internetu).
Zapomniałem o dość istotnym szczególe: korzystam z anteny zewnętrznej podpiętej dwoma kabelkami do modemu. Nie jest to antena "drut" tylko normalna (chyba nazywa się to dachowa), mam ją w oknie. Natomiast nie wydaje mi się, aby to było problemem, ponieważ jak pisałem w tym nieszczęsnym DWR116 jako-tako połączenie się utrzymywało, no i również testowałem przez kilka godzin z odłączoną anteną, na wolniejszych prędkościach z tym samym rezultatem.

Protokół w sumie tez możesz zmienić. Ale jedno na raz, żebyś wiedział co było ew. przyczyną.

A jakiego jeszcze protokołu mogę używać w tym modemie zamiast NCM?

Czy mogę również prosić o jakiś link do instrukcji / pokierowanie mnie jak zainstalować starszy sterownik NCM (dla testu)?

9

Odp: Problem z częstym rozłączaniem się modemu E3276 na WNDR4300

Aj, nie możesz oczywiście zmienić protokołu, on jest tylko ncm, sorry. Nie ma starszej wersji sterowników, musisz instalować starszą wersją systemu na innym kernelu.

Masz niepotrzebny router, uszkodzony czy nie - chętnie przygarnę go.

10

Odp: Problem z częstym rozłączaniem się modemu E3276 na WNDR4300

U mnie nie wiem co się dzieje mam taki sam modem podłączony do routera nexx wt3020. Na sofcie Cezarego i sciagniemym z dev.openwrt ten sam problem.

Sun Dec 13 11:20:35 2015 kern.err kernel: [  252.270000] huawei_cdc_ncm 1-1:1.1 wwan0: kevent 12 may have been dropped
Sun Dec 13 11:20:35 2015 daemon.notice netifd: Interface 'wan_4' is enabled
Sun Dec 13 11:20:35 2015 daemon.notice netifd: Interface 'wan_6' is enabled
Sun Dec 13 11:20:35 2015 daemon.notice netifd: Interface 'wan' is now up
Sun Dec 13 11:20:35 2015 daemon.notice netifd: Network device 'wwan0' link is up
Sun Dec 13 11:20:35 2015 daemon.notice netifd: Network alias 'wwan0' link is up
Sun Dec 13 11:20:35 2015 daemon.notice netifd: Interface 'wan_4' has link connectivity 
Sun Dec 13 11:20:35 2015 daemon.notice netifd: Interface 'wan_4' is setting up now
Sun Dec 13 11:20:35 2015 daemon.notice netifd: Interface 'wan_6' has link connectivity 
Sun Dec 13 11:20:35 2015 daemon.notice netifd: Interface 'wan_6' is setting up now
Sun Dec 13 11:20:35 2015 daemon.notice netifd: wan (6455): Command failed: Unknown error
Sun Dec 13 11:20:35 2015 daemon.notice netifd: wan (6455): Command failed: Unknown error
Sun Dec 13 11:20:35 2015 daemon.notice netifd: wan_4 (6568): udhcpc (v1.23.2) started
Sun Dec 13 11:20:36 2015 user.notice firewall: Reloading firewall due to ifup of wan (wwan0)
Sun Dec 13 11:20:36 2015 daemon.notice netifd: wan_4 (6568): Sending discover...
Sun Dec 13 11:20:36 2015 daemon.notice netifd: wan_4 (6568): Sending select for 10.183.128.212...
Sun Dec 13 11:20:36 2015 daemon.notice netifd: wan_4 (6568): Lease of 10.183.128.212 obtained, lease time 518400
Sun Dec 13 11:20:36 2015 daemon.notice netifd: Interface 'wan_4' is now up
Sun Dec 13 11:20:36 2015 daemon.info dnsmasq[1584]: reading /tmp/resolv.conf.auto
Sun Dec 13 11:20:36 2015 daemon.info dnsmasq[1584]: using local addresses only for domain lan
Sun Dec 13 11:20:36 2015 daemon.info dnsmasq[1584]: using nameserver 89.108.202.21#53
Sun Dec 13 11:20:36 2015 daemon.info dnsmasq[1584]: using nameserver 89.108.195.21#53
Sun Dec 13 11:20:44 2015 kern.info kernel: [  261.350000] usb 1-1: USB disconnect, device number 18
Sun Dec 13 11:20:44 2015 kern.info kernel: [  261.360000] option1 ttyUSB0: GSM modem (1-port) converter now disconnected from ttyUSB0
Sun Dec 13 11:20:44 2015 kern.info kernel: [  261.380000] option 1-1:1.0: device disconnected
Sun Dec 13 11:20:44 2015 kern.info kernel: [  261.390000] huawei_cdc_ncm 1-1:1.1 wwan0: unregister 'huawei_cdc_ncm' usb-101c0000.ehci-1, Huawei CDC NCM device
Sun Dec 13 11:20:44 2015 kern.notice kernel: [  261.430000] sd 27:0:0:0: [sda] Synchronizing SCSI cache
Sun Dec 13 11:20:44 2015 kern.info kernel: [  261.440000] sd 27:0:0:0: [sda]  
Sun Dec 13 11:20:44 2015 kern.warn kernel: [  261.450000] Result: hostbyte=0x01 driverbyte=0x00
Sun Dec 13 11:20:44 2015 daemon.notice netifd: Network device 'wwan0' link is down
Sun Dec 13 11:20:44 2015 daemon.notice netifd: Network alias 'wwan0' link is down
Sun Dec 13 11:20:44 2015 daemon.notice netifd: Interface 'wan_4' has link connectivity loss
Sun Dec 13 11:20:44 2015 daemon.notice netifd: Interface 'wan_6' has link connectivity loss
Sun Dec 13 11:20:44 2015 daemon.notice netifd: Interface 'wan_4' is disabled
Sun Dec 13 11:20:44 2015 daemon.notice netifd: Interface 'wan_6' is disabled
Sun Dec 13 11:20:44 2015 daemon.notice netifd: wan (6717): Stopping network
Sun Dec 13 11:20:45 2015 daemon.notice netifd: wan_4 (6568): udhcpc: SIOCGIFINDEX: No such device
Sun Dec 13 11:20:45 2015 daemon.notice netifd: wan_4 (6568): Received SIGTERM
Sun Dec 13 11:20:45 2015 daemon.notice netifd: wan (6717): Can't open device /dev/ttyUSB0.
Sun Dec 13 11:20:45 2015 daemon.notice netifd: wan (6717): Failed to disconnect
Sun Dec 13 11:20:45 2015 kern.info kernel: [  261.790000] usb 1-1: new high-speed USB device number 19 using ehci-platform
Sun Dec 13 11:20:45 2015 daemon.notice netifd: Interface 'wan' is now down
Sun Dec 13 11:20:45 2015 daemon.warn dnsmasq[1584]: no servers found in /tmp/resolv.conf.auto, will retry
Sun Dec 13 11:20:45 2015 kern.debug kernel: [  261.970000] usb 1-1: no of_node; not parsing pinctrl DT
Sun Dec 13 11:20:45 2015 kern.debug kernel: [  261.990000] option 1-1:1.0: no of_node; not parsing pinctrl DT
Sun Dec 13 11:20:45 2015 kern.info kernel: [  262.000000] option 1-1:1.0: GSM modem (1-port) converter detected
Sun Dec 13 11:20:45 2015 kern.debug kernel: [  262.010000] option1 ttyUSB0: no of_node; not parsing pinctrl DT
Sun Dec 13 11:20:45 2015 kern.info kernel: [  262.020000] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB0
Sun Dec 13 11:20:45 2015 kern.debug kernel: [  262.040000] huawei_cdc_ncm 1-1:1.1: no of_node; not parsing pinctrl DT
Sun Dec 13 11:20:45 2015 kern.info kernel: [  262.050000] huawei_cdc_ncm 1-1:1.1: MAC-Address: 0c:5b:8f:27:9a:64
Sun Dec 13 11:20:45 2015 kern.info kernel: [  262.070000] huawei_cdc_ncm 1-1:1.1: setting rx_max = 16384
Sun Dec 13 11:20:45 2015 kern.info kernel: [  262.160000] huawei_cdc_ncm 1-1:1.1: setting tx_max = 16384
Sun Dec 13 11:20:45 2015 kern.info kernel: [  262.200000] huawei_cdc_ncm 1-1:1.1: cdc-wdm0: USB WDM device
Sun Dec 13 11:20:45 2015 kern.info kernel: [  262.210000] huawei_cdc_ncm 1-1:1.1 wwan0: register 'huawei_cdc_ncm' at usb-101c0000.ehci-1, Huawei CDC NCM device, 0c:5b:8f:27:9a:64
Sun Dec 13 11:20:45 2015 kern.debug kernel: [  262.240000] usb-storage 1-1:1.2: no of_node; not parsing pinctrl DT
Sun Dec 13 11:20:45 2015 kern.info kernel: [  262.250000] usb-storage 1-1:1.2: USB Mass Storage device detected
Sun Dec 13 11:20:45 2015 kern.info kernel: [  262.270000] scsi host28: usb-storage 1-1:1.2
Sun Dec 13 11:20:45 2015 kern.debug kernel: [  262.270000] usb-storage 1-1:1.3: no of_node; not parsing pinctrl DT
Sun Dec 13 11:20:45 2015 kern.info kernel: [  262.290000] usb-storage 1-1:1.3: USB Mass Storage device detected
Sun Dec 13 11:20:45 2015 kern.info kernel: [  262.300000] scsi host29: usb-storage 1-1:1.3
Sun Dec 13 11:20:46 2015 kern.notice kernel: [  263.270000] scsi 28:0:0:0: CD-ROM            HUAWEI   Mass Storage     2.31 PQ: 0 ANSI: 2
Sun Dec 13 11:20:46 2015 kern.debug kernel: [  263.280000] sd 28:0:0:0: no of_node; not parsing pinctrl DT
Sun Dec 13 11:20:46 2015 kern.notice kernel: [  263.310000] scsi 29:0:0:0: Direct-Access     HUAWEI   TF CARD Storage  2.31 PQ: 0 ANSI: 2
Sun Dec 13 11:20:46 2015 kern.debug kernel: [  263.320000] sd 29:0:0:0: no of_node; not parsing pinctrl DT
Sun Dec 13 11:20:46 2015 kern.notice kernel: [  263.350000] sd 29:0:0:0: [sda] 1984000 512-byte logical blocks: (1.01 GB/968 MiB)
Sun Dec 13 11:20:46 2015 kern.notice kernel: [  263.370000] sd 29:0:0:0: [sda] Write Protect is off
Sun Dec 13 11:20:46 2015 kern.debug kernel: [  263.380000] sd 29:0:0:0: [sda] Mode Sense: 0f 00 00 00
Sun Dec 13 11:20:46 2015 kern.notice kernel: [  263.420000] sd 29:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Sun Dec 13 11:20:46 2015 kern.info kernel: [  263.460000]  sda: sda1 sda2
Sun Dec 13 11:20:46 2015 kern.notice kernel: [  263.500000] sd 29:0:0:0: [sda] Attached SCSI removable disk
Sun Dec 13 11:20:47 2015 daemon.notice netifd: Interface 'wan' is setting up now
Sun Dec 13 11:20:49 2015 daemon.notice netifd: wan (6952): sending -> AT
Sun Dec 13 11:20:50 2015 daemon.notice netifd: wan (6952): sending -> ATZ
Sun Dec 13 11:20:51 2015 daemon.notice netifd: wan (6952): sending -> ATQ0
Sun Dec 13 11:20:51 2015 daemon.notice netifd: wan (6952): sending -> ATV1
Sun Dec 13 11:20:52 2015 daemon.notice netifd: wan (6952): sending -> ATE1
Sun Dec 13 11:20:52 2015 daemon.notice netifd: wan (6952): sending -> ATS0=0
Sun Dec 13 11:20:53 2015 daemon.notice netifd: wan (6952): sending -> AT^NDISDUP=1,1,"internet"
Sun Dec 13 11:20:54 2015 daemon.notice netifd: wan (6952): Connected, starting DHCP
Sun Dec 13 11:20:54 2015 kern.err kernel: [  270.720000] huawei_cdc_ncm 1-1:1.1 wwan0: kevent 12 may have been dropped
Sun Dec 13 11:20:54 2015 daemon.notice netifd: Interface 'wan_4' is enabled
Sun Dec 13 11:20:54 2015 daemon.notice netifd: Interface 'wan_6' is enabled
Sun Dec 13 11:20:54 2015 daemon.notice netifd: Interface 'wan' is now up
Sun Dec 13 11:20:54 2015 daemon.notice netifd: Network device 'wwan0' link is up
Sun Dec 13 11:20:54 2015 daemon.notice netifd: Network alias 'wwan0' link is up
Sun Dec 13 11:20:54 2015 daemon.notice netifd: Interface 'wan_4' has link connectivity 
Sun Dec 13 11:20:54 2015 daemon.notice netifd: Interface 'wan_4' is setting up now
Sun Dec 13 11:20:54 2015 daemon.notice netifd: Interface 'wan_6' has link connectivity 
Sun Dec 13 11:20:54 2015 daemon.notice netifd: Interface 'wan_6' is setting up now
Sun Dec 13 11:20:54 2015 daemon.notice netifd: wan (6952): Command failed: Unknown error
Sun Dec 13 11:20:54 2015 daemon.notice netifd: wan (6952): Command failed: Unknown error
Sun Dec 13 11:20:54 2015 daemon.notice netifd: wan_4 (7062): udhcpc (v1.23.2) started
Sun Dec 13 11:20:54 2015 daemon.notice netifd: wan_4 (7062): Sending discover...
Sun Dec 13 11:20:54 2015 daemon.notice netifd: wan_4 (7062): Sending select for 10.183.128.212...
Sun Dec 13 11:20:54 2015 daemon.notice netifd: wan_4 (7062): Lease of 10.183.128.212 obtained, lease time 518400
Sun Dec 13 11:20:54 2015 user.notice firewall: Reloading firewall due to ifup of wan (wwan0)
Sun Dec 13 11:20:54 2015 daemon.notice netifd: Interface 'wan_4' is now up
Sun Dec 13 11:20:54 2015 daemon.info dnsmasq[1584]: reading /tmp/resolv.conf.auto
Sun Dec 13 11:20:54 2015 daemon.info dnsmasq[1584]: using local addresses only for domain lan
Sun Dec 13 11:20:54 2015 daemon.info dnsmasq[1584]: using nameserver 89.108.202.21#53
Sun Dec 13 11:20:54 2015 daemon.info dnsmasq[1584]: using nameserver 89.108.195.21#53
Sun Dec 13 11:20:55 2015 kern.info kernel: [  272.220000] usb 1-1: USB disconnect, device number 19
Sun Dec 13 11:20:55 2015 kern.info kernel: [  272.230000] option1 ttyUSB0: GSM modem (1-port) converter now disconnected from ttyUSB0
Sun Dec 13 11:20:55 2015 kern.info kernel: [  272.250000] option 1-1:1.0: device disconnected
Sun Dec 13 11:20:55 2015 daemon.notice netifd: Network device 'wwan0' link is down
Sun Dec 13 11:20:55 2015 daemon.notice netifd: Network alias 'wwan0' link is down
Sun Dec 13 11:20:55 2015 daemon.notice netifd: Interface 'wan_4' has link connectivity loss
Sun Dec 13 11:20:55 2015 kern.info kernel: [  272.280000] huawei_cdc_ncm 1-1:1.1 wwan0: unregister 'huawei_cdc_ncm' usb-101c0000.ehci-1, Huawei CDC NCM device
Sun Dec 13 11:20:55 2015 daemon.notice netifd: Interface 'wan_6' has link connectivity loss
Sun Dec 13 11:20:55 2015 daemon.notice netifd: Interface 'wan_4' is disabled
Sun Dec 13 11:20:55 2015 daemon.notice netifd: Interface 'wan_6' is disabled
Sun Dec 13 11:20:55 2015 kern.notice kernel: [  272.400000] sd 29:0:0:0: [sda] Synchronizing SCSI cache
Sun Dec 13 11:20:55 2015 kern.info kernel: [  272.410000] sd 29:0:0:0: [sda]  
Sun Dec 13 11:20:55 2015 kern.warn kernel: [  272.410000] Result: hostbyte=0x01 driverbyte=0x00
Sun Dec 13 11:20:55 2015 daemon.notice netifd: wan_4 (7062): udhcpc: SIOCGIFINDEX: No such device
Sun Dec 13 11:20:55 2015 daemon.notice netifd: wan_4 (7062): Received SIGTERM
Sun Dec 13 11:20:56 2015 daemon.notice netifd: wan (7142): Stopping network
Sun Dec 13 11:20:56 2015 kern.info kernel: [  272.770000] usb 1-1: new high-speed USB device number 20 using ehci-platform
Sun Dec 13 11:20:56 2015 daemon.notice netifd: wan (7142): Can't open device /dev/ttyUSB0.
Sun Dec 13 11:20:56 2015 daemon.notice netifd: wan (7142): Failed to disconnect
Sun Dec 13 11:20:56 2015 kern.debug kernel: [  272.950000] usb 1-1: no of_node; not parsing pinctrl DT
Sun Dec 13 11:20:56 2015 kern.debug kernel: [  272.990000] option 1-1:1.0: no of_node; not parsing pinctrl DT
Sun Dec 13 11:20:56 2015 kern.info kernel: [  273.000000] option 1-1:1.0: GSM modem (1-port) converter detected
Sun Dec 13 11:20:56 2015 kern.debug kernel: [  273.010000] option1 ttyUSB0: no of_node; not parsing pinctrl DT
Sun Dec 13 11:20:56 2015 kern.info kernel: [  273.020000] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB0
Sun Dec 13 11:20:56 2015 kern.debug kernel: [  273.040000] huawei_cdc_ncm 1-1:1.1: no of_node; not parsing pinctrl DT
Sun Dec 13 11:20:56 2015 kern.info kernel: [  273.050000] huawei_cdc_ncm 1-1:1.1: MAC-Address: xx:xx:xx:xx:xx:xx
Sun Dec 13 11:20:56 2015 kern.info kernel: [  273.070000] huawei_cdc_ncm 1-1:1.1: setting rx_max = 16384
Sun Dec 13 11:20:56 2015 kern.info kernel: [  273.120000] huawei_cdc_ncm 1-1:1.1: setting tx_max = 16384
Sun Dec 13 11:20:56 2015 kern.info kernel: [  273.140000] huawei_cdc_ncm 1-1:1.1: cdc-wdm0: USB WDM device
Sun Dec 13 11:20:56 2015 kern.info kernel: [  273.150000] huawei_cdc_ncm 1-1:1.1 wwan0: register 'huawei_cdc_ncm' at usb-101c0000.ehci-1, Huawei CDC NCM device, 0c:5b:8f:27:9a:64
Sun Dec 13 11:20:56 2015 kern.debug kernel: [  273.170000] usb-storage 1-1:1.2: no of_node; not parsing pinctrl DT
Sun Dec 13 11:20:56 2015 kern.info kernel: [  273.180000] usb-storage 1-1:1.2: USB Mass Storage device detected
Sun Dec 13 11:20:56 2015 kern.info kernel: [  273.200000] scsi host30: usb-storage 1-1:1.2
Sun Dec 13 11:20:56 2015 kern.debug kernel: [  273.210000] usb-storage 1-1:1.3: no of_node; not parsing pinctrl DT
Sun Dec 13 11:20:56 2015 kern.info kernel: [  273.220000] usb-storage 1-1:1.3: USB Mass Storage device detected
Sun Dec 13 11:20:56 2015 kern.info kernel: [  273.240000] scsi host31: usb-storage 1-1:1.3
Sun Dec 13 11:20:56 2015 kern.info kernel: [  273.240000] usb 1-1: USB disconnect, device number 20
Sun Dec 13 11:20:56 2015 kern.info kernel: [  273.260000] option1 ttyUSB0: GSM modem (1-port) converter now disconnected from ttyUSB0
Sun Dec 13 11:20:56 2015 kern.info kernel: [  273.270000] option 1-1:1.0: device disconnected
Sun Dec 13 11:20:56 2015 kern.info kernel: [  273.280000] huawei_cdc_ncm 1-1:1.1 wwan0: unregister 'huawei_cdc_ncm' usb-101c0000.ehci-1, Huawei CDC NCM device
Sun Dec 13 11:20:56 2015 daemon.notice netifd: Interface 'wan' is now down
Sun Dec 13 11:20:56 2015 daemon.warn dnsmasq[1584]: no servers found in /tmp/resolv.conf.auto, will retry
Sun Dec 13 11:20:57 2015 kern.info kernel: [  273.650000] usb 1-1: new high-speed USB device number 21 using ehci-platform
Sun Dec 13 11:20:57 2015 kern.debug kernel: [  273.830000] usb 1-1: no of_node; not parsing pinctrl DT
Sun Dec 13 11:20:57 2015 kern.debug kernel: [  273.860000] option 1-1:1.0: no of_node; not parsing pinctrl DT
Sun Dec 13 11:20:57 2015 kern.info kernel: [  273.870000] option 1-1:1.0: GSM modem (1-port) converter detected
Sun Dec 13 11:20:57 2015 kern.debug kernel: [  273.880000] option1 ttyUSB0: no of_node; not parsing pinctrl DT
Sun Dec 13 11:20:57 2015 kern.info kernel: [  273.890000] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB0
Sun Dec 13 11:20:57 2015 kern.debug kernel: [  273.910000] huawei_cdc_ncm 1-1:1.1: no of_node; not parsing pinctrl DT
Sun Dec 13 11:20:57 2015 kern.info kernel: [  273.930000] huawei_cdc_ncm 1-1:1.1: MAC-Address: 0c:5b:8f:27:9a:64
Sun Dec 13 11:20:57 2015 kern.info kernel: [  273.940000] huawei_cdc_ncm 1-1:1.1: setting rx_max = 16384
Sun Dec 13 11:20:57 2015 kern.info kernel: [  274.000000] huawei_cdc_ncm 1-1:1.1: setting tx_max = 16384
Sun Dec 13 11:20:57 2015 kern.info kernel: [  274.030000] huawei_cdc_ncm 1-1:1.1: cdc-wdm0: USB WDM device
Sun Dec 13 11:20:57 2015 kern.info kernel: [  274.050000] huawei_cdc_ncm 1-1:1.1 wwan0: register 'huawei_cdc_ncm' at usb-101c0000.ehci-1, Huawei CDC NCM device, 0c:5b:8f:27:9a:64
Sun Dec 13 11:20:57 2015 kern.debug kernel: [  274.070000] usb-storage 1-1:1.2: no of_node; not parsing pinctrl DT
Sun Dec 13 11:20:57 2015 kern.info kernel: [  274.080000] usb-storage 1-1:1.2: USB Mass Storage device detected
Sun Dec 13 11:20:57 2015 kern.info kernel: [  274.100000] scsi host32: usb-storage 1-1:1.2
Sun Dec 13 11:20:57 2015 kern.debug kernel: [  274.110000] usb-storage 1-1:1.3: no of_node; not parsing pinctrl DT
Sun Dec 13 11:20:57 2015 kern.info kernel: [  274.120000] usb-storage 1-1:1.3: USB Mass Storage device detected
Sun Dec 13 11:20:57 2015 kern.info kernel: [  274.130000] scsi host33: usb-storage 1-1:1.3
Sun Dec 13 11:20:58 2015 kern.info kernel: [  274.810000] usb 1-1: USB disconnect, device number 21
Sun Dec 13 11:20:58 2015 kern.info kernel: [  274.830000] option1 ttyUSB0: GSM modem (1-port) converter now disconnected from ttyUSB0
Sun Dec 13 11:20:58 2015 kern.info kernel: [  274.840000] option 1-1:1.0: device disconnected
Sun Dec 13 11:20:58 2015 kern.info kernel: [  274.850000] huawei_cdc_ncm 1-1:1.1 wwan0: unregister 'huawei_cdc_ncm' usb-101c0000.ehci-1, Huawei CDC NCM device
Sun Dec 13 11:20:58 2015 kern.info kernel: [  275.200000] usb 1-1: new high-speed USB device number 22 using ehci-platform
Sun Dec 13 11:20:58 2015 kern.debug kernel: [  275.400000] usb 1-1: no of_node; not parsing pinctrl DT
Sun Dec 13 11:20:58 2015 kern.debug kernel: [  275.430000] option 1-1:1.0: no of_node; not parsing pinctrl DT
Sun Dec 13 11:20:58 2015 kern.info kernel: [  275.440000] option 1-1:1.0: GSM modem (1-port) converter detected
Sun Dec 13 11:20:58 2015 kern.debug kernel: [  275.450000] option1 ttyUSB0: no of_node; not parsing pinctrl DT
Sun Dec 13 11:20:58 2015 kern.info kernel: [  275.460000] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB0
Sun Dec 13 11:20:58 2015 kern.debug kernel: [  275.480000] huawei_cdc_ncm 1-1:1.1: no of_node; not parsing pinctrl DT
Sun Dec 13 11:20:58 2015 kern.info kernel: [  275.490000] huawei_cdc_ncm 1-1:1.1: MAC-Address xx:xx:xx:xx:xx:xx
Sun Dec 13 11:20:58 2015 kern.info kernel: [  275.510000] huawei_cdc_ncm 1-1:1.1: setting rx_max = 16384
Sun Dec 13 11:20:58 2015 kern.info kernel: [  275.580000] huawei_cdc_ncm 1-1:1.1: setting tx_max = 16384
Sun Dec 13 11:20:59 2015 kern.info kernel: [  275.620000] huawei_cdc_ncm 1-1:1.1: cdc-wdm0: USB WDM device
Sun Dec 13 11:20:59 2015 kern.info kernel: [  275.630000] huawei_cdc_ncm 1-1:1.1 wwan0: register 'huawei_cdc_ncm' at usb-101c0000.ehci-1, Huawei CDC NCM device, 0c:5b:8f:27:9a:64
Sun Dec 13 11:20:59 2015 kern.debug kernel: [  275.650000] usb-storage 1-1:1.2: no of_node; not parsing pinctrl DT
Sun Dec 13 11:20:59 2015 kern.info kernel: [  275.660000] usb-storage 1-1:1.2: USB Mass Storage device detected
Sun Dec 13 11:20:59 2015 kern.info kernel: [  275.680000] scsi host34: usb-storage 1-1:1.2
Sun Dec 13 11:20:59 2015 kern.debug kernel: [  275.690000] usb-storage 1-1:1.3: no of_node; not parsing pinctrl DT
Sun Dec 13 11:20:59 2015 kern.info kernel: [  275.700000] usb-storage 1-1:1.3: USB Mass Storage device detected
Sun Dec 13 11:20:59 2015 kern.info kernel: [  275.740000] scsi host35: usb-storage 1-1:1.3
Sun Dec 13 11:20:59 2015 kern.err kernel: [  275.950000] usb usb1-port1: disabled by hub (EMI?), re-enabling...
Sun Dec 13 11:20:59 2015 kern.info kernel: [  275.970000] usb 1-1: USB disconnect, device number 22
Sun Dec 13 11:20:59 2015 kern.info kernel: [  275.980000] option1 ttyUSB0: GSM modem (1-port) converter now disconnected from ttyUSB0
Sun Dec 13 11:20:59 2015 kern.info kernel: [  275.990000] option 1-1:1.0: device disconnected
Sun Dec 13 11:20:59 2015 kern.info kernel: [  276.000000] huawei_cdc_ncm 1-1:1.1 wwan0: unregister 'huawei_cdc_ncm' usb-101c0000.ehci-1, Huawei CDC NCM device

Dodam że 2-3 tyg było bez problemu, zmienialem ładowarek i kabel bez skutku, zmiana softu nie pomaga... Ma ktoś podobny problem? Z góry dziękuje za odpowiedzi.

11

Odp: Problem z częstym rozłączaniem się modemu E3276 na WNDR4300

Rozłączyło ci urządzenie na magistrali. Jesteś pewien tego zasilacza?

Masz niepotrzebny router, uszkodzony czy nie - chętnie przygarnę go.

12

Odp: Problem z częstym rozłączaniem się modemu E3276 na WNDR4300

Jak zawsze Cezary ma racje smile odgialem troche styki w gniezdzie usb w ladowarce i pomoglo. Dzieki za podpowiedz wink

13

Odp: Problem z częstym rozłączaniem się modemu E3276 na WNDR4300

Nie ma starszej wersji sterowników, musisz instalować starszą wersją systemu na innym kernelu.

Aj... Nie lubię downgradeów, pewnie zaraz pojawiłyby się nowe problemy. Ale teoretycznie, jeśli wgrałbym "Barrier Breaker LuCI - 14.07" to te sterowniki będą starsze? Czy szukać jeszcze coś starszego, np. 12.09?

Spróbuję może jeszcze może zrobić coś w stylu: http://eko.one.pl/forum/viewtopic.php?p … 05#p153705
Czyli ping co 20 sekund, jeśli nie działa to zmiana na UMTS, po chwili z powrotem na LTE. Na pewno taki zabieg zająłby mniej czasu niż reconnect. Muszę pobawić się tymi komendami AT smile Chociaż i tak takie coś nie rozwiązałoby przyczyny problemu...

14

Odp: Problem z częstym rozłączaniem się modemu E3276 na WNDR4300

I AA i BB i CC mają inne kernele.

Masz niepotrzebny router, uszkodzony czy nie - chętnie przygarnę go.

15

Odp: Problem z częstym rozłączaniem się modemu E3276 na WNDR4300

OK, chyba "wykryłem" problem.
Ogólnie to jest bardzo dziwna sprawa, postaram się opisać co się dzieje, i również prosiłbym kogoś w miarę możliwości o spróbowanie na swoim modemie (zwłaszcza w sieci Plus / Cyfrowy Polsat).
W poście: http://eko.one.pl/forum/viewtopic.php?p … 76#p148476 znalazłem i lekko przerobiłem skrypt, nazwijmy go: czestotliwosc.sh:

#!/bin/sh
PORT=$(uci get network.wan.device)

case $1 in

"auto")
echo "Setting AUTO band selection..."
MODE='AT^SYSCFGEX="030201",3FFFFFFF,2,4,7FFFFFFFFFFFFFFF,,' gcom -d $PORT -s /etc/gcom/setmode.gcom
exit 0 ;;

"umts")
echo "Setting UMTS only - all bands..."
MODE='AT^SYSCFGEX="02",3FFFFFFF,2,4,7FFFFFFFFFFFFFFF,,' gcom -d $PORT -s /etc/gcom/setmode.gcom
exit 0 ;;

"lte")
echo "Setting LTE only - all bands..."
MODE='AT^SYSCFGEX="03",3FFFFFFF,2,4,7FFFFFFFFFFFFFFF,,' gcom -d $PORT -s /etc/gcom/setmode.gcom
exit 0 ;;

"u2100")
echo "Setting UMTS 2100 only..."
MODE='AT^SYSCFGEX="02",00400000,2,4,7FFFFFFFFFFFFFFF,,' gcom -d $PORT -s /etc/gcom/setmode.gcom
exit 0 ;;

"u900")
echo "Setting UMTS 900 only..."
MODE='AT^SYSCFGEX="02",2000000000000,2,4,7FFFFFFFFFFFFFFF,,' gcom -d $PORT -s /etc/gcom/setmode.gcom
exit 0 ;;

"l2600")
echo "Setting LTE 2600 only..."
MODE='AT^SYSCFGEX="03",3FFFFFFF,2,4,40,,' gcom -d $PORT -s /etc/gcom/setmode.gcom
exit 0 ;;

"l1800")
echo "Setting LTE 1800 only..."
MODE='AT^SYSCFGEX="03",3FFFFFFF,2,4,4,,' gcom -d $PORT -s /etc/gcom/setmode.gcom
exit 0 ;;

"l800")
echo "Setting LTE 800 only..."
MODE='AT^SYSCFGEX="03",3FFFFFFF,2,4,80000,,' gcom -d $PORT -s /etc/gcom/setmode.gcom
exit 0 ;;

*)
echo "Wrong or no RAT selected !"

esac

Załóżmy, że modem jest normalnie połączony z Internetem.
Po wywołaniu:

./czestotliwosc.sh umts

Internet przestaje działać, router nie może pingować 8.8.8.8.
3G info pokazuje normalny zasięg, ~30-40% WCDMA, wiem że mało ale co poradzić.
Po wywołaniu:

./czestotliwosc.sh lte

3G info pokazuje już wybrane LTE z zasięgiem ~70%, natomiast Internet dalej nie działa. Nie da się pingować 8.8.8.8
komenda "ifup wan" nie pomaga, natomiast pomaga jeśli zrobimy: "ifdown wan", a potem: "ifup wan". Wydawało mi się, że samo "ifup wan" powinno wystarczyć (przynajmniej tak kiedyś robiłem reconnect połączenia).

Nie umiem tego zinterpretować (pewnie przez małą wiedzę na temat modemów, routerów itd.), więc zapytam: czy to normalne, że po zmianie częstotliwości (czy tam bandu, nie wiem jak poprawnie nazywać) połączenie się zawiesza, aż do ręcznego restartu? Według mnie powinno się wznowić, utrzymać.
Jeśli ktoś ma jakiś pomysł o co z tym wszystkim chodzi, byłbym wdzięczny za wszelkie wskazówki smile

16 (edytowany przez jarek7714 2015-12-14 23:37:43)

Odp: Problem z częstym rozłączaniem się modemu E3276 na WNDR4300

Przmus napisał/a:

3G Info wskazuje:

# 3ginfo
Status: Połączony
Czas polaczenia: 0d, 00:12:51
Przeslano danych: 102.6 MiB / 5.1 MiB
Operator: Plus
Tryb pracy: LTE
Sila sygnalu: 67%
Urzadzenie: huawei E3276
MCC MNC: 260 01
LAC: 7D06 (32006)
LCID: 00863801 (8796161)
RNC: - (-)
eNB: 008638 (34360)
CID: 0001 (1)
CSQ: 21
RSSI: -71 dBm
RSCP: -145 dBm
Ec/IO: -32 dB
RSRP: -103 dBm
RSRQ: -13 dB

Ta prędkość wysyłania od kiedy pamiętam zawsze była taka sama. W każdym razie, modem potrafił utrzymać stabilne połączenie przez te 24 godziny.

Też mnie to dziwi własnie, bo nikt jeszcze nie potwierdził że ma tak samo, natomiast ja wysyłałem zgłoszenia techniczne do operatora w tej sprawie, najpierw upierali się, że to zależy od ustawień routera, potem "instruowali" jak zmienić czas dzierżawy DHCP, bo to niby od tego zależy, potem wysłali odpowiedź, że w umowie jest coś takiego że mogą w celu "podliczenia" zerwać połączenie po 24h i zasugerowali mi ręczny reconnect, przed upływem 24h, jeśli mam robić coś ważnego... pozostawię to już bez zbędnego komentarza. W każdym razie jakoś nie przeszkadzało to, kiedy modem zawieszał się i łączył ponownie w środku nocy.

Ww wskaźniki sygnału masz dobre (zwłaszcza że z anteny zewnętrznej, nie powinno być problemów ze stabilnością). Szkoda że nie możesz stabilności połączenia z komfrontować na komputerze-być może problem jest po stronie operatora (autoryzacja karty SIM/przypisanie usług na serwerze operatora)-miałem tak kiedyś, tylko że u mnie objaw był taki że wywalało totallnie z LTE, a czasami nawet HSPA włączało jakiś lejek. Niestety, rozmowa z BOK CP to rozmowa z koniem (w Plusie miałem podobnie, z tym że tam co niektórzy pamiętają jeszcze dawne standardy- sami mówili w dziale technicznym że są źle przypisane usługi na karcie, ale oczywiście reklamować, bo takie rzeczy na koncie może tylko zrobić dział reklamacji, reklamację ciągnąłem 6-m-cy, a że sprawa była postawiona na "ostrzu noża"- minął 30 dniowy okres na roztrzygnięcie, to wyprostowali wszystko i wypłacili jeszcze odszkodowanie w formie 2 miesięcznego upustu 100% na abonament).                                                                                                                                        Na dziś na szybko to widzę tylko takie rozwiązanie, że kupujemy prepaid-data Plusa i sparwdzamy na nim.                                            Proszę NCM-pod Tomato RBM E3372

 Connection Type    4G/LTE
IP Address    10.141.220.5
Subnet Mask    255.255.255.252
Gateway    10.141.220.6
DNS    208.67.222.222:53, 208.67.220.220:53, 8.8.8.8:53
MTU    1500
 
Status    Connected
Connection Uptime    4 days, 13:59:47
Remaining Lease Time    4 days, 10:00:13 

. smile

17 (edytowany przez Przmus 2015-12-15 00:19:07)

Odp: Problem z częstym rozłączaniem się modemu E3276 na WNDR4300

Mam kartę pre-paid Play'a i na niej trochę testowałem.
Wychodzi taka sama sytuacja: przy zmianie bandu modem traci połączenie i nie wznawia go. Niestety z Play'a tak muli połączenie, takie wysokie pingi są że nie da się nic sensownego zrobić. Więc nawet nie zostawiam podłączonego na kilka godzin.
Najciekawsze jest to, że miałem wybrany tryb "Auto", który wybrał LTE i modem był połączony przez LTE. Po wysłaniu komendy "./czestotliwosc.sh lte" rozłączył się. Taka sama sytuacja przy "ręcznym" wysłaniu:

echo -e 'AT^SYSCFGEX="03",3FFFFFFF,2,4,7FFFFFFFFFFFFFFF,,\r' > /dev/ttyUSB0

Czyli wychodzi na to, że przy każdej zmianie ten modem zrywa połączenie. Teraz zastanawiam się, czy to faktycznie jest przyczyną tych częstych rozłączeń, bo niby zawsze LTE jest na sztywno wybrane. Nie sądzę też, aby zmieniało nadajnik na jakiś inny...

Pozostaje chyba tylko wysłać zgłoszenie techniczne do operatora, może mają jakieś możliwości sprawdzenia z jakich powodów zawieszane jest połączenie. Ale wątpię, by to cokolwiek zmieniło.

18

Odp: Problem z częstym rozłączaniem się modemu E3276 na WNDR4300

Zauważyłem, że w 90% przypadków modem zawiesza się podczas przeglądania... allegro.pl lub ceneo.pl. Zazwyczaj po wyszukiwaniu czegoś, połowa strony się wczytuje (część obrazków) i dalej już nic. Router nie jest w stanie pingować google.com ani niczego innego.
Czy jest może jakiś sposób podejrzenia logów modemu? Albo jakiś sposób, aby sprawdzić ping bezpośrednio z poziomu modemu (np. przez picocom)?

19

Odp: Problem z częstym rozłączaniem się modemu E3276 na WNDR4300

Generalnie nie ma czegoś takiego. Może jakiś konkretny model ma coś zaimplementowane, ale ogólnie - nie. Chyba że to hilink i możesz sie do niego zatelnetować.

Masz niepotrzebny router, uszkodzony czy nie - chętnie przygarnę go.

20

Odp: Problem z częstym rozłączaniem się modemu E3276 na WNDR4300

Dzięki za odpowiedź.
Narazie znalazłem: http://www.cyfrowypolsat.pl/oferta/inte … i-e3276.cp
Jest tutaj instrukcja zmiany oprogramowania z ver. 2 na 1... Trochę mnie to dziwi (poradnik downgradu), ale zaryzykowałem i wgrałem tą wersje 1. Na wyniki będzie trzeba trochę poczekać.
Swoją drogą, na allegro znalazłem tanie modemy E3372h-153 Hilink. Cezary, widziałem, że polecasz modemy Hilink w kilku postach. bo są "mniej problematyczne". Mógłbyś proszę napisać jak to jest z Hilinkami pod OpenWRT? Normalnie ustawiam je np. przez NCM, a potem mogę sterować połączeniem modemu przez przeglądarkę?

21 (edytowany przez jarek7714 2015-12-15 18:41:15)

Odp: Problem z częstym rozłączaniem się modemu E3276 na WNDR4300

Przmus napisał/a:

Mam kartę pre-paid Play'a i na niej trochę testowałem.
Wychodzi taka sama sytuacja: przy zmianie bandu modem traci połączenie i nie wznawia go. Niestety z Play'a tak muli połączenie, takie wysokie pingi są że nie da się nic sensownego zrobić. Więc nawet nie zostawiam podłączonego na kilka godzin.

Usługa Play do testów się zupełnie nie nadaje (to już lepsze jest Aero2), przy o połowę mniejszych zasobach częstotliwości oraz znacznie mniejszym pokryciu kraju, operator ten generuje ruch o 30% większy od spółek concernu Z.S. (co przekłada się na to że w wielu miejscach są tak duże przeciążenia sieci, że oferta LTE jest jedynie atrakcyjna w porównaniu z darmowym Aero2).                   

Przmus napisał/a:

Po wysłaniu komendy "./czestotliwosc.sh lte" rozłączył się. Taka sama sytuacja przy "ręcznym" wysłaniu:

echo -e 'AT^SYSCFGEX="03",3FFFFFFF,2,4,7FFFFFFFFFFFFFFF,,\r' > /dev/ttyUSB0

Na żadnym z ww modemów, nie bawię się w sterowanie live modemem za pomocą komend AT (ustawiam na sztywno za pomocą aplikacji MP-tylko LTE, w E3276 HiLink ustawiam z GUI modemu dodatkowo zakresy częstotliwości LTE [ze względu że używam Gargoyle 1.6.2.2, przerabiałem modem na HiLink]). Teraz już ma aktywne połączenie w ramach jednej sesji, ponad 10dni

 Duration:     243:16:31, Device name:    E3276
Serial number:    A2FDWC93719...
IMEI:    86378101521...
IMSI :    26001150003...
ICCID:    894801151328530...
My number:    Unknown
Hardware version:    CH1E3276SM
Software version:    22.470.13.00.00
Web UI version:    17.100.03.01.03
WAN IP Address:    188.125...
DNS 1:    212.2.96.51
DNS 2:    212.2.96.52
RSSI:    -65dBm
RSRP:    -86dBm
RSRQ:    -16dB
SINR:    1dB
Cell ID:    0785B01
PCI:    276 

                                                                                                                                                                               

Przmus napisał/a:

Pozostaje chyba tylko wysłać zgłoszenie techniczne do operatora, może mają jakieś możliwości sprawdzenia z jakich powodów zawieszane jest połączenie. Ale wątpię, by to cokolwiek zmieniło.

Zgłoszenie możesz wysłać-jednakże czy ktokolwiek "ruszy palcem" w tej sprawie-wątpię (to moloch, mali WISP-kładą l… na takie zgłoszenia i leją wodę, a co dopiero w korporacji-jak będzie kończyła ci się umowa, to wówczas możesz powalczyć :)  ).

22

Odp: Problem z częstym rozłączaniem się modemu E3276 na WNDR4300

Żadnego ncm. To zwykła karta sieciowa, więc dhcp na interfejsie który powstał i tyle konfiguracji jest.

Masz niepotrzebny router, uszkodzony czy nie - chętnie przygarnę go.

23

Odp: Problem z częstym rozłączaniem się modemu E3276 na WNDR4300

Dziękuję za wyjaśnienie. Czyli na przyszłość HiLink i po problemie. Dziwi mnie, że niektórzy wzbraniają się przed Hilinkami.

UWAGA UWAGA!
Nie chcę zapeszać, ale mam dobre wieści!

Czas pracy: 16h 41m 57s

Nigdy jeszcze nie udało mi się utrzymać tak długiego połączenia na tym routerze i modemie E3276.
Rozwiązanie okazało się banalnie proste: wgranie najnowszego firmware do modemu.
Wcześniej miałem: 21.260.05.00.618
Downgrade do wersji: 21.192.03.00.618 - nie pomógł.
Zrezygnowany postanowiłem dać modemowi jeszcze jedną szansę i wgrałem niebrandowane: 21.436.03.00.00, pobrane z chomika: lesiolo (wielkie podziękowania za instrukcję i uczynienie całego procesu prostym).

Po tym zabiegu zauważyłem, że same strony ładują się szybciej (kto korzysta z mobilnego Internetu, wie że jest taki efekt stopniowego ładowania się stron, niezależnie od prędkości łącza). Ping zmniejszył się nieznacznie o 3 do 7 ms. porównując z poprzednimi speedtestami. Tak wiec (nie zapeszając) jestem bardzo zadowolony smile

Dziękuję wszystkim za zainteresowanie się tematem.

24

Odp: Problem z częstym rozłączaniem się modemu E3276 na WNDR4300

Przmus napisał/a:

Czyli na przyszłość HiLink i po problemie. Dziwi mnie, że niektórzy wzbraniają się przed Hilinkami.

Bez przesady z tym HiLinkiem (używałem kilka mięsięcy E3276 w NDIS-NCM i względem stabilności połączenia, nie widzę różnicy -używam starego systemu, nie mogę na nim zainstalować nowego sterownika od Huawei do NCM, bez niego na Gargoyle wyższe są opóźnienia o ok. 20ms i stabilność transferu jest co najmniej kiepska). HiLink też ma jedną wielką wadę (można ją wykluczyć-rozbierając "modem do rosołu", tak też uczyniłem, dodatkowo w okresie letnim zamocowałem radiator i modem ani razu się nie zrestartował, a w tym roku latem temperatuty były ekstremalne) przegrzewanie się-co może powodować równie częste restarty co w Twoim przypadku.                                                                                                                                                                             

Przmus napisał/a:

Wcześniej miałem: 21.260.05.00.618
Downgrade do wersji: 21.192.03.00.618 - nie pomógł.
Zrezygnowany postanowiłem dać modemowi jeszcze jedną szansę i wgrałem niebrandowane: 21.436.03.00.00, pobrane z chomika: lesiolo (wielkie podziękowania za instrukcję i uczynienie całego procesu prostym).

Czyli używasz zwykłego modemu w NDIS-NCM, HiLinki mają softy zaczynające się od 22… smile

25

Odp: Problem z częstym rozłączaniem się modemu E3276 na WNDR4300

jarek7714 napisał/a:

Czyli używasz zwykłego modemu w NDIS-NCM, HiLinki mają softy zaczynające się od 22… smile

Tak, ja zastanawiałem się nad kupnem innego modemu (po tych problemach, które doświadczyłem przez ostatnie dni), dlatego chciałem się dowiedzieć jak to z tymi Hilinkami jest, no i Cezary wyjaśnił że one działają jak karty sieciowe, czyli żadnego protokołu nie trzeba instalować.

Póki co:

Czas pracy: 19h 48m 30s

Więc chyba się udało smile