On 06/29/2011 07:21 AM, sagar sg wrote:
Hi Team,
I writing a dissector, in which I need to compare the time stamp in application
level with the arrival time stamp which has been displayed under frame tree of
wireshark. How can I access this arrival time from dissector?
Thanks in Advance
Regard
The Buildbot has detected a new failure of Visual-Studio-Code-Analysis on
Wireshark (development).
Full details are available at:
http://buildbot.wireshark.org/trunk/builders/Visual-Studio-Code-Analysis/builds/1133
Buildbot URL: http://buildbot.wireshark.org/trunk/
Buildslave for this Build: v
The Buildbot has detected a new failure of Windows-7-x64 on Wireshark
(development).
Full details are available at:
http://buildbot.wireshark.org/trunk/builders/Windows-7-x64/builds/2221
Buildbot URL: http://buildbot.wireshark.org/trunk/
Buildslave for this Build: windows-7-x64
Build Reason:
Hi Team,
I writing a dissector, in which I need to compare the time stamp in
application level with the arrival time stamp which has been displayed under
frame tree of wireshark. How can I access this arrival time from dissector?
Thanks in Advance
Regards,
Sagar
_
On Tue, Jun 28, 2011 at 9:37 PM, Guy Harris wrote:
> However, if LANG is blank, you presumably don't have Terminal set up to "Set
> local enviornment variables on startup" (Preferences > Settings > Advanced,
> at the bottom);
Actually I have "Set local environment variables on startup" checked.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm proud to announce the release of Wireshark 1.2.18.
NOTE: The 1.2.x series of Wireshark releases will reach end of life on
June 30, 2011. If you are still using Wireshark 1.2 we strongly
encourage you to upgrade to 1.6.
What is Wireshark?
Wir
On Jun 28, 2011, at 12:25 PM, Stig Bjørlykke wrote:
> On Tue, Jun 28, 2011 at 7:27 PM, Guy Harris wrote:
>> OK, what OS are you using?
>
> Snow:~ stig$ uname -a
> Darwin ...
Well, that answers *that* question. :-)
So the locale's encoding should probably be UTF-8, given that it's OS X.
Howev
On Tue, Jun 28, 2011 at 7:27 PM, Guy Harris wrote:
> OK, what OS are you using?
Snow:~ stig$ uname -a
Darwin Snow.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7
16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386
Snow:~ stig$ echo $LANG
Snow:~ stig$ gcc norsk.c -o norsk && ./norsk
S
On Jun 28, 2011, at 10:27 AM, Guy Harris wrote:
> We have an issue regarding strings in packets in general. Strings might be
> in a number of encodings, including ASCII (meaning that any byte with the 8th
> bit set is something that shouldn't be there), other national variants of ISO
> 646, U
On Jun 28, 2011, at 10:43 AM, Guy Harris wrote:
> On Jun 28, 2011, at 10:27 AM, Guy Harris wrote:
>
>> when putting them into a textual representation of the protocol tree or
>> into columns or something else to be shown to humans, map them to UTF-8,
>> with anything that can't be mapped
On Jun 28, 2011, at 10:27 AM, Guy Harris wrote:
> when putting them into a textual representation of the protocol tree or
> into columns or something else to be shown to humans, map them to UTF-8, with
> anything that can't be mapped to UTF-8 - including, if the encoding is
> putatively
On Jun 28, 2011, at 10:01 AM, Guy Harris wrote:
> In any case, that means that using strerror() is probably not going to be
> sufficient to fix the problem. What we might want to do is use UTF-8
> everywhere we can, and, for non-GUI output, convert to the appropriate
> character encoding - wh
On Jun 28, 2011, at 6:10 AM, Stig Bjørlykke wrote:
> On Tue, Jun 28, 2011 at 2:58 AM, Guy Harris wrote:
>>1) UN*Xes where LANG etc. aren't set to a locale with UTF-8 as the
>> encoding (are you seeing the issue with Norwegian characters on your system?
>> If so, what's the setting of
On Jun 28, 2011, at 3:33 AM, Stig Bjørlykke wrote:
> Do we always know where the error message is used?
> I suspect file_open_error_message() is used both in GUI and tshark.
Yes - it's in epan.
___
Sent via:Wireshark-dev
On Jun 28, 2011, at 3:22 AM, Jakub Zawadzki wrote:
> Btw. I know that nowadays I'm the only one who uses non-utf locales on
> console,
> but when we print on console (stdout/stderr) I think we should use strerror()
> from libc,
> i.e. strerror() which don't recode message to utf-8.
It's more c
On Jun 28, 2011, at 2:25 AM, Graham Bloice wrote:
> On 28/06/2011 01:58, Guy Harris wrote:
>>
>> 2) Windows, where "Unicode" generally means "UTF-16", and APIs that
>> return strings encoded as sequences of octets rather than hexadectets
>> probably return strings in the local code page.
The Buildbot has detected a new failure of Ubuntu-10.04-x64 on Wireshark
(development).
Full details are available at:
http://buildbot.wireshark.org/trunk/builders/Ubuntu-10.04-x64/builds/1609
Buildbot URL: http://buildbot.wireshark.org/trunk/
Buildslave for this Build: ubuntu-10.04-x64
Build
The Buildbot has detected a new failure of Windows-7-x64 on Wireshark
(development).
Full details are available at:
http://buildbot.wireshark.org/trunk/builders/Windows-7-x64/builds/2215
Buildbot URL: http://buildbot.wireshark.org/trunk/
Buildslave for this Build: windows-7-x64
Build Reason:
On Tue, Jun 28, 2011 at 2:58 AM, Guy Harris wrote:
> 1) UN*Xes where LANG etc. aren't set to a locale with UTF-8 as the
> encoding (are you seeing the issue with Norwegian characters on your system?
> If so, what's the setting of LANG?);
I only had issues with Norwegian characters in fi
On Tue, Jun 28, 2011 at 12:22 PM, Jakub Zawadzki
wrote:
> Btw. I know that nowadays I'm the only one who uses non-utf locales on
> console,
> but when we print on console (stdout/stderr) I think we should use strerror()
> from libc,
> i.e. strerror() which don't recode message to utf-8.
Do we a
On Tue, Jun 28, 2011 at 10:14:34AM +0200, Stig Bj?rlykke wrote:
> On Tue, Jun 28, 2011 at 9:35 AM, Jakub Zawadzki
> wrote:
> > g_strerror() ?
>
> Yes, of course :) Thank you.
no problem ;-)
Btw. I know that nowadays I'm the only one who uses non-utf locales on console,
but when we print on con
On 28/06/2011 01:58, Guy Harris wrote:
>
> 2) Windows, where "Unicode" generally means "UTF-16", and APIs that
> return strings encoded as sequences of octets rather than hexadectets
> probably return strings in the local code page.
>
Is this a first sighting of a new word "hexadectet"? Goo
On Tue, Jun 28, 2011 at 9:35 AM, Jakub Zawadzki
wrote:
> g_strerror() ?
Yes, of course :) Thank you.
--
Stig Bjørlykke
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
On Jun 28, 2011, at 8:31 AM, Michael Tüxen wrote:
> On Jun 28, 2011, at 4:45 AM, Guy Harris wrote:
>
>>
>> On Jun 27, 2011, at 12:13 PM, Michael Tüxen wrote:
>>
>>> It is fixed in r37806. The currently
>>> tshark -i lo0 -i en0 -f icmp sctp
>>> will use sctp as the default capture filter. This m
On Jun 28, 2011, at 9:26 AM, Joerg Mayer wrote:
> Can you please update the manpage to document the behavior of the different
> types?
ahhh. I missed that... I'll do.
Best regards
Michael
>
> Thanks
> Joerg
> --
> Joerg Mayer
> We are stuck with te
On Mon, Jun 27, 2011 at 05:58:35PM -0700, Guy Harris wrote:
> > We have about 240 calls to strerror().
>
> ...and, unfortunately, a variant that converts to UTF-8 and is API-compatible
> is non-trivial,
> as any version that allocates a buffer for the result of the conversion would
> leak memor
Can you please update the manpage to document the behavior of the different
types?
Thanks
Joerg
--
Joerg Mayer
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
27 matches
Mail list logo
