FRP Client doesnt start automatically
Creating a bug report/issue
Required Information
-
DietPi version | 8.22.3 (master/MichaIng)
-
Distro version | bookworm
-
Kernel version |
Linux DietPi 6.1.50-current-rockchip64 #3 SMP PREEMPT Wed Aug 30 14:11:13 UTC 2023 aarch64 GNU/Linux -
SBC model | ROCK64 (aarch64)
-
Power supply used | (EG: 5V 1A RAVpower)
-
SD card used | Samsung evo plus 16gb
-
Software title | FRP
-
Installed 28th sep
-
Can this issue be replicated on a fresh installation of DietPi? yes
- Bug report ID | 804e6a1b-715e-40ee-91fa-0ee8c5390e3b
Steps to reproduce
- Install FRP as both
- frpc in services status is inactive
Expected behaviour
- should be active and accesible by web browser
Actual behaviour
- i can active manually from dietpi-services, but if i restart services or sbc then it is inactive again
Extra details
-
│ ○ frpc.service - frp client (DietPi) │ │ Loaded: loaded (/etc/systemd/system/frpc.service; enabled; preset: enabled) │ │ Active: inactive (dead) since Fri 2023-09-29 12:00:44 BST; 14min ago │ │ Duration: 58ms │ │ Process: 7182 ExecStart=/usr/local/bin/frpc -c /etc/frp/frpc.ini (code=exited, status=0/SUCCESS) │ │ Main PID: 7182 (code=exited, status=0/SUCCESS) │ │ CPU: 56ms │ │ │ │ Sep 29 12:00:44 DietPi systemd[1]: Started frpc.service - frp client (DietPi). │ │ Sep 29 12:00:44 DietPi frpc[7182]: 2023/09/29 12:00:44 [I] [root.go:220] start frpc service for config file │ │ [/etc/frp/frpc.ini] │ │ Sep 29 12:00:44 DietPi frpc[7182]: 2023/09/29 12:00:44 [W] [service.go:133] login to server failed: dial tcp │ │ 127.0.0.1:7000: connect: connection refused │ │ Sep 29 12:00:44 DietPi frpc[7182]: 2023/09/29 12:00:44 [I] [root.go:236] frpc service for config file │ │ [/etc/frp/frpc.ini] stopped │ │ Sep 29 12:00:44 DietPi systemd[1]: frpc.service: Deactivated successfully.
looks like service is connecting to another service/port that is not allowing the connection.
login to server failed: dial tcp
127.0.0.1:7000: connect: connection refused
Can you check available ports
ss -tulpn | grep LISTEN
Also, do the frp server logs contain any hint?
journalctl -u frps
root@DietPi:~# ss -tulpn | grep LISTEN
tcp LISTEN 0 5 0.0.0.0:8181 0.0.0.0:* users:(("python3",pid=7637,fd=13))
tcp LISTEN 0 1000 0.0.0.0:22 0.0.0.0:* users:(("dropbear",pid=616,fd=3))
tcp LISTEN 0 4096 *:7500 *:* users:(("frps",pid=7610,fd=9))
tcp LISTEN 0 4096 *:7000 *:* users:(("frps",pid=7610,fd=3))
tcp LISTEN 0 4096 *:443 *:* users:(("frps",pid=7610,fd=8))
tcp LISTEN 0 1000 [::]:22 [::]:* users:(("dropbear",pid=616,fd=4))
tcp LISTEN 0 4096 *:80 *:* users:(("frps",pid=7610,fd=7))
root@DietPi:~# journalctl -u frps
Oct 02 08:01:12 DietPi systemd[1]: Started frps.service - frp server (DietPi).
Oct 02 08:01:14 DietPi frps[618]: 2023/10/02 08:01:14 [I] [root.go:204] frps uses config file: /etc/frp/frps.ini
Oct 02 08:01:17 DietPi frps[618]: 2023/10/02 08:01:17 [I] [service.go:206] frps tcp listen on 0.0.0.0:7000
Oct 02 08:01:17 DietPi frps[618]: 2023/10/02 08:01:17 [I] [service.go:267] http service listen on 0.0.0.0:80
Oct 02 08:01:17 DietPi frps[618]: 2023/10/02 08:01:17 [I] [service.go:282] https service listen on 0.0.0.0:443
Oct 02 08:01:17 DietPi frps[618]: 2023/10/02 08:01:17 [I] [service.go:318] Dashboard listen on 0.0.0.0:7500
Oct 02 08:01:17 DietPi frps[618]: 2023/10/02 08:01:17 [I] [root.go:213] frps started successfully
root@DietPi:~# journalctl -u frpc
Oct 02 08:01:12 DietPi systemd[1]: Started frpc.service - frp client (DietPi).
Oct 02 08:01:14 DietPi frpc[619]: 2023/10/02 08:01:14 [I] [root.go:220] start frpc service for config file [/etc/frp/frpc.ini]
Oct 02 08:01:14 DietPi frpc[619]: 2023/10/02 08:01:14 [W] [service.go:133] login to server failed: dial tcp 127.0.0.1:7000: connect: connection refused
Oct 02 08:01:14 DietPi frpc[619]: 2023/10/02 08:01:14 [I] [root.go:236] frpc service for config file [/etc/frp/frpc.ini] stopped
Oct 02 08:01:14 DietPi systemd[1]: frpc.service: Deactivated successfully.
Strange, no errors, the server is listening on port 7000 as expected, but still refuses the client connection.
Could you check whether the authentication token matches in /etc/frp/frps.ini and /etc/frp/frpc.ini?
I can replicate the issue. Will check for upstream changes.
A bug our end, missing spaces. Crazy how this could survive so long, probably some library used by frp was more generous regarding the syntax previously: https://github.com/MichaIng/DietPi/commit/406ecfa
still bugged on fresh install:
frpc.service - frp client (DietPi) │
│ Loaded: loaded (/etc/systemd/system/frpc.service; enabled; preset: enabled) │
│ Active: inactive (dead) since Wed 2023-12-06 21:34:56 GMT; 14h ago │
│ Duration: 1.906s │
│ Process: 652 ExecStart=/usr/local/bin/frpc -c /etc/frp/frpc.ini (code=exited, status=0/SUCCESS) │
│ Main PID: 652 (code=exited, status=0/SUCCESS) │
│ CPU: 148ms │
│ │
│ Dec 06 21:34:54 DietPi systemd[1]: Started frpc.service - frp client (DietPi). │
│ Dec 06 21:34:56 DietPi frpc[652]: WARNING: ini format is deprecated and the support will be removed in the future, │
│ please use yaml/json/toml format instead! │
│ Dec 06 21:34:56 DietPi frpc[652]: 2023/12/06 21:34:56 [I] [root.go:139] start frpc service for config file │
│ [/etc/frp/frpc.ini] │
│ Dec 06 21:34:56 DietPi frpc[652]: 2023/12/06 21:34:56 [W] [service.go:131] login to server failed: dial tcp │
│ 127.0.0.1:7000: connect: connection refused │
│ Dec 06 21:34:56 DietPi frpc[652]: 2023/12/06 21:34:56 [I] [root.go:154] frpc service for config file │
│ [/etc/frp/frpc.ini] stopped │
│ Dec 06 21:34:56 DietPi systemd[1]: frpc.service: Deactivated successfully.
Can you check whether the spaces are now present in your frpc.ini, and that the token matches with the one in frps.ini?
Seems we need to migrate to TOML format.