Help connecting to FileZilla Server administration API

Need help with FileZilla Server? Something does not work as expected? In this forum you may find an answer.

Moderator: Project members

Post Reply
Message
Author
User avatar
PolarbearDK
500 Syntax error
Posts: 14
Joined: 2014-09-16 13:30
First name: Philip
Last name: Hoppe
Location: Copenhagen, Denmark

Help connecting to FileZilla Server administration API

#1 Post by PolarbearDK » 2021-10-27 21:44

Hi, I'm the maintainer of the .NET API for administrating FileZilla Server (See sticky at the top).

The .NET API is not working with the new 1.x.x versions of FileZilla Server.
Th primary reason is that the Administrative GUI now requires TLS.

I have tried (with little success) to connect to the server with the following .NET Code:

Code: Select all

TcpClient client = new TcpClient();
client.Connect(Ip, Port);
var sslStream = new SslStream(client.GetStream(), false, new RemoteCertificateValidationCallback(CertificateValidationCallback), null);
var cert = new X509Certificate2("selfsign.pfx", "");
var certs = new X509Certificate2Collection {cert};
const SslProtocols allowedProtocols = SslProtocols.Tls12;
sslStream.AuthenticateAsClient("127.0.0.1", certs, allowedProtocols, true); 
After this I get a message in Filezilla Server log, that a session has connected.
However I get no response when sending commands - or I get a message "Not enough data" which seems to originate from GnuTLS.

Questions:
- Is the above code correct or am I doing something wrong?
- Should I use my own certificate or the same certificate as configured in GUI?
- Is the GUI "command API" that same or has it changed too?

User avatar
oibaf
Contributor
Posts: 396
Joined: 2021-07-16 21:02
First name: Fabio
Last name: Alemagna

Re: Help connecting to FileZilla Server administration API

#2 Post by oibaf » 2021-10-27 22:12

Hi,

The administration protocol is now completely different than the previous one, that's the main reason it's not working, aside from the TLS issue.

The messages are defined in "src/server/administration.hpp", the engine lives under "src/filezilla/rmp/*", and it all gets serialized/deserialized using the stuff under "src/filezilla/serialization/*".

User avatar
PolarbearDK
500 Syntax error
Posts: 14
Joined: 2014-09-16 13:30
First name: Philip
Last name: Hoppe
Location: Copenhagen, Denmark

Re: Help connecting to FileZilla Server administration API

#3 Post by PolarbearDK » 2021-10-28 20:25

"completely different" Ouch!

I've looked at the code, and have no clue what these messages look like. Is it binary or JSON or?
Could anybody provide a HEX dump of any simple command to get me started?
(I will Wireshark the traffic when I get the time, but it's fiddly with TLS...)

Is this new protocol stable or will it change a lot?
I manage to have the same .NET API talk to FileZilla Server versions ranging from 0.9.43 up to 0.9.60.

User avatar
oibaf
Contributor
Posts: 396
Joined: 2021-07-16 21:02
First name: Fabio
Last name: Alemagna

Re: Help connecting to FileZilla Server administration API

#4 Post by oibaf » 2021-10-29 04:46

The messages are declared in such a way as to support naming their fields as if they were functions declarations.

The messages fields can be of any type which supports serialization/deserialization by means of the serialization library under src/filezilla/serialization (inspired to the cereal serialization library, but with noticeable differences). This allows to use as messages fields the same data structures used in the program business logic.

The administration protocol itself is based on the Remote Message Passing library, under src/filezilla/rmp, which itself uses the binary archive to serialize/deserialize the messages over the wire.

The RPC library supports versioning, and so does the administration protocol. Such versioning guarantees freedom to completely change message formats and contents, and such a freedom is constantly taken advantage of. As such, I am afraid the answer to the question "is the protocol stable?" is a clearcut no, especially not at this stage of development.

I believe the best approach to make the admin protocol interoperable with .NET would be to just compile it in a shared library, bearing in mind that the messages signature, availability and semantics might change from one version of the protocol to the next.

Post Reply