Probleme mit Arduino Nano/ENC28J60 als UDP-Server

[Christian M. (Gast)]

Hallo Foraner!

Irgendwie stecke ich fest. Auf einem Arduino Nano V3.0 mit ENC28J60 über 
SPI läuft ein UDP-Server (wie: 
http://www.nikolaus-lueneburg.de/2015/01/arduino-udp-kommunikation/ nur 
etwas abgespeckt, siehe unten).

Ich erhalte Pakete, wenn ich vom Hauptrechner mit Hercules 
(http://www.hw-group.com/products/hercules/index_de.html), übrigens ein 
Superprogramm, Daten schicke. Aber von anderen Rechnern im Netz oder 
WiFi nicht.

Ich habe verschieden Ports ausprobiert, auch niedrigstellige. Alle 
Rechner sind im gleichen Subnetz, alles ist an einem D-Link Router 
angeschlossen, daran 2 Switches. Dem ENC habe ich auch schon IP zuweisen 
lassen.

Eigenartig ist, dass die Pakete am ENC/Aduino ankommen, die LED's 
blitzen auf. Es muss etwas an den Paketen sein, dafür habe ich mit 
Wireshark die Pakete analysiert, hier ein Paket, das ankommt:

Frame 1: 47 bytes on wire (376 bits), 47 bytes captured (376 bits) on interface 0
    Interface id: 0 (\Device\NPF_{A74DD738-DBC1-4916-B128-1E3215E667A7})
    Encapsulation type: Ethernet (1)
    Arrival Time: May  4, 2016 17:49:17.384593000 Osteurop�ische Sommerzeit
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1462373357.384593000 seconds
    [Time delta from previous captured frame: 0.000000000 seconds]
    [Time delta from previous displayed frame: 0.000000000 seconds]
    [Time since reference or first frame: 0.000000000 seconds]
    Frame Number: 1
    Frame Length: 47 bytes (376 bits)
    Capture Length: 47 bytes (376 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:ip:udp:data]
    [Coloring Rule Name: UDP]
    [Coloring Rule String: udp]
Ethernet II, Src: Shuttle_aa:07:94 (80:ee:73:aa:07:94), Dst: de:ad:be:ef:fe:ed (de:ad:be:ef:fe:ed)
    Destination: de:ad:be:ef:fe:ed (de:ad:be:ef:fe:ed)
        Address: de:ad:be:ef:fe:ed (de:ad:be:ef:fe:ed)
        .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Source: Shuttle_aa:07:94 (80:ee:73:aa:07:94)
        Address: Shuttle_aa:07:94 (80:ee:73:aa:07:94)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.1.157, Dst: 192.168.1.192
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 33
    Identification: 0x5f6d (24429)
    Flags: 0x00
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set
        ..0. .... = More fragments: Not set
    Fragment offset: 0
    Time to live: 128
    Protocol: UDP (17)
    Header checksum: 0x0000 [validation disabled]
        [Good: False]
        [Bad: False]
    Source: 192.168.1.157
    Destination: 192.168.1.192
    [Source GeoIP: Unknown]
    [Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: 36512 (36512), Dst Port: 36512 (36512)
    Source Port: 36512
    Destination Port: 36512
    Length: 13
    Checksum: 0x84cc [validation disabled]
        [Good Checksum: False]
        [Bad Checksum: False]
    [Stream index: 0]
Data (5 bytes)
    Data: 3132333435
    [Length: 5]

Für ein Packet, das nicht ankommt, vom Handy, sende ich es an den 
Rechner zu Hercules, damit ich es sehe:

Frame 1: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface 0
    Interface id: 0 (\Device\NPF_{A74DD738-DBC1-4916-B128-1E3215E667A7})
    Encapsulation type: Ethernet (1)
    Arrival Time: May  4, 2016 17:57:49.260766000 Osteurop�ische Sommerzeit
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1462373869.260766000 seconds
    [Time delta from previous captured frame: 0.000000000 seconds]
    [Time delta from previous displayed frame: 0.000000000 seconds]
    [Time since reference or first frame: 0.000000000 seconds]
    Frame Number: 1
    Frame Length: 60 bytes (480 bits)
    Capture Length: 60 bytes (480 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:ip:udp:data]
    [Coloring Rule Name: UDP]
    [Coloring Rule String: udp]
Ethernet II, Src: Mediatek_8b:e9:ce (00:0a:00:8b:e9:ce), Dst: Shuttle_aa:07:94 (80:ee:73:aa:07:94)
    Destination: Shuttle_aa:07:94 (80:ee:73:aa:07:94)
        Address: Shuttle_aa:07:94 (80:ee:73:aa:07:94)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Source: Mediatek_8b:e9:ce (00:0a:00:8b:e9:ce)
        Address: Mediatek_8b:e9:ce (00:0a:00:8b:e9:ce)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: IPv4 (0x0800)
    Padding: d34364373006995ab6b8336900
Internet Protocol Version 4, Src: 192.168.1.180, Dst: 192.168.1.157
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 33
    Identification: 0xa5db (42459)
    Flags: 0x02 (Don't Fragment)
        0... .... = Reserved bit: Not set
        .1.. .... = Don't fragment: Set
        ..0. .... = More fragments: Not set
    Fragment offset: 0
    Time to live: 64
    Protocol: UDP (17)
    Header checksum: 0x104f [validation disabled]
        [Good: False]
        [Bad: False]
    Source: 192.168.1.180
    Destination: 192.168.1.157
    [Source GeoIP: Unknown]
    [Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: 37914 (37914), Dst Port: 36512 (36512)
    Source Port: 37914
    Destination Port: 36512
    Length: 13
    Checksum: 0xbf10 [validation disabled]
        [Good Checksum: False]
        [Bad Checksum: False]
    [Stream index: 0]
Data (5 bytes)
    Data: 3132333435
    [Length: 5]

Die Unterschiede sind, soweit ich es feststellen kann, die Time-to-Live 
und das unterschiedliche Padding.

Kann im Router was verstellt sein?

Gruss Chregu

Arduino-Programm:

#include <SPI.h>
// #include <Ethernet.h>
// #include <EthernetUdp.h>
#include <UIPEthernet.h>

// Network Settings
byte mac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED };
IPAddress ip(192, 168, 1, 99);
IPAddress gateway(192, 168, 1, 1);
IPAddress subnet(255, 255, 255, 0);
#define UDP_TX_PACKET_MAX_SIZE 24

// Local UDP port to listen on
unsigned int localPort = 36512;

// Recipient IP
IPAddress RecipientIP(192, 168, 1, 157);

// Recipient UDP Port
unsigned int RecipientPort = 36512;

// Flag Buttonstate
char Buttonstate = 0;

// buffers for receiving and sending data
char packetBuffer[UDP_TX_PACKET_MAX_SIZE];

// An EthernetUDP instance to let us send and receive packets over UDP
EthernetUDP Udp;

void setup() {
  // start Ethernet und UDP
  Ethernet.begin(mac);  // ,ip
  Udp.begin(localPort);
  sendUDP("UDP Ready");

  Serial.begin(2400);
  Serial.print(Ethernet.localIP());
}

void loop()
{
  // if there's data available, read a packet
  int packetSize = Udp.parsePacket();
  if(packetSize)
  {
    Serial.println("Packet detektiert");
    // read the packet into packetBufffer
    Udp.read(packetBuffer, UDP_TX_PACKET_MAX_SIZE);
    
    // write packetBuffer to serial
    Serial.print("Packet Content: ");
    Serial.println(packetBuffer);
    
    // send "ACK" as reply
    Udp.beginPacket(Udp.remoteIP(), Udp.remotePort());
    Udp.write("ACK");
    Udp.endPacket();
  }
  delay(10);  
}


// Function zum Senden von UDP Packeten
void sendUDP(String text)
{
    Udp.beginPacket(RecipientIP, RecipientPort);
    // Udp.write("Test");
    Udp.print(text);
    Udp.endPacket();
    delay(10);
}

[Einer K. (Gast)]

Christian M. schrieb:
> Internet Protocol Version 4, Src: 192.168.1.157, Dst: 192.168.1.192

Christian M. schrieb:
> Internet Protocol Version 4, Src: 192.168.1.180, Dst: 192.168.1.157


Unterschiedliche Src hätte ich ja erwartet, aber unterschiedliche Dst?

Christian M. schrieb:
> IPAddress ip(192, 168, 1, 99);
Und wieder eine ganz andere Adresse....




Kein Wunder, dass es klemmt...

[Christian M. (Gast)]

Aber U.F., ich schrieb doch:

Christian M. schrieb:
> Für ein Packet, das nicht ankommt, vom Handy, sende ich es an den
> Rechner zu Hercules, damit ich es sehe:

Ich wollte das Paket sehen in Wireshark, wenn ich es direkt schicke, 
sieht es doch mein Rechner nicht.

Und:

Christian M. schrieb:
> Ethernet.begin(mac);  // ,ip

Darum habe ich vom DHCP-Server 192.168.1.192 bekommen. 192.168.1.157 ist 
der Rechner mit WS und 192.168.1.180 ist das Natel.

Gruss Chregu

[Jobst M. (jobstens-de)]

Wie wird die MAC-Adresse aufgelöst? ARP läuft?

Besorg Dir einen alten HUB (keinen Switch!)
Dort kannst Du an allen Ports allen Paketen lauschen.

Möglicherweise blinken Deine LEDs, weil die ARP-Pakete eintrudeln.
Beim PC funktioniert das dann wieder, der kann das.
Hast Du dem PC irgendwann mal die MAC-Adresse fest gegeben?

Gruß

Jobst

[Christian M. (Gast)]

Jobst M. schrieb:
> Wie wird die MAC-Adresse aufgelöst? ARP läuft?

Tut mir leid, kenne mich da zuwenig aus, wie kann ich das erfahren?
Habe dem ENC wieder fix .99 gegeben, vom Rechner ein Paket geschickt, 
kam prompt an, WS zeigt nichts ausser das Paket. Mit arp -a habe ich 
jetzt zwei Einträge mit der gleichen MAC, wie geht denn das? Wie sieht 
ein ARP-Paket aus?

> Besorg Dir einen alten HUB (keinen Switch!)
> Dort kannst Du an allen Ports allen Paketen lauschen.

Kacko, wo isser denn, hatte doch mal einen... Muss ich mir wieder zutun.

> Möglicherweise blinken Deine LEDs, weil die ARP-Pakete eintrudeln.
> Beim PC funktioniert das dann wieder, der kann das.
> Hast Du dem PC irgendwann mal die MAC-Adresse fest gegeben?

Momentan läuft der mit DHCP, sollte aber wieder feste Adresse bekommen, 
sobald ich wieder ein Konzept ausgearbeitet habe. Macht das evtl. einen 
Unterschied?

> Gruß
>
> Jobst

Gruss Chregu

Edit: Wieso braucht es ARP, kann das der Switch nicht machen? Bisher 
glaubte ich, sowas macht der Switch...

[Jobst M. (jobstens-de)]

Im Netzwerk kann ein Paket erst zugestellt werden, wenn die MAC-Adresse 
bekannt ist. Dazu schickt ein Rechner eine ARP-Anfrage mit der 
IP-Adresse ins Netz. (Ein Broadcast) Das Zielgerät antwortet mit seiner 
MAC-Adresse, dass es diese IP-Adresse hat:

Anfrage:
12:58:31.970037 arp who-has 192.168.0.1 tell 192.168.0.3
Antwort:
12:58:31.970118 arp reply 192.168.0.1 is-at 0F:ED:CB:24:7c:3e

Siehe auch arp bei Wikipedia.

Der Switch braucht die MAC-Adresse, um das Paket zum richtigen Port zu 
routen, daher notiert auch er sich diese Adressen. Dazu muss die Anfrage 
aber erst passieren.

Okay, dass eine neue IP nun auch diese MAC-Adresse trägt, spricht dafür, 
dass arp läuft. Sonst würde sie, vorausgesetzt, Du hast sie nicht von 
Hand eingetragen, nicht dort stehen.

DHCP spielt dafür keine Rolle.

Christian M. schrieb:
> WS zeigt nichts ausser das Paket

Dann kann WS das nicht anzeigen!? Wenn die MAC-Adresse durch einen 
vorherigen Versuch schon bekannt ist, wird natürlich nicht nochmal 
danach gefragt. Du müsstest vorher die ARP-Tabelle löschen.
Wenn Du sicher bist, dass ARP-Pakete geschickt werden, dann kann man 
weiter sehen.
Mit tcpdump unter Linux werden die Pakete sicher angezeigt.


Gruß

Jobst

[Christian M. (Gast)]

Jobst M. schrieb:
> Okay, dass eine neue IP nun auch diese MAC-Adresse trägt, spricht dafür,
> dass arp läuft. Sonst würde sie, vorausgesetzt, Du hast sie nicht von
> Hand eingetragen, nicht dort stehen.

Ja, vom Rechner geht's ja auch. Aber vom Telephon direkt zum ENC nicht, 
und das kann ich ja dann nur mit einem Hub testen. Aber selbst wenn ich 
es rausfinde, WAS finde ich dann raus, und wie behebe ich es? Den Hub 
muss ich mir erst besorgen.

> DHCP spielt dafür keine Rolle.

OK.

Jobst M. schrieb:
> Wenn Du sicher bist, dass ARP-Pakete geschickt werden, dann kann man
> weiter sehen.

Also wenn nur ARP-Pakete übertragen werden, habe ich ein Problem...?!

Danke für die Infos!

Chregu

Edit: Es ist mir aufgefallen, dass beim Senden vom Telephon an ALLEN 
Geräten im LAN die Act-LED aufblitzt. Kann das ein Hinweis sein, dass 
ARP-Pakete gesendet, aber nicht bestätigt werden?

[Jobst M. (jobstens-de)]

Christian M. schrieb:
> Also wenn nur ARP-Pakete übertragen werden, habe ich ein Problem...?!

Nein, nur wenn keine Antwort kommt.


> Edit: Es ist mir aufgefallen, dass beim Senden vom Telephon an ALLEN
> Geräten im LAN die Act-LED aufblitzt. Kann das ein Hinweis sein, dass
> ARP-Pakete gesendet, aber nicht bestätigt werden?

Beantwortet, nicht bestätigt.
Durchaus.

Wenn Du dem Arduiono eine neue IP gibst, welche Du vorher noch nicht 
verwendet hast und ihn dann vom PC ansprichst, dann geht es?

Das ist das, was mich noch etwas irritiert ...


Gruß

Jobst

[Christian M. (Gast)]

Hallo Jobst,

also ich habe mal .98 gegeben, ganz frisch :-)) Vom PC aus ein UDP-Paket 
geschickt, und siehe da: Alles klappt wie am Schnürchen:

187  21.366721  Shuttle_aa:07:94  Broadcast  ARP  42  Who has 192.168.1.98? Tell 192.168.1.157

188  21.367790  de:ad:be:ef:fe:ed  Shuttle_aa:07:94  ARP  60  192.168.1.98 is at de:ad:be:ef:fe:ed

189  21.367813  192.168.1.157  192.168.1.98  UDP  47  36512 → 36512  Len=5

In der ARP-Tabelle erscheint der neue Eintrag wie erwartet:

Schnittstelle: 192.168.1.157 --- 0xc
  Internetadresse       Physische Adresse     Typ
  192.168.1.1           00-15-e9-e2-38-ed     dynamisch 
  192.168.1.3           e8-ab-fa-80-c3-8a     dynamisch 
  192.168.1.51          00-11-32-03-11-79     dynamisch 
  192.168.1.91          10-1f-74-44-b9-dc     dynamisch 
  192.168.1.98          de-ad-be-ef-fe-ed     dynamisch 
  192.168.1.99          de-ad-be-ef-fe-ed     dynamisch 
  192.168.1.110         00-15-af-b5-fc-19     dynamisch 
  192.168.1.160         00-90-a9-e1-9e-9a     dynamisch 
  192.168.1.180         00-0a-00-8b-e9-ce     dynamisch

Aber jetzt wirds komisch:

Von einem zweiten Rechner schicke ich genau das gleiche paket mit 
Hercules. Der Eintrag wird in der ARP-Tabelle sogar gemacht, aber das 
Paket kommt nicht an!

Auch vom Handy kommt weiter nichts an, ausser das Flackern der LED.

Ich habe heute in allen Läden in der Stadt ein Hub gesucht, die Meisten 
wussten nicht mal, was das ist...

Nächste Woche bekomme ich einen vom anderen Ende des Landes...

Mit TCP hat immer alles wunderbar geklappt, irgendwo muss irgend etwas 
komisch sein, oder ich mache einen Denkfehler. Für meine Anwendung wäre 
UDP eben perfekt; nur Empfangen, macht nix wenn Pakete verloren gehen, 
wird weniger verzögert...

Gruss Chregu

[Jobst M. (jobstens-de)]

Christian M. schrieb:
> 188  21.367790  de:ad:be:ef:fe:ed  Shuttle_aa:07:94  ARP  60
> 192.168.1.98 is at de:ad:be:ef:fe:ed

Dieses Paket sagt: ARP geht. Denn es ist die Antwort auf die Frage.

Christian M. schrieb:
> Ich habe heute in allen Läden in der Stadt ein Hub gesucht, die Meisten
> wussten nicht mal, was das ist...

Nein, sowas baut man nicht mehr. Das ist altes Zeugs. Aber damit geht 
das eben einfach.

Kann es sein, dass eine Firewall im zweiten Rechner und dem Handy einen 
Zugriff auf diesen Port verhindern?

Was ist, wenn Du (Ziel-)Port 80 oder 53 benutzt?


Gruß

Jobst

[Christian M. (Gast)]

Jobst M. schrieb:

>> Ich habe heute in allen Läden in der Stadt ein Hub gesucht, die Meisten
>> wussten nicht mal, was das ist...
>
> Nein, sowas baut man nicht mehr. Das ist altes Zeugs. Aber damit geht
> das eben einfach.

Ja, ich weiss, ich habe die ja gefragt, ob sie noch sowas im Estrich 
rumliegen haben oder so. Ich hatte vor Jahren noch einen, neu, der ist 
warscheinlich damals dem Auswandern zum Opfer gefallen...
Jetzt schickt mir einer einen schönen alten ATI CentreCOM MR820TR im 
80er Look oder so. Der würde zu den USRobotics Modems passen, aber die 
sind auch weg...

> Kann es sein, dass eine Firewall im zweiten Rechner und dem Handy einen
> Zugriff auf diesen Port verhindern?
>
> Was ist, wenn Du (Ziel-)Port 80 oder 53 benutzt?

Ich habe jetzt von sämtlichen Rechnern, Telefonen und Tablets probiert, 
verschiedene Ports, aber es geht definitiv nur von diesem einen Rechner. 
Der Arduino/ENC sind per USB an eben Diesen angeschlossen, das hat doch 
keinen Einfluss!
Jetzt kann ich nur noch auf den Hub warten, oder wieder auf TCP zu 
wechseln...

Vielen Dank für Deine Hilfe! Gelernt habe ich viel in diesen Tagen!

Gruss Chregu

[Tiramisu (Gast)]

>Address: de:ad:be:ef:fe:ed (de:ad:be:ef:fe:ed)
>        .... ..1. .... .... .... .... = LG bit: Locally administered


Bitte mal 0x00 statt 0xde setzen! (Selbst wenn es das dann nicht ist,
ueber "locally administered MACs" ruempft jeder Netzwerkadmin die Nase,
dann ist es halt ein Schoenheitschange, wobei das willkuerliche Setzen
auch nicht das Ei des Kolumbus ist).

[Christian M. (Gast)]

Hallo Tiramisu,

bringt leider auch nichts, habe auch schon verschiedene MACs probiert. 
Bleibt immer gleich. Danke trotzdem!

Durch Zufall habe ich jetzt herausgefunden:

- Wenn das 1. Paket nach Reset vom Handy kommt, kommt es an, danach aber 
keines mehr, von gar keinem Rechner mehr.

- Von einem weiteren Rechner kommen alle Pakete an, nach einem Reset, 
aber nur noch von diesem Einen.

Also es ist jetzt so: Pakete kommen an, solange die IP-Adresse und der 
Local Port des Clienten dem ERSTEN Paket entsprechen, alles Andere kommt 
nicht an!
Leider schicken die von mir verwendeten UDP-Clients auf dem Smartphone 
immer zufällige Local-Ports im fünfstelligen Bereich.

Ist das im ESP oder Ethernet-Library so gewollt, oder ein Bug? Wenn das 
so normal ist, ist UDP für meine Anwendung nicht zu gebrauchen.

Gruss Chregu

[Tiramisu (Gast)]

>IPAddress ip(192, 168, 1, 99);

Welchen Range vergibt Dein DHCP-Server?

[Tiramisu (Gast)]

>IPAddress ip(192, 168, 1, 99);

Anders: Du bist sicher, dass die IP bei Dir nur einmal vergeben ist ;-)

[Tiramisu (Gast)]

>Hub

Falls Du ein Linux-System (und Netzwerkkarten) hast,
konfiguriere einen Switch siehe
https://help.ubuntu.com/community/NetworkConnectionBridge

und setze eine tcpdump auf das Bridgeinterface auf, am dem
der Arduino haengt. Das ist mindestens genauso gut wie ein Hub...

[Christian M. (Gast)]

Tiramisu schrieb:
> Welchen Range vergibt Dein DHCP-Server?

100-199. Alles under 100 vergeb ich manuell...

Tiramisu schrieb:
> Anders: Du bist sicher, dass die IP bei Dir nur einmal vergeben ist ;-)

Ja, 99 hat schon immer dem ESP gehört :-)) Wobei ich mittlerweile zur 
Sicherheit auch 98 und mit DHSP-Server verwendet habe -> keine 
Besserung...

Chregu

[Christian M. (Gast)]

Habe leider kein Linux. Warte jetzt mal auf den Hub...

Chregu

[Jobst M. (jobstens-de)]

Christian M. schrieb:
> Der Arduino/ENC sind per USB an eben Diesen angeschlossen, das hat doch
> keinen Einfluss!

Nein, sollte es eigentlich nicht. Aber das könntest Du ja ausprobieren.


> Jetzt kann ich nur noch auf den Hub warten, oder wieder auf TCP zu
> wechseln...

Wie, mit TCP geht es!? Das wäre eine wertvolle Info gewesen. Und mit 
meiner Info ...
Jobst M. schrieb:
> Im Netzwerk kann ein Paket erst zugestellt werden, wenn die MAC-Adresse
> bekannt ist.

... hätte es an dieser Stelle auch schon bei Dir klingeln müssen.


> Vielen Dank für Deine Hilfe! Gelernt habe ich viel in diesen Tagen!

Sehr gerne.

Ich bin nun gerade am knobeln, warum TCP gehen und UDP nicht gehen 
könnte.


Gruß

Jobst

[Jobst M. (jobstens-de)]

Christian M. schrieb:
> Leider schicken die von mir verwendeten UDP-Clients auf dem Smartphone
> immer zufällige Local-Ports im fünfstelligen Bereich.

Das sollte bei Clients -bis auf bei wenigen Ausnahmen- so sein.
Und wenn es wirklich zufällig und nicht aufzählend ist, ist das auch gut 
so!


Gruß

Jobst

[Christian M. (Gast)]

Jobst M. schrieb:
> Wie, mit TCP geht es!? Das wäre eine wertvolle Info gewesen.

Entschuldigung, tut mir leid, das war ich mir nicht bewusst.

Jobst M. schrieb:
> Ich bin nun gerade am knobeln, warum TCP gehen und UDP nicht gehen
> könnte.

Ja, gerade nochmal probiert: Einwandfrei von verschiedenen Clients. Und 
bei UDP wie schon beschrieben: Der Erste kommt durch!
Meinst Du, ich finde mit dem Hub noch was raus? Im Moment tippe ich eher 
drauf, dass im ENC/Library ein Bug ist.

Gruss Chregu

[Jobst M. (jobstens-de)]

Christian M. schrieb:
> Im Moment tippe ich eher drauf, dass im ENC/Library ein Bug ist.

Zumindest in der SW im Controller.
Ja, gehe ich auch mittlerweile von aus.


Gruß

Jobst

[Stefan F. (Gast)]

Statt Switch oder Hub könntest du den Mikrocontroller auch einfach mal 
direkt mit dem PC verbinden (gekreuztes Kabel evtl. nötig). Dann kannst 
du Netzwerk-Schnüffeltools verwenden.

Ich nutze Wireshark unter Linux und liebe an diesem Programm, dass es 
Fehler farblich hervorhebt.

[Christian M. (Gast)]

Ja muss ich nicht mal! Jetzt kann ich den Fehler ja simulieren vom PC 
aus:
WS ein und los:
- ein Paket schicken -> kommt an
- Local-Port am PC ändern
- noch ein Paket schicken -> kommt nicht an

Analyse zeigt: Beide Pakete werden korrekt und absolut identisch 
verschickt, bis auf den Local-Port!

Gruss Chregu

[Jobst M. (jobstens-de)]

Stefan U. schrieb:
> Statt Switch oder Hub könntest du den Mikrocontroller auch einfach mal
> direkt mit dem PC verbinden (gekreuztes Kabel evtl. nötig). Dann kannst
> du Netzwerk-Schnüffeltools verwenden.

Und wie lauscht er dann dem Verkehr von einem dritten Rechner!?

Stefan U. schrieb:
> Ich nutze Wireshark unter Linux und liebe an diesem Programm, dass es
> Fehler farblich hervorhebt.

Markiert es auch fehlende Pakete?

;-)

Gruß

Jobst

[Stefan F. (Gast)]

> Und wie lauscht er dann dem Verkehr von einem dritten Rechner!?
Gar nicht, ich dachte dabei daran, den selben PC als 
Kommunikationspartner zu verwenden.

> Wireshark ... Markiert es auch fehlende Pakete?
Das wäre cool, könnte man mal als Wunsch anmelden :-)

[Jobst M. (jobstens-de)]

Stefan U. schrieb:
> Gar nicht, ich dachte dabei daran, den selben PC als
> Kommunikationspartner zu verwenden.

Das ist aber sein Problem. Er wollte wissen, warum externe Pakete nicht 
beantwortet werden/ankommen. Mittlerweile ist das Problem aber schon 
eingekreist.


Gruß

Jobst