Ich versuche ein UDP-Paket mit Boost asio zu empfangen. Mein Code basiert auf diesem blockierenden UDP-Client-Beispiel von die ASIO-Dokumentation .
Ich versuche, ein BOOTP-ähnliches UDP-Paket von einem C6655 TI DSP zu empfangen, die in 3-Sekunden-Intervallen übertragen werden. Ich habe Wireshark, der die gleiche Schnittstelle beobachtet, die mein Programm überwacht, und es kann die eingehenden Pakete sehen (siehe unten für die genauen Paketdaten, die von Wireshark exportiert wurden). Die Pakete kommen nicht wirklich vom DSP, ich habe eins mit tcpdump aufgenommen und ich simuliere es von einem Raspberry Pi mit packeth .
Mein Programm empfängt die Pakete jedoch nicht. Es hat einen Timeout von 4 Sekunden (da der DSP alle 3 Sekunden sendet). Wenn es das Zeitlimit erreicht, gibt es eine entsprechende Nachricht aus, andernfalls soll es die Anzahl der empfangenen Bytes drucken. Der vollständige (kompilierbare) Quellcode des Programms folgt (ungefähr 100 Zeilen).
Der Befehl wird mit den Parametern 192.168.5.122 67 4000 aufgerufen, was bedeutet, dass 192.168.5.122:67 mit einem Timeout von 4000 Millisekunden abgefragt wird.
Bearbeiten: Zusätzlich zu dem unten stehenden Code habe ich dies auch als meinen Endpunkt versucht: udp::endpoint listen_endpoint(boost::asio::ip::address_v4::any(), atoi(argv[2])); sowie die IP-Adresse 0.0.0.0 , wie von einem Suchergebnis irgendwo vorgeschlagen.
Ich fügte auch das Folgende ohne Erfolg hinzu:
%Vor%Ich habe ein Programm, das dieses Paket, das mit Berkeley-Sockets geschrieben wurde, richtig empfangen kann. Es macht nichts Besonderes, was ich sehen kann, abgesehen von der Bindung an INADDR_ANY.
Hier ist das komplette Programm:
%Vor%Hier ist das Paket, das ich erhalten möchte. Dies beinhaltet den Ethernet-Frame:
%Vor%Ich habe eine Berkeley-Socket-Implementierung, die dieses Paket empfangen kann (ich habe die Fehlerbehandlung und anderen misc. Code entfernt):
%Vor% Was passiert nach socket_.cancel() , sondern vor dem nächsten Aufruf von socket_.async_receive() ? Wenn Daten eintreffen, ist dem Socket kein "receive handler" zugewiesen. Wenn der Timer abläuft, wird run_once() dreimal aufgerufen (weil jedes async_wait() , expires_at() und einige andere die Stornierung bereits zugewiesener Handler verursachen und bewirken, dass die bereits zugewiesenen Handler zum Lauf hinzugefügt werden Warteschlange mit dem Fehlercode operation_aborted ).
Sie haben nicht erwähnt, auf was Ihr Timeout eingestellt ist. Das Beispiel, auf dem Sie Ihren Code basieren (der aus der Boost-Dokumentation), legt das Zeitlimit auf 10 Sekunden fest, Sie konfigurieren es jedoch. Wenn das Zeitlimit zu eng ist, würde dies zu einem Durchdrehen führen (den vorherigen & gt; Aufruf des vorherigen Handlers & gt; post- & gt; usw.) und möglicherweise socket_.cancel() aufrufen, während das Paket empfangen wird. Wenn das der Fall ist, müssten Sie nicht so weit gehen, um es mit einer Sendung zu testen. Sie könnten es auch mit einer Punkt-zu-Punkt-Verbindung sehen.
Bearbeiten : Während eines langen Timeouts (4000 ms) und Ihres genauen Codes konnte ich eine gesendete Übertragung empfangen. Ich musste "traditionelles" netcat installieren, weil BSD netcat defekt ist. Aber funktioniert die folgende Zeile :
%Vor%XXX.255 ist nicht wörtlich "XXX.255". Es ist meine lokale Broadcast-Adresse. Option -b in nc.bsd ist defekt (Sie können sehen, warum, wenn Sie nc.bsd mit obigen Optionen strace).
unix staplexchange nc.traditional hat ein gutes Beispiel dafür, wie andere herausgefunden haben, warum nc.bsd UDP-Broadcasts nicht tun kann (Option -b tut nichts).
PackEth war nicht in der Lage, Broadcasts oder p-t-p-Verkehr zu senden, also würde ich es nicht als Maß dafür verwenden, ob Sie Broadcast-Verkehr senden können. Zugegebenermaßen habe ich nicht viel Erfahrung damit, also weiß ich nicht ob es kaputt ist oder ob ich es nicht richtig konfiguriert habe.
Tags und Links c++ boost-asio udp