Wiresalmon

Has anybody successfully used Wiresalmon on a Raspberry Pi?

When I tried it, it crashed. Last night I rebuilt the module, which involved rewriting the Makefile because I haven’t got round to making recent versions of GCC work for me (my fault). This version didn’t crash, and did capture some genuine stuff, but there were a few tens of k of real data, followed by over 3 MiB of rubbish.

The module appears to consist of a CMHG header and an assembly language body.

The whole thing is GPL so there would appear to be no legal restraint to updating it.

Has anybody successfully used Wiresalmon on a Raspberry Pi?

Only ever used Wiresalmon a couple of times as I have laptops that run Wireshark¹ and switches that do port mirroring (that’s SPAN ports in Cisco speak)

Might have a play on modern kit.

¹ One of my standard tools for work, along with tcp and udp trace utilities and iperf

One step forward, one step back…

Late last night I installed GCC 4.7.4. Since Wiresalmon’s Makefile was clearly intended for use with GCC, I thought I’d have a go with the original Makefile. GCC doesn’t recognise objasm – its assemblers are as and asasm, though I know nothing about their use. I tried assembling the one assembly language source file with the current ROOL objasm, but GCC doesn’t recognise the format of the resulting object file. asasm objects to one of the ADR directives; as doesn’t understand throwback.

Clearly the makefile was for use with an earlier version of GCC.

It doesn’t help that I haven’t kept up with ARM assembly language, so I don’t know what is correct code for modern platforms.

Is anyone able and willing to look at Wiresalmon’s assembly language source code (a single file, 421 lines line including empty lines) and offer advice on what, if anything, needs to be changed in the source, and what needs to be changed about the makefile to invoke the right assembler correctly?

Dave, asasm should be a drop-in replacement for objasm. See https://www.riscosopen.org/forum/forums/1/topics/946 for the announcement.

You cannot link objasm output to current GCC output, because objasm outputs AOF/AIF and GCC since 4.1 outputs ELF.

Well, objasm assembles the file happily; asasm objects to one of the ADR directives.

I’ll have another look tomorrow – it’s bedtime now.

Well, objasm assembles the file happily; asasm objects to one of the ADR directives

That sort rings a bell from a discussion in 2014.
Is this related? ADR vs ADRL

https://www.riscosopen.org/forum/forums/11/topics/2861#posts-36126

The ADR asasm complains about is in this section:

; Copy source address
ADD     a1, v4, #22
ADR     a2, v2
MOV     a3, #6
BL      memcpy

As the source address is copied to v2 at the start of the routine the ADR most likely needs to be a MOV. ObjAsm assembles it to MOV R1,#5 (where it should be MOV R1,R5), but really should have flagged it as an error.

After changing the ADR the module seems assembles fine but haven’t tested whether is working correctly. Couldn’t completely build Wiresalmon as distcc locks the ARMiniX solid.

Thanks, Fred. I agree with your analysis. In hindsight I shouldn’t have panicked.

Here’s the interesting bit. I still haven’t managed to build the front end app, but it hasn’t mattered so far as the front end as distributed appears to work anyway. The module appears to work, at least once anyway, when assembled with Norcroft and my modified Makefile, but with a minimally modified original Makefile and building with GCC 4.7.4 and asasm, the module locks the RPi solid every time.

Once when I ran it, only 24 bytes were put into the capture file, so I wouldn’t yet say that it’s reliable by any means. Still, positive progress compared to a week ago!

I’ve verified that the change corrects the source MAC address of some packets – curiously only those coming from the local machine, others being correct anyway, though I don’t understand why.

I’m working towards a release of the corrected version, which appears to work on the BBxM and Raspberry Pi too.

I got the wiresalmon front end to build and run with alignment exceptions turned on.

Compiling the module with gcc causes a lockup soon after running on an IGEPv5.

The original module seems to work ok with alignment exceptions turned off. Rebuilding it with Norcroft doesn’t make any difference. Lots of aborts with alignments exceptions turned on.

I had a go at building the Qt5 version of Wireshark. This seems to work on RISC OS ok. It loads and displays the pcap files generated by wiresalmon. Saves having to find another machine to run Wireshark on.

I didn’t think it was possible to get QT5 apps to run on RISC OS. I would be delighted to try it out.

Re: Qt5, this thread may be of interest too :)

I’m working towards a release of the corrected version, which appears to work on the BBxM and Raspberry Pi too

Did this ever happen? Asking because I need something to debug network issues on rPI running RO5.28 and the ROD network stack.

The distribution version (at least, I think that’s what I’m running) works on my RPi3B+ with alignment exceptions turned off. I use it fairly often to capture packets. I look at them with Wireshark on a Linux box by sharing the RAMFS drive by Moonfish.

With the knowledge that all of us who’ve looked at the source have, we ought to be able to come up with a version that builds under modern tools.

The distribution version (at least, I think that’s what I’m running) works on my RPi3B+ with alignment exceptions turned off.

I’ve downloaded Alex Waugh’s version, which displays 1.00 18-Nov-2007. That starts up with alignment exceptions off, then crashes when capture starts. The crash is a total lockup – no alt-break no ctrl-break needs power off.

If I run it, use menu, info to show the version, then click away, it crashes without causing a lockup. “Internal error, abort on data transfer at &0005D1B4”

The computer is an rPi3b+, reports Cortex A53 running 5.28 stable, and the ROD network stack. It also crashes with the ROM network stack.

Is there a more up to date version somewhere?

That’s the version I’m using too.

Turn alignment exceptions off; run it.

Click Select on the icon bar, drag the file icon to where you want to save the file to.

Click “Start capture”. The file icon appears in the destination folder; capture has started.

When you’ve collected what you want, click “Stop capture”.

No crash. The full facilities haven’t been used, but the job has been done.

You can close and open the capture window all you like without a crash.

If you create an obey file to ensure the WireSalmon module is loaded,
from that obey file run a bit of BASIC to call the WireSalmon_Start SWI,
delay for 30-60 seconds and then call the WireSalmon_Stop SWI

does that produce a viable capture file without going base-over-apex?

If so, all the problem code is in the front end and it “just” needs a new front end writing. If not, then it’s the module

WireSalmon_Start

Small correction – that should be Wiresalmon_Start & Stop.

However, Wiresalmon_Start just responded ‘Not Found’ on my Titanium. This may be because a file name has not been set? Not sure if or how this can be set. Stop appeared to work.

Note that I tried the module after I had tried the front-end, which had aborted. One of these actions stuffed my network connection (which is using ROD stack), so I had to re-boot. There were lots of ZeroPain errors during this as well (possibly all from Verma). I may try again when I have some more time.

That’s the version I’m using too.
Turn alignment exceptions off; run it.
Click Select on the icon bar, drag the file icon to where you want to save the file to.
Click “Start capture”. The file icon appears in the destination folder; capture has started.
When you’ve collected what you want, click “Stop capture”.
No crash. The full facilities haven’t been used, but the job has been done.
You can close and open the capture window all you like without a crash.

That describes exactly what I did, resulting in a complete lock up.

I was using the ROD network stack at the time.

I’ll try again with the ROM stack. No crash.

Try again with ROD stack. Total lockup.
The error message is “The application may have gone wrong. Click Continue to try to resume, or Quit to stop.” No buttons respond.

I’ve reported this to the ROD developers.

[Edit] If the capture file is dragged to the RAM disc, the lockup doesn’t happen. A file is created and written to.

[Edit 2] New test. Run wiresalmon front end. Do nothing with it.
SYS “Freeway_Register”,0,5 returns “No valid Internet interfaces found”. Quit WireSalmon. This error continues until reboot.

If it is from 2007 and ported, it may have been compiled with older GCC which wasn’t ARMv8 safe. Have you run it through the “PatchSWP” program to fix it? Alternatively, there’s a module on the Annoucements forum which is supposed to implement the older commands on newer CPUs (and vice versa).

However, Wiresalmon_Start just responded ‘Not Found’ on my Titanium. This may be because a file name has not been set?

Obey !Run file

Set test$Dir <Obey$Dir>
RMEnsure Wiresalmon 1.00 RMLoad <test$Dir>.wiresalmon
run <test$Dir>.TimeCapture

Crap BASIC

ON ERROR PRINT REPORT$ + " " + capturefile$ + " at line " + STR$(ERL) : END
capturefile$ ="<test$dir>.cap"
DIM q% &5000 
SYS "Wiresalmon_Start",capturefile$
polls%=1
delay% = 1000
SYS "OS_ReadMonotonicTime" TO time%
time%+=delay%
t$="Wait"
$q%="TASK"
SYS "Wimp_Initialise",310,!q%,t$
REPEAT
  SYS "Wimp_PollIdle",,q%,time%:polls%-=1
UNTIL polls%<0
SYS "Wiresalmon_Stop"
END

Crude, but it served to test the viability of a simple something to call the SWI’s

Good reason to revive an old thread: I’ve built the Wiresalmon module from source with the current DDE.

Good news: it survives the first “tyre kick” test in that it has captured some net traffic. I think it will probably turn out to behave identically to the original module, except that I’ve changed an ADR to a MOV, as suggested somewhere back in this thread.

Bad news: it doesn’t work with the ROD stack on my machine; it immediately kills the stack.

Further news: Alex Waugh has pointed me at an available copy of the RTK library, so I need to do some more handle-cranking before I can declare success or failure at building the front end.

The reason for trying to do this now is that Wiresalmon has proved to be a very valuable tool to me in the past, and it might be very valuable in diagnosing why the ROD stack fails for a few people.

Appeal for help: the module consists only of a CMHG header, a single C file, and a single assembler file, none of which is very big, but it’s doing things in an area that I’m not familiar with, i.e. the Internet stack’s internals. More pairs of eyes, and analytical minds, on the code will probably turn up reasons why it fails for me on the ROD stack.

And while we’re at it, does Wiresalmon work for anybody with the new ROD stack? Those of us having problems seem all to be using RasPi 3B+. Note that, in order for the front end not to crash, alignment exceptions have to be turned off. Once that’s done, if you run Wiresalmon with the new stack, does the network still work for you?

Wiresalmon’s source is at https://github.com/ajw498/pcap

seem all to be using RasPi 3B+.

My 3B+ is fine. It’s the 2B that decided to succumb to entropy. On the same network and the same time as the 3B+. 🤷🏻‍♀️

I’ve looked at the RTK library’s source; there are many source files. OTOH Wiresalmon’s front end appears to do such a simple job that I feel tempted to create a replacement in C using the Toolbox. We would then have something that can be supported by many people.