Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: Ħαℓ₸℮ℵ ␏⫢ ⦚ » 22. 05. 2023, 21:55:36
-
Záhada je uvedená v dotazu. Když volám přes LTE, tcdump -i any ( z root shellu) ukazuje prázdno.
Jak do toho hazi vidle více rozhraní? rmnet_data0 až 8, aktivní jsou 2.
Adresy 10.../29, na jinem 100/28, na tretim fe80/64... Navic v čase rotujou... Všechno jsou navic i cgnat, public ip je jina.
Jak do toho hází vidle různé APN? (Odlišné je IMS od mms a od "dat")
-
Když tam dáš koknrétní iface místo any taky nic?
Já jsem ted již déle mimo tady toho a doufal jsem že odpoví nákej Linux Ninja, ale co pamatuji byl tam rozdíl v tom že 'any' nenastaví rozhraní do PROMISC módu.
-
MImochodem,(TLDR), k čemu by mi mělo být promiscious, myslím že (přinejmenším na linkové úrovni )jde o jednu cílovou mac(tento mobil) nicméně zkusím sniffnout.
A tak mě napadá, když má mobil více rmnet_dataN ,i r_rmnet_dataN (to by mě fakt zajímalo k čemu a co znamenají). Musí jít přece o jedno rádio, tak musí být tyto rmnet_data sdruženo do jednoho fyzického
Tedy: když je tu tolik rmnet, nepoužívají se třeba prorůzná APN, nebo jak jsou APN v této hiearchii v jakém vztahu. Zároveň operátor v vyúčtování ukazuje při přístupu na net 3 různá "čísla" (významověě nic neřeknou, něco jako když 56k modemy vytáčely nějaké číslo) - dekodoval jsem, že jde o data přes internet,klasická mobilní data, zadruhé komunikaci na zákaznický portál, možná pak nějaká servisní komunikace (DNS) za třetí na služby "v balíčku zdarma " (vodafone pás) - ale to klidně může být splitováno na síťové vrstvě i když to půjde přes jedno apn nebo možná i rmnet
Hmm, ověřeno na desktopu, any= žádné promisc.mode, ověřeno přes dmesg,hlášku "entered promisc mode", která tam není. To mi uniklo
Všiml jsem si že v s --i any je důsledek : headers = cooked LINUX_SLL, obráceně implikace neplatí.
Ale na mobilu, ať už dám -i rmnet_data2, hlavičky sou stále COOKED (ano implikace neplatí), ale zároveň dmesg ukáže "entered promisc.mode." :)
šel jsem i dál, iw phy přirozeně vylistuje jen wifinu.
rmnet_ipa0: <UP,LOWER_UP> mtu 2000 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 1000 link/530
10: rmnet_data1: <UP,LOWER_UP> mtu 1500 qdisc htb state UNKNOWN mode DEFAULT group default qlen 1000 link/530
11: rmnet_data2: <UP,LOWER_UP> mtu 2000 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 1000 link/[530]
17: r_rmnet_data0: <UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 1000 link/[530]
ty co nejsou up:
ip6tn0, ip6_vti0 ,link type tunnel6
sit0 link type sit
CO je mi divné link type je "[530]"(s hran.závorkami), ale snad to ničemu nevadí....
-
Tak jsem sniffoval zvlášť na každém aktivním: rmnet_data0,1,2 i ipa0 a nic- žádná komunikace... Promisc . zajištěn.
Má to nějaké vysvětlení? třeba nějaká akcelerace- offloading, nebo že to nezpracovává jádro(neprotékají jádrem) a nějak přes IPC se předává rovnou vyšší protokol( dekodovaný ipsec -> rtp stream -> audio waveforma...)?
-
Hele vypadá to tom víš víc než já.. ale tamy se mi zdá že v tom nic zapeklitého nebude.
Zkoušel jsi -w (do sounoru) -n (neresolvovat) ?