Hi Rishie,
2012/8/3 Rishie Sharma
<storfisken88@xxxxxxxxx>
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.
