Schrift
Wiki:Tipp zum Debugging: use Data::Dumper; local $Data::Dumper::Useqq = 1; print Dumper \@var;
[thread]4455[/thread]

DHCP Client



<< >> 6 Einträge, 1 Seite
Gast Gast
 2007-02-22 16:09
#37475 #37475
Hallo Leute,

ich möchte mit Perl einen einfachen DHCP-Client zum testen schreiben aber ich komme da ein Problem.
Das Paket Net::DHCPClient bekomme ich nicht zum laufen (wahrscheinlich wegen Net::RawIP) also hab ich es mit Net::DHCP probiert.

Ich sende nun also ein DHCPDISCOVER und dann wartet das Script auf Antwort. Es kommt auch ein DHCPOFFER zurück aber das Script verarbeitet es nicht. Ich vermute, einfach, dass es bei recv() einfach eine andere IP erwartet, denn gesendet habe ich ja an 255.255.255.255 und die Antwort kommt von einer Host-IP (in meinem Fall dem Gateway, der die Nachricht vom DHCP-Server weitergeleitet hat).

Nun wollte ich halt einfach einen Socket für die Anfrage und einen horchenden für die Antwort nehmen aber beim erstellen des Antwort-Sockets bekomme ich immer einen Fehler:

listen: Unknown error at dhcp.pl line 32.

...nicht sehr Aussagekräfig.

Der Code für diesen Socket sieht so aus:
Code: (dl )
1
2
3
socket(Server, PF_INET, SOCK_DGRAM, 0) || die "socket: $!";
bind(Server, sockaddr_in(68, INADDR_ANY)) || die "bind: $!";
listen(Server, 5) || die "listen: $!";


Hat jemand eine Idee, was da falsch ist?
betterworld
 2007-02-22 16:15
#37476 #37476
User since
2003-08-21
2613 Artikel
ModeratorIn

user image
listen macht fuer UDP-Sockets keinen Sinn. Man kann von UDP-Sockets einfach per recv oder Diamond-Operator lesen, da muss man vorher nichts besonderes (wie listen) machen.
murphy
 2007-02-22 20:36
#37477 #37477
User since
2004-07-19
1776 Artikel
HausmeisterIn
[Homepage]
user image
[quote=Guest,22.02.2007, 14:09][...] Ich vermute, einfach, dass es bei recv() einfach eine andere IP erwartet, denn gesendet habe ich ja an 255.255.255.255 und die Antwort kommt von einer Host-IP (in meinem Fall dem Gateway, der die Nachricht vom DHCP-Server weitergeleitet hat). [...][/quote]
Einem UDP-Socket ist es völlig egal, von welcher IP Daten bei ihm ankommen, solange Du nicht mittels connect einen spezifischen Kommunikationspartner festgelegt hast.

edit: Selbst wenn der Socket connected ist, darf das beim Empfang höchstens dann einen Unterschied machen, wenn man recv statt recvfrom benutzt.\n\n

<!--EDIT|murphy|1172169686-->
When C++ is your hammer, every problem looks like your thumb.
betterworld
 2007-02-23 13:21
#37478 #37478
User since
2003-08-21
2613 Artikel
ModeratorIn

user image
[quote=murphy,22.02.2007, 19:36]edit: Selbst wenn der Socket connected ist, darf das beim Empfang höchstens dann einen Unterschied machen, wenn man recv statt recvfrom benutzt.[/quote]
Nein. Wenn man recv (bzw recvfrom mit NULL als erstes Argument) benutzt, bekommt man bei einem connected Socket immer nur Sachen von der Adresse, zu der man connected ist. Ich habe das auch gerade ausprobiert.
murphy
 2007-02-23 15:18
#37479 #37479
User since
2004-07-19
1776 Artikel
HausmeisterIn
[Homepage]
user image
Dann verhält sich da vielleicht Linux anders als MacOS X oder die BSD Manpages sind falsch. Auf meinem Notebook habe ich das zwar noch nicht getestet, die Manpage zu udp behauptet dort aber, dass connect nur auf recv nicht auf recvfrom einen Einfluss hat.
When C++ is your hammer, every problem looks like your thumb.
betterworld
 2007-02-23 15:22
#37480 #37480
User since
2003-08-21
2613 Artikel
ModeratorIn

user image
[quote=murphy,23.02.2007, 14:18]Dann verhält sich da vielleicht Linux anders als MacOS X oder die BSD Manpages sind falsch. Auf meinem Notebook habe ich das zwar noch nicht getestet, die Manpage zu udp behauptet dort aber, dass connect nur auf recv nicht auf recvfrom einen Einfluss hat.[/quote]
Sorry, ich habe Dich vorhin falsch gelesen...
Es hat natuerlich auf recvfrom nur dann einen Einfluss, wenn das erste Argument NULL ist, was dann äquivalent zu recv ist. In Perl gibt es allerdings kein recvfrom, auch wenn recv ueber recvfrom implementiert ist. Komisch
<< >> 6 Einträge, 1 Seite



View all threads created 2007-02-22 16:09.