G
YouTube TikTok Games
Skip to content

Using Own Peer ID as Master Peer ID For Legacy FNEs Causes Upstream Disconnects #113

Open

Description

@faultywarrior

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.

Activity

  1. gatekeep commented on Jan 22, 2026

    @gatekeep
    Member

    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.

  2. faultywarrior commented on Jan 22, 2026

    @faultywarrior
    ContributorAuthor

    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.

  3. gatekeep commented on Jan 22, 2026

    @gatekeep
    Member

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions