Tool um Ethernet frames zu erzeugen

[Ing. ET (Gast)]

Hallo,
ich suche ein Tool um ein Ethernet paket (beliebig, kein UDP oder TCP) 
zu erzeugen. Z.B. sowas

484406  8230.852310  00000000.0040681e13f5  00000000.ffffffffffff  IPX SAP  General Response


0000  ff ff ff ff ff ff 00 40  68 1e 13 f5 00 60 ff ff   .......@ h....`..
0010  00 60 00 04 00 00 00 00  ff ff ff ff ff ff 04 52   .`...... .......R
...
0060  00 00 00 00 00 40 68 1e  13 f5 40 0c 00 01         .....@h. ..@...

Ich habe bei netcat nachgeschaut, aber anscheinend kann man nur 
IP-Pakete verschicken.
Weiss jemand eine Lösung? Es soll unter Windows XP laufen.

Danke und Gruß, Ing. ET

[Klaus W. (mfgkw)]

Ein fertiges Programm zum Aufrufen kenne ich nicht, aber wenn du Ing. ET 
bist und etwas programmieren kannst, geht es wahrscheinlich besser mit 
einem selbstgebauten Programm.

Unter Linux zumindest sind sogenannte "raw packets at the device driver 
(OSI Layer 2) level" wahrscheinlich das, was du suchst.
Siehe man 7 packet
Windows-Äquivalent kenne ich nicht, aber vielleicht erleichtert es die 
Suche.
Wenn es dort ähnlich gemacht ist, geht die Suche wohl mit der Doku zu 
den Win32-Sockets los.

[Jörg W. (dl8dtl) (Moderator)]

http://de.wikipedia.org/wiki/TUN/TAP

[Andreas (Gast)]

Hallo,

ich habe so was schon mal mit WinPcap oder mit den NDIS Protocol Drivern 
gemacht.

WinPcap ist relativ einfach zu programmieren, allerdings auch langsam, 
wenn man viel senden/empfangen muß. Die NDIS Protocol Driver waren nach 
meiner Beobachtung etwa um Faktor 3 schneller.

Gegenstelle war ein AtMega644.

Grüsse,
Andreas

[Klaus W. (mfgkw)]

Jörg Wunsch schrieb:
> http://de.wikipedia.org/wiki/TUN/TAP

Hilft das?

Mit TAP kann ich eine Ethernetkarte simulieren und den
darüber liegenden Schichten vorgaukeln.
Aber er hat die reale Karte und will damit Pakete schicken.

Abgesehen davon ist das auch nicht näher an Windows dran als mein 
Vorschlag :-)
PS: der letzte Satz war Quark, das scheint es auch für Windows zu geben.

[Jörg W. (dl8dtl) (Moderator)]

Klaus Wachtler schrieb:

> Mit TAP kann ich eine Ethernetkarte simulieren und den
> darüber liegenden Schichten vorgaukeln.

Ja, sieht so aus, als würde das nur für die andere Richtung gehen.

OK, war nur'n Versuch. ;-)

[Andreas (Gast)]

Na ja, Virtual Tunnels over TCP/IP networks ist für diesen Zweck etwas 
durch die Brust ins Auge.

Wenn man Wireshark am Laufen hat, hat man die PCap libraries sowieso 
schon installiert, und dann sind die paar Zeilen um ein 
pcap_sendpacket() zu implementieren auch nicht der Rede wert.

Und einen  NDIS Protocol Driver zu entwickeln ist auch nicht unbedingt 
nötig, solange man das Microsoft example NDISProt (Windows Driver Kit) 
benutzt.

Will man beliebige MAC Adressen verwenden, muß im Header noch 
NDIS_PACKET_TYPE_PROMISCUOUS für promiscuous mode reading modifiziert 
werden und der Treiber neu kompiliert werden.

Die Applikation setzt dann auf die jeweiligen Treiber auf.

Diese beiden Methoden sind eigentlich die mir bekannten üblichen 
Strategien.

[Andreas (Gast)]

P.S. Anmerkung: Für die Windows Welt gesprochen ... (*X ausgenommen)

[Jürgen W. (lovos)]

Ich habe jpcap installiert und habe ein Prograemmchen in Java 
geschrieben. Das ging recht straight-forward.

http://netresearch.ics.uci.edu/kfujii/jpcap/doc/javadoc/index.html

[Reto B. (schnuber)]

Andreas schrieb:
> Hallo,
>
> ich habe so was schon mal mit WinPcap oder mit den NDIS Protocol Drivern
> gemacht.
>
> WinPcap ist relativ einfach zu programmieren, allerdings auch langsam,
> wenn man viel senden/empfangen muß. Die NDIS Protocol Driver waren nach
> meiner Beobachtung etwa um Faktor 3 schneller.
>
> Gegenstelle war ein AtMega644.
>
> Grüsse,
> Andreas

Was für einen Datendurchsatz erreicht man den mit den jeweiligen 
Methoden (WinPcap, NDIS). Ich habe eine Gigabit Ethernet schnittstelle 
und möchte damit mit der gleichen Methode wie unser Startautor  Ing. ET 
(Gast) daten darüber streamen. Mindestens 30 MB/s sollte hanfhabbar 
sein.

[hans (Gast)]

realterm

[Andreas (Gast)]

Schnuber B. schrieb:
> Was für einen Datendurchsatz erreicht man den mit den jeweiligen
> Methoden (WinPcap, NDIS). Ich habe eine Gigabit Ethernet schnittstelle
> und möchte damit mit der gleichen Methode wie unser Startautor  Ing. ET
> (Gast) daten darüber streamen. Mindestens 30 MB/s sollte hanfhabbar
> sein.

Zum Datendurchsatz kann ich Dir leider nichts allgemeingültiges sagen. 
Ich habe die jeweiligen Implementierungen im Rahmen von LAN-Bootloadern 
verwendet. Nachdem da seitenweise ins Flash geschrieben, CRC-Vergleiche 
vorgenommen und Protokollchecks durchgeführt werden, könnte man da nur 
einen absoluten E2E-Durchsatz messen, der sehr von der Performance des 
uCs und der Bootloader-Applikation + Protokoll abhängig ist (Blockgröße, 
Multipages, etc). Ich habe versucht den Bootloader auf unter 4k zu 
bringen, daher auch die RAW-Ethernet-Methode mit proprietärem 
Lightweight-Protokoll(gelandet bin ich dann bei etwa 3 kB).

Nachdem ich mit den PCAP Libs angefangen habe und ich zum Test einen 
644er geflasht habe, hatte ich Zeiten im Minutenbereich für den gesamten 
Flashinhalt (abzüglich Bootloader).

Das lag vor allem nicht an den Sendezeiten, sondern durch hohe Latenz 
beim Empfang innerhalb des PCap-Stacks.

Nachdem mein Bootloader-Client objektorientiert aufgebaut ist, habe ich 
den PCap-Stack gegen einen NDIS-Stack getauscht und lag so unter einer 
Minute.

D.h. hier war in etwa der Faktor 3 in der Performance zu sehen. Für 
meine Bootloader-Tests war diese Aussage ausreichend (insbesondere da 
die Engines dennoch softwaremäßig umschaltbar sind).

Bei Deinen angestrebten 30MB/s sollte zunächst mal definiert werden, von 
was gesprochen wird. Brutto-Durchsatz, Netto-Durchsatz, Datenrichtung, 
Protokollaufbau (Blockgrösse, Handshaking, Verbindungsart).

Möchtest Du ein eigenes Schicht 3 Protokoll entwerfen oder Dich an einen 
Standard halten ?

Wenn Du in diesen Parametern frei bist, kannst Du hier natürlich auf 
Performance optimieren, so wie ich im Rahmen des Bootloaders auf 
Programsize optimiert habe.

Ich schätze mal, daß bei Verwendung von NDIS der Flaschenhals für 30MBit 
sicher nicht im Treiber, bzw. der PC-Protokollimplementierung liegt.