Forum: Router z obsługa LTE 4g i Tomato ?

Cytat

rpar napisał(a):

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!

Jak dla mnie sprawa jest jasna usraelski broadcom ma w HW moduł/soft do SZPIEGOWANIA i dlatego te cyrki .
Przecie to w usraelu norma że szpiegują patrz ->intel itd. 1000x linków

W crapie rt10 300Mhz być może to wycięli z HW bo by nie nadążał ale w szybszych broadcom za dopłatą (WASZĄ) macie szpiega i szumną reklamę.

Na bank tak jest i w żadne zapewnienia że to niby błąd był nie uwierzę nigdy , radzę się temu przyglądać jak będą kłamać i udawać