Re: [Wireshark-dev] Short question for modus operandi

[Roland Knall]

Hi

On Wed, Apr 13, 2011 at 5:40 PM, Chris Maynard  wrote:
> Roland Knall  writes:
>
>> I have provided some time ago a patch for submission into wireshark
>> (Bug #5753). Over the course of the next two weeks a new version of
>> this patch would be completed, which would enable the dissector to
>> talk Modbus/TCP as well. But this version would be very preliminary,
>> and not stable for a longer time.
>
> "Not stable" or "not complete"?  I think incomplete dissectors are OK as they
> can always be improved upon later as time permits, but unstable is not
> acceptable.

It is stable. It is in use around the office with various
configurations, and it has been fuzz tested. For the fuzz test I used
various network configurations to create capture files, and than
tested with that. Therefore, I can say with certainty, that it is
stable.

Also, there is nothing missing protocol implementation wise. Although
some though already went into implementing conversations and taps, but
besides that, it is feature complete.


> The latest patch you provided seems to have been reviewed by Guy, Jeff and
> Jakub.  I *think* it's probably close to the point of being accepted, so I'd 
> say
> rather than introducing another patch that "might not be stable for a longer
> time", that you should hold off until after this patch has been accepted.
> Another patch at this point might prolong the time it takes to be accepted, 
> but
> I guess it depends somewhat on the extent of your new changes and if you 
> really
> meant "not complete" rather than "not stable".


Ok, than I'll wait.


kind regards,
Roland
___
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] buildbot failure in Wireshark (development) on Windows-7-x64

[buildbot-no-reply]

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/1551

Buildbot URL: http://buildbot.wireshark.org/trunk/

Buildslave for this Build: windows-7-x64

Build Reason: 
Build Source Stamp: 36636
Blamelist: guy

BUILD FAILED: failed nmake all

sincerely,
 -The Buildbot

___
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] Wireshark 1.5.1 has wrong release date

[Gerald Combs]

Fixed. Thanks!

On 4/13/11 6:03 PM, Christopher Maynard wrote:
> FYI: http://www.wireshark.org/ still indicates the previous January 24, 2011
> release date for Wireshark 1.5.0.
> 
> ___
> 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] Wireshark 1.5.1 has wrong release date

[Christopher Maynard]

FYI: http://www.wireshark.org/ still indicates the previous January 24, 2011
release date for Wireshark 1.5.0.

___
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] how to cross-compile tshark and tools

[George Nychis]

Thanks for the responses, I sincerely appreciate it.

I was able to build lemon for my host machine, and compile the majority of
the project.  My goal is to get libwireshark working on Android as a shared
library.  It seems to build successfully as a static library, so I am going
to try build it as a shared library and test it out on Android.

I changed some of the build variables in the lemon configuration file to get
around this for now.

On Wed, Apr 13, 2011 at 12:46 PM, Guy Harris  wrote:

>
> On Apr 13, 2011, at 9:41 AM, Guy Harris wrote:
>
> > Of course, none of that addresses any configuration tests we might do
> that involve compiling *and* running code; if we do any of that,
> cross-compilation is even harder to make work.
>
> And we do, in fact, do tests such as that.  For example, we run code to
> test whether the GLib module mechanism, which we use as a
> platform-independent mechanism for loading modules (plugins) at run time, is
> available.  If it's always present in GLib 2.x - i.e., if GLib won't compile
> on a platform that has no module-loading mechanism the GLib module mechanism
> can use - or if there's a better way to test whether the host-system
> supports run-time module loading, we could fix that.
>
> We also test whether dladdr() can be used to find a file name for the
> executable.  That one might be harder to do for cross compilation.
>
> There's also a check for a pre-BIND82 inet_pton() bug - perhaps that's so
> old and crufty that we don't need to care about it any more.
>
> ___
> 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] packet reassembly

[Martin Kaiser]

Dear all,

I'm trying to implement reassembly of DVB-CI link layer packages.
Finally, I got to a point where the code is working but I'm not sure if
I understand it well enough. Therefore, I'd like your comments before I
submit a patch.

The DVB-CI link layer (lpdu) is fairly simple:

   1 byte "transport connection id"
   1 byte more/last indicator
   

There's no such thing as a sequence number, the lpdus should arrive in
order (DVB-CI devices aren't able to re-order).

Please see the code below for a rough outline.
I tried to avoid saving any state in static variables.

Is it ok to call fragment_add_seq_next() and process_reassembled_data()
even if the packet is not fragmented? In my tests, I seem to receive the
complete payload_tvb for a non-fragmented packet.

Is it ok to use a constant sequence number for all packets? It seems ok
if the packets arrive in order (to avoid it, I would probably need
static variables and increment the sequence number at the beginning of
each fragmented transport packet - which can't be detected reliably).

Is it necessary to set pinfo->fragmented and save/restore its original
value? Where is the temporary setting used?

Thanks in advance for your feedback.


   Martin



static void
dissect_dvbci_lpdu(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree,
guint8 direction)
{
/* ... */
tvbuff_t *payload_tvb = NULL;
fragment_data *frag_msg = NULL;
gboolean save_fragmented;


/* ... create link_tree ... */

/* ... get all data and do some checks ... */

save_fragmented = pinfo->fragmented;
frag_msg = fragment_add_seq_next(tvb, 2, pinfo,
4, /* sequence id, TODO: can this be a constant value if
  packets must arrive in order? */
msg_fragment_table,
msg_reassembled_table,
tvb_reported_length_remaining(tvb, 2),
more_last == ML_MORE ? 1 : 0);

payload_tvb = process_reassembled_data(tvb, 2, pinfo,
"Reassembled Message", frag_msg, &msg_frag_items,
NULL, link_tree);
if (payload_tvb) {
pinfo->fragmented = TRUE;
}
else {
pinfo->fragmented = FALSE;
if (more_last == ML_MORE)
col_append_fstr(pinfo->cinfo, COL_INFO, " (Message fragment)");
else {
payload_tvb = tvb_new_subset(tvb, 2, -1, -1);
   }
}
if (payload_tvb)
dissect_dvbci_tpdu(payload_tvb, pinfo, tree, direction, tcid);
pinfo->fragmented = save_fragmented;


___
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] buildbot failure in Wireshark (development) on Clang-Code-Analysis

[buildbot-no-reply]

The Buildbot has detected a new failure of Clang-Code-Analysis on Wireshark 
(development).
Full details are available at:
 http://buildbot.wireshark.org/trunk/builders/Clang-Code-Analysis/builds/58

Buildbot URL: http://buildbot.wireshark.org/trunk/

Buildslave for this Build: clang-code-analysis

Build Reason: The Nightly scheduler named 'daily' triggered this build
Build Source Stamp: HEAD
Blamelist: 

BUILD FAILED: failed failed slave lost

sincerely,
 -The Buildbot

___
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] HTTP reassemble and clear text displaying question

[Cui Heng]

Dear all

  I have a question in the wireshark source code:

  If I have HTTP trace of libpcap format, I found wireshark can
perfectly reassemble the HTTP response data and parse its content(e.g. HTML)
in clear text. Can some one suggest me which src file(s) or part of
functions achieve this parsing?

PS, I've got wireshark with version 1.2.4, I think there should not be quite
different in the versions.

thank you very much
Best Regards
Cui
___
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] how to cross-compile tshark and tools

[Guy Harris]

On Apr 13, 2011, at 9:41 AM, Guy Harris wrote:

> Of course, none of that addresses any configuration tests we might do that 
> involve compiling *and* running code; if we do any of that, cross-compilation 
> is even harder to make work.

And we do, in fact, do tests such as that.  For example, we run code to test 
whether the GLib module mechanism, which we use as a platform-independent 
mechanism for loading modules (plugins) at run time, is available.  If it's 
always present in GLib 2.x - i.e., if GLib won't compile on a platform that has 
no module-loading mechanism the GLib module mechanism can use - or if there's a 
better way to test whether the host-system supports run-time module loading, we 
could fix that.

We also test whether dladdr() can be used to find a file name for the 
executable.  That one might be harder to do for cross compilation.

There's also a check for a pre-BIND82 inet_pton() bug - perhaps that's so old 
and crufty that we don't need to care about it any more.

___
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] how to cross-compile tshark and tools

[Guy Harris]

On Apr 13, 2011, at 9:27 AM, George Nychis wrote:

>> On Wed, Apr 13, 2011 at 12:05 PM, Jeff Morriss  
>> wrote:
>> George Nychis wrote:
>> BTW, it appears that this has come up before in the past (2009):
>> https://$1.wireshark.org/lists/wireshark-users/200910/msg00123.html 
>> 
>> 
>> 
>> but it doesn't seem like a resolution was made.. but this post has a 
>> short-term workaround:
>> http://seclists.org/wireshark/2009/Oct/286
>> 
>> I am going to try this out, the original poster never got back with whether 
>> this worked or not.
>> 
>> What version are you trying to cross-compile?  I believe that the changes 
>> discussed in that thread were eventually checked in with rev 30586.
> 
> Hi Jeff,
> 
> I am on Revision: 36615
> 
> So it seems like I am past that revision.

What's in the configure.in file in the trunk is:

dnl Check for CPU / vendor / OS
dnl The user is encouraged to use either `AC_CANONICAL_BUILD', or
dnl `AC_CANONICAL_HOST', or `AC_CANONICAL_TARGET', depending on the
dnl needs.  Using `AC_CANONICAL_TARGET' is enough to run the two other
dnl macros.
dnl
dnl As nothing in the Wireshark is itself a build tool (we are not,
dnl for example, a compiler that generates machine code), we probably
dnl don't need AC_CANONICAL_TARGET, so, in theory, we should be able
dnl to use AC_CANONICAL_BUILD and AC_CANONICAL_HOST - or perhaps just
dnl AC_CANONICAL_HOST - instead.  Note that we do have tools, such as
dnl lemon, that need to be built for the build machine, not for the
dnl host machine, so we might need both.
dnl
dnl This has to be done *after* AC_INIT, otherwise autogen.sh fails.

dnl AC_CANONICAL_BUILD
dnl AC_CANONICAL_HOST
AC_CANONICAL_TARGET

So the question then is what *else* has to be done to arrange that lemon, and 
other tools such as rdps, be built for the machine on which the build is being 
done (the build-system, to use the term used in the Autoconf manual), and that 
*Shark itself be built for the machine we're cross-compiling for (the 
host-system) - we don't build anything for the target-system, as we don't have 
a target-system as we're not a build tool.  Presumably there would have to be 
multiple CC variables, so that you use one to build stuff that needs to run on 
the build-system and use another one to build stuff that needs to run on the 
host-system.

Of course, none of that addresses any configuration tests we might do that 
involve compiling *and* running code; if we do any of that, cross-compilation 
is even harder to make work.
___
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] how to cross-compile tshark and tools

[George Nychis]

Hi Jeff,

I am on Revision: 36615

So it seems like I am past that revision.

On Wed, Apr 13, 2011 at 12:05 PM, Jeff Morriss wrote:

> George Nychis wrote:
>
>> BTW, it appears that this has come up before in the past (2009):
>> https://$1.wireshark.org/lists/wireshark-users/200910/msg00123.html <
>> http://1.wireshark.org/lists/wireshark-users/200910/msg00123.html>
>>
>>
>> but it doesn't seem like a resolution was made.. but this post has a
>> short-term workaround:
>> http://seclists.org/wireshark/2009/Oct/286
>>
>> I am going to try this out, the original poster never got back with
>> whether this worked or not.
>>
>
> What version are you trying to cross-compile?  I believe that the changes
> discussed in that thread were eventually checked in with rev 30586.
> ___
> 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] [Wireshark-commits] rev 36622: /trunk/tools/ /trunk/tools/: fuzz-test.sh test-fuzzed-cap.sh

[Stephen Fisher]

On Wed, Apr 13, 2011 at 03:36:13PM +, morr...@wireshark.org wrote:
> http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=36622

>  Export MALLOC_OPTIONS=AJ to increase memory allocation debug on 
>  FreeBSD (and others).

>  (I don't have easy access to either of these OS so this has not been 
>  tested.)

It appears to be working on FreeBSD.  If I add an invalid flag (such as 
'Y') to the MALLOC_OPTIONS on FreeBSD, it gives me an error:

expr: (malloc) Unsupported character in malloc options: 'Y'

Otherwise the fuzz test runs fine.

___
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] buildbot failure in Wireshark (development) on Visual-Studio-Code-Analysis

[buildbot-no-reply]

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/435

Buildbot URL: http://buildbot.wireshark.org/trunk/

Buildslave for this Build: vs-code-analysis

Build Reason: 
Build Source Stamp: 36622
Blamelist: morriss

BUILD FAILED: failed nmake all

sincerely,
 -The Buildbot

___
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] how to cross-compile tshark and tools

[Jeff Morriss]

George Nychis wrote:

BTW, it appears that this has come up before in the past (2009):
https://$1.wireshark.org/lists/wireshark-users/200910/msg00123.html 



but it doesn't seem like a resolution was made.. but this post has a 
short-term workaround:

http://seclists.org/wireshark/2009/Oct/286

I am going to try this out, the original poster never got back with 
whether this worked or not.


What version are you trying to cross-compile?  I believe that the 
changes discussed in that thread were eventually checked in with rev 30586.

___
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] [Wireshark-commits] rev 36614: /trunk/ /trunk/epan/dissectors/: packet-snmp.c /trunk/asn1/snmp/: packet-snmp-template.c

[Stephen Fisher]

On Wed, Apr 13, 2011 at 07:57:35AM +0200, Stig Bjørlykke wrote:
> On Wed, Apr 13, 2011 at 12:12 AM,   wrote:
> > Log:
> >  Fix Coverity 1047: UNUSED_VALUE in dissect_smux
> 
> I don't think this is the correct fix, because now the 
> proto_item_add_subtree() has no function. I think maybe smux_tree 
> should be used in dissect_SMUX_PDUs_PDU().

Thanks for pointing that out.  I've reversed my commit and changed the 
dissect_SMUX_PDUs_PDU() call to use smux_tree instead in r36624.

___
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] Short question for modus operandi

[Chris Maynard]

Roland Knall  writes:

> I have provided some time ago a patch for submission into wireshark
> (Bug #5753). Over the course of the next two weeks a new version of
> this patch would be completed, which would enable the dissector to
> talk Modbus/TCP as well. But this version would be very preliminary,
> and not stable for a longer time.

"Not stable" or "not complete"?  I think incomplete dissectors are OK as they
can always be improved upon later as time permits, but unstable is not 
acceptable. 

> 
> Should I remove the current patch and resubmit it with the changes, or
> should I wait until this version of the patch gets submitted (which is
> pretty stable right now), and then submit the changes?

The latest patch you provided seems to have been reviewed by Guy, Jeff and
Jakub.  I *think* it's probably close to the point of being accepted, so I'd say
rather than introducing another patch that "might not be stable for a longer
time", that you should hold off until after this patch has been accepted. 
Another patch at this point might prolong the time it takes to be accepted, but
I guess it depends somewhat on the extent of your new changes and if you really
meant "not complete" rather than "not stable".


___
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] how to cross-compile tshark and tools

[George Nychis]

BTW, it appears that this has come up before in the past (2009):
https://$1.wireshark.org/lists/wireshark-users/200910/msg00123.html

but it doesn't seem like a resolution was made.. but this post has a
short-term workaround:
http://seclists.org/wireshark/2009/Oct/286

I am going to try this out, the original poster never got back with whether
this worked or not.

On Wed, Apr 13, 2011 at 10:32 AM, George Nychis  wrote:

> Hi all,
>
> I am trying to cross-compile tshark for an arm system, but I am hitting an
> issue I am not sure how to overcome.
>
> I have added my gcc cross-compiler to my path, and configured my system as:
> ./configure -host=arm-eabi --disable-wireshark --with-pcap=no
>
> I succeed in building several of the components, but whenever it comes down
> to building the "epan" related components I hit the error that:
> make[3]: Entering directory
> `/home/gnychis/Documents/wireshark/epan/dfilter'
> ../../tools/lemon/lemon t=./../../tools/lemon/lempar.c ./grammar.lemon || \
> (rm -f grammar.c grammar.h ; false)
> /bin/bash: ../../tools/lemon/lemon: cannot execute binary file
>
> Well, this is expected since lemon was built using my cross-compiler.
>
> But, I am not sure what to do at this point.  I cannot use lemon since it
> is not built for the host, but I could build lemon specifically for the
> host... but would that create issues for when the target is on arm?
>
> I'd greatly appreciate any feedback.
>
> Thanks!
> George
>
___
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] buildbot failure in Wireshark (development) on Windows-7-x64

[buildbot-no-reply]

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/1542

Buildbot URL: http://buildbot.wireshark.org/trunk/

Buildslave for this Build: windows-7-x64

Build Reason: 
Build Source Stamp: 36620
Blamelist: etxrab

BUILD FAILED: failed nmake setup

sincerely,
 -The Buildbot

___
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] how to cross-compile tshark and tools

[George Nychis]

Hi all,

I am trying to cross-compile tshark for an arm system, but I am hitting an
issue I am not sure how to overcome.

I have added my gcc cross-compiler to my path, and configured my system as:
./configure -host=arm-eabi --disable-wireshark --with-pcap=no

I succeed in building several of the components, but whenever it comes down
to building the "epan" related components I hit the error that:
make[3]: Entering directory `/home/gnychis/Documents/wireshark/epan/dfilter'
../../tools/lemon/lemon t=./../../tools/lemon/lempar.c ./grammar.lemon || \
(rm -f grammar.c grammar.h ; false)
/bin/bash: ../../tools/lemon/lemon: cannot execute binary file

Well, this is expected since lemon was built using my cross-compiler.

But, I am not sure what to do at this point.  I cannot use lemon since it is
not built for the host, but I could build lemon specifically for the host...
but would that create issues for when the target is on arm?

I'd greatly appreciate any feedback.

Thanks!
George
___
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] Short question for modus operandi

[Roland Knall]

Hello

I have provided some time ago a patch for submission into wireshark
(Bug #5753). Over the course of the next two weeks a new version of
this patch would be completed, which would enable the dissector to
talk Modbus/TCP as well. But this version would be very preliminary,
and not stable for a longer time.

Should I remove the current patch and resubmit it with the changes, or
should I wait until this version of the patch gets submitted (which is
pretty stable right now), and then submit the changes?

kind regards,
Roland
___
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