lwip auf Microcontroller akzeptiert UDP packet nicht (Port Unreachable)

[Tom (Gast)]

Hallo miteinander

Ich möchte mittels UDP zwischen einem TMS320F28388D Microcontroller 
(192.168.0.4) und einem Linux PC (192.168.0.1) kommunizieren habe aber 
das Problem, dass der uC auf welchem der lwip stack läuft, nicht richtig 
auf den Empfang des UDP Packets reagiert.

Die Sockets auf beiden Seiten sind mit dem Port 3030 verbunden.

Wenn der Linux PC das erste Packet sendet, antwortet der lwip stack mit 
einer ICMP Nachricht "Destination unreachable (Port unreachable)", 
obwohl ich eigtl. einen Socket auf dem Mikrocontroller erzeuge, der mit 
diesem Port verbunden sein sollte.

Hat vielleicht jemand eine Idee, wo mein Problem liegen könnte?

Nachfolgend mein Code:

Aufsetzen des UDP sockets:

const u16_t COMM_PORT=3030;
struct udp_pcb* current_udp_pcb;
ip_addr_t IPAddr_remote={0xC0A80001};     //ip address of the remote pc
     
void setupCommInterface(void){
    //create a new udp pcb
    current_udp_pcb = udp_new();
    //bind the pcb to the port comm_port
    //this receives on port COMM_PORT from any IP address
    err_t err=udp_bind(current_udp_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){}
    }
    //set the remote IP address and port for sending data via UDP
    err=udp_connect(current_udp_pcb,&IPAddr_remote,COMM_PORT);

    udp_recv(current_udp_pcb,udp_recv_cb,NULL);
}

Definition des UDP Callbacks:

bool command_available=false;
uint8_t buffer[2048];
void udp_recv_cb(void *arg, struct udp_pcb *pcb, struct pbuf *p, const ip_addr_t *addr, u16_t port){
    // -- process the data in p --
    memcpy(buffer,p->payload,p->len);
    u16_t bytes_read=p->len;
    // TODO : check size to ensure that an entire command has been received
    //indicate that a new command is available for processing in the buffer
    command_available=true;
    pbuf_free(p);
    return;
}

Main Methode

int main(void)
{
    unsigned long ulUser0, ulUser1;
    unsigned char pucMACArray[8];
    //
    // User specific IP Address Configuration.
    // Current implementation works with Static IP address only.
    //
    unsigned long IPAddr = 0xC0A80004;
    unsigned long NetMask = 0xFFFFFF00;
    unsigned long GWAddr = 0x00000000;
    //
    // Initializing the CM. Loading the required functions to SRAM.
    //
    CM_init();
    SYSTICK_setPeriod(systickPeriodValue);
    SYSTICK_enableCounter();
    SYSTICK_registerInterruptHandler(SysTickIntHandler);
    SYSTICK_enableInterrupt();
    //
    // Enable processor interrupts.
    //
    Interrupt_enableInProcessor();
        
    // Set user/company specific MAC octets
    // (for this code we are using A8-63-F2-00-00-80)
    // 0x00 MACOCT3 MACOCT2 MACOCT1
    ulUser0 = 0x00F263A8;
    // 0x00 MACOCT6 MACOCT5 MACOCT4
    ulUser1 = 0x00800000;
    //
    // Convert the 24/24 split MAC address from NV ram into a 32/16 split MAC
    // address needed to program the hardware registers, then program the MAC
    // address into the Ethernet Controller registers.
    //
    pucMACArray[0] = ((ulUser0 >>  0) & 0xff);
    pucMACArray[1] = ((ulUser0 >>  8) & 0xff);
    pucMACArray[2] = ((ulUser0 >> 16) & 0xff);
    pucMACArray[3] = ((ulUser1 >>  0) & 0xff);
    pucMACArray[4] = ((ulUser1 >>  8) & 0xff);
    pucMACArray[5] = ((ulUser1 >> 16) & 0xff);
    //
    // Initialize ethernet module.
    //
    Ethernet_init(pucMACArray);
    //
    // Initialze the lwIP library, using static IP addresses.
    //
    lwIPInit(0, pucMACArray, IPAddr, NetMask, GWAddr, IPADDR_USE_STATIC);
    //
    // Initialize the ccard communication interface
    //
    setupCommInterface();
    //
    // Loop forever. All the work is done in interrupt handlers.
    //
    while(1){
        if(command_available){
            processCommand();
            command_available=false;
        }
    }
}

[(prx) A. K. (prx)]

Bei TCP/IP-APIs müssen IP-Adressen und Ports oft in "network byte order" 
angegeben werden. Ob im lwip auch weiss ich nicht. Dazu gibts 
üblicherweise sowas wie htons().

[J. S. (jojos)]

die Portangabe sollte richtig sein. Ist für diese Portierung noch eine 
ISR nötig? Oder muss das lwip_process() zyklisch im main aufgerufen 
werden?

[Stefan F. (Gast)]

Tom schrieb:
> Ich möchte mittels UDP kommunizieren
> Die Sockets auf beiden Seiten sind mit dem Port 3030 verbunden.

Das kann nicht sein. Sockets (Verbindungen) gibt es nur bei TCP.

UDP ist wie Postkarten bei der Deutschen Post. Du schickst ein UDP Paket 
irgendwohin und hoffentlich kommt es an. Vielleicht auch nicht. Du wirst 
es nie erfahren.

Das heißt, die Meldung "Destination unreachable (Port unreachable)" 
halte ich für unmöglich.

Zum Testen empfehle ich dir das Programm "netcat". Damit kannst du 
sowohl TCP als auch UDP in beide Richtungen testen. Beispiel:

In einem Fenster starte ich einen UDP Listener:

sfrings@stefanspc:~$ nc -l -u -p 3000

In einem anderen Fenster sende ich ein UDP Paket:

sfrings@stefanspc:~$ nc -u localhost 3000
Hallo

Ergebnis im ersten Fenster:

sfrings@stefanspc:~$ nc -l -u -p 3000
Hallo

Gegentest: Sende etwas an einen "falschen" Port:

sfrings@stefanspc:~$ nc -u localhost 3001
Möööp

Du bekommst keine Fehlermeldung. Das Paket landet im Nirvana. Das ist 
bei UDP so beabsichtigt.

Ich möchte nochmal auf meinen obigen Satz zurück kommen:
> Das kann nicht sein. Sockets (Verbindungen) gibt es nur bei TCP.

Bei der uIP Biblipthek (vom selben Author) wird der Begriff "connection" 
im Kontext von UDP missbraucht. Man tut so, als würde man eine 
Verbindung zu einem partner aufbauen. Tatsächlich hat man aber nur 
festgelegt, auf welchem Port man künftig etwas empfangen will, bzw. 
wohin man etwas Senden will. Das "öffnen" einer UDP Verbindung findet 
nur im RAM des Mikrocontrollers statt, dabei findet noch keine 
Kommunikation auf dem Kabel statt.

Mir ist klar, dass damit dein Problem nicht gelöst ist. Aber ich hoffe, 
dass diese Info dir hilft, das UDP Protokoll zu verstehen damit du das 
Problem gezielter weiter untersuchen kannst.

[c-hater (Gast)]

Stefan ⛄ F. schrieb:

> Das kann nicht sein. Sockets (Verbindungen) gibt es nur bei TCP.

Das stimmt natürlich nicht. Sockets sind zwar irgendwie schon 
"Verbindungen", aber nicht im Sinne einer TCP-Verbindung, wie du 
scheinbar glaubst.

Sockets sind eine Abstraktion und können dann Ausprägungen in 
verschiedene konkrete Typen haben. Such' einfach mal mit Google nach 
"SocketType" und staune, wieviele (durchaus verschiedene) Enumerationen 
du findest. Das zeigt ganz klar, dass dieses allgemeine Socket-Konzept 
in vielen Sprachen und Frameworks verwendet wird.

Bei lwip (um was es im Thread ging), heißt das ein wenig anders als 
üblich, aber es ist das gleiche Konzept wie üblich. Siehe sockets.c ab 
Zeile 158.

/* Socket protocol types (TCP/UDP/RAW) */
#define SOCK_STREAM     1
#define SOCK_DGRAM      2
#define SOCK_RAW        3

[c-hater (Gast)]

c-hater schrieb:

> üblich, aber es ist das gleiche Konzept wie üblich. Siehe sockets.c

Ist natürlich socket.h, nicht socket.c.

[Hmmm (Gast)]

Stefan ⛄ F. schrieb:
> Tom schrieb:
>> Ich möchte mittels UDP kommunizieren
>> Die Sockets auf beiden Seiten sind mit dem Port 3030 verbunden.
>
> Das kann nicht sein. Sockets (Verbindungen) gibt es nur bei TCP.
>
> UDP ist wie Postkarten bei der Deutschen Post. Du schickst ein UDP Paket
> irgendwohin und hoffentlich kommt es an. Vielleicht auch nicht. Du wirst
> es nie erfahren.
>
> Das heißt, die Meldung "Destination unreachable (Port unreachable)"
> halte ich für unmöglich.

Och Stefan...

Auch bei UDP unterscheidet der IP-Stack, ob auf dem jeweiligen Port 
etwas lauscht (was per bind() passiert), und wenn nicht, geht die o.g. 
ICMP-Message zurück.

$ echo "test" | nc -u 127.0.0.1 12345

16:48:13.581316 IP 127.0.0.1.55734 > 127.0.0.1.12345: UDP, length 5

16:48:13.581398 IP 127.0.0.1 > 127.0.0.1: ICMP 127.0.0.1 udp port 12345 
unreachable, length 41

Stefan ⛄ F. schrieb:
> Bei der uIP Biblipthek (vom selben Author) wird der Begriff "connection"
> im Kontext von UDP missbraucht. Man tut so, als würde man eine
> Verbindung zu einem partner aufbauen. Tatsächlich hat man aber nur
> festgelegt, auf welchem Port man künftig etwas empfangen will, bzw.
> wohin man etwas Senden will.

Da wird nichts missbraucht, so ist es im POSIX-Umfeld bei connect() 
auch:

https://pubs.opengroup.org/onlinepubs/009695399/functions/connect.html

Dort wird natürlich keine Verbindung im Sinne eines Handshakes 
hergestellt, sondern dafür gesorgt, dass zum einen per send() statt 
sendto() verschickte Pakete dort hingehen und zum anderen nur noch 
Pakete angenommen werden, die von dieser Gegenstelle kommen.

[Stefan F. (Gast)]

Ok, streichen wir die Sockets aus meiner Antwort.

Ich bleibe dabei, dass UDP keine Verbindungen kennt. Ob ein gesendetes 
Paket den Empfänger erreicht hat und ob der Empfänger empfangsbereit 
war, erfährt der Sender nicht. Es gibt da keinerlei Rückmeldung.

Die müsste man ggf. selbst auf Anwendungs-Ebene implementieren.

[TTL (Gast)]

Destination unreachable hört sich doch sehr nach IP an, also Layer 3. 
Kannst du das Ding überhaupt anpingen? Probier das erstmal, bevor du UDP 
ins Layer 4 schickst.

[Hmmm (Gast)]

TTL schrieb:
> Destination unreachable hört sich doch sehr nach IP an, also Layer 3.
> Kannst du das Ding überhaupt anpingen?

Type "Destination unreachable", Code "Port unreachable" und kommt von 
der Zieladresse.

Auf Layer 3 ist alles in Ordnung, der IP-Stack ist bloss der Meinung, 
dass auf diesem UDP-Port nichts lauscht.

Es wäre mal interessant zu wissen, was udp_bind() zurückliefert. Die 
momentane Fehlerbehandlung sieht ja noch eher rudimentär aus.

[Dergute W. (derguteweka)]

Moin,

Stefan ⛄ F. schrieb:
> Ich bleibe dabei, dass UDP keine Verbindungen kennt. Ob ein gesendetes
> Paket den Empfänger erreicht hat und ob der Empfänger empfangsbereit
> war, erfährt der Sender nicht.

Der Sender muss es nicht erfahren. Wenn aber der Netzwerkstack des 
Empfaengers "nett" ist, dann kann er sehr wohl dem Sender Bescheid 
sagen; es ist nicht verboten, dann ein entsprechendes ICMP wie im 
Wireshark im 1. Post sichtbar zurueckzuschicken...

Gruss
WK

[c-hater (Gast)]

Stefan ⛄ F. schrieb:

> Ok, streichen wir die Sockets aus meiner Antwort.

Besser ist das...

> Ich bleibe dabei, dass UDP keine Verbindungen kennt. Ob ein gesendetes
> Paket den Empfänger erreicht hat und ob der Empfänger empfangsbereit
> war, erfährt der Sender nicht. Es gibt da keinerlei Rückmeldung.

Natürlich ist das so. Deswegen halt "Datagram" und nicht "Stream". Das 
unterscheidet die beiden Socket-Typen. Aber es gibt trotzdem viele 
Gemeinsamkeiten. Auch bei der Benutzung. Genau deswegen war es ja 
sinnvoll, die Socket-Sache als eine gemeinsame Abstraktion einzuführen.

> Die müsste man ggf. selbst auf Anwendungs-Ebene implementieren.

Oder besser gleich TCP verwenden? Das existiert, ist gut durchgetestet 
und funktioniert.

[(prx) A. K. (prx)]

c-hater schrieb:
> Oder besser gleich TCP verwenden? Das existiert, ist gut durchgetestet
> und funktioniert.

Je nach Anwendung kann TCP auch nachteilig sein.

[c-hater (Gast)]

(prx) A. K. schrieb:

> Je nach Anwendung kann TCP auch nachteilig sein.

Natürlich. Wäre es nicht so, gäbe es UDP nicht. Aber wenn man die 
Eigenschaften von TCP will/braucht, dann ist es definitiv Schwachsinn, 
auf höherer Ebene was eigenes, auf UDP basierendes zu bauen, um das zu 
erreichen. Da nimmt man natürlich TCP.