Or bug reports, plural - I suspect the two problems he cites are unrelated to
each other.
Guy + Jaap. I will get cook up some reproducible test-case
and add a bug-report.
--gv
___
Sent via:Wireshark-dev mailing list
A
On Jan 2, 2012, at 12:20 PM, Jaap Keuter wrote:
> Can you file a proper bug report on this at bugs.wireshark.org
Or bug reports, plural - I suspect the two problems he cites are unrelated to
each other.
___
Sent via:Wir
On Jan 2, 2012, at 7:26 AM, Gisle Vanem wrote:
> There are some places in the ./gtk sources that causes a
> crash while sniffing on a AirPcap adapter. I don't know why;
> maybe most code assumes the captured frames contain network
> layer packets.
Or not. They could be the result of various dif
Hi,
Can you file a proper bug report on this at bugs.wireshark.org
That way the bug context and patch won't get lost (although it may take
a while for it to be picked up, unfortunately).
Thanks,
Jaap
On 2012-01-02 16:26, Gisle Vanem wrote:
There are some places in the ./gtk sources that caus
On 2012-01-02 08:16, Michael Tuexen wrote:
> On Jan 2, 2012, at 3:53 AM, Guy Harris wrote:
>
>>
>> On Jan 1, 2012, at 3:00 PM, Martin Kaiser wrote:
>>
>>> In a pcapng file, does the string stored in an opt_comment option have
>>> to be 0-terminated? I couldn't find anything explicit about this in
There are some places in the ./gtk sources that causes a
crash while sniffing on a AirPcap adapter. I don't know why;
maybe most code assumes the captured frames contain network
layer packets. Since my Airpcap (\\.\airpcap00 on Win-XP) only gives
me IEEE 802.11 radio frames, I can only speculate.
On Jan 1, 2012, at 3:06 AM, Joerg Mayer wrote:
> OK, a more general question:
> As it looks like we will soon have a second "full blown" ui (tshark isn't
> interactive, so I don't count this), how about
> - reorganizing the filesystem into something like:
> ui/ <- common ui stuf
On Jan 2, 2012, at 3:53 AM, Guy Harris wrote:
>
> On Jan 1, 2012, at 3:00 PM, Martin Kaiser wrote:
>
>> In a pcapng file, does the string stored in an opt_comment option have
>> to be 0-terminated? I couldn't find anything explicit about this in the
>> specification. Pcapng options have a length