lwIP Microcontroller reagiert nicht auf TCP `SYN`

[etechniker (Gast)]

Hallo zusammen

Ich sende Daten von einem Linux PC an einen TMS320F2838D auf dem lwIP 
läuft. Ich möchte erreichen, dass man den entsprechenden Linux Prozess 
beenden kann und die TCP Verbindung danach schnell wiederaufbauen kann 
durch einen Neustart des Linux Prozesses.

Wenn ich das nun auf meinem Rechner teste funktioniert das jeweils fünf 
mal gut, d.h. ich kann den Linux Prozess mittels SIGINT beenden und die 
TCP Verbindung wird korrekt geschlossen, auf Wireshark sehe ich das 
entsprechende FIN-ACK-FIN-ACK Muster.

Komischerweise funktioniert es nach dem fünften Wiederaufbauversuch 
nicht mehr, d.h. wenn ich den Prozess zum fünften mal Neustarte sehe ich 
auf Wireshark ein `SYN` Paket an den uC aber der lwIP uC reagiert nicht 
darauf.

Ich sehe kein Antwortpaket des uC und wenn ich den uC debugge wird die 
entsprechende callback Routine `accept_cb` zum Akzeptieren von TCP 
Verbindungen auch nicht aufgerufen.

Auf dem uC scheint jedoch immer noch ein "welcoming_socket" vorhanden zu 
sein der sich im state `LISTEN` befindet (also derselbe welcoming_socket 
der zuvor bereits vier mal eine TCP Verbindung ohne Probleme 
entgegengenommen hat), das zeigt zumindest der Debugger an wenn ich mir 
die entsprechende struct anschaue.

Ich benutze den folgenden Code zum Aufsetzen des welcoming_socket:

void setupCommInterface(void){
    //create a new tcp pcb
    struct tcp_pcb* connection_pcb = tcp_new();
    //bind the pcb to the port comm_port
    err_t err=tcp_bind(connection_pcb,IP_ANY_TYPE,COMM_PORT);
    if(err!=ERR_OK){
        if(err==ERR_USE){
            while(1){}
        }
        else if(err==ERR_VAL){
            while(1){}
        }
        while(1){}
    }

    welcoming_socket_pcb=tcp_listen(connection_pcb);

    tcp_accept(welcoming_socket_pcb,accept_cb);
}

Die callback Routine welche die eingehende TCP Verbindung akzeptieren 
sollte ist die folgende:

// TCP accept callback function is called when an incoming TCP connection on COMM_PORT is established
err_t accept_cb(void * arg, struct tcp_pcb* new_pcb, err_t err){
    if(err==ERR_OK){
        //set the connection active flag
        connection_active=true;
        //register callback for received data
        tcp_recv(new_pcb, tcp_recvd_cb);
        return ERR_OK;
    }
    else{
        while(1){
            //wait forever to preserve debug state
        }
    }
}

Gibt es da vielleicht irgendeine Socket-Option die den fünften 
verbindungsaufbau unterbindet?

[Stefan F. (Gast)]

Nur so eine Vermutung ins Blaue:

Der Mikrocontroller kann bis zu 5 Verbindungen gleichzeitig annehmen. 
Nachdem eine Verbindung geschlossen wurde, bleibt irgend eine Resource 
fälschlicherweise weiterhin belegt.

Dein Problem ist beginnt also vermutlich schon bei der ersten 
Verbindung.

Ich habe mir beim Vorgänger (µIP) eine Schnittstelle zum Monitoring 
eingebaut, wo ich unter anderem den Status der 5 Kanäle sehen konnte. 
Vielleicht würde dir so eine Ausgabe auch helfen.

[Programmierer (Gast)]

Weiß gerade nicht wie das bei lwIP funktioniert, reagierst du auf der 
uC-Software auf das Schließen der Verbindung, d.h. schließt du den PCB 
(new_pcb) ? Wenn nicht, hängt der eventuell noch rum und blockiert 
Ressourcen. Man kann in der lwIP-Config einstellen wie viele 
PCBs/Sockets gleichzeitig möglich sind...

[etechniker (Gast)]

Programmierer schrieb:
> Weiß gerade nicht wie das bei lwIP funktioniert, reagierst du auf
> der
> uC-Software auf das Schließen der Verbindung, d.h. schließt du den PCB
> (new_pcb) ? Wenn nicht, hängt der eventuell noch rum und blockiert
> Ressourcen. Man kann in der lwIP-Config einstellen wie viele
> PCBs/Sockets gleichzeitig möglich sind...

Vielen Dank für die Antwort. Das Schliessen funktioniert wie im unteren 
Code gezeigt. Wenn der lwIP ein `FIN` erhält ruft er die callback 
Funktion `tcp_recvd_cb` auf mit einem `NULL` buffer `p`. Daraufhin führe 
ich `tcp_close()` aus.

Manchmal kriege ich den Fehler scheinbar schon nach vier Versuchen. Aber 
es scheint tatsächlich so als ob `tcp_close()` nicht ganz alle 
Ressourcen sofort freigibt.

// TCP received callback function is called when new data was received on COMM_PORT
err_t tcp_recvd_cb(void* arg, struct tcp_pcb* tcppcb, struct pbuf* p,err_t err){
    //payload being NULL indicated that the TCP connection has been terminated
    if(p==NULL){
        connection_active=false;
        // close the pcb
        tcp_close(tcppcb);
        // listen to new connections again
        //tcp_accept(welcoming_socket_pcb,accept_cb);
        return ERR_OK;
    }
    else{
        if(err==ERR_OK){
            // -- process the data in p , p is NULL if the remote host terminated the connection --
            memcpy(buffer,p->payload,p->len);
            u16_t bytes_read=p->len;
            //indicate that a new command is available for processing in the buffer
            command_available=true;
            // -- indicate that bytes were read and we are ready to receive more data --
            tcp_recved(tcppcb,bytes_read);   //indicate that no_bytes_read were read and we are ready to receive more data
            // -- echo the received data back
            //tcp_write(tcppcb,buffer,bytes_read,TCP_WRITE_FLAG_COPY);
            return ERR_OK;
        }
        else{
            //wait forever and preserve debug state
            while(1);
        }
    }
}

[542325 (Gast)]

das ist witzigerweise "normal"

die alten Verbindungen stehen im "FIN_WAIT_2"
das hat mir auch schon oft den spass verdorben

ich habe bei mir die socket API ..daher ist das etwas anders.

Ich setze aber vor dem close alle sockets in den nonblocking mode
und immer mit den Flags :  SO_REUSE

sonst vlt vor dem close: lwip_shutdown(stream->sock, SHUT_RDWR);

holzhammermethode: SO_LINGER vor dem close

das killt den TIME_WAIT status