Re: [Wireshark-dev] Issue with building wireshark from source

2011-10-31 Thread Jeff Morriss

On 10/31/2011 08:59 PM, vijay wrote:

I have installed all the dependent packages - gtk3.1 , glib, pango atk
and all the required packages.
Now when I run ./configure in wireshark build I get the following error:

checking for GTK+ - version >= 2.4.0... no
*** Could not run GTK+ test program, checking why...
*** The test program failed to compile or link. See the file config.log
for the
*** exact error that occured. This usually means GTK+ is incorrectly
installed.
configure: error: GTK+ 2.4 or later isn't available, so Wireshark can't
be compiled

I have the latest version of GTK+ installed. Could some one please tell
me what the issue is here?


In this case "the latest version of GTK+" is not really a good thing. 
GTK3 is special in that they ripped out backwards compatability for a 
lot of stuff, which means that applications (such as Wireshark) 
frequently need to be *ported* to GTK3.


So, for now, stick with the latest GTK v2 you can get.
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe


[Wireshark-dev] Issue with building wireshark from source

2011-10-31 Thread vijay
I have installed all the dependent packages - gtk3.1 , glib, pango atk and
all the required packages.
Now when I run ./configure in wireshark build I get the following error:

checking for GTK+ - version >= 2.4.0... no
*** Could not run GTK+ test program, checking why...
*** The test program failed to compile or link. See the file config.log for
the
*** exact error that occured. This usually means GTK+ is incorrectly
installed.
configure: error: GTK+ 2.4 or later isn't available, so Wireshark can't be
compiled

I have the latest version of GTK+ installed. Could some one please tell me
what the issue is here?

 When i searched for solution many were suggesting gtk-dev package.
I am using 64bit ubuntu and I could not find a suitable GTK devel package.

Can some one tell me where i can find the package?

Thanks
Vijay
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] What's the proper way to modify the tvb content for upper layer dissection ?

2011-10-31 Thread Jaap Keuter
  

Hi, 

See tvb_new_child_real_data() 

Thanks,
Jaap 

On Sun, 30 Oct
2011 12:17:17 +0100, Sylvain Munaut wrote: 

> 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 to alter it. What's the proper way
> to do that and ensure I
don't create a memory leak ?
> 
> Cheers,
> 
> Sylvain
>
___
>
Sent via: Wireshark-dev mailing list 
> Archives:
http://www.wireshark.org/lists/wireshark-dev [2]
> Unsubscribe:
https://wireshark.org/mailman/options/wireshark-dev [3]
>
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe [4]

 


Links:
--
[1] mailto:wireshark-dev@wireshark.org
[2]
http://www.wireshark.org/lists/wireshark-dev
[3]
https://wireshark.org/mailman/options/wireshark-dev
[4]
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Affix bluetooth stack

2011-10-31 Thread Tyson Key
PS - I've just had a play with the "virtual HCI" implementation in the
Linux kernel version shipped with *buntu 11.04, and it appears that the
maintainers of their LibPCap builds have thoughtfully decided to disable
support for capturing on Bluetooth interfaces, for some unknown reason.

In this case, your best bet would be to install the "libbluetooth-dev"
package, and build a non-crippled version of LibPCap (and Wireshark?) from
source, with the appropriate "./configure" argument specified.

Sorry for disappointing you,

Tyson.

On 31 October 2011 18:21, Tyson Key  wrote:

> Yes.
>
> Please see the newly-updated wiki page regarding this (at
> http://wiki.wireshark.org/CaptureSetup/Bluetooth). It's been a long time
> since I've worked with Bluetooth, but I clearly remember it working under
> Fedora without any additional configuration, or effort on my part.
>
> A "hcidump" utility from the developers of the Linux Bluetooth stack/BlueZ
> also exists, should you prefer to use it to generate (Wireshark-compatible)
> logs, instead - although it doesn't quite meet the criteria of "live
> capturing and display" (since you have to manually reload its generated log
> in Wireshark).
>
> You could also try running "tshark -D | grep bluetooth*" (or "tshark -D |
> grep hci*") as root, or using "sudo" to see if your Bluetooth interface
> appears.
>
> I hope that helps,
>
> Tyson.
>
>
> On 31 October 2011 18:13, vijay  wrote:
>
>> Hi Tyson,
>>
>>   I need to do a live capture on Bluetooth traffic does wireshark support
>> capture with BLueZ stack in linux ?
>>
>> Vijay
>>
>>
>> On Mon, Oct 31, 2011 at 3:10 AM, Tyson Key  wrote:
>>
>>> Hi Vijay,
>>>
>>> There's no need to install Affix under KUbuntu (although installing
>>> other stuff from the repositories related to Bluetooth wouldn't hurt). Just
>>> enable Bluetooth connectivity as normal, and connect your adapter if
>>> necessary.
>>>
>>> Tyson.
>>>
>>> On 31 October 2011 08:03, vijay  wrote:
>>>
 Hi,

 I not sure if this is the correct forum to post this but, Could some
 one tell me if it is possible to install affix bluetooth stack in kubuntu?
 Currently BLueZ bluetooth stack is installed and wireshark requires
 Affix stack for live capture of bluetooth traffic.

 The affix website says that it can be installed in a kernel with
 version 2.6.x or higher, and the version of the kernel I have installed is
 3.0.X. Now can
 I install the affix stack in my OS? or Affix doesnt support Kubuntu?

 Thanks


 ___
 Sent via:Wireshark-dev mailing list 
 Archives:http://www.wireshark.org/lists/wireshark-dev
 Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org
 ?subject=unsubscribe

>>>
>>>
>>>
>>> --
>>>   Fight Internet Censorship!
>>> http://www.eff.org
>>> http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
>>> 00447934365844
>>>
>>>
>>> ___
>>> Sent via:Wireshark-dev mailing list 
>>> Archives:http://www.wireshark.org/lists/wireshark-dev
>>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>> mailto:wireshark-dev-requ...@wireshark.org
>>> ?subject=unsubscribe
>>>
>>
>>
>>
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:http://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>> mailto:wireshark-dev-requ...@wireshark.org
>> ?subject=unsubscribe
>>
>
>
>
> --
>   Fight Internet Censorship!
> http://www.eff.org
> http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
> 00447934365844
>



-- 
  Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Affix bluetooth stack

2011-10-31 Thread Tyson Key
Yes.

Please see the newly-updated wiki page regarding this (at
http://wiki.wireshark.org/CaptureSetup/Bluetooth). It's been a long time
since I've worked with Bluetooth, but I clearly remember it working under
Fedora without any additional configuration, or effort on my part.

A "hcidump" utility from the developers of the Linux Bluetooth stack/BlueZ
also exists, should you prefer to use it to generate (Wireshark-compatible)
logs, instead - although it doesn't quite meet the criteria of "live
capturing and display" (since you have to manually reload its generated log
in Wireshark).

You could also try running "tshark -D | grep bluetooth*" (or "tshark -D |
grep hci*") as root, or using "sudo" to see if your Bluetooth interface
appears.

I hope that helps,

Tyson.

On 31 October 2011 18:13, vijay  wrote:

> Hi Tyson,
>
>   I need to do a live capture on Bluetooth traffic does wireshark support
> capture with BLueZ stack in linux ?
>
> Vijay
>
>
> On Mon, Oct 31, 2011 at 3:10 AM, Tyson Key  wrote:
>
>> Hi Vijay,
>>
>> There's no need to install Affix under KUbuntu (although installing other
>> stuff from the repositories related to Bluetooth wouldn't hurt). Just
>> enable Bluetooth connectivity as normal, and connect your adapter if
>> necessary.
>>
>> Tyson.
>>
>> On 31 October 2011 08:03, vijay  wrote:
>>
>>> Hi,
>>>
>>> I not sure if this is the correct forum to post this but, Could some one
>>> tell me if it is possible to install affix bluetooth stack in kubuntu?
>>> Currently BLueZ bluetooth stack is installed and wireshark requires
>>> Affix stack for live capture of bluetooth traffic.
>>>
>>> The affix website says that it can be installed in a kernel with version
>>> 2.6.x or higher, and the version of the kernel I have installed is 3.0.X.
>>> Now can
>>> I install the affix stack in my OS? or Affix doesnt support Kubuntu?
>>>
>>> Thanks
>>>
>>>
>>> ___
>>> Sent via:Wireshark-dev mailing list 
>>> Archives:http://www.wireshark.org/lists/wireshark-dev
>>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>> mailto:wireshark-dev-requ...@wireshark.org
>>> ?subject=unsubscribe
>>>
>>
>>
>>
>> --
>>   Fight Internet Censorship!
>> http://www.eff.org
>> http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
>> 00447934365844
>>
>>
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:http://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>> mailto:wireshark-dev-requ...@wireshark.org
>> ?subject=unsubscribe
>>
>
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>



-- 
  Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Affix bluetooth stack

2011-10-31 Thread vijay
Hi Tyson,

  I need to do a live capture on Bluetooth traffic does wireshark support
capture with BLueZ stack in linux ?

Vijay

On Mon, Oct 31, 2011 at 3:10 AM, Tyson Key  wrote:

> Hi Vijay,
>
> There's no need to install Affix under KUbuntu (although installing other
> stuff from the repositories related to Bluetooth wouldn't hurt). Just
> enable Bluetooth connectivity as normal, and connect your adapter if
> necessary.
>
> Tyson.
>
> On 31 October 2011 08:03, vijay  wrote:
>
>> Hi,
>>
>> I not sure if this is the correct forum to post this but, Could some one
>> tell me if it is possible to install affix bluetooth stack in kubuntu?
>> Currently BLueZ bluetooth stack is installed and wireshark requires Affix
>> stack for live capture of bluetooth traffic.
>>
>> The affix website says that it can be installed in a kernel with version
>> 2.6.x or higher, and the version of the kernel I have installed is 3.0.X.
>> Now can
>> I install the affix stack in my OS? or Affix doesnt support Kubuntu?
>>
>> Thanks
>>
>>
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:http://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>> mailto:wireshark-dev-requ...@wireshark.org
>> ?subject=unsubscribe
>>
>
>
>
> --
>   Fight Internet Censorship!
> http://www.eff.org
> http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
> 00447934365844
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] support for Bluetooth protocol live capture

2011-10-31 Thread Guy Harris

On Oct 31, 2011, at 6:55 AM, Andrei Emeltchenko wrote:

> This is not exactly correct.

By which you mean "not at all correct", presumably. :-)

I've updated the Wiki page to note that it's the BlueZ stack, and that (as per 
the history page on the BlueZ site) it first became part of the mainline kernel 
in 2.4.6.

___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe


Re: [Wireshark-dev] Affix bluetooth stack

2011-10-31 Thread Guy Harris

On Oct 31, 2011, at 6:52 AM, Andrei Emeltchenko wrote:

> Hi,
> 
> On Mon, Oct 31, 2011 at 10:03 AM, vijay  wrote:
>> Hi,
>> 
>> I not sure if this is the correct forum to post this but, Could some one
>> tell me if it is possible to install affix bluetooth stack in kubuntu?
>> Currently BLueZ bluetooth stack is installed and wireshark requires Affix
> 
> Where did you read this?
> 
> Bluez is enough.

It's on the

http://wiki.wireshark.org/CaptureSetup/Bluetooth

page on the Wireshark Wiki, because

1) I had the impression that the Affix stack was the one that's part of 
the kernel now

and

2) the Bluetooth support contributed by Paolo Abeni to libpcap relied 
on the standard kernel code.

2) is, as far as I know, true, but, at least in the 2.6.32.4 kernel, 1) is 
false, at least according to the comments, several of which refer to BlueZ.  
Perhaps I'd gotten in backwards about the Bluetooth stacks.  I'll update the 
Wiki page.
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe


Re: [Wireshark-dev] Same protocol dissector in built-in and plugin form coexisting under different names?

2011-10-31 Thread Anders Broman
Hi,
If possible it's better to try to do that via hooks in the existing dissector.
packet-gtp.c has a dissector table to dissect protocol extension by vendor ID 
if the protocols extension mechanism is used.
Regards
Anders


From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of David Wei HX
Sent: den 31 oktober 2011 08:51
To: wireshark-dev@wireshark.org
Subject: [Wireshark-dev] Same protocol dissector in built-in and plugin form 
coexisting under different names?

Dear Wireshark community,

Is it possible to have two dissectors for the same protocol, one built-in and 
one as a plugin, with the plugin having a slightly different name that can 
dissect additional (perhaps proprietary) information?

For example, without modifying the built-in GTP dissector, can I add a 
GTP-Ericsson dissector as a plugin and disable the built-in GTP dissector by 
modifying the disabled_protos file?

I have attempted this but found that I must modify libwireshark.def and 
recompile in order for the plugin to find certain definitions.

Best regards,
David Wei


___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Same protocol dissector in built-in and plugin form coexisting under different names?

2011-10-31 Thread David Wei HX
Dear Wireshark community,

Is it possible to have two dissectors for the same protocol, one built-in and 
one as a plugin, with the plugin having a slightly different name that can 
dissect additional (perhaps proprietary) information?

For example, without modifying the built-in GTP dissector, can I add a 
GTP-Ericsson dissector as a plugin and disable the built-in GTP dissector by 
modifying the disabled_protos file?

I have attempted this but found that I must modify libwireshark.def and 
recompile in order for the plugin to find certain definitions.

Best regards,
David Wei


___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] support for Bluetooth protocol live capture

2011-10-31 Thread Andrei Emeltchenko
Hi,

On Fri, Oct 28, 2011 at 6:37 AM, Guy Harris  wrote:
>
> On Oct 27, 2011, at 7:50 PM, vijay wrote:
>
>> Can anyone tell me if wireshark support live capture of bluetooth traffic.
>
> On Linux, yes.
>
>> Wireshark wiki says libpcap supports live capture of bluetooth packets , 
>> Wireshark can read pcap files containing bluetooth traffic.
>> But wireshark cannot capture bluetooth traffic. I donot understand why it is 
>> so?
>
> It's so because nobody'd bothered to update the CaptureSetup/Bluetooth page 
> on the Wireshark wiki to indicate that Bluetooth capturing is now supported 
> if Wireshark is using a sufficiently-recent version of libpcap and running on 
> a system with a kernel with the Affix Bluetooth stack (which I think is the 
> basis of the official Bluetooth stack that's now a standard part of the 
> kernel). :-)

This is not exactly correct. Affix was a competing stack from Nokia
which never came to official Linux kernel despite some parts were
rewritten for bluez.

Regards,
Andrei

>
>> wont the above 2 features be sufficient for live capture?
>
> Yes, so I updated the page.
>
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe


Re: [Wireshark-dev] Affix bluetooth stack

2011-10-31 Thread Andrei Emeltchenko
Hi,

On Mon, Oct 31, 2011 at 10:03 AM, vijay  wrote:
> Hi,
>
> I not sure if this is the correct forum to post this but, Could some one
> tell me if it is possible to install affix bluetooth stack in kubuntu?
> Currently BLueZ bluetooth stack is installed and wireshark requires Affix

Where did you read this?

Bluez is enough.

Regards,
Andrei

> stack for live capture of bluetooth traffic.
>
> The affix website says that it can be installed in a kernel with version
> 2.6.x or higher, and the version of the kernel I have installed is 3.0.X.
> Now can
> I install the affix stack in my OS? or Affix doesnt support Kubuntu?
>
> Thanks
>
> ___
> Sent via:    Wireshark-dev mailing list 
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe


[Wireshark-dev] Looking for h248/asn1 packet traces

2011-10-31 Thread Alex Lindberg
I am looking for examples of h248/asn1 based packet captures to validate my my 
custom plugins for h248. All h248 versions (1, 2 and 3).

The only examples on the sample captures page only include MEGACO (text based) 
examples.

    http://wiki.wireshark.org/SampleCaptures

If you have any you wish to share please post them to the above wiki or you may 
send them to me directly.

   alind...@yahoo.com

Thanks for your help.
Alex Lindberg
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Is it still ok to create hidden items ?

2011-10-31 Thread ronnie sahlberg
Make each of them an expansion
and show the generic ".node" field inside the expansion with a help
blurb of "matches either sender or receiver"
?

Wireshark has a 5 digit number of filterable fields already   so for
users to find that a certain field exists and can be used is "tricky".
Unless your protocol is IP, TCP or UDP,   unless the user can "see"
the filter variable in the decode pane it pretty much does not exist.


regards
ronnie sahlberg


On Mon, Oct 31, 2011 at 9:10 PM, Roland Knall  wrote:
> Hi
>
> Ok, always ready to learn something new, but answer me this:
>
>  You have two fields displayed, in my case:
>
> Sender: 0x0001
> Receiver: 0x0002
>
> How do you add a generated field, which will match either one of these
> entries, so that you can ask:
>
> opensafety.msg.node == 0x0002
>
> and only receive messages where either the Sender or the Receiver
> field has the value 0x0002 ?
>
> Using generated fields, just clobbers up the display in such a case,
> because you would have to have 2 entries for [Node] which confuses the
> user. Or am I overlooking some special usage of generated fields here?
>
> One definite negative side-effect of using hidden fields is of course,
> that you can not use the "Apply as .." or "Prepare as .." entries, and
> that the user has to know about them. But that was already mentioned
> earlier.
>
> regards,
> Roland
>
>
> On Mon, Oct 31, 2011 at 11:03 AM, Anders Broman
>  wrote:
>> Hi,
>> I'd say using a generated field is more elegant :-)
>> /Anders
>>
>> -Original Message-
>> From: wireshark-dev-boun...@wireshark.org 
>> [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Roland Knall
>> Sent: den 31 oktober 2011 10:51
>> To: Developer support list for Wireshark
>> Subject: Re: [Wireshark-dev] Is it still ok to create hidden items ?
>>
>> Hi
>>
>> As I just came across something regarding this issue, there is a counter 
>> argument to the whole "if it is not there, the user may not find it" idea. 
>> Looking at the way the IP dissector is used, hidden fields have their 
>> merits. ip.addr is a more generic way of avoiding ( ip.src == x || ip.dest 
>> == x ). I plan to use it in the same way in the openSAFETY dissector, where 
>> I have the fields opensafety.msg.sender and opensafety.msg.receiver, and I 
>> am currently implementing a opensafety.msg.node matching either one.
>>
>> The most elegant solution for such a case is still using hidden fields.
>>
>> regards,
>> Roland
>>
>> On Thu, Oct 27, 2011 at 4:04 PM, Teto  wrote:
>>> Thanks for both of your ideas. What bothers me with Michaels'idea is
>>> that I wonder how many wireshark users know of or use "contains" and
>>> "matches" compared to eq or == keywords. From that point of view,
>>> Jeff's idea looks as a good idea.
>>>
>>> On Thu, Oct 27, 2011 at 3:34 PM, Jeff Morriss  
>>> wrote:

 Teto wrote:
>
> Hi,
>
> Just had a question about what's the best practice. I have a packet
> with a field contianing several keywords. I intend to split those
> keywords so that one can filter display based upon a keyword.
> My problem is am compelled to display each keyword separately (one
> itemp per kewyord and group them in a subtree) or could I display
> all of them in one item in the main tree (my preference) and then
> create several hidden fields (one per keyword). I wonder if that
> last

 Why not combine the two?  Put one item (or maybe even just a text 
 entry--from proto_tree_add_text()) with all the keywords (possibly added 
 with proto_tree_append_text()) and then create a subtree below that with 
 each keyword individually?

 This is how we get, for example, nice summary lines for the TCP protocol 
 (including port numbers, etc.) while keeping the port numbers themselves 
 as separate filterable items in the TCP subtree.
>>> __
>>> _ Sent via:    Wireshark-dev mailing list
>>> 
>>> Archives:    http://www.wireshark.org/lists/wireshark-dev
>>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>>
>>> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>> ___
>> Sent via:    Wireshark-dev mailing list 
>> Archives:    http://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>             mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>> ___
>> Sent via:    Wireshark-dev mailing list 
>> Archives:    http://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>             mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>>
> ___
> Sent via:    Wireshark-dev mailing lis

Re: [Wireshark-dev] Is it still ok to create hidden items ?

2011-10-31 Thread Roland Knall
Hi

Ok, always ready to learn something new, but answer me this:

 You have two fields displayed, in my case:

Sender: 0x0001
Receiver: 0x0002

How do you add a generated field, which will match either one of these
entries, so that you can ask:

opensafety.msg.node == 0x0002

and only receive messages where either the Sender or the Receiver
field has the value 0x0002 ?

Using generated fields, just clobbers up the display in such a case,
because you would have to have 2 entries for [Node] which confuses the
user. Or am I overlooking some special usage of generated fields here?

One definite negative side-effect of using hidden fields is of course,
that you can not use the "Apply as .." or "Prepare as .." entries, and
that the user has to know about them. But that was already mentioned
earlier.

regards,
Roland


On Mon, Oct 31, 2011 at 11:03 AM, Anders Broman
 wrote:
> Hi,
> I'd say using a generated field is more elegant :-)
> /Anders
>
> -Original Message-
> From: wireshark-dev-boun...@wireshark.org 
> [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Roland Knall
> Sent: den 31 oktober 2011 10:51
> To: Developer support list for Wireshark
> Subject: Re: [Wireshark-dev] Is it still ok to create hidden items ?
>
> Hi
>
> As I just came across something regarding this issue, there is a counter 
> argument to the whole "if it is not there, the user may not find it" idea. 
> Looking at the way the IP dissector is used, hidden fields have their merits. 
> ip.addr is a more generic way of avoiding ( ip.src == x || ip.dest == x ). I 
> plan to use it in the same way in the openSAFETY dissector, where I have the 
> fields opensafety.msg.sender and opensafety.msg.receiver, and I am currently 
> implementing a opensafety.msg.node matching either one.
>
> The most elegant solution for such a case is still using hidden fields.
>
> regards,
> Roland
>
> On Thu, Oct 27, 2011 at 4:04 PM, Teto  wrote:
>> Thanks for both of your ideas. What bothers me with Michaels'idea is
>> that I wonder how many wireshark users know of or use "contains" and
>> "matches" compared to eq or == keywords. From that point of view,
>> Jeff's idea looks as a good idea.
>>
>> On Thu, Oct 27, 2011 at 3:34 PM, Jeff Morriss  
>> wrote:
>>>
>>> Teto wrote:

 Hi,

 Just had a question about what's the best practice. I have a packet
 with a field contianing several keywords. I intend to split those
 keywords so that one can filter display based upon a keyword.
 My problem is am compelled to display each keyword separately (one
 itemp per kewyord and group them in a subtree) or could I display
 all of them in one item in the main tree (my preference) and then
 create several hidden fields (one per keyword). I wonder if that
 last
>>>
>>> Why not combine the two?  Put one item (or maybe even just a text 
>>> entry--from proto_tree_add_text()) with all the keywords (possibly added 
>>> with proto_tree_append_text()) and then create a subtree below that with 
>>> each keyword individually?
>>>
>>> This is how we get, for example, nice summary lines for the TCP protocol 
>>> (including port numbers, etc.) while keeping the port numbers themselves as 
>>> separate filterable items in the TCP subtree.
>> __
>> _ Sent via:    Wireshark-dev mailing list
>> 
>> Archives:    http://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>
>> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
> ___
> Sent via:    Wireshark-dev mailing list 
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
> ___
> Sent via:    Wireshark-dev mailing list 
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe


Re: [Wireshark-dev] Is it still ok to create hidden items ?

2011-10-31 Thread Anders Broman
Hi,
I'd say using a generated field is more elegant :-)
/Anders 

-Original Message-
From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Roland Knall
Sent: den 31 oktober 2011 10:51
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Is it still ok to create hidden items ?

Hi

As I just came across something regarding this issue, there is a counter 
argument to the whole "if it is not there, the user may not find it" idea. 
Looking at the way the IP dissector is used, hidden fields have their merits. 
ip.addr is a more generic way of avoiding ( ip.src == x || ip.dest == x ). I 
plan to use it in the same way in the openSAFETY dissector, where I have the 
fields opensafety.msg.sender and opensafety.msg.receiver, and I am currently 
implementing a opensafety.msg.node matching either one.

The most elegant solution for such a case is still using hidden fields.

regards,
Roland

On Thu, Oct 27, 2011 at 4:04 PM, Teto  wrote:
> Thanks for both of your ideas. What bothers me with Michaels'idea is 
> that I wonder how many wireshark users know of or use "contains" and 
> "matches" compared to eq or == keywords. From that point of view, 
> Jeff's idea looks as a good idea.
>
> On Thu, Oct 27, 2011 at 3:34 PM, Jeff Morriss  
> wrote:
>>
>> Teto wrote:
>>>
>>> Hi,
>>>
>>> Just had a question about what's the best practice. I have a packet 
>>> with a field contianing several keywords. I intend to split those 
>>> keywords so that one can filter display based upon a keyword.
>>> My problem is am compelled to display each keyword separately (one 
>>> itemp per kewyord and group them in a subtree) or could I display 
>>> all of them in one item in the main tree (my preference) and then 
>>> create several hidden fields (one per keyword). I wonder if that 
>>> last
>>
>> Why not combine the two?  Put one item (or maybe even just a text 
>> entry--from proto_tree_add_text()) with all the keywords (possibly added 
>> with proto_tree_append_text()) and then create a subtree below that with 
>> each keyword individually?
>>
>> This is how we get, for example, nice summary lines for the TCP protocol 
>> (including port numbers, etc.) while keeping the port numbers themselves as 
>> separate filterable items in the TCP subtree.
> __
> _ Sent via:    Wireshark-dev mailing list 
> 
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe


Re: [Wireshark-dev] Is it still ok to create hidden items ?

2011-10-31 Thread Roland Knall
Hi

As I just came across something regarding this issue, there is a
counter argument to the whole "if it is not there, the user may not
find it" idea. Looking at the way the IP dissector is used, hidden
fields have their merits. ip.addr is a more generic way of avoiding (
ip.src == x || ip.dest == x ). I plan to use it in the same way in the
openSAFETY dissector, where I have the fields opensafety.msg.sender
and opensafety.msg.receiver, and I am currently implementing a
opensafety.msg.node matching either one.

The most elegant solution for such a case is still using hidden fields.

regards,
Roland

On Thu, Oct 27, 2011 at 4:04 PM, Teto  wrote:
> Thanks for both of your ideas. What bothers me with Michaels'idea is
> that I wonder how many wireshark users know of or use "contains" and
> "matches" compared to eq or == keywords. From that point of view,
> Jeff's idea looks as a good idea.
>
> On Thu, Oct 27, 2011 at 3:34 PM, Jeff Morriss  
> wrote:
>>
>> Teto wrote:
>>>
>>> Hi,
>>>
>>> Just had a question about what's the best practice. I have a packet
>>> with a field contianing several keywords. I intend to split those
>>> keywords so that one can filter display based upon a keyword.
>>> My problem is am compelled to display each keyword separately (one
>>> itemp per kewyord and group them in a subtree) or could I display all
>>> of them in one item in the main tree (my preference) and then create
>>> several hidden fields (one per keyword). I wonder if that last
>>
>> Why not combine the two?  Put one item (or maybe even just a text 
>> entry--from proto_tree_add_text()) with all the keywords (possibly added 
>> with proto_tree_append_text()) and then create a subtree below that with 
>> each keyword individually?
>>
>> This is how we get, for example, nice summary lines for the TCP protocol 
>> (including port numbers, etc.) while keeping the port numbers themselves as 
>> separate filterable items in the TCP subtree.
> ___
> Sent via:    Wireshark-dev mailing list 
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe


Re: [Wireshark-dev] Affix bluetooth stack

2011-10-31 Thread Tyson Key
Hi Vijay,

There's no need to install Affix under KUbuntu (although installing other
stuff from the repositories related to Bluetooth wouldn't hurt). Just
enable Bluetooth connectivity as normal, and connect your adapter if
necessary.

Tyson.

On 31 October 2011 08:03, vijay  wrote:

> Hi,
>
> I not sure if this is the correct forum to post this but, Could some one
> tell me if it is possible to install affix bluetooth stack in kubuntu?
> Currently BLueZ bluetooth stack is installed and wireshark requires Affix
> stack for live capture of bluetooth traffic.
>
> The affix website says that it can be installed in a kernel with version
> 2.6.x or higher, and the version of the kernel I have installed is 3.0.X.
> Now can
> I install the affix stack in my OS? or Affix doesnt support Kubuntu?
>
> Thanks
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>



-- 
  Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Affix bluetooth stack

2011-10-31 Thread vijay
Hi,

I not sure if this is the correct forum to post this but, Could some one
tell me if it is possible to install affix bluetooth stack in kubuntu?
Currently BLueZ bluetooth stack is installed and wireshark requires Affix
stack for live capture of bluetooth traffic.

The affix website says that it can be installed in a kernel with version
2.6.x or higher, and the version of the kernel I have installed is 3.0.X.
Now can
I install the affix stack in my OS? or Affix doesnt support Kubuntu?

Thanks
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe