Programmer Debugging: Solving the ‘Login to Server Failed: EOF’ Issue with FRP

As a qualified programmer, one should embrace the ideal of working overtime wherever they are.

To facilitate debugging at home, Lao Gao used frp to expose the ssh port on his company’s development machine. However, during the configuration of the frp client, the following message always appeared:

2019/08/30 23:42:47 [W] [service.go:82] login to server failed: EOF EOF

Initially suspected that it was a version issue with frp, so both the client and server were updated to the latest version, but the problem persisted. Continuing to attempt changing the port, the issue was still unresolved.

After searching online, it was discovered that many people have encountered the login to server failed: EOF issue. Let’s see how Lao Gao resolved it!

Local Packet Capture

Launch Wireshark, select the network card, and input the filter rule:

tcp and ip.addr==xxx.xxx.220.109

>

The last three RST packets are very suspicious, there are also three IRC protocol packets. Opening them reveals they actually contain authentication data.

{"version":"0.28.2","hostname":"","os":"darwin","arch":"amd64","user":"","privilege_key":"144fa23b09635f403ccd18","timestamp":1567119104,"run_id":"","pool_count":1}

Server Packet Capture

Open the terminal, input the command

# xxxx is the port listened to by frptcpdump -i eth0  port xxxx -n... (Packet data omitted for brevity) ...

Well, note the last three packets, which are also RST and in the opposite direction compared to what I captured locally. Clearly, this indicates a replay attack! 😄

Solution

It seems like the company’s firewall detected some characteristic traffic and triggered rules, resulting in the reset of the frp authentication packets, thus the frp server closed the connection. By examining the source code, we see that after sending the authentication information, it executes the ReadMsgInto method. Since the connection was already closed, we received the EOF error!

Reconsidering the RST packets in Wireshark prior to the three TCP packets, it’s quite possible that this piece of plaintext data exposed frp, leading to the firewall blocking it.

So how can one solve the login to server failed: EOF issue?

By reviewing the source code, it’s evident that frp, from version v0.25.0 onwards, added a client option that supports TLS transmission, i.e., asymmetric encryption has been supported. When initializing services in frps, a basic TLS service is already running for us, perfectly!

Enabling it is quite simple. In the original [common] configuration of both the server and client, add tls_enable = true!

Note: Both the server and client must be configured!

Alternative Solution

Since the firewall detected my tcp, can I switch to udp?

frp supports using kcp as the underlying communication protocol, which by default is based on the udp protocol. Let’s not talk much and try it quickly!

Steps (assuming kcp’s port is 7000):

1. In the original [common] configuration of the server, add kcp_bind_port = 7000 to enable udp support
2. In the original [common] section of the client, add protocol = kcp, making sure the ports match!