mirror of
https://github.com/fatedier/frp.git
synced 2026-05-15 08:05:49 -06:00
[GH-ISSUE #3095] [Feature Request] Recognize which device to connect to over remote port from 100s of devices in field #2481
Labels
No labels
In Progress
WIP
WaitingForInfo
bug
doc
duplicate
easy
enhancement
future
help wanted
invalid
lifecycle/stale
need-issue-template
need-usage-help
no plan
proposal
pull-request
question
todo
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/frp#2481
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ovfstack on GitHub (Sep 9, 2022).
Original GitHub issue: https://github.com/fatedier/frp/issues/3095
Describe the feature request
Hello,
We want to deploy 100s of devices in field which can run frpc and connect back to frps. The logic is each of this device will generate a unique remote port value when frpc is installed. This is a random unique port value which is generated when frpc is installed. On the frps side, how to know which device is available on which port?
The reason to use random but unique remote port value for each frpc is to simplify the device deployment. However when trying to connect from frps side to frpc over ssh, we need to know which port will connect to which device. Is there a way to map deviceid (Mac address in our case) that we know before hand with this remote port, so that we know that to ssh in to a device (which has a particular MAC address) we need to ssh to which remote port on frps
Describe alternatives you've considered
No response
Affected area
@fatedier commented on GitHub (Sep 9, 2022):
Set
userin your frpc configuration https://github.com/fatedier/frp/blob/dev/conf/frpc_full.ini#L83And you can get the info from frps dashboard api.
@github-actions[bot] commented on GitHub (Oct 10, 2022):
Issues go stale after 30d of inactivity. Stale issues rot after an additional 7d of inactivity and eventually close.