Hello,
Display it. You are writing a dissector which describes the data seen on the
wire, not one which goes "You are not interested in this".
Also, if there is something on the screen which says "Reserved" or a number of
bits which say "Not in use" and there is a value in it, then you know tha
On 12/08/2013 11:38 PM, Jakub Zawadzki wrote:
> On Sun, Dec 08, 2013 at 11:08:39PM +0100, Martin Kaiser wrote:
>> sorry for causing problems with the DVB-CI decryption test.
>
> Don't worry. It's DTLS failing not DVB-CI ;-)
> Sorry.
This is the fix for the DTLS problem:
https://bugs.wireshark.or
On Sun, Dec 08, 2013 at 11:08:39PM +0100, Martin Kaiser wrote:
> sorry for causing problems with the DVB-CI decryption test.
Don't worry. It's DTLS failing not DVB-CI ;-)
Sorry.
___
Sent via:Wireshark-dev mailing list
Arc
Hi Graham,
Le 8 déc. 2013 à 22:56, Graham Bloice a écrit :
> Compiling with VS2013, the GetVersionEx function is now reported as
> deprecated:
>
> E:\Wireshark\trunk\version_info.c(368): warning C4996: 'GetVersionExW': was
> declared deprecated [E:\Wireshark\2013build\wireshark.vcxproj]
> E:\
Hi Jakub and all,
sorry for causing problems with the DVB-CI decryption test.
Does this fail for others as well?
If so, could you send me the output of
tshark \
-o "dvb-ci.sek: " \
-o "dvb-ci.siv: " \
-Tfields -e dvb-ci.cc.sac.pad
Compiling with VS2013, the GetVersionEx function is now reported as
deprecated:
E:\Wireshark\trunk\version_info.c(368): warning C4996: 'GetVersionExW': was
declared deprecated [E:\Wireshark\2013build\wireshark.vcxproj]
E:\Wireshark\trunk\version_info.c(853): warning C4996: 'GetVersionExW': was
dec
On 7 December 2013 18:43, Graham Bloice wrote:
> On 7 December 2013 17:06, Jakub Zawadzki wrote:
>
>> On Sat, Dec 07, 2013 at 04:50:10PM +, Graham Bloice wrote:
>> > Started testing builds with VS 2013 Pro (nmake build), complaints about
>> > redefinitions:
>> >
>> > C:\Program Files (x86)\W
2013/12/7 Jakub Zawadzki
> Hi,
>
> I renamed base_display_e to field_display_e, and added new enums to
> field_display_e,
> but I wonder if it's correct approach.
>
> For FT_ABSOLUTE_TIME we're using seperate enum
> (absolute_time_display_e), so maybe FT_STRING* should also have own enum
> string
On Sun, Dec 08, 2013 at 09:23:23PM +0200, Kaul wrote:
> Thanks for the automated build links - I guess I'll watch them more closely
> and only sync when my platform passes.
>
> Interesting - I'm pulling from trunk and still fail on that. Perhaps it
> wasn't fixed entirely, or I have to do some cle
Thanks for the automated build links - I guess I'll watch them more closely
and only sync when my platform passes.
Interesting - I'm pulling from trunk and still fail on that. Perhaps it
wasn't fixed entirely, or I have to do some cleanup?
On Sun, Dec 8, 2013 at 6:51 PM, Hauke Mehrtens wrote:
Hi,
today I updated the wireshark trunk folder, and I saw that file
packet-zbee-zcl.c is improved adding OTA UPGRADE dissector and others.
This file structure was changed in order to simply the main zcl file.
So, sub files were created in order to group specific clusters dissectors:
- packet-zbee
On 12/08/2013 04:30 PM, Kaul wrote:
> Hi all,
>
> I've been trying to enhance a specific dissector for two weeks now.
> Since I'm afraid of diverging the code (although I'm working on a
> specific dissector), I update my code base often (~ once a day).
> Regretfully, 5 times (in 2 weeks!) this has
The best would be
proto_tree_add_item(seg_param_tree, hf_scsi_reserved, tvb, offset, 2,
ENC_BIG_ENDIAN) (obviously may need adjusting for your specfic situation)
offset += 2
so it's filterable (and users can possibly find situtions where reserved fields
aren't 0)
Different hf_ filters varia
Should I:
proto_tree_add_text(seg_param_tree, tvb, offset, 2, "reserved");
offset += 2;
or:
offset += 2; /* reserved */
What is better? (Regretully I'm working on SCSI, whose creators LOVED
sprinkling reserved bytes everywhere!).
Do we have a standard? (perhaps worth having a global param for
Hi all,
I've been trying to enhance a specific dissector for two weeks now.
Since I'm afraid of diverging the code (although I'm working on a specific
dissector), I update my code base often (~ once a day). Regretfully, 5
times (in 2 weeks!) this has resulted in compilation failure.
I'm pretty sur
15 matches
Mail list logo
