F400 PTP link dropping / thousands of bugsplats

So all of a sudden the F400 AX PTP link I had been bragging on has started dropping this morning. While my first assumption was interference ( SA, as usual not helpful) the logs on the AP are suddenly full of Bugsplat. AP had been up for 128 days, and no bugsplats until this morning starting about the same time the link started dropping and there are thousands of lines of this bugsplat in the last few hours.

Apr 20 13:47:07 BH11M admin[192.221.181.62] get_crash: [BUGSPLAT] Report data locked (ARCH)
Apr 20 13:47:03 BH11M admin[192.221.181.62] get_crash: [BUGSPLAT] Report data locked (ARCH)
Apr 20 13:46:58 BH11M admin[192.221.181.62] get_crash: [BUGSPLAT] Report data locked (ARCH)
Apr 20 13:46:53 BH11M admin[192.221.181.62] get_crash: [BUGSPLAT] Report data locked (ARCH)
Apr 20 13:46:48 BH11M admin[192.221.181.62] get_crash: [BUGSPLAT] Report data locked (ARCH)
Apr 20 13:46:48 BH11M admin[192.221.181.62] get_crash: [BUGSPLAT] Report data locked (ARCH)
Apr 20 13:46:36 BH11M admin[192.221.181.62] set_param: {"device_props":{"spectralEnable":"0"},"template_props":{"config_id":"25"}}
Apr 20 13:46:27 BH11M admin[192.221.181.62] get_crash: [BUGSPLAT] Send crash report data (JSON) to GUI:
Apr 20 13:46:27 BH11M admin[192.221.181.62] get_crash: [BUGSPLAT] Start send crash report (ARCH) to GUI:
Apr 20 13:44:23 BH11M admin[192.221.181.62] get_crash: [BUGSPLAT] Report data locked (ARCH)
Apr 20 13:44:13 BH11M admin[192.221.181.62] get_crash: [BUGSPLAT] Report data locked (ARCH)
Apr 20 13:44:03 BH11M admin[192.221.181.62] get_crash: [BUGSPLAT] Report data locked (ARCH)
Apr 20 13:43:19 BH11M admin[192.221.181.62] get_crash: [BUGSPLAT] Report data locked (ARCH)
Apr 20 13:43:09 BH11M admin[192.221.181.62] get_crash: [BUGSPLAT] Report data locked (ARCH)
Apr 20 13:43:04 BH11M admin[192.221.181.62] get_crash: [BUGSPLAT] Report data locked (ARCH)
Apr 20 13:42:59 BH11M admin[192.221.181.62] get_crash: [BUGSPLAT] Send crash report data (JSON) to GUI:

I rebooted the radio but the bugsplats continue.

The SA, per usual, is being pretty much useless. The link is a 40Mhz channel @5660 and this is what both ends show… I just… I’m so glad cambium got their pay to play QOS going but the SA is still , after years, a steaming useless pile of trash. (Edit: oh and I didn’t start out zoomed in and selecting “detailed” I started out normal, got no useful results after 10+ minutes, zoomed in, still getting nothing useful and then detailed / zoomed in… the only change is 1/2 the SM showed up on the AP).

SM

AP (that 20Mhz block is it’s own SM … well half of it)

1 Like

You tried updating to 5.4.1 stable release? It just came out the other day.

1 Like

Hi, @brubble1! Could you PM me tech support? Want to see this crash

Sorry Andrii I had so many other things going on at the time that it didn’t even occur to me to grab a support file. We got it back up stable on a 40Mhz channel and I moved on to other things. I upgraded the firmware to the 5.4.1RC7 early this morning and put it back on an 80Mhz channel and so far it isn’t dropping but now the log is showing several BH11M creporterd: kernel process_crash… get_crash_data fail : -1 an hour.

If you still want support files I send them.

Edit: The kernal process_crash lines were rolling in on both radios at several an hour. I just turned off the SA on both radios, will see if the crashes go away or continue.

Edit Edit : It appears they do continue after the SA is shut off

Apr 21 09:18:52 BH11M admin [#.#.#.#] web_inte: User: ‘admin’ role: ‘admin’ is logged in…
Apr 21 09:10:32 BH11M admin [#.#.#.#] login: a: User is logged out…
Apr 21 09:03:35 BH11M creporterd: kernel process_crash… get_crash_data fail : -1
Apr 21 08:46:20 BH11M json-configd[1053]: Value of spectralEnable was changed to ‘0’

Eric,

Thanks for your suggestion. Iink had been 40Mhz for around a year, changed it to 80Mhz a few day days ago (huge time consuming headache moving / creating space for channels with an all but completely useless SA on a couple dozen ePMP AP’s that can all see each other… what a nightmare) Anyway, initially moved back to 40Mhz but centered where the 80 had been not on it’s original 40Mhz (just about 10mhz away though) and it stayed up for an hour and dropped again (when it would drop it stayed dropped, no amount of soft rebooting would fix only changing the channel and/or the channel width). Moved back to the exact 40Mhz channel it had been happily running on for a year and the link stayed up for the rest of evening though the bugsplats continued to fill the logs.

I’m not sure the bugsplats were even related to the issue but they did show up at the same time so they get the blame for now. It really seems like something noise related but the ePMP SA is just such a useless tool sometimes… often… most the time… anyway last night/early this morning I did update the link to the 5.4.1RC7 and I put it back on 80Mhz where it was. The bugsplats did not come back after the upgrade but now I have what appears to be a new error showing up over and over in the logs ( Apr 21 09:03:35 BH11M creporterd: kernel process_crash… get_crash_data fail : -1). However for now the link is staying up and only time will tell I guess.

1 Like