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

[Carter Bullard]

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