[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <3658DF8E-535E-43C6-95FD-CE61E3A7164F@alum.mit.edu>
Date: Sat, 13 Apr 2019 00:55:29 -0700
From: Guy Harris <guy@...m.mit.edu>
To: Harald Welte <laforge@...monks.org>
Cc: Johannes Berg <johannes@...solutions.net>,
openbsc@...ts.osmocom.org, radiotap@...bsd.org,
linux-wireless@...r.kernel.org,
Subash Abhinov Kasiviswanathan <subashab@...eaurora.org>,
Dan Williams <dcbw@...hat.com>,
Bjørn Mork <bjorn@...k.no>,
netdev@...r.kernel.org, Sean Tranchetti <stranche@...eaurora.org>,
Aleksander Morgado <aleksander@...ksander.es>
Subject: Re: gsmtap design/extensions?
On Apr 13, 2019, at 12:35 AM, Harald Welte <laforge@...monks.org> wrote:
> the "physical link info" is present in GSMTAP, but the granularity of
> GSMTAP frames is not user-IP frames, but "MAC blocks". So your user IP
> frame might not be visible as it's still compressed, encrypted,
> fragmented, etc.
The granularity of Ethernet frames is not user IP frames, but Ethernet datagrams, so you user IP frame might not be visible as it's fragmented (the fragments might still be IP datagrams, but they would have to be reassembled - which Wireshark, for example, does, for those people still doing NFS-over-UDP :-)).
"Encrypted" may not apply there, but it *does* apply for 802.11 frames on a protected network (which Wireshark can decrypt, if you have 1) the network password for WEP or WPA-Personal and 2) the EAPOL handshake for WPA-Personal).
Powered by blists - more mailing lists