Is the kernal crashing ? Should I be looking at replacing this 400C link?

Products ePMP
1

400C PTP been running great for about a year. Recently had to change from 40Mhz to 80Mhz channel and link started failing and bugsplat errors spamming logs. Updated radios to newest beta RC a few days ago and so far link stable, no bugsplats but now these are spamming the logs of both radios

Apr 24 10:23:39 BH11M creporterd: kernel process_crash… get_crash_data fail : -1
Apr 24 10:03:39 BH11M creporterd: kernel process_crash… get_crash_data fail : -1
Apr 24 09:43:39 BH11M creporterd: kernel process_crash… get_crash_data fail : -1
Apr 24 09:23:39 BH11M creporterd: kernel process_crash… get_crash_data fail : -1
Apr 24 09:03:39 BH11M creporterd: kernel process_crash… get_crash_data fail : -1
Apr 24 08:43:39 BH11M creporterd: kernel process_crash… get_crash_data fail : -1

I feel like this is along the same lines as or related to the bugsplats just different wording. It appears to be saying that the kernal is crashing and it’s unable to get the crash data but it wouldn’t be the first time I completely misunderstood what a log entry was trying to tell me.

My main concern is if I there is something wrong with one or both of these radios of if this is just some glitch caused by the software ?

1 Like
2

Hi,

I would be interested to take a look into the Tech Support File if you could share it.
I would assume that it’s related to crashes that happened before and now the device is trying to send it to the remote server.

Thank you.

4

I’m seing that in the lastes versions, when you make the first conection to the GUI, they request to modify the admin’s password, the SNMP communitys and grant o deny the send crash reports to cambium.
It’s posible that if this option was enabled, despiste if the unit is setting to connect or not to cnMaestro (on premise o cloud) make a side conection to another CN server to send specifics the crash reports?

6

We would be happy to take a look deeper in the described issue if you can share Tech Support File from the radio with me.
The daemon on the device is trying to collect the information related to the crash if it happened even if the option “Not send” is set.

Thank you.

8

Hello @brubble1,

I’m aware of this ticket and currently trying to reproduce this issue in my lab. Our team initial assumption was wrong and we still able to see it in RC9.
creproterd - is a daemon reporting crashes and the issue is there.
There is no actual kernel crush itself.

10

Have you tried swapping which radio is the AP? I dont mean physical swap, just with the current SM setup as an AP.
I remember when the epmp1000 radios had this similar DFS issue that we were seeing out of band RF that was triggering DFS hits and swapping the radios config made the link stable.

1 Like
12

Actually it does even with ePTP. One will always boot up as the AP and this one needs to be determined as the master since the link synchronization comes from the AP even with the ePTP protocol.

13

@Douglas_Generous – I think @brubble1 is talking about as the ratio goes. With TDD, you if you want 75%/25% that’s from the AP’s perspective. With ePTP (or flexible frame) the AP/Master is still in charge of scheduling, but I think brubble meant “as far as downlink/uplink performance, it doesn’t matter” as much.

1 Like
15

I was thinking in terms of how DFS events are detected. Any sudden increase of the noise floor as detected by the AP (sudden drop in SNR) while using a DFS channel will result in a DFS back-off.
This can be as simple as being too close to another radio using the same DFS channel or a harmonic of another band that is strong enough to trigger the DFS back-off.
Swapping which end that controls the link can help if the source is close to the current AP/master side of the link.

1 Like
16

Yep, this is a great troubleshooting suggestion :+1:

It’ll be nice when 4.7.1 is out and has the seamless channel switching finally. That’ll really REALLY help for optimization and for tweaking and for troubleshooting too.

1 Like
17

Was there a resolutioon to this issue? Seeing the same thing in the log on both ends of a F400 CSM PTP link, get-crash data fail every 20 minutes. Crash report and CNMaestro are disabled. Running latest 5.4.1 software. Both units are reporting the error. Other than the annoyance factor, no seeing anything weird with the link and it has been stable.

18

The message can be seen in the log when the remote crash reporting is disabled.
It will be fixed in the upcoming releases.
No impact on stability or performance.

Thank you.

1 Like
19

lThanks, appreciate it!

20

I am seeing this on APs after updating to 4.7.1.

Does anyone know what Syslog Mask these errors belong to, or know a resource that will point me in that direction?

Many thanks.

21

Hi. As far as I know, this is NOT an actual error… it is just a report saying that it was ‘unable to get the crash data’.

So basically - there is no crash, there is no actual error… but if you have your ‘report crash data to Cambium’ thing turned off, then 4.7.1 there is this report every 20 minutes that says essentially exactly that… it’s just saying "unable to report the (nonexistant) crash data’

1 Like