On Fri, Aug 3, 2012 at 9:55 AM, Pascal Quantin
<pascal.quantin@xxxxxxxxx> wrote:
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.
Martin Mathieson might have some dct2000 captures so as to check that everything is still working as expected. I do not have any myself, so we will have to rely on someone else to confirm that it is still working as expected ;)
Yes.... I'm not sure anyone is using that support at the moment, or if it didn't work, they've quietly given up :( I don't think I have any of those log files to hand, but will try to recreate some when I find the time. Was thinking I'd let the dust settle on your changes so I'd only need to fix things up once. I'm happy to see all of this support being added, but I'm not really working with 3G any more.
Martin
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@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe