Two currently non-functional Fingboxes

SRP
SRP LAMember Posts: 117
100 Comments 25 Agrees 25 Likes 5 Awesomes
✭✭✭
edited May 12, 2021 in Fingbox #1
Hello All & @Robin,

I'm hoping someone can answer a couple of questions and lower my blood pressure. Apologies for this appearing in the Community User Guides section - I've no idea how that happened!

Firstly, I have two separate Fingboxes, a V2 and a V1, both of which were working until factory resetting them with the button and pin respectively, through the flashing white to solid white LED cycle. Both were then disconnected and reconnected but now freeze on the solid white LED and do not progress to green. Any ideas?

I'm fairly sure I've followed all the instructions on resetting outlined in the various threads here, like repeated power cycles, waiting 30 minutes before reconnection attempts and ensuring the FBs are plugged into the wall power socket directly rather than via a power extender, all to no avail.

Second question. The reason for resetting the Fingboxes, which I had set up on two separate VLANS, was that although the FBs found and monitored only the correct VLAN associated devices, each would unfortunately also repeatedly pick up BSSIDs from a new AP that I plugged in as new or rogue which were not associated with the BSSID-VLAN bindings.

I guess I'm pleased it picked them up since that's what the feature is for in case someone locally sets up a rogue matching SSID name, however, I had no way of trusting those which had nothing to do with the VLANS without them getting added to the monitored BSSID list on each Fingbox.

I attempted to add the detected AP BSSIDs to the trusted list and then delete them but got caught in an unbreakable AP discovery-trust-delete-discovery cycle. Ultimately I could never clear the 'new AP found' notification list. In other words, each box was monitoring BSSIDs I didn't wish them to,

Is there any way to 'pass' a newly found BSSID without it getting monitored moving forward? I resorted to a factory reset because I figured a fresh setup would solve the issue but ran into problem 1. ;)

Any help would be greatly appreciated.

Cheers,

S.

Answers

  • Marc
    Marc Moderator, Beta Tester Posts: 2,666
    1,000 Likes 2500 Comments 100 Answers 250 Awesomes
    ✭✭✭✭✭✭
    Hi @SRP, I moved this to the Fingbox area for relevance.  As you tagged @Robin already, lets wait for him to chime in and see if he can resolve your issue...
    Thats Daphnee, she's a good dog...
  • SRP
    SRP LAMember Posts: 117
    100 Comments 25 Agrees 25 Likes 5 Awesomes
    ✭✭✭
    edited May 12, 2021 #3

    Thanks @Marc for the reply and the area shift!

    A representative from Fing has already very kindly emailed me regarding the 'stuck' boxes and opened a support ticket to attempt to get the matter resolved.

    The BSSID issue is an interesting one because the FBs are, I guess, behaving as they should in a normal case when new APs are added to a single LAN/subnet/VLAN/Fingbox network and a new AP with matching SSID names shows up. One would always want the new trusted BSSIDs monitored moving forward if the AP was trusted in this scenario. It may also be 'harmless' for multiple FBs to monitor the same BSSID across network segments I suppose but instinctively this felt odd and the issue didn't even crop up with the BSSIDs the AP added on the the primary LAN segment monitored by my main Fingbox.

    Plugging a fourth spare new Fingbox in resolved the situation on one particular VLAN segment, I'm guessing because the BSSIDs discovered at setup include the additional 'new' AP's BSSIDs???

    It's complete supposition on my part that somewhere in my backend account a base list of SSID name-trusted BSSID bindings is maintained and it's currently not possible to expand this list after initial setup without adding move forward monitoring???

    Cheers,

    S.