开云体育

??}

?

?? - When you use Pat, are you making an outbound AX.25 connection to a remote system or is some remote system making a AX.25 connection to you?
????? - How often do you make this connection attempt?

Do you remember I mentioned the "complexity" in my AX.25 stack? ?I might need a little latitude on this one, so apologies in advance.

As I'm sure you are aware, when you transmit through the AX.25 stack, you cannot "hear" that transmission. ?If you could, chaos would ensue. ?This is a bit inconvenient in the scenario where you want to monitor your own services. ?As an example, if you ran your Winlink client (pat) on the same station as your Winlink server (rmsgw), those two could never talk. ?Such is my situation where pat/rmsgw run on the same Pi and it is my only packet station.

I found two solutions to this dilemma; the first is to digi back to yourself. ?Of course that's a massive waste of RF and I didn't want to be "that guy". ?The other, more elegant solution, involves kissnetd and a pair of loopback ax ports (a.k.a. "the complexity"). ?You can probably see why I didn't want to muddy the waters with this before; sorry about that. ?I've had this loopback config setup for about 5 years now. ?Did I mention I have disabled this? ?Just making sure.

To answer the question, I've normally used the loopback for Pat's connections, so checking my mail doesn't cross RF. ?Realizing the loopback complexity was a liability, I removed those parts last week and I've been using the digi back to myself option. ?The schedule runs just once a day a 9:15a. ?I've had very few inbound connections to my RMS server, but I've never been able to correlate an inbound connection with a crash.

? ?- It might be good to run a script via cron running every minute on your Pis under test that:

I've actually done most of that (uptime, free, slabtop, proc temperature, voltage events) on a 10 second cycle. ?I've not recorded disk space or process list as I didn't see much value there. ?As you implied, when the kernel crashes, nothing gets flushed to disk, so my logs are unremarkable. ?However, I like the dmesg idea. ?Given that's a direct read from /dev/kmsg, I think I'll avoid writing that to disk and just stream it to a terminal. ?The hot pipe means it has a better chance of making it to the wire than down to disk. ?

? ?- What kernel version are you currently using?? - Can you take a picture of the kernel crash screen?

The kernel is?6.1.0-rpi7-rpi-v8. ?I do have a photo of the crash, but groups.io compresses the picture to such an extent that it is illegible. ?I posted the text of the crash (from the serial console) in a message a few weeks ago. ?Were you looking for something that might be on the screen that wouldn't be on the serial console?

? ?- You mentioned that when you rebuilt the TEST machine to use a real sound device instead of a sound-loopback, it started to crash.? To me, this could be RFI induced.? How physically close is the radio to your Raspberry PIs?? How much RF power is the radio transmitting at?

Drats, RFI! ?Don't worry, I'm not going to pull the "not in my shack" argument. ?RFI is always an option, but is notoriously hard to diagnose. ?To answer your questions, I have 3 Pi (PROD, TEST, and an unrelated Pi4) 3 to 4 feet away from the radio and my radio is set to "Mid" power (which is 10w in Kenwood speak). ?I mentioned the audio tap, so my data cable is your typical Mini-DIN6 on the radio end and a very atypical, butchered mess of ribbon cable, and Dupont/TRS connectors on the other (i.e. RFI playground). ?However, do think back just a moment to my loopback remarks, and understand that the crash has usually happened without any RF transmit (i.e. no RFI) while mail was being checked over the loopback.

Since RFI is so difficult to identify, how about a differential test against RFI? ?As it happens, I have an idle Pi3 sitting here. ?This Pi, let's call it LEGACY, is the direct predecessor to PROD, so it has a fully operational packet configuration that was decommissioned a couple of months ago. ?More importantly though, it has 2 years of clean operational history (no crashes) in this environment just a few inches away from where TEST and PROD are right now. ?It would be trivial to swap LEGACY into where TEST sits today. ?In that scenario, if LEGACY were to crash, then it points the finger at RFI; if it doesn't crash then a kernel bug is likely to blame. ?Thoughts?

? Thanks
? Mike
? Thanks
? Mike