Re: [Wireshark-dev] Rough consensus and quiet humming

[Francesco Fondelli]

Meetecho team introduced the "virtual hum tool"... there should be a draft
somewhere describing it. Hmm.

On Thu, Apr 22, 2021 at 10:39 AM Graham Bloice 
wrote:

> In a covid pandemic, working from home world, no one can hear you hum.
>
> On Thu, 22 Apr 2021 at 08:43, Guy Harris  wrote:
>
>>
>> https://twitter.com/MeghanEMorris/status/1382109954224521216/photo/1
>>
>
> --
> Graham Bloice
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] How does tshark "synchronize" multiple interfaces?

[Francesco Fondelli]

Hi, try with/without the '-t' option (Use a separate thread per interface).
If I recall correctly - in my case - the dumpcap behavior with -t looked
similar to the one of your sniffer.

If that is the point, you can play with PACKET_FANOUT/PACKET_FANOUT_HASH in
your sniffer.

http://man7.org/linux/man-pages/man7/packet.7.html

https://stackoverflow.com/questions/41660747/linux-understanding-setsockopt-
packet-fanout-for-network-scaling

hope this helps
ciao
fra


On Tue, Feb 6, 2018 at 8:54 PM, S. Jacobi  wrote:

> On Tue, 6 Feb 2018 10:31:38 -0800
> Guy Harris  wrote:
>
> > On Feb 6, 2018, at 9:20 AM, Richard Sharpe
> >  wrote:
> >
> > > On Tue, Feb 6, 2018 at 9:07 AM, S. Jacobi
> > >  wrote:
> > >> On Tue, 6 Feb 2018 09:05:14 -0800
> > >> Richard Sharpe  wrote:
> > >>
> > >>> As far as I am aware it is the kernel that is doing this. Also, I
> > >>> believe that only Linux supports the any device.
> > >>
> > >> We are on Linux, yes, but we don't capture from any. tshark allows
> > >> to specify multiple interfaces.
> > >
> > > I have not looked at the code, but I suspect that it is something
> > > like this:
> > >
> > > https://stackoverflow.com/questions/37294540/binding-
> the-af-packet-socket-to-all-interfaces
> > >
> > > That is, the kernel is doing it.
> >
> > That's how the "any" device is implemented by libpcap, so that's what
> > happens if you capture on the "any" device.
> >
> > However, if, in Wireshark or TShark or dumpcap, you capture from an
> > explicitly specified list of interfaces containing more than one
> > interface, there are multiple pcap_t's open, and packets are
> > separately received from all of those pcap_t's and those are written
> > to a single capture file.
> >
> > So if they aren't in timestamp order when you explicitly capture on
> > more than one interface, that's dumpcap's fault (which means it's the
> > fault of "Wireshark", in the sense of the entire Wireshark release,
> > as dumpcap is the program that does the packet capturing for
> > Wireshark and TShark), not the fault of the OS kernel.
>
> The packets out-of-timestamp-order are quite rare and always between
> two interfaces. It could be that dumpcap tries to put them in the
> correct order but fails to do so when one interface lags behind. Thanks
> for your answers anyway.
> 
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=
> unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Overview of MPLS PW bugs

[Francesco Fondelli]

Hi Guy,

https://code.wireshark.org/review/#/c/19599/

change 19599 is an attempt to improve the situation. It is a work in progress.

- The code that takes into consideration padding can be done better
for IPv4 (line 497).
- I suspect the IPv6 case (line 510) is wrong because the ip6len is
not the total len.

I tested this change against traces found in bug 13301 and "it works",
I also tested this with plain IPv4 encapsulated in MPLS and "it
works".

Any help is appreciated.
thanks
ciao
fra

On Sun, Jan 8, 2017 at 8:24 PM, Guy Harris  wrote:
[cut]
> and the captures in that bug may be real rather than synthesized (some 
> obscure companies named "Cisco" and "Huawei" has OUIs that have 4 as the 
> first nibble and some obscure companies named "Hewlett-Packard" and "Juniper" 
> has OUIs that have 6 as the first nibble).

believe me I am very aware of that :-)
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Overview of MPLS PW bugs

[Francesco Fondelli]

Hi Guy,

point 3 and probably point 4, are too risky. If we go against the best
current practice (RFC 4928, BCP 128) we need a very-very strong
indication that the following data is not IP. I agree on everything
else.

thanks
ciao
fra

On Sun, Jan 8, 2017 at 2:31 AM, Guy Harris  wrote:
> On Jan 7, 2017, at 9:39 AM, Jaap Keuter  wrote:
>
>> There has been a steady stream of MPLS PW related comments and bugs over 
>> time,
>> and things haven't improved enough, apparently. This text tries to give some
>> insight in the issues so that possible solutions cover all cases involved.
>
> I'll start here with a broader discussion of how a protocol specifies the 
> protocol running above it, and how the dissector for the first protocol 
> selects the dissector for the next protocol.
>
> Some protocols have a "next protocol" field or fields (Ethernet, IEEE 802.2, 
> SNAP, IPv4, IPv6, anything with an IANA media type string, ...).  For those, 
> it's easy - use a dissector table, and it will handle 99.9% 
> of the cases correctly.  "Decode As" would be necessary only in cases where 
> two protocols are using the same value, either because the old protocol's 
> assignment was revoked and a new protocol given the assignment (which doesn't 
> sound like good practice, unless you have a *really* small set of possible 
> values) or because somebody's not playing by the rules.  Heuristics should 
> only be necessary in cases where the field is optional, such as IANA media 
> type strings.
>
> Some protocols have a field or fields that indicate a source or destination 
> port, or a circuit number, which might be usable *hint* for identifying the 
> next protocol, but which is not sufficient to indicate it (TCP and UDP are 
> the canonical examples of this; ATM's VPI/VCI are another example).  For 
> those, you use a dissector table with dissectors that do checks and reject 
> packets, heuristics, mechanisms for other dissectors to make port-to-protocol 
> assignments if that can be done(e.g., SDP and RTCP setting up RTP sessions), 
> and, when all else fails - which could be fairly common - Decode As.
>
> For the latter category of protocols, the fewer "well known" field values 
> there are, the more you depend on heuristics to avoid Decode As.  MPLS is a 
> protocol with *very* few "well known" label values.
>
> MPLS is a very good example of the last category of protocols; RFC 3032 gives 
> only 16 reserved label values.  That's the problem here; at least with TCP 
> ports, for example, a lot of the well-known ports help.
>
> The protocols we support atop MPLS are:
>
> I-TDM (Internal TDM)
> Y.1711 (has a reserved label)
> ATM pseudo-wires of various sorts (RFC 4717)
> CESoPSN pseudo-wire (RFC 5086)
> Ethernet pseudo-wire (RFC 4448)
> Frame Relay pseudo-wire (RFC 4619)
> PPP/HDLC pseudo-wires (RFC 4618)
> SAToP (RFC 4553)
> IPv4
> IPv6
> Pseudo-wire Associated Channel Header dissection (RFC 4385)
>
> For most of these, we require Decode As.
>
> The exceptions are:
>
> IPv4, IPv6, Associated Channel Header, Ethernet
>
> for which, for frames with no explicit binding to a label, we use the 
> first-nibble heuristic, possibly combined with other heuristics.
>
> In addition, the Ethernet pseudo-wire dissector also uses heuristics to 
> determine whether there's a control word or not.  It *looks* as if the ATM 
> pseudo-wire dissector always assumes a control work, even though RFC 4717 says
>
>The features that the control word provides may not be needed for a
>given ATM PW.  For example, ECMP may not be present or active on a
>given MPLS network, strict frame sequencing may not be required, etc.
>If this is the case, and the control word is not REQUIRED by the
>encapsulation mode for other functions (such as length or the
>transport of ATM protocol specific information), the control word
>provides little value and is therefore OPTIONAL.  Early ATM PW
>implementations have been deployed that do not include a control word
>or the ability to process one if present.  To aid in backwards
>compatibility, future implementations MUST be able to send and
>receive frames without a control word present.
>
> If the control word were *always* present, we wouldn't be having these 
> problems, and people wouldn't be filing bugs.  Thus, the bugs demonstrate 
> that, at least for Ethernet, the control word isn't always present.
>
> Bug 11849 was due to an "is this Ethernet?" heuristic being too strong, by 
> accepting only a small number of Ethertypes; it was fixed by weakening the 
> heuristic not to look at the type/length field at all.
>
> Bug 13039 is due to the "is this Ethernet?" heuristic being too strong, by 
> not accepting frames with local MAC addresses.
>
> Bug 13295 is due to the "is this Ethernet?" heuristic being too weak, by 
> 

Re: [Wireshark-dev] Overview of MPLS PW bugs

[Francesco Fondelli]

Hi Guy,

On Sat, Jan 7, 2017 at 10:38 PM, Guy Harris <g...@alum.mit.edu> wrote:
> On Jan 7, 2017, at 1:15 PM, Francesco Fondelli <francesco.fonde...@gmail.com> 
> wrote:
>
>> the pw_eth_heuristic is too strong, it does not take into
>> consideration locally-assigned MAC addresses and multicast (as noted
>> in some bugs by Guy Harris and Michael Mann). Patches are welcome :-)
>
> The heuristic used in the pw_eth_heuristic dissector is both too strong *and* 
> too weak:
>
> it's too strong because it only recognizes globally-assigned MAC 
> addresses;
>
> it's too weak because it only checks the MAC address - it doesn't 
> check whether, if the type/length field is a type field, the type is one we 
> know or, if it's a length field, whether the headers following the MAC header 
> are something we'll dissect.
>
> Bugs for *both* of those problems have been filed.

I agree. The pw_eth_heuristic should be improved.

>> That said, I think the current situation is a good trade-off.
>
> The *current heuristics* are clearly *not* a good trade-off, given the bugs 
> that have been filed.  They need to be improved, in both directions.

With current situation I meant the logic we have in packet-mpls.c.

>> The not edulcorated version reads "Ethernet PW without control word is
>> a pain in the ass, do not use it".
>
> That may be the case, but apparently people *do* use it, and if we can make 
> life less painful for them without making life more painful for the people 
> "doing the right thing", we should do so.

I agree. However, we should try hard not to break the good boys that
are just using plain IPv{4,6}.

>> an other improvement could be to add logic to signalling dissectors
>> (e.g. LDP, BGP) in order to add explicit label-to-dissector bindings.
>> This would be useful only in case signalling and data plane are
>> captured together. Therefore, I guess this is not common and it isn't
>> worth it.
>
> We *already* do that for some other control and data plane protocols; for 
> example, RTSP and SDP dissectors can set up UDP traffic to be dissected as 
> RTP (there are other examples as well), so I don't consider that a 
> sufficiently good reason not to do it.

Still think is a corner case, but I put it in the todo list.

thanks
ciao
fra
___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Overview of MPLS PW bugs

[Francesco Fondelli]

Hi Jaap,

the pw_eth_heuristic is too strong, it does not take into
consideration locally-assigned MAC addresses and multicast (as noted
in some bugs by Guy Harris and Michael Mann). Patches are welcome :-)

That said, I think the current situation is a good trade-off.

Ethernet PWs *without* CW use to be common back in ~2000. At that time
someone thought "Hey, IEEE will never allocate Ethernet MAC addresses
starting with 4 o 6... we already have transit routers that perform
load balance if 1st nibble is 4 or 6 if you want strict packet
ordering just put 0 or 1, that's it, you have a pseudo-wire" :-)

I do not have numbers but I think today the majority of Ethernet PW
out there are making use of the CW and Wireshark default behavior
should be based on this. RFC 7325 is an enlightening and comprehensive
documentation about MPLS forwarding. In Section 2.4.1 it says:

2.4.1.  Pseudowire Control Word

   Within the core of a network, some form of multipath is almost
   certain to be used.  Multipath techniques deployed today are likely
   to be looking beneath the label stack for an opportunity to hash on
   IP addresses.

   A pseudowire encapsulated at a network edge must have a means to
   prevent reordering within the core if the pseudowire will be crossing
   a network core, or any part of a network topology where multipath is
   used (see [RFC4385] and [RFC4928]).

   Not supporting the ability to encapsulate a pseudowire with a Control
   Word may lock a product out from consideration.  A pseudowire
   capability without Control Word support might be sufficient for
   applications that are strictly both intra-metro and low bandwidth.
   However, a provider with other applications will very likely not
   tolerate having equipment that can only support a subset of their
   pseudowire needs.

The not edulcorated version reads "Ethernet PW without control word is
a pain in the ass, do not use it".

Hope this helps
ciao
fra

PS
an other improvement could be to add logic to signalling dissectors
(e.g. LDP, BGP) in order to add explicit label-to-dissector bindings.
This would be useful only in case signalling and data plane are
captured together. Therefore, I guess this is not common and it isn't
worth it.

On Sat, Jan 7, 2017 at 6:39 PM, Jaap Keuter  wrote:
>
> Introduction
>
> There has been a steady stream of MPLS PW related comments and bugs over time,
> and things haven't improved enough, apparently. This text tries to give some
> insight in the issues so that possible solutions cover all cases involved.
>
> Background
>
> Multi Protocol Label Switching (MPLS) is highly optimized for speed. That is
> speed of processing of network frames, getting frames forwarded as efficiently
> as possible while handling pushing and popping labels at the predefined 
> network
> boundaries. Pseudo Wire (PW) tries to make the network connection so that it 
> can
> be seen as a literal replacement for a wire, or a circuit switched connection.
> To do so optionally a control word if prefixed before transport across the 
> MPLS
> network.
>
> These two combined allow a highly efficient and high bandwidth mesh of 
> point-to-
> point connections. So much so that the protocols carry little, if any,
> information related to the type of data transported. This is especially true 
> for
> the MPLS label stack and the PW control word. Only a label number is assigned,
> it is up to the endpoints between which frames are exchanged using this
> (bottom-of-stack) label to decide (out of band) what format this data is in.
> Also the presence of a control word is mutually agreed upon out of band. 
> Usually
> these are statically configured in the MPLS edge routers.
>
> This fact complicates matter for a man-in-the-middle observer, like Wireshark.
> Without the knowledge of the out-of-band agreed communication settings it 
> takes
> guesswork to decide what these are and thus how to interpret these frames.
>
> Wireshark does try by means of heuristic analysis of the frame contents to
> determine the makeup of each MPLS frame, and sets up the dissection of the 
> inner
> parts. Since there is so little to go on, heuristic analysis is error prone.
> Often the user has to be involved, using other knowledge, to set the correct
> dissection parameters.
>
> MPLS RFC's
>
> if you read the various RFCs on MPLS it becomes clear that other have 
> struggled
> with these matters also. See for instance RFC 4928, 4385 and 4448, and all 
> RFCs
> referenced from them.
>
> Bug history
>
> Combing through Bugzilla and the source code repository a collection of MPLS
> related bugs and changes can be found. Here we try to list them in a
> chronological order.
>
> Remove MPLS preference that doubled for Decode As.
> https://code.wireshark.org/review/#/c/7899/
>
> Bug 11271: Dissecting engine stops after MPLS shims
> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11271
>
> https://code.wireshark.org/review/#/c/8912/
> MPLS: 

Re: [Wireshark-dev] Ethernet header below MPLS...

[Francesco Fondelli]

If the Ethernet PW is without the CW (Control Word) - as it seems from
your ASCII art - the "magic" might be happened in
dissect_pw_eth_heuristic() around line 134 of packet-pw-eth.c.

To get the big picture (line 462 of packet-mpls.c + line 134 of
packet-pw-eth.c):

- is there any user specific label binding for this label (via decode
as)? yes use it, else
- use the 1st nibble logic (see BCP 4928, RFC 4385 and 5586): 4 =>
IPv4, 6 => IPv6, 1 => PW Associated Channel (i.e. OAM stuff like
S-BFD, BFD, LM, CC, CV...)
- if the first nibble is 0 well... wiiild gue... we try with a bit
of "magic" (at line 134 of packet-pw-eth.c)
 - if the first 6+6 bytes look like (by checking manufacture OUI
database) a pair of Ethernet addresses we go with Ethernet PW
*without* CW (it seems your case)
 - else hmmm wait... the first nibble was 0 so it might have been
the case of Ethernet PW with a 'Generic PW MPLS Control Word' as per
RFC 4385 (uncommon)

Isn't Wireshark great? :-)

ciao
fra

On Fri, Sep 16, 2016 at 1:13 AM, barcaroller  wrote:
> I have a pcap file where, in each packet, the header hierarchy is as
> follows:
>
> ETH
>   IP
> GRE
>   MPLS
> ETH  <--- ?
>   VLAN
> IP
>   TCP/UDP
>
>
> I would not expect to see an Ethernet header right below an MPLS header.
> And yet wireshark was able to properly identify/parse the headers, even
> though there's no indication in the MPLS header that the following header is
> Ethernet.  How did wireshark do that?
>
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] MPLS dissection fail

[Francesco Fondelli]

I think we should revert to the original behavior as suggested in the
bug report.  WS being able to automatically dissect the majority of
MPLS encapsulated traffic with the first nibble set to 0 is a feature
we should preserve.

thank you
ciao
fra

On Sat, Jun 13, 2015 at 1:28 AM, Jasper Bongertz jas...@packet-foo.com wrote:
 Hi all,

 I just added a bug report, as agreed with Alexis, regarding the
 dissection failure in 1.99 when a frame contains MPLS shims. This is
 the bug report URL:

 https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11271

 and I also attached a screen shot comparing 1.12.5 and 1.99 to this
 email (I hope it doesn't get stripped off by the list)

 Cheers,
 Jasper
 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 Archives:https://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 wireshark-dev@wireshark.org
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Bugzilla and Gerrit

[Francesco Fondelli]

Hi,

am I supposed to open a Bugzilla ticket or just submit a change for
review into the Gerrit system? Or both? (for a dissector enhancement)

Sorry if the question is not new or dumb, I am following the
git-gerrit workflow for the first time.

thank you
ciao
fra
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] Bugzilla and Gerrit

[Francesco Fondelli]

I got it. Thank you both.

ciao
fra

On Wed, Apr 2, 2014 at 3:17 PM,  mman...@netscape.net wrote:
 You don't need to open a Bugzilla ticket strictly for an enhancement.
 However you may want to open a Bugzilla ticket to supply a capture that
 exercises a dissector enhancement (for fuzzbot and regression testing) if
 one hasn't already been provided.  You can then reference the Gerrit link in
 the bug itself.

 -Original Message-
 From: Francesco Fondelli francesco.fonde...@gmail.com
 To: Developer support list for Wireshark wireshark-dev@wireshark.org
 Sent: Wed, Apr 2, 2014 9:13 am
 Subject: [Wireshark-dev] Bugzilla and Gerrit

 Hi,

 am I supposed to open a Bugzilla ticket or just submit a change for
 review into the Gerrit system? Or both? (for a dissector enhancement)

 Sorry if the question is not new or dumb, I am following the
 git-gerrit workflow for the first time.

 thank you
 ciao
 fra
 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
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] Linked bug reports

[Francesco Fondelli]

Hi Krishnamurthy, Guy, all,

please take into consideration the possibility to add 6610 on top of 6521.

In 6521 GAL is introduced in packet-mpls.h

Index: epan/dissectors/packet-mpls.h
===
--- epan/dissectors/packet-mpls.h   (revision 39670)
+++ epan/dissectors/packet-mpls.h   (working copy)
@@ -30,12 +30,16 @@
 #ifndef PACKET_MPLS_H
 #define PACKET_MPLS_H

-/* Special labels in MPLS */
+/*
+ * Special labels in MPLS
+ * (FF: www.iana.org/assignments/mpls-label-values/mpls-label-values.txt)
+ */
 enum {
 LABEL_IP4_EXPLICIT_NULL = 0,
 LABEL_ROUTER_ALERT,
 LABEL_IP6_EXPLICIT_NULL,
 LABEL_IMPLICIT_NULL,
+LABEL_GAL = 13,
 LABEL_OAM_ALERT = 14,
 LABEL_MAX_RESERVED = 15,
 LABEL_INVALID = 0x


Krishnamurthy... you should made few changes like:

if (label == 0x0D) {
}

if (label == LABEL_GAL) {
}

I believe it will be cleaner.

hope this helps
thanks
ciao
FF

On Tue, Nov 22, 2011 at 7:45 PM, Guy Harris g...@alum.mit.edu wrote:

 On Nov 22, 2011, at 10:44 AM, Krishnamurthy Mayya wrote:

 Thanks a lot Harris.Now i have submitted a single bug ( Bug 6610 in 
 bugzilla) with all the required attachments and marked the previous bugs as 
 duplicate which are no longer need to be referred. This would be fine right??

 Yes.
 ___
 Sent via:    Wireshark-dev mailing list wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
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 -- atm n:1 dissector

[Francesco Fondelli]

On Tue, Apr 7, 2009 at 4:17 PM, Tamazov, Artem
artem.tama...@tellabs.com wrote:

 Hello Francesco,

Hi Artem,

first of all thanks for making my PW dissection framework better
than the original :-)

 Recently I've implemented ATM N:1 dissection and get into merge conflict
 after SVN merge.
 It looks that we have the same plans regarding Wireshark ;)
 I mean:
     DONE:
     - ATM N-to-One Cell Mode (with CW)
     - ATM N-to-One Cell Mode (no CW)
     TODO:
     - ATM One-to-One Cell Mode
     - ATM AAL5 SDU Mode
     - ATM AAL5 PDU Mode

:-)

 Well, let's decide how to handle this.

 It first glance, my implementation hase more features related to validation
 of packets.

yes

 Also it supports some old equipment (it has a couple of options for this).

I didn't know someone was using CW length/reserved bits with a value != 0, if
they use the length to determine if a packet is valid or not they will have
some interoperability problems, it is nice that WS is able to highlight it.

 Your implementation more extensively uses existing ATM dissector, which is
 important.

filter for ATM and ATM fields is a MUST, IMHO, given the fact that there are
ATM cells within that PW.  I had to call the ATM dissector and put part
of the work there.  This looked to me the more appropriate way to accomplish
the task.  Any idea from WS people?

 For now I am going to look at your ATM PW dissector with more attention.
 Also I would like you to look at my code.
 Then we can decide how to resolve this situation.


ok no problem

 If you agree, I will send my patches to you (I will prepare them so you will
 not experience merge conflicts).

thanks

 What is your opinion?

a) re-spin your patch using mine as a base and get good things from
both approaches
b) revert mine (a part of it, i.e. packet-pw-eth.c is fine as it is
now, don't revert
   packet-atm.c stuff about NNI dissection option because this is fine
'per se') and apply
   your patch.

Any core WS developer opinion?

 Regards,
 Artem Tamazov//

thanks
Ciao
FF
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] [PATCH]: enhanced what's past last mpls label? heuristic

[Francesco Fondelli]

On Wed, Jul 9, 2008 at 12:22 AM, Jaap Keuter [EMAIL PROTECTED] wrote:
 Hi,

Hi,

 If you submitted this in the bug database there is no need to post it here as
 well. That's all.

I see.  I thought was still useful for someone to have a reference in
wireshark-dev
ml as well.  Next time I'll use only the bugzilla system.

 Thanx,
 Jaap

thanks

Ciao
FF
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] [PATCH]: enhanced what's past last mpls label? heuristic

[Francesco Fondelli]

On Mon, Jul 7, 2008 at 7:49 PM, Jaap Keuter [EMAIL PROTECTED] wrote:
 Hi,

 Please read http://www.wireshark.org/docs/wsdg_html/#ChSrcSend about
 submitting patches for Wireshark. Just to make sure it doesn't get lost.

 Thanx,
 Jaap

Hi Jaap,

did I forget something in bug report #2689 ?

Ciao
FF
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev

[Wireshark-dev] [PATCH]: enhanced what's past last mpls label? heuristic

[Francesco Fondelli]

Hi all,

Attached is a patch for:

- PW Associated Channel Header dissection as per RFC 4385
- PW MPLS Control Word dissection as per RFC 4385
- mpls subdissector table indexed by label value
- enhanced what's past last mpls label? heuristic
- Ethernet PW (w/o CW) support as per RFC 4448

The new logic to dissect data after last mpls label is:

if (!dissector_try_label(mpls_subdissector_table, label, ...)) {
   if (nibble == 6) {
   call_dissector(ipv6_handle, ...);
   } else if (nibble == 4) {
   call_dissector(ipv4_handle, ...);
   } else if (nibble == 1) {
   dissect_pw_ach(next_tvb, ...);
   } else if (nibble == 0) {
  if (looks_like_plain_eth(next_tvb)) {
 call_dissector(eth_withoutfcs_handle, next_tvb, ...);
  } else {
 dissect_pw_mcw(next_tvb, ...);
  }
   } else {
  call_dissector(eth_withoutfcs_handle, ...);
   }
}

The mpls protocol dissector has now a subdissector table indexed by label.
If the user specifies a binding (through Decode as...) label N -- proto X
wireshark will pass data past last mpls label to dissector X. If there is
no label2proto binding the legacy first nibble based algorithm (corrected and
enhanced) is used.

the original code was:

 if (ipvers == 6) {
   call_dissector(ipv6_handle, next_tvb, pinfo, tree);
 } else if (ipvers == 4) {
   call_dissector(ipv4_handle, next_tvb, pinfo, tree);
 } else if (ipvers == 1) {
   dissect_mpls_control(next_tvb, pinfo, tree);
 } else {
   call_dissector(eth_withoutfcs_handle, next_tvb, pinfo, tree);
 }

dissect_mpls_control() is now called dissect_pw_ach() (ach stands for
Associated Channel Header) as per RFC 4385 terminology.
dissect_pw_mcw() (mcw stands for MPLS Generic/Preferred Control Word)
is called only if the first nibble is 0 (as per RFC 4385) and if the
first 12 bytes of data look like two mac addresses.

Ethernet PWs are common nowadays with and without CW (control word:
4 bytes between last mpls label and the encapsulated ethernet header)
in service provider networks.  I have been told few times that
wireshark doesn't work because of the CW presence.  This patch
automagically provides a valid dissection in most common eth
PWs with/without CW cases.

Moreover, this patch allows wireshark users to manually provide info
in case the heuristic fails.

If you accept this changes new dissectors, one for each type of PW
encapsulated traffic, can be easily implemented (packet-pw-eth.c is
provided as a starting point).

- Structure-Agnostic Time Division Multiplexing (TDM) over Packet
  (SAToP) (RFC 4553)

- Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service
  over Packet Switched Network
  (CESoPSN) (RFC 5086)

are at the top of my to-do list.

I have used and fuzz-tested this code.  Please check it in.

Ciao
FF

ps
patch is against svn #25387 but unfortunately is a diff -ru dir1 dir2
because I cannot svn diff anymore due to bad bad proxy settings,
sorry, it should work fine anyway.

pps
bug report is #2689


new_mpls_heuristic.patch
Description: Binary data
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] dissection of packets with unknown format (LDP/MPLS/PWE)

[Francesco Fondelli]

On Mon, Apr 28, 2008 at 3:13 AM, Alexandre Abreu [EMAIL PROTECTED] wrote:
 Hi.

  Has anyone ever found a case where the successful dissection of one
  protocol depends on what was negotiated in another protocol? I've been

to be honest it should work anyway (PW + ethernet):

while (there are labels) {
   dissect_labels();
   dissect_special_labels();
   if (bos)
  break;
}

next_tvb = tvb_new_subset(tvb, offset, -1, -1);

ipvers = (tvb_get_guint8(tvb, offset)  4)  0x0F;
if (ipvers == 6) {
  call_dissector(ipv6_handle, next_tvb, pinfo, tree);
} else if (ipvers == 4) {
  call_dissector(ipv4_handle, next_tvb, pinfo, tree);
} else if (ipvers == 1) {
  dissect_mpls_control(next_tvb, pinfo, tree);
} else {
  call_dissector(eth_withoutfcs_handle, next_tvb, pinfo, tree);
}

if you got control word after PW label and you transport ethernet (nibble )
dissect_mpls_control() should call call_dissector(eth_withoutfcs_handle...).
If you don't have control word you take the else path. If this is not
the case there is a bug.

could you please send a pcap file? I can work on it.

A Decode this PW as...[eth/TDM/etc] option was on my wish-list... because you
cannot relay on catching LDP signalling (it might be absent or on a different
physical wire/fiber).

  Tks in advance

you are welcome

  AA

Ciao
FF
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] [patch] export as C arrays

[Francesco Fondelli]

On Tue, Mar 11, 2008 at 8:02 PM, Guy Harris [EMAIL PROTECTED] wrote:
 Francesco Fondelli wrote:

   Attached is a patch to export packets data as C Arrays.  I often
   have the need to [re]send data captured with wireshark using a
   raw/pf_packet socket.  Output format is one char[] per packet,

  char, or unsigned char?  The latter prevents the sign-extension that
  would occur on most platforms (probably all the platforms on which
  Wireshark is run).

possible signess of the char type might be a problem for someone... well if
they don't know it. I think to use unsigned char[] would be wiser.

Ciao
FF
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] Packets are filtered and dissected but ethertype unknown?

[Francesco Fondelli]

On 10/7/07, keith mercer [EMAIL PROTECTED] wrote:
 I have recently completed a plugin for CFM (802.1ag) and
 the only bug left I am trying to fix before I submit my
 code is that for some odd
[cut]

Hi all,

auch! I have a 802.1ag dissector as well. I did not submit it
because is not finished (I'm parsing only fixed length ccm pdus,
but the framework should be ok)... sorry we worked at the
same thing at the same time I should have said something a
week ago on this ml. BTW you find in attach my dissector
feel free to take bits and pieces at your will. I hope
your will be checked in soon... I need it :-)

thank you
Ciao
FF


packet-ieee8021ag.c
Description: Binary data
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] [PATCH 1/1][DCCP Dissector]: Feature-Negotiation options, updates, and decoding CCID3 options

[Francesco Fondelli]

On 9/25/07, Gerrit Renker [EMAIL PROTECTED] wrote:
 This is an update for the DCCP dissector and has previously been
[cut]

Hi Gerrit/all,

I was not aware of bugzilla-based new submission
procedure, sorry.

I have created bug report #1865 and I have set the
review_for_checkin flag... hope I did it right, please
let me know whether it is fine or not.

BTW, please check this patch in.

thank you
Ciao
FF
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] How to represent range values using range_string

[Francesco Fondelli]

On 1/26/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:


 Hi  ,

Hi,

 I had mailed to the  forum regarding how to use range_string,
 but not received any reply yet  .

As far as I know Sebastien Tandel's patch is not yet checked in:
http://www.wireshark.org/lists/wireshark-dev/200701/msg00321.html

so you can't use proto_tree_add_item and RVALS stuff with range_string

 Could anyone please  provide any suggestion to this regard .

have a look at packet-ansi_map.c or packet-ospf.c and
doc/README.developer about range_string usage.

Ciao
FF
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

[Wireshark-dev] [PATCH] DCCP: timestamp/timestamp echo

[Francesco Fondelli]

Hi all,

Gerrit Renker fixed a bug in DCCP dissector about long timestamps.
(bad offsets)

He wrote:

attached is a patch which updates the offsets of the timestamps.
I have verified this against [RFC 4342, sec. 13]
and it seems correct.


I have verified it as well, it's correct.

You find attached a svn diff (rev 20554), please apply.

Ciao
FF
Index: packet-dcp.c
===
--- packet-dcp.c	(revision 20554)
+++ packet-dcp.c	(working copy)
@@ -44,6 +44,10 @@
  * (unlike UDP/packet-udp, from which the code stems,
  * zero checksums are illegal in DCCP (as in TCP))
  * (Gerrit Renker)
+ *
+ * Gen 29, 2007: updates the offsets of the timestamps to be
+ * compliant to (cf. RFC 4342, sec. 13).
+ * (Gerrit Renker)
  */
 
 #ifdef HAVE_CONFIG_H
@@ -499,14 +503,14 @@
 proto_tree_add_uint(dcp_options_tree, hf_dcp_timestamp_echo, tvb, offset + 2, 4,
 		tvb_get_ntohl(tvb, offset + 2));
 
-proto_tree_add_uint(dcp_options_tree, hf_dcp_elapsed_time, tvb, offset + 4, 2, 
-		tvb_get_ntohs(tvb, offset + 4));
+proto_tree_add_uint(dcp_options_tree, hf_dcp_elapsed_time, tvb, offset + 6, 2,
+		tvb_get_ntohs(tvb, offset + 6));
 			} else if (option_len==10) {
 proto_tree_add_uint(dcp_options_tree, hf_dcp_timestamp_echo, tvb, offset + 2, 4,
 		tvb_get_ntohl(tvb, offset + 2));
 
-proto_tree_add_uint(dcp_options_tree, hf_dcp_elapsed_time, tvb, offset + 4, 4, 
-		tvb_get_ntohl(tvb, offset + 4));
+proto_tree_add_uint(dcp_options_tree, hf_dcp_elapsed_time, tvb, offset + 6, 4, 
+		tvb_get_ntohl(tvb, offset + 6));
 			} else
 proto_tree_add_text(dcp_options_tree, tvb, offset, option_len, Wrong Timestamp Echo length);
 			break;
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

[Wireshark-dev] [PATCH] range_string and OSPF bcmodelid

[Francesco Fondelli]

I'm repost my last mail, please have a look at it.

thanks
Ciao
FF



Hi all,

I needed to dissect a simple hf item in ospf, a integer one.
The possible values were in ranges like:

0 3 foo
1 4 bar
5 5 shark
6   100 reserved
101 200 private use

in such a case I normally use switch or if statements
and several proto_tree_add_uint_format() or
proto_tree_add_text() to properly handle the reserved and
private use cases. If I'm not wrong there is no
way to dissect such a hf in one shot using a
single proto_tree_add_xxx() call.

So I defined a range_string struct. It's like value_string
but stores range - string pairs.
Moreover I wrote rval_to_str(), match_strrval_idx()
match_strrval() which are behaving exactly as
val_to_str(), match_strval_idx() and match_strval().
(almost cut  paste :-))

now we can do something like:

static const range_string rvals[] = {
  {   0,   3, foo},
  {   1,   4, bar},
  {   5,   5, shark },
  {   6, 100, reserved},
  { 101, 200, private},
  { 0, 0, NULL}
};

proto_tree_add_uint_format(tree,
 hf_augh,
 tvb,
 offset,
 1,
 value,
 bla bla: %u (%s),
 value,
 rval_to_str(value, rvals, Unknown));

This way people can write less lines of code (yes I'm lazy ;-)))
and IMHO it's more readable.

if you like this solution please apply
range_string_and_ospf_bcmodel_id.patch,
if you don't please apply ospf_bcmodel_id.patch. You
find both in attachment, they are diffed against
svn rev. 19892.


Thanks
Ciao
FF
Index: AUTHORS
===
--- AUTHORS	(revision 19892)
+++ AUTHORS	(working copy)
@@ -2277,6 +2277,7 @@
 	MPLS OAM support, Y.1711
 	RSVP/OSPF Extensions for Support of Diffserv-aware MPLS-TE, RFC 4124
 	Linux Packet Generator support
+	rval_to_str() and alike
 }
 
 Bill Meier		wmeier [AT] newsguy.com {
Index: epan/value_string.c
===
--- epan/value_string.c	(revision 19892)
+++ epan/value_string.c	(working copy)
@@ -109,3 +109,50 @@
   g_snprintf(p, 1024-(p-buf), fmt, val_to_str((val  mask)  shift, tab, Unknown));
   return buf;
 }
+
+
+/* FF: ranges aware versions */
+
+/* Tries to match val against each range in the range_string array rs.
+   Returns the associated string ptr on a match.
+   Formats val with fmt, and returns the resulting string, on failure. */
+const gchar *rval_to_str(guint32 val, const range_string *rs, const char *fmt) 
+{
+  const gchar *ret = NULL;
+
+  g_assert(fmt != NULL);
+
+  ret = match_strrval(val, rs);
+  if(ret != NULL)
+return ret;
+
+  return ep_strdup_printf(fmt, val);
+}
+
+/* Tries to match val against each range in the range_string array rs.
+   Returns the associated string ptr, and sets *idx to the index in
+   that table, on a match, and returns NULL, and sets *idx to -1,
+   on failure. */
+const gchar *match_strrval_idx(guint32 val, const range_string *rs, gint *idx)
+{
+  gint i = 0;
+
+  while(rs[i].strptr) {
+if( (val = rs[i].value_min)  (val = rs[i].value_max) ) {
+  *idx = i;
+  return (rs[i].strptr);
+}
+i++;
+  }
+
+  *idx = -1;
+  return (NULL);
+}
+
+/* Like match_strrval_idx(), but doesn't return the index. */
+const gchar *match_strrval(guint32 val, const range_string *rs)
+{
+gint ignore_me = 0;
+return match_strrval_idx(val, rs, ignore_me);
+}
+
Index: epan/value_string.h
===
--- epan/value_string.h	(revision 19892)
+++ epan/value_string.h	(working copy)
@@ -34,6 +34,13 @@
   const gchar   *strptr;
 } value_string;
 
+/* Struct for the rval_to_str, match_strrval_idx, and match_strrval functions */
+typedef struct _range_string {
+  guint32value_min;
+  guint32value_max;
+  const gchar   *strptr;
+} range_string;
+
 /* #define VS_DEF(x) { x, #x } */
 /* #define VS_END{ 0, NULL } */
 
@@ -61,4 +68,21 @@
 extern const char *decode_enumerated_bitfield_shifted(guint32 val, guint32 mask,
   int width, const value_string *tab, const char *fmt);
 
+
+/* ranges aware versions */
+
+/* Tries to match val against each range in the range_string array rs.
+   Returns the associated string ptr on a match.
+   Formats val with fmt, and returns the resulting string, on failure. */
+extern const gchar* rval_to_str(guint32 val, const range_string *rs, const char *fmt);
+
+/* Tries to match val against each range in the range_string array rs.
+   Returns the associated string ptr, and sets *idx to the index in
+   that table, on a match, and returns NULL, and sets *idx to -1,
+   on failure. */
+extern const gchar *match_strrval_idx(guint32 val, const range_string *rs, gint *idx);
+
+/* Like match_strrval_idx(), but doesn't 

[Wireshark-dev] [PATCH] DCCP: variable-length checksums

[Francesco Fondelli]

Hi,

please find attached a patch file against svn rev. 19883. This is Gerrit Renker
code which:

  * makes checksum computation dependent
upon the header CsCov field (cf. RFC 4340, 5.1)
  * removes the case where checksums are zero
(unlike UDP/packet-udp, from which the code stems,
 zero checksums are illegal in DCCP (as in TCP))
  * fixes a minor typo - missing bitshift of the
CCVal field

Moreover the wiki page has been updated, please have a look at:
http://wiki.wireshark.org/DCCP and new traces added.

I have used and fuzz-tested this code.
Please check it in.

thanks,
Ciao
FF
Index: epan/dissectors/packet-dcp.c
===
--- epan/dissectors/packet-dcp.c	(revision 19883)
+++ epan/dissectors/packet-dcp.c	(working copy)
@@ -30,10 +30,21 @@
  */
 
 
-/* Note: PROTOABBREV name collision problem, 'dccp' is used by Distributed Checksum 
-   Clearinghouse Protocol.
-   This dissector should be named packet-dccp.c IMHO.
-*/
+/* NOTES: 
+ *
+ * PROTOABBREV name collision problem, 'dccp' is used by 
+ * Distributed Checksum Clearinghouse Protocol.
+ * This dissector should be named packet-dccp.c IMHO.
+ *
+ * Nov 13, 2006: makes checksum computation dependent
+ * upon the header CsCov field (cf. RFC 4340, 5.1) 
+ * (Gerrit Renker)
+ *
+ * Nov 13, 2006: removes the case where checksums are zero
+ * (unlike UDP/packet-udp, from which the code stems,
+ * zero checksums are illegal in DCCP (as in TCP))
+ * (Gerrit Renker)
+ */
 
 #ifdef HAVE_CONFIG_H
 # include config.h
@@ -541,6 +552,16 @@
 
 	} /* end while() */
 }
+/* compute DCCP checksum coverage according to RFC 4340, section 9 */
+static inline guint dccp_csum_coverage(const e_dcphdr *dcph, guint len)
+{
+	guint cov;
+	
+	if (dcph-cscov == 0)
+		return len;
+	cov = (dcph-data_offset + dcph-cscov - 1) * sizeof(guint32);
+	return (cov  len)? len : cov;
+}
 
 static void dissect_dcp(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
 {
@@ -595,7 +616,8 @@
 	/* DBG(dcph-data_offset: %d\n, dcph-data_offset); */
 	dcph-cscov=tvb_get_guint8(tvb, offset+5)0x0F;
 	/* DBG(dcph-cscov: %d\n, dcph-cscov); */
-	dcph-ccval=tvb_get_guint8(tvb, offset+5)0xF0;
+	dcph-ccval=tvb_get_guint8(tvb, offset+5) 0xF0;
+	dcph-ccval = 4;
 	/* DBG(dcph-ccval: %d\n, dcph-ccval); */
 	dcph-checksum=tvb_get_ntohs(tvb, offset+6);
 	/* DBG(dcph-checksum: %d\n, dcph-checksum); */
@@ -662,15 +684,11 @@
 		proto_tree_add_uint(dcp_tree, hf_dcp_ccval, tvb, offset + 5, 1, dcph-ccval);
 		proto_tree_add_uint(dcp_tree, hf_dcp_cscov, tvb, offset + 5, 1, dcph-cscov);
 
-		/* checksum analisys taken from packet-udp */
+		/* checksum analysis taken from packet-udp (difference: mandatory checksums in DCCP) */
 
 		reported_len = tvb_reported_length(tvb);
 		len = tvb_length(tvb);
-		if (dcph-checksum == 0) {
-			/* No checksum supplied in the packet */
-			proto_tree_add_uint_format_value(dcp_tree, hf_dcp_checksum, tvb,
-			 offset + 6, 2, dcph-checksum, 0x%04x (none), dcph-checksum);
-		} else if (!pinfo-fragmented  len = reported_len) {
+		if (!pinfo-fragmented  len = reported_len) {
 
 			/* The packet isn't part of a fragmented datagram and isn't
 			   truncated, so we can checksum it.
@@ -703,7 +721,7 @@
 	break;
 }
 cksum_vec[3].ptr = tvb_get_ptr(tvb, offset, len);
-cksum_vec[3].len = reported_len;
+cksum_vec[3].len = dccp_csum_coverage(dcph, reported_len);
 computed_cksum = in_cksum(cksum_vec[0], 4);
 if (computed_cksum == 0) {
 	proto_tree_add_uint_format_value(dcp_tree, hf_dcp_checksum, tvb,
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] [Wireshark-commits] rev 19254: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-dcp.c packet-dcp.h packet-icep.c

[Francesco Fondelli]

On 9/18/06, Ulf Lamping [EMAIL PROTECTED] wrote:

 BTW: Why is this dissector named dcp and uses dcp as it's filter string?!?

 The specs uses Datagram Congestion Control Protocol and DCCP everywhere, so 
 this is quite confusing to use dcp for the filter.

 Regards, ULFL


Unfortunately protoabbrev dccp was already in use by packet-dccp.c
dissector :-(
(Distributed Checksum Clearinghouse Protocol)
... and dcp was the former name of datagram [congestion] control
protocol a couple of
years ago.

Ciao
FF
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] [patch] new dissector for linux packet kernel generator

[Francesco Fondelli]

On 9/18/06, Jaap Keuter [EMAIL PROTECTED] wrote:
 Hi,

 Checked in with some changes.
 - replace Licepnse with License (how did that happen! ;)

Oh joy, shame on me! packet-dcp.c packet-dcp.h packet-icep.c are affected too
It was a monkey typing replace-regexp on emacs ;-)) please fix it

 Thanx,
 Jaap

Thanks
Ciao
FF
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

[Wireshark-dev] [patch] new dissector for linux packet kernel generator

[Francesco Fondelli]

Hi all,

You find attached a patch file (against svn 19058) to dissect packets
produced by the Linux kernel packet generator. You also find attached
a pcap trace with pktgen data over IPv6 with double 802.1Q tags.

I have used and fuzz-tested this code.
Please check it in.

thanks,
Ciao
FF


pktgen.patch
Description: Binary data


pktgen_IPv6_QinQ.pcap
Description: Binary data
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev