Re: packet-rlc.c changes

[Pascal Quantin <pascal.quantin () gmail com>]

Hi Rishie,

2012/8/3 Rishie Sharma <storfisken88 () gmail com>

> Hi! I am the one who (through Anders Broman) made changes to RLC. I
> subscribed to the list today to comment on some of the changes.
>
> "Remove a created-but-unused subtree (and its ett).  It's not obvious to
> me  whether this tree was going to be used for something or not."
>
> I was going to add a subtree so you can filter on the values easily
> (instead of just proto_item_append_text:ing the values) but then I got
> caught up in something else and forgot about it, it's not important.
>
> I was unaware that packet-catapult-dct2000.c and packet-fp_hint.c also
> use packet-rlc.c. That makes the whole ordeal a bit scarier because I don't
> know what they are and I've made some radical changes to RLC so I've
> probably broken something there like changing variables and such. I saw
> that comment on UDP framing protocol in RLC but to be honest I did not
> understand what it is and what it's used for so if someone who knows
> could try and see how much I've broken so far  that would be great.

I just had a quick look and fixed what seemed the most obvious (like the
removal of the test on ciphered/deciphered variables while they did not
interfere with your own code). I did not verify the changes done related to
reassembly so it would be nice if you could double check this part.
The UDP framing protocol can be used to decode directly a RLC PDU without
having it encapsulated in MAC/FP PDUs. I use it myself to decode PDUs
logged in a UE and after a quick check it seems to be still working.


> With lchid and rbid for me it's just a number that is used to identify a
> sequence in RLC so if you say it is rbid and not lchid it's probably
> correct.

The Logical Channel Identity is used at MAC level while the Radio Bearer
Identity is the entity used in RLC layer (to handle the sequence number,
state variables, ciphering state... per entity) that is mapped on a LCH-ID.
So yes they are different.


> The changes to the ciphering and deciphering are because me and Jacob
> Nordgren are trying around to see if we can actually decrypt an encrypted
> RLC in the RLC code with a KASUMI algorithm implementation and yesterday we
> did have some progress. I am unsure how the copyrights and licenses and
> such work with this though, Jacob wrote the KASUMI by himself following the
> 3gpp specification. I wonder, would that be OK to put GPL on and commit to
> the Wireshark SVN?


It would be nice to add it in the epan/crypt folder. I do have myself the
code for SNOW3G and ZUC ciphers and the corresponding integrity and
ciphering algorithms (used for LTE) that I might add to Wireshark also
(Martin, ping me if you are interested).


Regards,
Pascal.

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe