You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Using Own Peer ID as Master Peer ID For Legacy FNEs Causes Upstream Disconnects #113
Opening this so this doesn't get lost - FNE code needs to be updated to just NAK connections from peers which claim to be downstream FNEs but which fail to provide a valid Master Peer ID. The current handling of re-using the FNE's master peer ID causes upstream FNEs to disconnect due to a duplicate peer ID.
Hmmmm. While I've not tested this exact condition recently, initially this was okay (that is to maintain backward compat the peer ID is used as the master ID when master ID is not properly presented during the login handshake). Are you certain you do not have actual duplicates? Normally you should never reuse a peer ID (as either a literal peer ID or a master ID, all numerical network ID values should be unique).
This could especially be a problem if you use a console (because they currently do not present the master ID and represent themselves as a "FNE" to bypass ACL restrictions) that is attached to more then one FNE simultaneously, that is on the same network.
The presented fix here isn't really good because it will ultimately break backward compat.
Are you certain you do not have actual duplicates?
I've confirmed no actual duplicates exist - I only have a single FNE and a single Console instance up. As soon as the console instance connects to my FNE, the upstream hub FNE I peer to kicks my FNE for duplicate peer ID.
This could especially be a problem if you use a console (because they currently do not present the master ID and represent themselves as a "FNE" to bypass ACL restrictions) that is attached to more then one FNE simultaneously, that is on the same network.
This is the crux of my problem.
The presented fix here isn't really good because it will ultimately break backward compat.
I don't like it either, but it would technically "fix" the problem...and make people stop using FNE releases from 6+ months ago. I suppose an alternate solution could be, since we know the master ID of all other peers, simply generate a random one that is unique to the rest and use that instead of the fixed one.
Can you describe the actual configuration you are using? I won't be able to look at this for a little while, but I'd like to be able to eventually debug it and having a similar configuration would be beneficial.
Activity
gatekeep commentedon Jan 22, 2026
Hmmmm. While I've not tested this exact condition recently, initially this was okay (that is to maintain backward compat the peer ID is used as the master ID when master ID is not properly presented during the login handshake). Are you certain you do not have actual duplicates? Normally you should never reuse a peer ID (as either a literal peer ID or a master ID, all numerical network ID values should be unique).
This could especially be a problem if you use a console (because they currently do not present the master ID and represent themselves as a "FNE" to bypass ACL restrictions) that is attached to more then one FNE simultaneously, that is on the same network.
The presented fix here isn't really good because it will ultimately break backward compat.
faultywarrior commentedon Jan 22, 2026
I've confirmed no actual duplicates exist - I only have a single FNE and a single Console instance up. As soon as the console instance connects to my FNE, the upstream hub FNE I peer to kicks my FNE for duplicate peer ID.
This is the crux of my problem.
I don't like it either, but it would technically "fix" the problem...and make people stop using FNE releases from 6+ months ago. I suppose an alternate solution could be, since we know the master ID of all other peers, simply generate a random one that is unique to the rest and use that instead of the fixed one.
gatekeep commentedon Jan 22, 2026
Can you describe the actual configuration you are using? I won't be able to look at this for a little while, but I'd like to be able to eventually debug it and having a similar configuration would be beneficial.