Prázdný tcpdump -i any při volání přes LTE

[Ħαℓ₸℮ℵ ␏⫢ ⦚ »]

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")

[Reklama]

[k0k0t]

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.

Kód: [Vybrat]

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...)?

[k0k0t]

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) ?

[Reklama]