Wiresalmon

Erm, it looks like that may have been it. I’ve just changed both the LDR to LDRB and done a capture with alignment exceptions on. No crash.

But I must go to bed now. More news tomorrow, I hope!

I haven’t fixed compiler warnings “LDM or STM of single register is probably slower than LDR or STR”.

Let me just check if I’ve got these right:

STMFD sp!, {lr}

should be replaced by

STR lr, [sp, #-4]!

and

LDMFD sp!, {pc}

should be replaced by

LDR pc, [sp], #4

Yes?

Yup. In my notes I have:

STR    R14, [R13, #-4]!
...
LDR    PC, [R13], #4

Which is the same thing using BASIC style register nomenclature.

Thanks, Rick!

One pair I find easier to remember – a case for a Macro.

I’ve put a work in progress version of Wiresalmon at https://davehigton.me.uk/WorkInProgress/Wiresalmon.zip

This replaces what was there before, which was just the module. This is the app, and the module, including the sources.

It should run with alignment exceptions enabled, but only (according to my experiments) with the ROOL Internet stack. When I have tried it with the ROD stack, the whole machine has completely stiffed.

This version is certainly not the final version – it needs a little more idiot resistance to be added.

Please try it and let me know if it works for you – success or failure.

Wiresalmon is NOT like a full Wireshark; this is just the bit that captures the network traffic and creates a pcap file, which you can then share across a network (I use Moonfish and Ubuntu) to decode the packets.

I have just tried Wiresalmon for the first time – and it seems to start, start capture, stop capture and quit here without problems so far, and the output displays with WireShark on my PC. This is on a Titanium, running RO5.29 (29 Aug 2023), with normal ROOL stack and Alignment Excepions Off. I will experiment further when I get chance. Another very useful tool updated! Thanks Dave.

with normal ROOL stack and Alignment Excepions Off

Importantly, this one should run with aligment exceptions On.

Completely stiffs the Pi2 with the ROD stack. You know this, just confirming it happens here.

Interestingly, even though the machine is functionally dead (no response to Caps Lock or mouse movement), it did after a couple of seconds pop up an error box to say that “Pinboard may have gone wrong (etc)” but obviously one can’t click on anything.
It sounds like the IPv6 issue in that something is going wrong at a low level and this is trickling up until other stuff crashes. But the brief delay before the error box sounds like some sort of timeout expired… but given that everything was frozen I think the SVC or IRQ stacks had already been corrupted, so there was nowhere to go after the timeout but further into the abyss of crashiness.

I’ve put a work in progress version of Wiresalmon at

Thanks for that Dave.

It works on my ARMX6 and also on my PinkBookPro and captures data.

On the PineBookPro I have to either plug in the Network adaptor after starting WireSalmon or unplug and reinsert it again for the network to work.

If I have the USB Ethernet adaptor in and then run WireSalmon I get an error to say the cable is unplugged so I guess something isn’t coming up right again in the network stack until the adaptor is unplugged and reinserted.

I’ll see if I get time to check the output as I’m trying to help find out why ShareFS fails, on the Pro, when pushing files using a 1GB AX 188179A USB to Ethernet adaptor.

Any way thanks once again for all the work on WireSalmon as it yet another useful diagnostic tool for RISC OS.

Thanks for the reports!

Doug: what version of EtherUSB (or whatever driver it is) are you running?

I wonder if temp version could be made that didn’t rm the Ethernet mods?

I’ve put a work in progress version of Wiresalmon at https://davehigton.me.uk/WorkInProgress/Wiresalmon.zip

Some comments on it, as I was bored…

Make: As you’re having issues with unaligned access, I’d suggest including -za1 which should disable unaligned accesses.
c.wiresalmon, line 45: Typo pcap_hdr_s.
c.wiresalmon, line 309: You’re calling `OS_RemoveTickerEvent` to remove the callback rather than `OS_RemoveCallBack`
c.wiresalmon, line 177: You’re assuming that you will be called on a guaranteed timescale – that’s not true; callevery could be late – very late in some cases.
c.wiresalmon, line 291: You’re not checking the write was successful (you do check at line 233). Probably not too significant.
c.wiresalmon, line 278: You’re opening the file, but still using the C buffering. You might be better off setting the buffer size to 0 so that when written, the data is always flushed out to disc, rather than having an additional level of buffering.

s.wiresalmonasm: I think you’d be better establishing a C environment and having the intercept code, once the SWI is recognised, in C. It’ll make it a heck of a lot easier to reason about. However, if you’re really keen on keeping it in assembler, changing your offsets into register-based constants wouldn’t be a bad idea, eg:

MAX_DRIVERS             * 10
MAX_CLAIMS              * 20

                        ^ 0
pcaprec_hdr_ts_sec      # 4
pcaprec_hdr_ts_usec     # 4
pcaprec_hdr_incl_len    # 4
pcaprec_hdr_orig_len    # 4
pcaprec_hdr_size        # 0


                        ^ 0
driver_swibase          # 4
driver_mac              # 6
driver_pad              # 2
driver_size

                        ^ 0, v1
c_writeptr              # 0                 ; char *volatile writeptr;
c_writeend              # 4                 ;
c_overflow              # 4                 ; volatile int overflow;
c_rechdr                # pcalrec_hdr_size  ; pcaprec_hdr_t rechdr;
c_oldswihandler         # 4                 ; void *oldswihandler;
c_capturing             # 4                 ; FILE *capturing;
c_drivers               # driver_size * MAX_DRIVERS ; struct driver drivers[MAX_DRIVERS];
c_numrxclaims           # 4                 ; int numrxclaims;
c_rxclaims              # 4 * MAX_CLAIMS    ; void *rxclaims[2*MAX_CLAIMS];

Similarly, defining the MBuf structures with structure sizes, rather than having them precomposed offsets, would be what I’d do.

I wouldn’t have created a wimp application as the main user of the tool; personally I’d have created a command line tool that does the bulk of the work so that you’re not required to use the desktop, and avoids involving a lot more complexity.

The overflow handling is using a single flag, but you’ve got a whole word. For no extra cost you could actually count the number of packets you’ve lost. Then you can use the DCI statistics to report that information, which would be quite cute.

There doesn’t seem to be a way to capture to memory? Personally that’s how I’d have approached it – a capture to memory, and then a client that pulls the data from memory to write to disc in the foreground.

No documentation for the API appears to be present? That would seem pretty fundamental to me.

I don’t see how you’re filtering for a specific driver. It looks like you’re capturing all drivers on the system; is that right?

The module appears to always trap the SWI vector, whether it’s in use or not, which means that you’re going to slow the system just by loading the module. Similarly, it’s always sitting on the CallEvery from initialisation, rather than when it’s in use.

The driver list is static when the module starts – if you have a new driver appear it won’t be recognised or captured until the module is restarted.

The Stop SWI explicitly returns an error to say that it overflowed. This means that clients need to be aware of the error number that the overflow reports, in order to distinguish between ‘the operation we requested was performed, but it had failed sometime in the background’ and any other errors. It would be better to return the status in a flag, rather than as an error – because the stop has been performed just fine. It’s that there’s a deferred error that you’re reporting.

This approaches the capturing in a different way to how I attacked it – mainly because restarting the drivers is the only way you can reliably do what you’re doing here without support of the protocol modules, and I didn’t really want to do that. Meh, different approaches.

It certainly starts on RISC OS Pyromaniac, but as that doesn’t use the DCI 4 driver by default, that’s not surprising. Starting it up with the ROD Internet stack seems to work, but I never get anything captured – probably because the SWI vector is entirely skipped if the call would happen internally.

Thanks for your comments, Charles – much appreciated.

I have to point out that the whole thing was originated by Alex Waugh, and TTBOMK hasn’t been updated by him since 2007. All I have done is to make minimal changes to the module to make it build and run on modern machines; and to create a new front end app, mirroring as closely as possible Alex’s original, simply to avoid using a user-generated library (RTK) which was abandoned a long time ago. The front end really does no more than to start and stop the module capturing.

It is possible to use the module from the command line, I believe.

I do intend to document the API soon. At the moment, all we have is Alex’s documentation. But the API only consists of two simple SWIs, so it is simple to do.

Some of your observations are beyond my current level of understanding of the internals of RISC OS, so it may well be some time before I can do a full job – but it’s open source (GPL 2+), so all contributions are welcome. I will start now.

Having said that, I started the current effort in the hope that Wiresalmon would be a useful diagnostic tool for the problems that several people (me included) experience when running the new ROD Internet stack. Unfortunately John Ballance says that the new stack does not provide the necessary interface, so my efforts may well turn out to have been at least partly in vain.

One other thing: I have no wish to keep it all in assembler. It has crossed my mind numerous times to look at moving the assembler code into C; I think most of it should go with little trouble. (Whose famous last words are they?)

what version of EtherUSB (or whatever driver it is) are you running?

That would be either Thomas Millius’s EtherUSB 0.43 , ROOL’s 0.42 (30-Sep-23) beta or a debug version of it supplied by ROOL.

ROOL seem to think from the debug data that something is getting stuck handling interrupts.

As previously stated the standard AX 88772B 100mB USB to Ethernet adaptor works OK.

I’m not sure WireSalmon can give any further information that the debug EtherUSB module can’t, but every little bit of information helps when something is stuck in a terminal loop that can only be recovered from by killing the remote machine by powering it off.

Did ROD say what they have changed?

I think there is no DCI4 interface, but I’m not sure.

If OS_RemoveTickerEvent or OS_RemoveCallBack is called for a ticker event or callback that has already been removed, is there any error?

(I can’t see why there should be; if there isn’t, it saves refcounting.)

If OS_RemoveTickerEvent or OS_RemoveCallBack is called for a ticker event or callback that has already been removed, is there any error?

There isn’t any error, no. The documeentation makes no explicit statement about whether there would be an error if they weren’t there, so that doesn’t mean that you should rely on it – it might not be unreasonable for a heap corruption error to be returned. And of course you should always call SWIs with their X-form in modules, so you’d be capturing the error in any case.

However, you might still want to track the state and only call if it necessary, if only because doing work that you don’t need to and performing operations that are unnecessary is bad practice.

Tried WSam on VRpc DL RO5.xx – seemed to capture something.
Ref the asm code would prefer R0 R1 etc.
Not much info on how it works – other that it captures packets :-(

Did come across I think Gerfs info on networking.
Will take some reading :-)

[Edit]

If you wanted to run it from the command line – a couple of simple files to do the 2 swis – but need to have some means to having a save address.

If you wanted to run it from the command line – a couple of simple files to do the 2 swis – but need to have some means to having a save address.

Wiresalmon_Start takes a pointer to a filename in R0, and a buffer length in R1. If R1 = 0, the buffer is defaulted to 512 kiB. This is what the app does, and I’ve never tested it with anythng else.

Wiresalmon_Stop takes no parameters.

There’s no easy way to determine whether a filename refers to a local or remote (i.e. via the LAN) filing system, is there, other than checking against all the filing system names known at compilation time?

I’ve updated the WIP version on my web site: https://davehigton.me.uk/WorkInProgress/Wiresalmon.zip with the last changes before I submit it back to Alex Waugh to go into github. Please try it (unless you’re on the ROD IPv6 stack, because it will crash your machine) and let me know of any issues.