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

[elof2 at sentor.se]

Hi David and Carter!

Any updates to this very promising thread?

/Elof


On Tue, 16 Jul 2013, Carter Bullard wrote:

> Hey Dave,
> Talk about confusion.....  I think trying to change " port " to " service " would be a bad idea.
> Since we don't print Layer 2 SAPs now, should be better to figure out a decent name for those.
>
> I didn't mean that we would/could drop " proto ".  I was saying we could drop "proto" from "l2proto" and "l3proto".
>
> If we invent an new printer, then it should print out the complete output string needed for text2pcap, so there is a fair amount of work to do.
>
>   ra -M printer=text2pcap
>
> should be all you need.  So you'll have to provide a lot of examples for me to implement the printer.
>
> Carter
>
> Sent from my iPad
>
> On Jul 16, 2013, at 6:27 AM, "David Edelman" <dedelman at iname.com> wrote:
>
>> 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
>>
>>
>