Howdy,
I'm writing a wiretap file reader for a format which uses ascii encoding for
metadata, and I'd like to use regex/PCRE for it. (it would be a lot
cleaner/simpler than sscanf)
I'd like to be able to contribute this file reader back into mainline someday.
Since PCRE is optional in the dev
at 01:14:37PM -0400, Hadriel Kaplan wrote:
Since PCRE is optional in the dev docs, does that mean I can't
safely assume it's available in wireshark builds?
Yes, however, we recently started using GLib's GRegex functionality in
place of PCRE when running a high-enough GLib version. It's
OK, cool, got it.
thanks again!
On Sep 18, 2010, at 4:44 PM, Stephen Fisher wrote:
On Sat, Sep 18, 2010 at 01:46:43PM -0400, Hadriel Kaplan wrote:
Thanks for the tip! (I had looked at GRegex but worried about older
GLib, but version checking is fine with me) BTW, your answer of yes
Howdy,
I've submitted bug 5242 with an attached patch diff for supporting the IPFIX
file format, per RFC 5655.
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5242
The one open issue/question I have regards a heuristic for determining if it's
the right file type. Unfortunately, the IPFIX
!
-hadriel
On Sep 21, 2010, at 1:42 PM, Jeff Morriss wrote:
Hadriel Kaplan wrote:
Howdy,
I've submitted bug 5242 with an attached patch diff for supporting the IPFIX
file format, per RFC 5655.
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5242
The one open issue/question I have regards
Howdy,
For a few years my company's provided a free offline-tool to convert from an
internal SIP message capture format of SIP messages received by our system
parsers, to pcap format. This tool does the classic trick of creating fake
Ethernet+IP+UDP headers and formatting the thing as a pcap.
Howdy,
I'm thinking of adding XML dictionary file support to the IPFIX dissector,
similar in concept to the Diameter dictionary. It appears Wireshark's Diameter
dictionary reader uses flex/bison to parse the XML, and I'm curious if that's
what we're supposed to use for such things in
, Oct 16, 2010 at 12:40:17PM -0400, Hadriel Kaplan wrote:
or libxml2 which I think is included in wireshark builds (right?),
libxml2 is not a requirement to build Wireshark, nor is it even an
option.
because I'm not familiar with flex/bison or lex/yacc. But if there's
some specific reason
Ugh - my patch submitted as bug 5242 caused it. Sorry bout that. I didn't
realize the bug was taken in yet (I had added myself to its cc list, but never
got an email).
-hadriel
On Oct 20, 2010, at 10:28 AM, Jeff Morriss wrote:
Bill Meier wrote:
buildbot-no-re...@wireshark.org wrote:
The
Yeah but I feel stupid because I actually found and fixed that bug in my local
ipfix.c afterwards, and didn't go fix it in the bug-database entry. :(
-hadriel
On Oct 20, 2010, at 12:28 PM, Bill Meier wrote:
Hadriel Kaplan wrote:
Ugh - my patch submitted as bug 5242 caused it. Sorry bout
In wireshark, select analyze - enabled protocols... and uncheck everything
you don't need. (though you will need to keep the lower layers dissected -
e.g., for HTTP you'd need to keep Ethernet, IP, TCP selected, and possibly
IPv6, and of course HTTP and possibly SSL, etc)
If all you want is
You don't have the following at the beginning of your .c file:
#ifdef HAVE_CONFIG_H
#include config.h
#endif
I assume without that, HAVE_LIBZ (and a bunch of other stuff) isn't defined
when your .c file includes the remaining header files, and it's doomed.
-hadriel
On Oct 22, 2010, at 7:50
Howdy,
The current packet-netflow.c dissector has a big switch (pen_type) {...}
block in dissect_v9_v10_pdu_data(), which looks up specific known netflow/ipfix
fields as it walks netflow v9/10 PDUs.
Unfortunately, it's a bit of a hack as pen_type is a guint64 and a switch
statement will
On Nov 7, 2010, at 12:33 PM, Jakub Zawadzki wrote:
On Sun, Nov 07, 2010 at 10:46:47AM -0500, Hadriel Kaplan wrote:
Howdy,
The current packet-netflow.c dissector has a big switch (pen_type) {...}
block in dissect_v9_v10_pdu_data(), which looks up specific known
netflow/ipfix fields
On Nov 7, 2010, at 12:51 PM, Bill Meier wrote:
Looking at the code a bit I see that currently pen
seems to be effectively limited to 16 bits even though 32 bits are
fetched from the tvbuff:
dissect_v9_v10_template_fields(...) {
...
guint16 pen;
...
if
On Nov 7, 2010, at 4:13 PM, Jakub Zawadzki wrote:
On Sun, Nov 07, 2010 at 03:37:36PM -0500, Hadriel Kaplan wrote:
I really don't want to force it bigger than int, I just want to make it
unsigned.
cause:
(gdb) call /x (unsigned long long) (0xdead 16)
$1
Holy crap - what spec is that??
-hadriel
On Nov 9, 2010, at 9:51 AM, Billy Prin wrote:
Hi,
I am writing my first dissector for an internal protocol. Part of the
protocol is based on a spec that must be obtained via a web service based on
its ID. So in order to obtain the information
On Nov 11, 2010, at 7:30 PM, Jouni Malinen wrote:
This looks somewhat better than the picture I got from the wiki page
(http://wiki.wireshark.org/Development/PcapNg) which seemed to
indicate that only Ethernet link type would be supported. Though, the
per-packet opt_comment part would likely
On Nov 11, 2010, at 8:45 PM, Guy Harris wrote:
On Nov 11, 2010, at 5:27 PM, Hadriel Kaplan wrote:
If you do it, please make it agnostic to the file format, or at least easy
to patch for other file formats. Wireshark supports reading/writing
multiple file formats, some of which also
+1 for packet length - I always add this too, as does everyone else I work with
as far as I've seen.
But the icons+text I think is unnecessary and will annoy some people - there's
precious little space for actual packet decoding display already and cluttering
it up with more toolbar
Howdy,
Sorry for the long email, but it's better than wasting time coding something
people won't accept. :)
I have a need to add yet another file format for Wireshark to read from (not
write/dump to), which I've done before in C. It occurs to me, though, that my
use-case this time would be
Not critiquing your approach, but if you've got a tool that analyzes pcap data
for TCP/IP connections/stats, and also uses Wireshark, why not just write the
tool inside Wireshark? (e.g., as a tap)
Alternatively, if your tool is stand-alone and uses Wireshark only for detailed
drill-down
Howdy,
Setting column text via Lua plugins by using the pinfo:set() method (the Pinfo
from a Listener tap), doesn't seem to work for two reasons:
1) The TL_REQUIRES_COLUMNS flag wasn't being set when registering Lua listener
taps in Listener_new(). I fixed that in my local copy.
2) Wireshark
On Feb 11, 2013, at 7:37 PM, Guy Harris g...@alum.mit.edu wrote:
*If* Wireshark is supposed to support setting columns in taps, rather than in
dissectors or in post-dissectors:
http://wiki.wireshark.org/Lua/Examples/PostDissector
*then* the listener taps would have to be called
Project-A:
Provide a way for Wireshark to automatically check-for and optionally
auto-retrieve the most recent version from wireshark's site/mirrors,
automagically every X timeframe (where X is user-configurable to every X
days/weeks), in the background asynchronously. This should be disabled
On Feb 15, 2013, at 2:15 AM, Guy Harris g...@alum.mit.edu wrote:
On Feb 14, 2013, at 9:09 PM, Hadriel Kaplan hkap...@acmepacket.com wrote:
Provide a way for Wireshark to automatically check-for and optionally
auto-retrieve the most recent version from wireshark's site/mirrors
On Feb 15, 2013, at 4:37 AM, Bálint Réczey bal...@balintreczey.hu wrote:
And also pointless, since every modern distribution have apt-get or
yum or something similar.
Mac OSX has macports (which BTW is broken for Wireshark for me right now, due
to bug 8298).
But you have to remember to go
On Feb 15, 2013, at 12:00 PM, Gerald Combs ger...@wireshark.org wrote:
A combination of Sparkle, WinSparkle, or Fervor might do what we need:
http://sparkle.andymatuschak.org/
http://winsparkle.org/
https://github.com/pypt/fervor
Excellent! I figured the underlying component must have
On Feb 15, 2013, at 2:20 PM, Guy Harris g...@alum.mit.edu wrote:
For Linux and *BSD, the developers/distributors largely have their own
package collections, which include Wireshark.
For OS X and Windows, the vendors may have App Stores, to which Wireshark
would almost certainly not be
On Feb 15, 2013, at 3:41 PM, Guy Harris g...@alum.mit.edu wrote:
I'm not following you - I'm not talking about adding wireshark to MacPorts
or yum, etc. (it's already available through them)
MacPorts and yum/apt/etc. aren't the same sort of thing, which is the point
I'm making.
Ahh, now
On Feb 15, 2013, at 7:51 PM, Gerald Combs ger...@wireshark.org wrote:
As it turns out, getting WinSparkle up and running was pretty easy. I'm
going to try to have automatic updates for Win32 and possibly Win64 in
place for the 1.9.0 release.
Sweet!
-hadriel
Wireshark's SIP dissector is throwing an error on the RAck header field method
name.
It shouldn't, because the message's header is correctly formed, but there's a
bug in packet-sip.c:
for case POS_RACK, when it goes to add the method name, it's using
'(int)linelen-sub_value_offset' for the
Howdy,
About a year ago r41216 fixed bug 3315, so that fragments which contributed to
a reassembled PDU that matched a display-filter would be exported along with
the filter-matching PDU's final frame. I.e., suppose I have a display-filter
of 'sip' and frame #3 is the only frame displayed
filter' style thing they can pipe two instances together,
or save and reopen the filtered file.
Evan
On Sat, Mar 2, 2013 at 12:50 AM, Hadriel Kaplan hkap...@acmepacket.com
wrote:
Howdy,
About a year ago r41216 fixed bug 3315, so that fragments which contributed
to a reassembled PDU
BTW, some output from that bug's pcap with your filter:
./tshark -r testcapture.pcapng -R 'ip.src == 10.90.130.69 ip.dst ==
10.90.130.66 tcp.flags.push == 1'
5 0.001054000 0.5 10.90.130.69 - 10.90.130.66 HTTP/XML POST
/urreq/rrurreq.dll/?soaprequest HTTP/1.1
./tshark -r
On Mar 3, 2013, at 9:57 AM, Evan Huus eapa...@gmail.com wrote:
Right now, wireshark has three CLI filter flags: -R, -d, -f.
-d is available through the 'filter' field in the file-open dialogue
-f is available through the 'capture filter' field in the
capture-options dialogue
-R is not
On Mar 3, 2013, at 9:57 AM, Evan Huus eapa...@gmail.com wrote:
For consistency, I would suggest that both tshark and wireshark take
only two filter flags:
-d using wireshark dfilter syntax
-f using libpcap syntax
Tshark's -d uses only one pass unless -2 is specified. In either case
it
On Mar 3, 2013, at 1:06 PM, Evan Huus eapa...@gmail.com wrote:
Hmm, yes. So the one-pass mode should behave the same as wireshark
except for fragmented packets then?
And except for response frame referencing in request frames, which I think was
the reason the two-pass mode was added to begin
On Mar 3, 2013, at 1:51 PM, Christopher Maynard christopher.mayn...@gtech.com
wrote:
I think there is a difference between displaying the packets matching the
filter
and saving the packets matching the filter to another pcap file. In the
former
case, Wireshark does not display packets
On Mar 3, 2013, at 10:00 PM, Evan Huus eapa...@gmail.com
wrote:
This is getting complicated. A few points in no particular order:
=== tshark default behaviour ===
We can't make -2 the default for tshark doing live capture, as that
would require us to buffer all output until the capture
On Mar 3, 2013, at 10:00 PM, Evan Huus eapa...@gmail.com wrote:
=== filtering ===
I *really* do not like the renumbering of frames that the read filters
currently do (-R in wireshark, -2R in tshark). I find it confusing and
not useful entirely apart from the fact that there is no graceful
On Mar 8, 2013, at 6:40 AM, Cristian Constantin const.cr...@googlemail.com
wrote:
cristian: thanks a lot tony and hadriel. it works. otoh I need to dive
a little bit more into this lua language.
one more thing though. suppose I do this in the tap.packet():
local tags = {
On Mar 8, 2013, at 6:20 PM, Jeff Morriss jeff.morriss...@gmail.com wrote:
Note that someone did find a use case for not saving those dependencies: for
when Wireshark got the dependencies wrong (due to, in that case, packet
duplication):
On Mar 9, 2013, at 3:41 AM, Cristian Constantin const.cr...@googlemail.com
wrote:
cristian: if I need tag as a number I should use:
tonumber (tostring (tag))
right?
You can do it that way - but looking at the C-code it looks like you can also
just do this:
local myval = tag.value
On Mar 8, 2013, at 10:49 AM, Lee Brooks
lee.brooks.in...@gmail.commailto:lee.brooks.in...@gmail.com wrote:
Okay, I've tried creating a Wireshark Lua plugin however I'm unable to keep a
thread open in the background to change the GUI-filter without blocking the
Wireshark main thread. I've even
On Mar 16, 2013, at 7:35 AM, Jaap Keuter jaap.keu...@xs4all.nl wrote:
We may want to get something like this going for OUI's as well.
I think the current OUI getter code (make-manuf) needs to change anyway - it
currently gets the 22-bit OUIs and Individual Address Blocks (IABs) from IEEE's
On Mar 16, 2013, at 1:59 PM, Hadriel Kaplan hkap...@acmepacket.com wrote:
I think the current OUI getter code (make-manuf) needs to change anyway - it
currently gets the 22-bit OUIs and Individual Address Blocks (IABs) from
IEEE's website, but does not get the OUI-36 listing that's been
This email is getting long - sorry bout that.
On Mar 18, 2013, at 6:24 AM, Cristian Constantin const.cr...@googlemail.com
wrote:
cristian: even when the packet filter looks like this:
tap = Listener.new(nil, mtp2 isup)
??
the script prints the 'nil' for all the packets in the
On Mar 18, 2013, at 8:14 AM, Hadriel Kaplan hkap...@acmepacket.com wrote:
So apparently I'm wrong... well, sorta wrong - there are two 'mtp2.li' fields
as I said, but it appears that the Lua code will unfortunately return nil if
the first one is not filled in, and the first one in this case
On Mar 27, 2013, at 6:38 AM, michal.labed...@tieto.com wrote:
2) Why destroy the G729/G723 support? Even though it's not in there, they're
hooks for having it there.
As I know license of this library (G729/G723) does not allow the linking
with Wireshark. Instead of there is plugin
On Mar 27, 2013, at 8:52 AM, Evan Huus eapa...@gmail.com wrote:
We just got another bug on what I believe is exactly the same issue:
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8529
Do we have at least a rough consensus on what the correct behaviour is?
I've had a patch sitting
On Mar 27, 2013, at 12:17 PM, Evan Huus eapa...@gmail.com wrote:
That patch is a Very Good Thing. I know we discussed a few tweaks (for
example it probably shouldn't imply -2?), but I think those and the
actual flag used are bike-shedding at this point.
I still want to pick some nits, but
On Mar 27, 2013, at 1:57 PM, Evan Huus eapa...@gmail.com wrote:
-d filtering is done when displaying, and has no effect on the
internal dissection at all (note this does not force 2 passes).
Actually I'm pretty sure Wireshark *does* perform two passes when a display
filter is applied from
On Mar 27, 2013, at 5:44 PM, Evan Huus eapa...@gmail.com wrote:
On Wed, Mar 27, 2013 at 2:43 PM, Hadriel Kaplan hkap...@acmepacket.com
wrote:
On Mar 27, 2013, at 1:57 PM, Evan Huus eapa...@gmail.com wrote:
-d filtering is done when displaying, and has no effect on the
internal
On Mar 28, 2013, at 7:36 AM, Evan Huus eapa...@gmail.com wrote:
- We need to keep '-2' around for the case where the user wants to do
2-pass analysis without any filtering.
Agreed, and that's still done/supported by the patch.
- Buffering is unfortunately necessary behaviour, but still
On Mar 28, 2013, at 1:37 PM, Evan Huus eapa...@gmail.com wrote:
On Thu, Mar 28, 2013 at 12:41 PM, Hadriel Kaplan hkap...@acmepacket.com
wrote:
How about this: we make '-d' usable in one-pass or two-pass modes, based on
'-2' etc.; and we make the '-R' automatically-and-only be for two
Hi Cristian - thanks for example script!
Comments inline...
On Mar 20, 2013, at 1:11 PM, Cristian Constantin const.cr...@googlemail.com
wrote:
hi!
I attach a lua script that can extract and dump in a separate file
isup payloads from either sigtran or ss7 packets.
Do you have a sample
On Mar 29, 2013, at 11:15 AM, Evan Huus eapa...@gmail.com wrote:
I've updated the bug with a link to this discussion and a quick
summary. Were you planning to code this or should I add it to my todo
list?
I am more than happy to let you do it. :)
Sorry I didn't mean for this topic to take
On Aug 12, 2013, at 6:22 AM, Martin Kaiser li...@kaiser.cx wrote:
I'm not really familiar with SIP over TCP (in all my use cases, SIP is
over UDP) but your proposal makes sense.
Thanks Pascal,
that explains why nobody spotted this so far.
I think it's more because it's only the
for commit message:
remote: Merge branch 'master' of ssh://code.wireshark.org:29418/wireshark
remote:
remote: Change-Id: I822fbedd22746042a4a18f40811a78a4e570bba0
git log shows this:
commit 3c98af518ea9c497bada38e4e600977802da9226
Author: Hadriel Kaplan hadri...@yahoo.com
Date: Wed Jan 29 23:43:31
In the past with svn, when we found a bug caused by a previous code change, we
used the revision number in bugzilla comments with a leading ‘r’, like
‘r12345’. This would auto-create a very convenient url link in bugzilla to the
svn browsing web pages. Now that we’re on git, do we:
1)
Howdy,
I noticed myself and some others recently submitting changes to .gitignore,
adding files we keep in our directories, such as our favorite editor’s specific
files.
Being a git newbie I figured this was just going to be necessary, and
wireshark’s .gitignore would grow to include a very
On Feb 7, 2014, at 8:04 PM, Guy Harris g...@alum.mit.edu wrote:
There's a LuaFileSystem package:
http://keplerproject.github.io/luafilesystem/
that presumably uses standard UN*X calls on UN*Xes and appropriate Windows
calls on Windows.
We also have our own wrappers in the
On Feb 8, 2014, at 8:36 PM, Tony Trinh ton...@gmail.com wrote:
Hadrial Kaplan wrote:
The problem is if you write a plugin for others to use, requiring them to
compile code is a high bar to expect. So if it's more than just another pure
lua lib which doesn't need c-code to be compiled,
Speaking of old reviews, anything going on with the Michael Labedzki's
omnivorous-shark one? (https://code.wireshark.org/review/#/c/16)
I ask because I've implemented a feature whose code will change quite a bit
if/when the omnivorous-shark one gets merged, so I've been waiting for that
merge
+1
I was just using one of those last week and resorted to grep'ing through the
code to find the who set those various tvb length values, to figure out which
length was which. Making it sound more similar to wtap_pkthdr's len vs.
caplen is better, which it sounds like your change would do.
On Feb 18, 2014, at 4:23 PM, Dirk Jagdmann d...@cubic.org wrote:
I understand that there are good reasons to know about the actual length of
the
frame and the captured length. I suggest that we simply state these lengths in
the function name and *not* have an unqualified (shorter) name
Howdy,
Does anyone know what clang static analyzer checker-XXX version is used by the
bots, for example for this:
http://www.wireshark.org/download/automated/analysis/scan-build-2014-02-18-1/
I ask because I'm trying to cleanup some of the ones in wslua, and I don't get
the same errors when
On Feb 19, 2014, at 7:46 PM, Gerald Combs ger...@wireshark.org wrote:
May be see with Gerald to update the analyzer
It's now using Clang 3.3.
Cool, that seems to have removed some previous (false-positive) errors.
Thanks!
-hadriel
On Feb 19, 2014, at 7:03 PM, Evan Huus eapa...@gmail.com wrote:
You can reuse a single spare field for all of these bytes, and they
would only cause a single entry in the filter expression dialog. I
suspect this is the best answer.
Speaking of duplicating field abbreviation names, I was
On Feb 20, 2014, at 2:35 PM, Pascal Quantin pascal.quan...@gmail.com wrote:
Hi,
It can create issues (as you can guess) and this is tracked by bug 2402.
Huh. Well at least it's a recent problem. ;)
-hadriel
___
Sent
Howdy,
Along the lines of bug 2402, I'm adding verification code to prevent Lua script
duplicate field registration (bug 9709). The idea is to allow duplicate fields
if their ftypes are similar enough; otherwise reject it.
The question, though, is what ftypes are similar enough?
There's a
On Feb 21, 2014, at 1:29 PM, Evan Huus eapa...@gmail.com wrote:
That patch almost (but not quite) matches what's listed in
README.dissector (lines 1018-1024). I believe the README is correct,
in which case the patch is simply out of date (I believe it's missing
FT_AX25 and FT_VINES, and
filtering input. (though I'm not positive about that)
-hadriel
On Feb 21, 2014, at 2:15 PM, Guy Harris g...@alum.mit.edu wrote:
On Feb 21, 2014, at 10:43 AM, Hadriel Kaplan hadriel.kap...@oracle.com
wrote:
So this then:
- FT_INT8, FT_INT16, FT_INT24 and FT_INT32
- FT_UINT8, FT_UINT16
Also, FT_IPv4 and FT_IPv6 are frequently in duplicate fields. Should they
be/not-be? Display filter input/verification might have issues with it, but it
seems logical to have generic foo.src/foo.dst/etc. fields of both types.
-hadriel
On Feb 21, 2014, at 2:43 PM, Hadriel Kaplan hadriel.kap
On Feb 21, 2014, at 6:36 PM, Guy Harris g...@alum.mit.edu wrote:
On Feb 21, 2014, at 12:08 PM, Hadriel Kaplan hadriel.kap...@oracle.com
wrote:
Also, FT_IPv4 and FT_IPv6 are frequently in duplicate fields. Should they
be/not-be? Display filter input/verification might have issues
On Feb 21, 2014, at 6:27 PM, Guy Harris g...@alum.mit.edu wrote:
On Feb 21, 2014, at 11:43 AM, Hadriel Kaplan hadriel.kap...@oracle.com
wrote:
A different question though is why FT_UINT64 isn't in the same group as the
other FT_UINT* ones.
Because Wireshark was developed in an era
Howdy,
Has anyone gotten Wireshark to build with Qt 5.2.1 on MacOSX Mavericks? If so,
what magic pixie dust did you use to make it find the QDialog and QFrame header
files, when Qt 5.2 does not apparently install them? (yes, I've google'd to no
avail)
Using the macosx-setup.sh script I've
On Feb 25, 2014, at 4:57 PM, Joerg Mayer jma...@loplof.de wrote:
I just did that, and received the following message during push:
jmayer@egg:~/work/wireshark/git/ui/qt(master) git push
I believe you're supposed to do 'git review branchname', which does the 'git
push' for you and probably
On Feb 25, 2014, at 7:06 PM, Joerg Mayer jma...@loplof.de wrote:
jmayer@egg:~/work/wireshark/git(master) git branch newsupdate
jmayer@egg:~/work/wireshark/git(master) git checkout newsupdate
Switched to branch 'newsupdate'
% git checkout -b newsupdate
would have created the branch and
On Feb 25, 2014, at 8:14 PM, Evan Huus eapa...@gmail.com wrote:
We also have the developer guide ([1] and friends). Ideally this
information would only live in one place, though there doesn't seem to
be a consensus as to where that is (wiki, README, developer guide).
[1]
On Feb 25, 2014, at 8:44 PM, Evan Huus eapa...@gmail.com wrote:
I'm all for consolidating the above information - we just need to
decide which of the many places to consolidate *to*. We've been
playing musical chairs every few months moving things around from A to
B, B to C, and C to A, but
On Feb 26, 2014, at 3:22 AM, Joerg Mayer jma...@loplof.de wrote:
a) Develpment documentation must be available for offline work.
Folding the development READMEs into the developer guide now
that the stuff has moved over to asciidoc would reduce the
number of places to two - and the
On Feb 26, 2014, at 3:51 AM, Joerg Mayer jma...@loplof.de wrote:
On Tue, Feb 25, 2014 at 08:39:37PM -0500, Hadriel Kaplan wrote:
- avoiding merging local branches because a merge commit won't have the
change-id and can't/shouldn't be sent up to gerrit
?
I believe that if you have two
On Feb 26, 2014, at 2:31 PM, Bálint Réczey bal...@balintreczey.hu wrote:
From my experience (giving trainings on git/gerrit and observing other
trainers and trainees) the most efficient way of learning Git + Gerrit based
collaboration is reading Pro Git [1] then the Gerrit intro [2] . This is
Look at:
https://code.wireshark.org/review/#/c/420/
It's saying it does NOT have the verified flag, even though there's a comment
saying you set it. And it has a whole bunch of patches showing, even though I
did not submit all of those. Weird. It may be fubar.
-hadriel
On Feb 27, 2014,
Gerrit-PatchSet: $patchSet.patchSetId
Gerrit-Project: wireshark
Gerrit-Branch: master
Gerrit-Owner: Hadriel Kaplan hadri...@yahoo.com
Gerrit-Reviewer: Evan Huus eapa...@gmail.com
On Feb 27, 2014, at 12:58 PM, Evan Huus eapa...@gmail.com wrote:
I marked the verified flag and it still didn't work. I
://gerrit-review.googlesource.com/#/c/53080/2
Hopefully it will be part of 2.8.2.
On 2/27/14 10:06 AM, Hadriel Kaplan wrote:
Look at:
https://code.wireshark.org/review/#/c/420/
It's saying it does NOT have the verified flag, even though there's a
comment saying you set it. And it has
changes 375 and 420? I'm not sure
I can fix the problem on the server end.
A fix for the problem has been merged in Gerrit:
https://gerrit-review.googlesource.com/#/c/53080/2
Hopefully it will be part of 2.8.2.
On 2/27/14 10:06 AM, Hadriel Kaplan wrote:
Look at:
https
Scratch that - looks like you did it already.
Well that was exciting. :)
-hadriel
On Feb 27, 2014, at 3:35 PM, Hadriel Kaplan hadriel.kap...@oracle.com wrote:
Actually shouldn't it be Evan who abandons them? I assumed the cherry-pick
mode of gerrit meant he was cherry-picking my branch
Howdy,
I've been looking into bug 9835, which involves SIP+SDP setting up RTP
conversations/flows. I've found 3 bugs so far in the relevant code areas, but
the last one I'm stuck on looks like it's by design. It looks like the UDP
dissector creates a addr:port-specific conversation for new
... move along...
-hadriel
On Mar 4, 2014, at 10:06 PM, Hadriel Kaplan hadriel.kap...@oracle.com wrote:
Howdy,
I've been looking into bug 9835, which involves SIP+SDP setting up RTP
conversations/flows. I've found 3 bugs so far in the relevant code areas,
but the last one I'm stuck on looks
Actually it's more like the 'short_name' field in that file_type_subtybe
struct, but not exactly - the open_info ones are captialized whereas the
file_type_subtybe 'short_name' ones are lower-case.
But in my opinion they should be not only the same exact name strings, but
inside just one
BTW, is changing the wtap_register_open_info() function prototype/ABI again
soon going to cause you problems?
I ask because it changes again, with an additional argument, in here:
https://code.wireshark.org/review/#/c/431/
The additional argument is for whether the wiretap reader being
A bit off-topic, but since I'm asking because Wireshark uses it and I want to
grok it for Wireshark...
Can anyone recommend a good book on Qt GUI programming? A search on Amazon and
stackoverflow and other usual sites came up with lots of hits, but mostly for
outdated books. And the docs on
Sorry about that - I uploaded that commit before I made it a habit to turn on
extra compiler warnings on my Mac OSX. :(
It's surprising, though, since the files which caused you and others issues are
from a very-widely-used Lua library that's been around for years. You'd think
they'd have
On Mar 11, 2014, at 1:18 PM, Christopher Maynard
christopher.mayn...@gtech.com wrote:
If possible, add some information/basic steps on a few more topics as well?
For example:
1) How do you undo a commit, or undo part of a commit?
You can reset the head, but I really think going there
On Mar 11, 2014, at 1:59 PM, Evan Huus eapa...@gmail.com wrote:
http://wiki.wireshark.org/Development/SubmittingPatches
as a very bare-bones tutorial. Hopefully others will expand it as
necessary.
I've tried to answer a few of these with a new revision of the page.
I see you have the
On Mar 11, 2014, at 3:01 PM, Guy Harris g...@alum.mit.edu wrote:
On Mar 11, 2014, at 11:18 AM, Hadriel Kaplan hadriel.kap...@oracle.com
wrote:
I see you have the 'pip install git-review' stuff on that page... fwiw, I've
never gotten git-review to work on my Mac. I got it installed
On Mar 11, 2014, at 5:15 PM, Guy Harris g...@alum.mit.edu wrote:
Perhaps we should have a page on some wireshark.org where a user can enter
some identifier for an automated build and an SHA hash for a commit and find
out whether that build has that commit, and perhaps also say take me to
1 - 100 of 185 matches
Mail list logo
