Anders Broman wrote:
Hi,
The buildbot is failing. I'm not sure which of the recent changes that
caused this.
Indeed. I think it was r21330, by Sebastien:
http://anonsvn.wireshark.org/viewvc/viewvc.py?view=revrevision=21330
Specifically, this bit:
hi wireshark developers,
attached a small bugfix that uses the correct bits
for determining if the ATM payload is a OAM cell.
asking for inclusion.
tx,
/hannes
Index: packet-juniper.c
===
--- packet-juniper.c(revision 21334)
Something in the transmission path for mails to wireshark-dev (I assume
it's the wireshark.org Mailman, but who knows) seems to be wrapping
Subject: lines incorrectly. Essentially it replaces a space in the
subject with a CRLF followed by a tab.
According to RFC822 (3.1.1) Unfolding is
Guy Harris wrote:
On Apr 3, 2007, at 4:53 PM, Bob Doolittle wrote:
Thanks. My subdissector is now being called, and is updating the List
window
properly. But for some odd reason the sub-protocol isn't appearing
in the
Details window tree, and I'm handling it identically to how I
Richard van der Hoff wrote:
Anders Broman wrote:
Hi,
The buildbot is failing. I'm not sure which of the recent changes that
caused this.
Indeed. I think it was r21330, by Sebastien:
http://anonsvn.wireshark.org/viewvc/viewvc.py?view=revrevision=21330
Specifically, this bit:
Hello,
since I signed up this list just recently, I take the opportunity to
introduce myself. My full name is Dr. Simon Ginsburg and I'm Product
Manager for communication protocols/products for the company Saia-
Burgess Controls Ltd in Switzerland. This is the company, where my
college
Hi,
Dissector specific
Item 19. What's the reason, the APDU part of BACnet/IP is not
dissected? Is it just the workload (for which a solution can be
found) or there a technical reason such as variable length, the BACnet
specific solution of segmenting or other?
Dissectors get done/extended
Guy Harris wrote:
What's the code in the subdissector that adds the top-level entry for
the protocol?
Sorry - I just realized you asked for the subdissector code, and I sent
the dissector code for the top-level protocol. At least you can check that
I'm calling dissector_try_port properly...
On 4/4/07, Bob Doolittle [EMAIL PROTECTED] wrote:
Guy Harris wrote:
So the tree argument to the subdissector is non-null?
Yes it is. Under what circumstances is it NULL, by the way? I'm
mimic'ing the
appropriate tests/structure but don't understand why yet...
I don't know when it's
Charles Lepple wrote:
I don't know when it's NULL while the GUI is up, but I gather the
intent was for cases like when tshark is displaying only the one-line
summary, and not the full tree.
The intent is for all cases where a protocol tree isn't needed.
This includes:
1) tshark,
Guy Harris wrote:
Bob Doolittle wrote:
alp_dgram_tree = proto_item_add_subtree(ti, ett_alp_dgram);
ett_alp_dgram - and ett_alp_commonr - aren't -1, right?
Right. They were both initialized in the proto_register_* routines
by calling proto_register_subtree_array(). I'm
On Wed, Apr 04, 2007 at 11:53:14AM +0100, Richard van der Hoff wrote:
Richard van der Hoff wrote: Something in the transmission path for mails to
wireshark-dev (I assume it's the wireshark.org Mailman, but who knows)
seems to be wrapping Subject: lines incorrectly. Essentially it replaces a
On Wed, Apr 04, 2007 at 11:53:14AM +0100, Richard van der Hoff wrote:
Richard van der Hoff wrote: Something in the transmission path for mails to
wireshark-dev (I assume it's the wireshark.org Mailman, but who knows)
seems to be wrapping Subject: lines incorrectly. Essentially it replaces a
13 matches
Mail list logo
