☰

Undefinierte iperf3-Ports?

tag-icon • tag-icon iperf
Undefinierte iperf3-Ports?

Ich versuche, alle mit einer iperf3-UDP-Sitzung verbundenen Ports zu identifizieren, und stelle fest, dass das TCP-Handshake einen undefinierten(?) Port auf dem iperf3-Server verwendet.

Gibt es eine Möglichkeit, alle für einen iperf3-Test verwendeten Ports anzugeben?

Veranschaulichendes Beispiel:

In diesem Beispiel beobachte ich die folgenden verwendeten IP-Adressen und Ports:

  • [Client] 10.0.1.20, Port 5222
  • [Server] 10.0.1.89, Port 5205
  • [Client] 10.0.1.20,Port 56039 ????

Klient:

// iperf3 (v3.1.3) Client running on Ubuntu 16.04 IP address: 10.0.1.20, port 5222
$ iperf3 -c 10.0.1.89 -u -p 5205 --cport 5222 -B 10.0.1.20

Server:

// iperf3 (v3.1.3) Server running on Ubuntu 16.04 IP address: 10.0.1.89, port 5205
$ iperf3 -s -p 5205
-----------------------------------------------------------
Server listening on 5205
-----------------------------------------------------------
Accepted connection from 10.0.1.20, port 56039
[  5] local 10.0.1.89 port 5205 connected to 10.0.1.20 port 5222
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
...

Dies wird auch durch eine auf dem Client ausgeführte Wireshark-Aufzeichnung bestätigt.

Antwort1

Nein, es ist nicht möglich, diesen Client-Port über ein Befehlszeilenargument festzulegen, auch nicht mithilfe der iperf-API.

Dies gilt zumindest für die aktuelle Version 3.1 von iperf.Quellcodeist es möglich, die Funktion zu finden, die für die Herstellung der ersten TCP-Verbindung verantwortlich ist:

/* iperf_connect -- client to server connection function */
int
iperf_connect(struct iperf_test *test)
{
[...]
    /* Create and connect the control channel */
    if (test->ctrl_sck < 0)
        // Create the control channel using an ephemeral port
        test->ctrl_sck = netdial(test->settings->domain, Ptcp, test->bind_address, 0, test->server_hostname, test->server_port, test->settings->connect_timeout);

    if (test->ctrl_sck < 0) {
        i_errno = IECONNECT;
        return -1;
    }
[...]

Betrachten wir die netdial()Signatur der Funktion, die für die Herstellung der Verbindung zu einem Server zuständig ist:

netdial(int domain, int proto, char *local, int local_port, char *server, int port, int timeout)

Genauer gesagt können wir sehen, dass es dienetdial()local_port-Parameter als 0. Dies sollte beim Erstellen des TCP-Steuerkanals einen zufälligen Port zur Clientseite festlegen.

Wie Thomas bereits erwähnt hat, --cportwird die Option nur dieDatenströmeport und wir können auch überprüfen, dass ein Blick auf dieQuellcodefür die Funktion, die für den Aufbau des UDP-Datenstroms zuständig ist:

 if ((s = netdial(test->settings->domain, Pudp, test->bind_address, test->bind_port, test->server_hostname, test->server_port, -1)) < 0)

Diese Funktion verwendet die test->bind_portOption als local_portParameter, der aus der --cportOption abgerufen wird.

Antwort2

Auf deriperf3-WebsiteEs gibt eine Beschreibung zu diesem Verhalten.

...Die anfängliche TCP-Verbindung wird verwendet, um Testparameter auszutauschen, den Start und das Ende des Tests zu steuern und Testergebnisse auszutauschen. Dies wird manchmal als „Steuerverbindung“ bezeichnet. Die eigentlichen Testdaten werden über eine separate TCP-Verbindung, als separater Fluss von UDP-Paketen oder als unabhängige SCTP-Verbindung gesendet, je nachdem, welches Protokoll vom Client angegeben wurde...

man iperf3Wenn man sich die und die Option ansieht --cport, scheint dies nur dieDatenströmeund ohne Auswirkung auf dieSteueranschlussDies ist der dritte Port, den Sie als undefinierten Port identifizieren.

verwandte Informationen