On Feb 3, 2012, at 7:51 AM, Joerg Mayer wrote:
> iOS version:
> - Probably not: Apple does not allow GPLed Software in the applestore:
> http://michelf.com/weblog/2011/gpl-ios-app-store/
...and also probably doesn't allow programs that run as root, which would be
needed if the permissions on t
Joerg Mayer wrote:
As some people met in Brussels on the eve of FOSDEM and talked about Wireshark,
here are some notes on what was talked about. We just don't want to leave anyone
out on what was talked about.
As usual: These are personal opinions etc, nothing is set in stone
[...]
packet-
On 2/3/2012 11:50 AM, Graham Bloice wrote:
cmake:
- on windows
+ cmake would allow out-of-tree builds on Windows
+ starting with a cygwin/nmake alternative would be an idea as there is
no native windows / VisualStudio setup available right now.
Meaning: out-of-tree using nmak
> >
> > cmake:
> > - on windows
>
> >+ cmake would allow out-of-tree builds on Windows
> >+ starting with a cygwin/nmake alternative would be an idea as there is
> > no native windows / VisualStudio setup available right now.
>
> Meaning: out-of-tree using nmake ?
>
> (If so, I cou
Hi all down there in Belgium,
I see I missed a lot already :/ Good to see so many things discussed.
Well done documenting this Jörg.
Without starting a complete discussion I would like to put in my 2
cents.
On backporting, I did a lot of that stuff for 1.4.11. From my
experience, when the
Jörg:
Thanks for the detailed write-up.
Bill
(See below)
On 2/3/2012 10:51 AM, Joerg Mayer wrote:
qtshark:
- maybe we can attract a seasoned qt-developer to help us getting started
with the qtshark design stuff
+1
cmake:
- on windows
+ cmake would allow out-of-tree builds on W
As some people met in Brussels on the eve of FOSDEM and talked about Wireshark,
here are some notes on what was talked about. We just don't want to leave anyone
out on what was talked about.
As usual: These are personal opinions etc, nothing is set in stone
ciao
Jörg
Next release:
- w
On Fri, Feb 3, 2012 at 3:02 PM, Anders Broman
wrote:
> Hi,
> Forget about my comment about the sip hash table.
>
> Please add the patch(es) to bugzilla, if possible break it up to something we
> can commit straight away and stuff that needs to be worked on to work
> For all taps as that can't be
Hi,
Forget about my comment about the sip hash table.
Please add the patch(es) to bugzilla, if possible break it up to something we
can commit straight away and stuff that needs to be worked on to work
For all taps as that can't be committed until it's done for all tap. Two bug
reports?
Regards
On Fri, Feb 3, 2012 at 1:44 PM, Anders Broman
wrote:
> Hi,
> Please put the patches in bugzilla, if possible split them in two parts one
> that's ok for all types(Step 2,3,4?) of calls and one which
> Implements the stuff for SIP but not for the other call types.
cristian: step 1 is dealing only
Hi,
It was just a thought for this specific case, as I think it might be exactly
the same hash table...
7Anders
-Original Message-
From: wireshark-dev-boun...@wireshark.org
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Jaap Keuter
Sent: den 3 februari 2012 14:46
To: Develop
Hi,
Sharing this table between a dissector and a tap would probably be Bad
Style, IMHO.
Sending this relevant information from the dissector to the tap may be
possible.
Question is how the generalize this for all types of calls.
Thanks,
Jaap
On 2012-02-03 13:44, Anders Broman wrote:
Hi,
Pl
On 2012-02-03 13:01, Cristian Constantin wrote:
hi!
wireshark can draw call flows for sip voip calls
(accessible through the menu Telephony/VoIP Calls).
however, when the capture is large, containing tens of
thousands of sip voip calls, wireshark becomes very slow
at producing the list of calls
Hi,
Please put the patches in bugzilla, if possible split them in two parts one
that's ok for all types(Step 2,3,4?) of calls and one which
Implements the stuff for SIP but not for the other call types. I think the SIP
dissector keeps a table over the calls as well could that table be shared?
Reg
hi!
wireshark can draw call flows for sip voip calls
(accessible through the menu Telephony/VoIP Calls).
however, when the capture is large, containing tens of
thousands of sip voip calls, wireshark becomes very slow
at producing the list of calls and the call flows.
here are my experiences with
My apologies for the short notice, but if anyone wants to join in the
conference you can connect to the following URLs and phone numbers:
Meeting Name: Gerald Combs
Summary: Wireshark development
Invited By: Gerald Combs (gerald.co...@riverbed.com)
When: 02/03/2012 12:45 AM - 6:45 AM
Time Zone:
On Feb 3, 2012, at 1:07 AM, jma...@wireshark.org wrote:
> The libpcap puts pcap-filter into the misc section (which seems to be 7).
Section 7 in systems with V7/BSD-style man page conventions, section 5 in
systems with System III/System V-style man page conventions; see libpcap's
configure scr
17 matches
Mail list logo
