Hi,
>From Pascal:
> GMR-1 dissectors, like GSM-A dissectors, can be seen either as separate
> protocols belonging to the same family, or as a single protocol with sub
> dissectors:it depends a bit on your point of view :) Personnally I see them
> as a single one (like Sylvain) and was rather happ
Hi Pascal,
> For me not all changes have the same potential of breakage: a change in an
> API used by an external tool can easily lead to a complete incompatibility
> (GSMTAP format unapproved changes for example) while a filter rename or a
> wrong subtree used to display a field (GMR-1 breakages
Hi Pascal,
> If you check the mailing list archive you will see that I also raised
> this issue regarding filter names for protocols split across several
> files. See http://www.wireshark.org/lists/wireshark-dev/201207/msg00258.html
> for the mail exchange.
Yes, I've seen this (I replied in the s
Hi,
I've just seen those changes (filter names) now and I'm really not
happy with them ...
1) I explicitely asked this list for objections against the gmr1.xx vs
gmr1_xx name and I was told that using gmr1.xx made sense given it's
always the same protocol. And nobody expressed any view against it
Hi,
>> I have submitted some patches under bug 6885.
> I am looking forward to feedback.
>
>
I've just ported my dissector to it and it works great.
I just had an issue with signed fields that were not sign extended to
properly reflect the negative value.
I opened a bug and submitted a fix :
h
Hi,
> I recently found a need for such a function for the gsm_rlcmac dissector for
> EGPRS header fields which have split uint encoding.
> I have just written the function:
> [snip]
Ok, looks good. I'll wait for those to get merged and I'll adapt my
patch to use them.
(I need them exactly for GP
its,encoding)
> make more sense?
See above: Sometimes the bits don't have to be taken "in order" ...
Cheers,
Sylvain
From 656fbda551f07b8d5bd1c4af412f257692628e9c Mon Sep 17 00:00:00 2001
From: Sylvain Munaut
Date: Sun, 18 Dec 2011 13:22:10 +0100
Subject: [PATCH] pro
Hi,
> - CSN1 decoding is manually coded right now - and wrong in some places.
> Automatic creation like ASN.1 possible but rather hard problem.
Something pretty important to me is that the code can be modified to
"look" nice.
For eg. when you look at the TETRA dissectors that uses ASN.1
autogen
Hi,
I'm about to submit GMR-1 dissectors and when running them through the
checkfiltername script, it warns me about the name I chose.
Since GMR-1 has different channel types with completely different
messages (and messages encoding), there is several packet-xxx:
packet-gmr1_dtap.c
packet-gmr1_r
Hi,
> See tvb_new_child_real_data()
Thanks. I'm using it with a buffer allocated with ep_alloc, as seen in
some other dissector. And it seems to work fine.
Cheers,
Sylvain
___
Sent via:Wireshark-dev mailing list
Arc
Hi,
I have a protocol where the payload for the next layer is not simply
the rest of the tvb ( The last nibble of the last octet of data octet
needs to come from some fields in the header ).
So before I handoff the tvb for further dissection (or hand it off to
the segmentation handling), I need t
Hi,
> Well, at least in 1.6.x and later (I don't know whether this was supported in
> 1.4.x), doc/README.developer says:
>
> [ snip ]
>
> BASE_CUSTOM allows one to specify a callback function pointer that will
> format the value. The function pointer of the same type
Hi,
I'm trying to write a dissector for the GMR sattelite phone packets.
Among the fields, a lot of them are :
- CSN encoded (thus I can use the packet-csn.c helpers a lot)
- Not bit aligned at all (thus the CSN generic helpers use the
proto_add_bits(...) calls for the fields)
- Have a 'meaning
13 matches
Mail list logo
