Czyli teraz czekamy na ruch Asusa? Powinno im zależeć więc mam nadziej,że staną na wysokości zadania...

a jak ASUS nic nie wymysli to czy chca wprowadzic akcje sewisowa i wymienic stare routerki na ARMy - mam 2

Czy to nie jest zle info. Nawet jak ASUS jakos to uaktualni czy Ty bedziesz mial dostep do zrodla aby uaktualnic sterownik tomato?

Moj WNR3500 z tomato radzi sobie dobrze z LTE z 3372 Hilink ale muszę zmieniać ręcznie wan na LTE i spowrotem.
Testowalem tez Tplink 3220 i 3420 z OFW i tam zmienia automatycznie z WAN na LTE ale juz nie wraca na WAN - trzeba restaryować router.
czy może jakiś asus działa na OFW tak żeby w przypadku awarii podstawowego łącza włączał LTE i potem wracał na podstawowe?
Mam słabe łącze podstawowe i szukam rozwiązania z backupem w postaci LTE

Witajcie, czy jest szansa aby modem E3372 CL1E3372SM Ver.A BEZ hilinka działał w Asus RT-N16 jako LTE? Jeżeli nie to czy wgranie hilinka pomoże?
Obecnie modem działa na 3G, wersja firmware 1.28.0000 MIPSR2-130 K26 USB AIO. Próbowałem odpalić go na 4G/LTE ale w logu wyrzuca w kółko

Modem Huawei E3372
Wersja sprzętu CL1E3372SM Ver.A
Wersja firmware 21.286.03.00.264
Wersja programu 23.015.05.03.264

jak pisałem w shoutboxie, ten modem nie zadziała na żadnym sofcie nawet z dużo nowszym kernelem. Po prostu nie jest wspierany przez kernel w trybie NDIS. Sflas**** go na Hilinka i będzie działał.

Witam,

Mam pytanie, którą aktualizację obrazu do Tendy wgrać (K26RT-N/build5x-130-EN), tą z Tendy czy tą z Asus RT-Nxx (ostatni VPN) ?
Pozdrawiam.

jeżeli chcesz mieć oba radia kosztem wsparcia modemów 3G/4G to wgraj obraz z Tendy. Jeżeli chcesz poświęcić drugie radio ale mieć obsługę 3G/4G to wgraj obraz z katalogu Asus RT-Nxx

Przerobiłem modem na hilinka i działa ale mam ten sam problem co wszyscy posiadacze Asusa czyli nie ładujące się niektóre strony :| Teraz pytanie jaki router kupić do tego LTE żeby wszystko śmigało?

Nie oszukujmy się - w tomato to kuleje z tym modemem - kupuj router pod Openwrt (sam używam Netgear WNDR4300 i pięknie śmiga w LTE, nawet bez aktywnego huba 44/25 Mb/s (mieszkam ok. 200m od najbliższego BTS) - a jak z hubem (oczywiście aktywnym) i bliżej BTS leci 80-95/35-40 Mb/s - testowane z kartą Orange w Warszawie, w nocy) - tam to śmiga od strzała (i polecam mimo wszystko Hilink - mniej problemów z konfiguracją na dowolnej wersji Openwrt od AA wzwyż) i nie ma żadnych problemów z żadnymi stronami u dowolnego, polskiego operatora komórkowego.

no ja napisalem do Broadcoma o tych problemach i niestety ale dostalem odpowiedz ze w takich sprawach powinnienem sie kontaktowac z producentem routera a nie z nimi .

@lulo prosze przeczytaj caly temat zanim zaczniesz mieszac. Zostalo wyraznie udowodnione ze to nie wina tomato tylko konkretnych procesorow Broadcoma i nawet jak zaintalujesz Gargoyle na tych routerach zachowuja sie tak samo.

jw. Problem tyczy się routerów z procesorami BCM47xx. I nie ważne czy jest to Asus, netgear czy linksys... Nie ważne czy wgramy Tomato, DD-WRT, Olega, merlina czy openwrt (testowane na RT-N16). Problem zawsze występuje.

Sprawdzałem RT-N10U z Tomato i na nim problem nie występuje (procesor BCM5356U).

Na odpowiedź od Asusa co do problemu wciąż czekamy. Prosili o czas do końca miesiąca. Zatem cierpliwości

Ja właśnie posiadam tego nieszczęsnego asusa RT-N16.... w takim razie tymczasowo wracam do 3G mam gdzieś Mikrotika RB951Ui-2HnD z USB ale nie wiem czy na nim ten modem będzie hulać



to w ogóle jest jakaś kpina chyba nie przyjmują tego do wiadomości, co ma producent do tego skoro na każdym modelu z tym prockiem jest problem?

No skoro to wina konkretnych wersji procesorów to chyba wybór jest oczywisty - nie epatować na siłę maszynkę jaką się ma, tylko nabyć inną co lepiej współdziała z tym, czy innym modemem - jeżeli to LTE jest istotą rzeczy - czekać na reakcję firmy w takiej sprawie to zapewne szybciej wyjdzie wersja 3xLTE.
No ale jak ktoś lubi czekać - to niech czeka.
Według mojego osobistego śledztwa w tym temacie wynika, że to jest zarówno wina sprzętu jak i tomato - tomato jak to soft - zawsze da się ogarnąć, oprócz własnościowych sterów/firmware, w których zapewne leży glu sprawy.

Uparliście się, że to wina Broadcoma.
A może problem leży w nowych chipach Huawei-a i/lub linuksowych sterownikach do nich?

Przecież shibby pisał wielokrotnie, że E3372 nonHilink nie działa poprawnie na żadnym linuksie.

powiem szczerze juz chyba 3 raz w tym poscie prosze osoby ktore nawet nie zadaly sobie trudu aby caly post przeczytac aby sie nie wypowiadaly.

W poscie zostalo udowodnione ze to nie wina tomato i dlaczego osoby ktore nie siedza w twemacie sie nad tym upieraja.

niestety to nie wina sterow linuxa jezeli tak uwazasz to powiedz czemu tp-link na gargoyle dziala OK a na tej samej kompilacji gargojle juz RT-N16 nie. I dlaczego na zadnym sofcie nawet tomati RT-N10U dziala poprawnie a juz na tej samej kompilacji RT-N16 nie dziala.

Ludzie przestancie bzdury wypisywac nie pomagacie. Prawda jest taka ze jak Asus nie zalatwi sprawy to nie powstanie latka na zaden soft alternatywny i jak komus zalezy na LTE to musi zapomniec o routerkach na Broadcom BCM47xx.

Miejcie na tyle przyzwoitosci jak nie potraficie nic pozytywnego wniesc do dyskusji aby nie oczerniac tomato. Wlasnie przez takich jak Wy potem w necie ludzie wypisuja brednie ze to wina tomato.

@lulo - no to ci mówię, że nie jest to wina tomato. W szczególności w wersji v130 całkowicie przebudowany został mechanizm detekcji modemów jak i przeportowane zostały moduły z wyższych kerneli (dla ARM nawet z K3.18). Najlepszym dowodem tego jest fakt, że na RT-N10U z Tomato Hilinki śmigają aż miło i problemu z doczytywaniem stron nie ma.

@Maxikaaz - zgadza się, E3372 w wersji non-Hilink nie jest wykrywany przez kernel. Wykrywane są tylko interfejsy serialowe (ttyUSB), które można użyć jedynie do połączenia pppd (tryb RAS). Niestety żaden z modułów nie widzi modemu jako urządzenie usb0/ethX/wwan0, przez co nie można nawiązać połączenia NDIS. Ale tu nie o to chodzi. Problem jaki jest z broadcomami BCM47xx objawia się na Hilinkach (testowałem E3276 i E3372), że przy niektórych stronach HTTPS pakiety TCP dostają "checksum incorrect" co objawia się niedoczytywaniem tych stron. To definitywnie wina obsługi broadcoma, bo:
1) RT-N16 testowałem z openwrt CC, tomato, dd-wrt, asuswrt i Olegiem i na każdym sofcie ten problem występował. Natomiast ta sama wersja openwrt CC wgrana na np. 1043nd i problem ustępował.
2) Testowałem wiele routerów (mipsel i arm) z BCM47xx i na każdym ten problem występował
3) przeportowałem wszystkie moduły odpowiedzialne za obsługę NDIS z kernela 3.18 i nie pomogło
4) poruszałem temat TCP checksum offload, skompilowałem ethtool, wszystko bez efektu
5) koniec końców ten sam obraz tomato wgrany na RT-N16 i RT-N10U i na pierwszym problem jest, na drugim problemu nie ma.

nie widzę więc innego wytłumaczenia aniżeli jakiś błąd w kernelu w obsłudze BCM47xx.

Pozdrawiam

Aż mnie korci, żeby zapytać - próbowałeś też na RT-N16 z DD-WRT K3.xx ?

Tak przy okazji - HiLink od strony routera widziany jest jako interfejs sieciowy na USB. Może błędy są w obsłudze USB ?

Trochę dziwne, że problem dotyczy zarówno MIPS jak i ARM. Inne architektury, więc problem nie powinien zależeć od procesora.

RT-N10u też posiada procesor z rodziny BCM47xx. Po prostu Broadcom tak oznaczał (BCM53xx) zubożone wersje procesorów, można w przybliżeniu to odnieść do Pentium/Celerona u Intela.

Pomyślałem tak przeglądając dane, że tenże RT-10u ma procesor taktowany tylko 300MHz. Może to być jakiś trop, może warto dla testów obniżyć taktowanie w RT-N16 do takich wartości i wtedy spróbować ?

Połączony z 16 June 2015 21:49:09:
Magistrala USB w teorii ma przepływność 480Mbit/s, taktowanie procesora w RT-N16 to 480MHz (albo okolice).
Może gdzieś są zależności (interferencje) takie, jak w RT-AC68u, między USB3.0 a interfejsem radiowym 2.4GHz ?

a mam ciekawostke kumpel do mnie przyszedl z bardzo wolno dzialajacym LTE no i podlaczylem u siebie i smiga ladnie 30Mbit/s+ ale co mnie zaciekawilo to ze ma 3372s-153 z Play no-hilink i smiga z routerem D-Lnk DWR-116 ktos wie jaki soft jest w srodku?

Witam wszystkich,
Aż dziw bierze że do tej pory nie wpadłem na ten wątek ...
Od dłuższego już czasu walczę z problemem niedziałających i/lub niedoczytujących się stron.
Pozwólcie, że posumuję moje znaleziska - być może naprowadzą naszych Guru na cel i pozwolą problem rozwiązać Na pomoc ze strony Asus/Broadcom raczej bym nie liczył :(
Do rzeczy.
Mój Sprzęt:
Routery: Asus RT-N66U, Asus RT-AC68U, Dovado 4GR, Tp-Link 3020, Dlink DWR116
Modemy: e398 (RAS i QMI), e3276 (cdc_ncm i Hilink), e3372 (Hilink)
Firmware: Tomato, OpenWrt, Merlin, ROOter, dd-wrt, stock.
Operatorzy: Plus, T-Mobile (czasowo do testów), Play, CP
Testy:
Testowałem różne konfiguracje, różne wersje firmware. Na potrzeby testów tworzyłem też własne FW z przeportowanymi modułami usbnet.ko, cdc_ncm.co, cdc_ether.ko, qmi_wwan.co i okolicami. Moje FW były na bazie Merlina na ARM i MIPS.

Moje badania pokazały, że:
1. Problem dotyczy WSZYSTKICH modemów w tym również NCM i QMI
2. Problem występuje TYLKO na routerach opartych o kostki Broadcom'a (w moim przypadku Asusy)
3. Problem występuje TYLKO wtedy gdy używany jest stos oparty o usbnet.ko (czyli NDIS)
4. Problem NIE występuje przy połączeniach typu RAS (ppp) (bo nie jest używany usbnet :))
5. Problem nie występuje przy WANie ethernetowym

Na podstawie analizy pakietów (tcpdump) zauważyłem, że problem dotyczy paczek z ustawioną flagą DF (don't fragment) czyli (choć nie tylko) https. Błędna suma wylicza się dla ostatniego segmentu paczki. Ładnie to widać na citibankonline.pl. Błąd występuje tylko przy określonej długości segmentu więc jeśli na przykład zmienimy MTU to część stron zacznie działać ale inna część przestanie - zależy jak się akurat "rozłoży" - stąd zapewne wynika niedeterministyczność zachowania.
Jakiś wpływ na wyliczanie sumy ma obecność opcji w headerze tcp. Robiłem test z citibankonline.pl na Windows i Ubuntu przy czym Ubuntu był na witualce w Windows na zbridgownej karcie. Na Ubuntu wszysko działało miodnie na Windows nie - w tym samym czasie na tym samym routerze. Jedyna różnica w pakietach to obecność opcji w headerze tcp. Jak były opcje to działało jak nie było to transmisja umierała.

Kod do wyliczania nieszczęsnej sumy kontrolnej jest w kilku miejscach i jest współużywany przez różne interfejsy.
Gdyby wyliczanie było całkowicie zababolone niedziałałoby nic - pamiętajmy że RAS, Ethernet WAN działają dobrze.
Wg mnie kluczem do zagadki jest ostatni segment. W usbnet robiona jest jakaś magia z packet padding, która dotyczy właśnie ostatniego segmentu. Były nawet na to jakieś fixy ale zapewne nie brały pod uwagę kodu broadcom. W części linuksa specyficznej dla Broadcom (np. /arch/mips/lib/csum_partial.S dla mips)
są wstawki assemblerowe odpowiedzialne za wylicznie sum kontrolnych. Wg mnie muszą one "współgrać" z tym co sie dzieje na poziomie usbnet.
W sieci jest sporo na temat "usbnet rx fix" - dotyczą co prawda innych interfejsów (np. asix) ale jakby dotykają podobnego problemu.

Pozdrawiam,

PS. Podziękowania dla Shibbego - kawał naprawdę dobrej roboty!

Na tomato e3372 non-hilink działa chyba maks 30Mbps, to i tak lepiej niż na ofw (np. ac68u) gdzie jest 20Mbps i zrywane czasami połączenie.