Schrift
Start · Board · Anwendungen/Programme/Skripte in Perl · Netzwerkprogrammierung und Netzwerke mit Perl
[thread]4380[/thread]

Net::RawIP sucks...: Module, die es so nicht geben sollte

Leser: 1


<< >> 7 Einträge, 1 Seite
pearl-man
 2005-11-07 11:15
#36915 #36915
User since
2005-07-25
65 Artikel
BenutzerIn
[default_avatar]
Wollte etwas mit Net::RawIP rumspielen, doch das Modul ist meiner Meinung nach noch nicht so ausgereift. Von der wirklich mehr als schlechten Doku mal abgesehen, habe ich mit dem Modul noch nichts sinnvolles schreiben können. Beispiel:

Code: (dl )
1
2
3
4
5
6
7
8
#!/usr/bin/perl -w

use strict;
use Net::RawIP;
$a = new Net::RawIP({ip => {saddr => '10.1.2.60', daddr =>'10.1.2.70'},
                tcp => {source => 1234, dest => 80, syn => 1}});
$a->send(0, 3);
print "[FINISHED]\n";


habe den TCP-Traffic mit tcpdump migesnifft:

10:10:38.783338 IP5 bad-hlen 16 (erhalte ich für alle 3 Pakete)

auch reagiert der angesprochenen Host nicht mit einem SYN-ACK-Paket, wie er sollte erhält er solch ein SYN-Paket.

jemand Erfahrung mit dem Modul?
betterworld
 2005-11-07 14:52
#36916 #36916
User since
2003-08-21
2613 Artikel
ModeratorIn

user image
[quote=pearl-man,07.11.2005, 10:15]auch reagiert der angesprochenen Host nicht mit einem SYN-ACK-Paket, wie er sollte erhält er solch ein SYN-Paket.[/quote]
Bei mir geht es: Ich hab dein Skript mal ausprobiert (mit entsprechend geaenderten IP-Adressen), und es scheint zu funktionieren.

Hier ist die Ausgabe von tcpdump (ich hab mal den ersten Teil der IP-Adressen immer durch 42.42 ersetzt):
Code: (dl )
1
2
3
4
5
6
7
8
9
10
11
# tcpdump -i eth0 -vvn port 80
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
11:18:54.819724 IP (tos 0x10, ttl  64, id 0, offset 0, flags [DF], length: 40) 42.42.111.237.1234 > 42.42.111.138.80: S [tcp sum ok] 0:0(0) win 65535
11:18:54.819904 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], length: 44) 42.42.111.138.80 > 42.42.111.237.1234: S [tcp sum ok] 1786898179:1786898179(0) ack 1 win 5840 <mss 1460>
11:18:54.819961 IP (tos 0x0, ttl  64, id 7411, offset 0, flags [DF], length: 40) 42.42.111.237.1234 > 42.42.111.138.80: R [tcp sum ok] 1:1(0) win 0
11:18:54.820822 IP (tos 0x10, ttl  64, id 0, offset 0, flags [DF], length: 40) 42.42.111.237.1234 > 42.42.111.138.80: S [tcp sum ok] 0:0(0) win 65535
11:18:54.820942 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], length: 44) 42.42.111.138.80 > 42.42.111.237.1234: S [tcp sum ok] 1786899230:1786899230(0) ack 1 win 5840 <mss 1460>
11:18:54.820972 IP (tos 0x0, ttl  64, id 7412, offset 0, flags [DF], length: 40) 42.42.111.237.1234 > 42.42.111.138.80: R [tcp sum ok] 1:1(0) win 0
11:18:54.821828 IP (tos 0x10, ttl  64, id 0, offset 0, flags [DF], length: 40) 42.42.111.237.1234 > 42.42.111.138.80: S [tcp sum ok] 0:0(0) win 65535
11:18:54.821946 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], length: 44) 42.42.111.138.80 > 42.42.111.237.1234: S [tcp sum ok] 1786900236:1786900236(0) ack 1 win 5840 <mss 1460>
11:18:54.821981 IP (tos 0x0, ttl  64, id 7413, offset 0, flags [DF], length: 40) 42.42.111.237.1234 > 42.42.111.138.80: R [tcp sum ok] 1:1(0) win 0


Alles, wie es sein sollte: 111.237 schickt ein SYN los an 111.138, kriegt ein SYN|ACK zurueck, welches mit einem RST abgeschmettert wird, weil der Kernel nichts von dem Perlskript weiß. Das Ganze passiert dreimal, warum auch immer.

(Meine Modul-Version ist 0.1)
Lieblingsmodule: CPAN:IPC::System::Simple, CPAN:Path::Class
pearl-man
 2005-11-07 16:19
#36917 #36917
User since
2005-07-25
65 Artikel
BenutzerIn
[default_avatar]
habe Version 0.2, allerdings läuft die Sache unter OS X 10.3. Da RawIP ja nur ein Interface zu einigen libs herstellt könnte es auch damit zu tun haben, aber ???
Gast Gast
 2006-02-08 19:50
#36918 #36918
Meiner Meinung nach ist die einzig wirklich funktionale Moeglichkeit per Inline entsprechenden C-Code einzubauen.
Ist zwar dann eine Hybrid-Loesung und nicht ganz perl-ish, aber auf jeden Fall schlichtweg effektiver...

so far...
Nic
jmb
 2006-02-11 10:52
#36919 #36919
User since
2006-02-08
30 Artikel
BenutzerIn
[default_avatar]
Die Diskussion passt eigentlich ganz gut zu meiner aktuellen Problematik, daher haenge ich mich hier mal mit rein...

Ich habe massive Probleme mit den NetPacket Paketen beim neu-encoden von TCP / UDP packeten. Ansonsten funktionieren die Pakete eigentlich recht gut - aber sobald ich ein Paket decode, den Payload veraendere, die laenge neu berechne, zusammenbaue und losschicken will, "verliert" Netpacket die Paket ID. Auch bei Schleifendurchlaeufen "verlieren" Objekte Ihre Werte (sind jedoch noch gesetzt). Grausam...

Genug gejammert, nun zur Frage:
Hab Ihr einen Paket Tipp zum Encoden / Decoden von Paketen, das stabilerer laeuft als NetPacket? Habt Ihr eventuell interessante Links fuer mich? Ich nutze das ganze zusammen mit netfilter ipq (und schicke mir damit die Pakete ins Userland).

Sollte ich garnicht finden, muss ich wohl auf Inline C umsteigen, was ich eigentlich nicht wollte.

Danke im Voraus fuer hoffentlich viele gute Links ;)

Jmb
Gast Gast
 2006-06-27 18:27
#36920 #36920
Außer Net::RawIP reicht eigentliche pack() und unpack() aus um die Pakete zu encoden/decoden
pearl-man
 2006-06-29 18:51
#36921 #36921
User since
2005-07-25
65 Artikel
BenutzerIn
[default_avatar]
hats gefunzt??
<< >> 7 Einträge, 1 Seite



View all threads created 2005-11-07 11:15.