I hate to let a good eff-up go to waste so cambium make this a training exercise would you 
I had installed a chain of v5000s and was subsequently going through in maestro to tweak channels to optimize connections. Having not had my 2nd coffee yet this was first error, obviously. I have tried all channels and cannot get the link to come back.
Found the error in the thread title in the e2e minion log of adjacent DN
In the openr log I find " E0428 08:21:46.699561 3878 Spark.cpp:654] Received packet from fe80::204:56ff:fe88:3b14%br0 on unknown interface with index 8. Ignoring the packet. "
Aside from factory reset which I will undertake in a few hours is there any expedient way to recover ?
Hi,
BF_TRAINING_FAILED indicates me that the peer radio is either not responding due to channel/golay being different or peer radio being powered off or incorrect sector selection or peer radio is at the edge of coverage (or) incorrectly configured MAC address for peer radio
I would check how to integrate this pain point in our training.
But, below notes would assist you while optimizing/changing channels and Golay codes.
-
When changing Golay Codes please ensure that the Golay override is only applied at one end. We would recommend keeping it consistent and having it only applied at the DNs and not at the CNs.
-
For a DN to DN link, Golay override for that link should only be applied at one end.
-
During Channel changes, the CNs have a channel re-scan mechanism, whereby they start scanning all channels following a 120sec timeout. So only a channel change at the DN would be necessary.
-
There is no channel rescan mechanism for a DN, once the link has been formed. Therefore, when changing channel, one needs to issue a channel override at the downstream node (further away from the POP) first before submitting the channel change to the upstream DN (Closer to the POP).
1 Like