A more tshark-like radecode.pl - An update and some questions

[David Edelman]

The L2 and L3 proto fields would be very useful, so is the
printer=text2pcap. Would it be worthwhile naming the l3 fields [s|d]service
to make a clear distinction between the layer 2 and layer 3 SAPs?   I'm not
too sure that dropping proto will work given the number of people who have
scripts that are likely to break.

I'll look at ragraph and use that mechanism for passing parameters to
radecode.pl

Regards,

--Dave

-----Original Message-----
From: Carter Bullard [mailto:carter at qosient.com] 
Sent: Tuesday, July 16, 2013 6:17 AM
To: David Edelman
Cc: Argus
Subject: Re: A more tshark-like radecode.pl - An update and some questions

Hey Dave,
For ARP and RARP, we have the complete packet in the flow record.  The user
data is anything after the ARP header, so you shouldn't get much.  To get
the " interesting " stuff printed, we need to define the fields that make up
the complete header.   We could try something like " arphdr ", but that
isn't very generic.    If we defined a printer like " text2pcap ", then we
could know what to print for each flow class without having to define new
fields and compound types.

Yes, we can add something like l2proto, but we'll need to add l3proto as
well.  " proto " isn't always layer 3, as you know.  Probably can drop the
proto ?

Check out how we pass options in ragraph().  We pick out those that are
intended for rrd-graph, and pass the rest through to rabins().  I would not
try to use the -M strategy for passing options to your script.  That will be
confusing.

Carter

Sent from my iPad

On Jul 15, 2013, at 10:11 PM, "David Edelman" <dedelman at iname.com> wrote:

> Carter,
> 
> I've been doing quite a bit of work on a very different and much more
> capable radecode.pl. I am at the point that I want to include ARP decoding
> and possibly LLDP. My initial experiments indicate that the user data
> (source and destination) for an ARP request / response does not contain
very
> much in the way of the "interesting" stuff . I know that you print the ARP
> packets with special formatting, but is it possible to include the stuff
> that follows the Ethernet header  in the user data that is captured?
> 
> 
> The other thing that would be very nice would be an ra() -s option of
> L2proto so that I could differentiate from "the end of the Internet as we
> know it" (IPv6) and the stuff that keeps the Internet going as well as
> several other things that tend to get lumped into the general  IP bucket.
> I'd be real happy to see it as Hex encoded values like 0x0800 for ARP. 
> 
> One other point that needs clarification; if I pass a -M value to ra()
that
> is not recognized will it be ignored silently? I now have four different
> output types for radecode.pl: tshark (verbose), tshark (terse), tcpdump,
and
> wireshark in full living color. I'd like to pass a value to radecode.pl
and
> not have it confuse ra() if I were to use something like -M
> radecode=verbose|terse|tcpdump|wireshark would that cause problems?
> 
> For the folks who are interested, while text2pcap is very limited in its
> current capabilities. It was coded to use structured comments (a la EPS)
to
> add capabilities like multiple protocols in an input stream, real IP
> addresses, real Ethernet addresses, real TTL values, in fact just about
> anything that you can think of and are willing to code. I have these and
> base TCP sequence numbers working reliably  and I have a version of
> radecode.pl that creates the input file in the necessary format.  
> I have used It  on large quantities of flow records but there is a fly or
> two in the ointment:
> 
> 1 - text2pcap is distributed as part of wireshark so you have the pleasure
> of building wireshark even though the changes are limited to a single file
> (text2pcap.c)
> 2 - I have not had much success with getting hold of the maintainer to
> either provide the code updates for inclusion in the distribution or to
> request a text2pcap only distribution. (I also haven't had much time to
> follow up on this)
> 
> I'd like to add at least ARP to the mix, but that and other protocols are
> simple enough to add as soon as we overcome the logistics of the text2pcap
> distribution. I really would prefer to hold off as long as possible
dealing
> with the IPv6 stuff so volunteers are invited to look at what has to be
done
> to create an IPv6 header and code it. The text2pcap.c code is actually
very
> clean and the changes would be confined to one place in the source module.
> 
> If there is any interest, I'd be happy to provide both the modified
> text2pcap.c source and the updated radecode.pl 
> 
> Fair warning - wireshark requires the normal ./configure; make; make
install
> sequence and you cannot leave out the make install and just copy the
> text2pcap image to the /usr/local/bin directory. You might be able to tell
> configure to only produce text2pcap but I am not wildly optimistic it
would
> work as advertised.
> 
> --Dave
> 
> 
>