Ethereal ax25 monitoring

Ethereal ax25 monitoring

[Chuck Hast]

Is there any ability to use ethereal to monitor ax25 packets, I have poked
around and find nothing to the effect. I see that Ethereal states that it does
monitor 706 protocols but appears that ax25 is not one of them. 

Anyone have any ideas on this?

-- 
Chuck Hast 
To paraphrase my flight instructor;
"the only dumb question is the one you DID NOT ask resulting in my going
out and having to identify your bits and pieces in the midst of torn
and twisted metal."

Re: Ethereal ax25 monitoring

[Richard Stearn]

Chuck Hast wrote:
> Is there any ability to use ethereal to monitor ax25 packets, I have poked
> around and find nothing to the effect. I see that Ethereal states that it does
> monitor 706 protocols but appears that ax25 is not one of them. 
> 
> Anyone have any ideas on this?

Chuck

As of version 0.10.12 (current version) there does not appear to be a
dissector for ax.25 in the source code.

A quick rummage through the mail-list archive did return any items
indicating ax.25 as being currently known about.

There appears to be a reasonably conprehensive guide to how a new
dissector is created and connected in. I am am attempting to compile
0.10.12 to see how easily I could import an ax.25 module from a
protocol analyser I wrote some years ago.

-- 
Regards
	Richard

Re: Ethereal ax25 monitoring

[Richard Stearn]

Richard Stearn wrote:
> There appears to be a reasonably conprehensive guide to how a new
> dissector is created and connected in. I am am attempting to compile
> 0.10.12 to see how easily I could import an ax.25 module from a
> protocol analyser I wrote some years ago.

OK, an update for those interested.

I have managed to add an outline AX.25 dissector to Ethereal. It doesn't do
anything, that wasn't the plot. Importing the ax.25 module from my old
analyser is a non-starter (as I suspected) so it is a reimplement from
scratch.

Before I actually get down to design and coding I will make some enquiries
on the Ethereal dev mailing list to see if anybody on that list is currently
working on an AX.25 dissector and also to see if it would be accepted if offered.

So is there anybody on this list who has done/is doing/has abandoned an AX.25
dissector for Ethereal?

Is there anybody on the list who is up for testing?

My guess is that Netrom & Rose would also be on the followup list, any others?.

-- 
Regards
	Richard
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hardware wrangler, Windows smasher, Network knotter and Unix whisperer.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Re: Ethereal ax25 monitoring

[Ralf Baechle DL5RB]

On Sun, Aug 14, 2005 at 10:54:41PM +0100, Richard Stearn wrote:

> Before I actually get down to design and coding I will make some enquiries
> on the Ethereal dev mailing list to see if anybody on that list is currently
> working on an AX.25 dissector and also to see if it would be accepted if 
> offered.
> 
> So is there anybody on this list who has done/is doing/has abandoned an 
> AX.25
> dissector for Ethereal?

I looked at it and it was looking like it was going to sidetrack me more
than I wanted by that time.

> Is there anybody on the list who is up for testing?

Definately; this is going to be a highly valuable tool.

> My guess is that Netrom & Rose would also be on the followup list, any 
> others?.

Any protocols built on top of these, that would include, IP over AX.25,
ARP over AX.25, VJ compressed IP over AX.25, IP over NET/ROM, IP over ROSE,
routing protocols such as RSPF.

  Ralf

Re: Ethereal ax25 monitoring

[Richard Stearn]

An update on AX.25 in Ethereal.

I have enquired on the Ethereal list and the attitude (sample of 1) is
that "if the protocol exists and is used then it will be accepted".
Subject to a few pratical provisos.

The deeper issue I have found is that Ethereal uses libpcap for the
actual packet capture, and libpcap does not support AX.25 as a packet
type.

There appears to a replacement for libpcap in development within Ethereal
however that is probably a long term project. So my next move is to see
what the issues are with getting the AX.25 packet type added to libpcap.

It looks to me that AX.25 on Ethereal is going to be a long time coming.

-- 
Regards

	Richard

Re: Ethereal ax25 monitoring

[gerard borg]

Hi 

I have been reading with interest these mails in the quest to
get ethereal to detect AX25 packets. 

I do not know the solution to this problem but what Richard is saying
about libpcap sounds similar to some experiences I have had including a
project to get mkiss to run with ethernet bridging where bridging here
refers to the software described at

http://bridge.sourceforge.net/

I found that the bridge utilities would not recognise an ax25 network
device (such as ax0). The trick with the bridging software is to use
ethernet encapsulation. This implied that in order to bridge an mkiss
tty to an ethernet card, one has to get rid of the ax25 encapsulation
altogether and replace it with ethernet encapsulation. 

In my project I did not need the ax25 MAC anyway and the simplest
solution was to get rid of ax25 from mkiss by rewriting the routines
ax_rebuild_header and ax_header according to a description given in the
network device drivers chapter of A Rubini's book "Linux Device
Drivers". 

Concerning libcap, I also remember trying some software from the book on
open source security tools by Mike Schiffman. This software is based on
these open source packet libraries. Again this software could not see
ax25 packets. This is the same problem with ethereal I guess.

Sorry I cannot be more help this. If anyone is interested however, I do
have the version of mkiss.c that looks like an ethernet device to Linux.
Superficially this sounds like "back to slip.c" but there are some
differences, mainly simplifications and a KISS-like robustness over
wireless links. 
 

Gerard Borg





On Wed, 2005-08-31 at 22:46 +0100, Richard Stearn wrote:
> An update on AX.25 in Ethereal.
> 
> I have enquired on the Ethereal list and the attitude (sample of 1) is
> that "if the protocol exists and is used then it will be accepted".
> Subject to a few pratical provisos.
> 
> The deeper issue I have found is that Ethereal uses libpcap for the
> actual packet capture, and libpcap does not support AX.25 as a packet
> type.
> 
> There appears to a replacement for libpcap in development within Ethereal
> however that is probably a long term project. So my next move is to see
> what the issues are with getting the AX.25 packet type added to libpcap.
> 
> It looks to me that AX.25 on Ethereal is going to be a long time coming.
> 

Re: Ethereal ax25 monitoring

[Ralf Baechle DL5RB]

On Wed, Aug 31, 2005 at 10:46:34PM +0100, Richard Stearn wrote:

> An update on AX.25 in Ethereal.
> 
> I have enquired on the Ethereal list and the attitude (sample of 1) is
> that "if the protocol exists and is used then it will be accepted".
> Subject to a few pratical provisos.
> 
> The deeper issue I have found is that Ethereal uses libpcap for the
> actual packet capture, and libpcap does not support AX.25 as a packet
> type.
> 
> There appears to a replacement for libpcap in development within Ethereal
> however that is probably a long term project. So my next move is to see
> what the issues are with getting the AX.25 packet type added to libpcap.
> 
> It looks to me that AX.25 on Ethereal is going to be a long time coming.

Libpcap is also being used for example by tcpdump, so it's certainly very
useful to have it ported anyway.

73 de DL5RB op Ralf

--
Loc. JN47BS / CQ 14 / ITU 28 / DOK A21

Re: Ethereal ax25 monitoring

[Richard Stearn]

An update on AX.25 in Ethereal.

I now have a version of libpcap that recognises the existance of AX.25.
99% of it was already there, I just had to add a few lines in a couple
of files to allow recognition.

 From there I have gone on to start adding a print-ax25 to tcpdump. I now
have something to test.

At this point it all started to go wrong.

Currently all my AX.25 packet comms is done from a dedicated system running
on a (heavily) modified 2.0.36 kernel that I really do not wish to disturb
with software testing. Also I doubt if many others are still running on
2.0.X anyway.

All the development has been done on a Toshiba laptop running a 2.4.31 kernel.
So, for convenience, I have just attempted to get AX.25 running on the laptop
and run into a problem.

It don't transmit, the packets don't even appear to make it down the protocol
stack (the packet stats don't change at any level). Well, to be slightly more
accurate, it did for about 10 minutes until I rebooted the laptop and it has
not transmitted since.

So, the necessary initial detail:

Toshiba 510CDT
Slackware 8.1
kernel 2.4.31
ax25-apps-0.0.6
ax25-tools-0.0.8
libax25-0.0.11
baycom serial half duplex modem (the minimal hardware one)

Yes, the modem works, I put it on another laptop running a 2.0.36 kernel nd
it chatters happily to my main station.

Yes, the tty works as a tty.

There is one unusual "feature", from a cold boot, the baycom_ser_hdx module
has to be loaded, unloaded and reloaded before the bcsh0 interface will
come up. If I don't do that then ifconfig returns the error:
	SIOCSIFFLAGS permission denied.

Yes, the modules are loading. I have even tried recompiling with all the
necessary drivers compiled in, this did not work either. It actually goes
worse as the load, unload, reload trick to fix the SIOCSIFFLAGS error #
could not be done of course.

Yes, I can turn on debugging and work my way through the stack but Chuck
and others would like a protocol analyser before the collapse of the
universe.

My current guess is I am missing a patch or I need to change one of the
ax25 stack defaults.

So, what have I missed?

-- 
Regards
	Richard