bin selber was in richtung lan-party-network management am basteln. jedoch verfolge ich einen GAAAANZ anderen ansatz --> somit kein merge moeglich (gibt auch keine page).
aber darum schreib ich hier nicht. hab mir mal den code ein wenig angeschaut und da ist mir was bezueglich dem dhcplog.sh aufgefallen.
so wie ich das dort sehe, startet ihr einen tcpdump welcher einfach die dhcp packete captured. das problem ist aber, dass bei einem geswitchten netzwerk keine solche packete von einem anderen server ankommen werden (es sei denn, man arbeitet mit billigen switches, dann ist es unter umstaenden moeglich).
was man also machen muss ist ein dhcp request schicke und diesen danach auswerten. die auswertung macht in eurem fall das tcpdump. fehlt also noch das verschicken eines requests.
ein bsp dazu wird unter ( http://www.informatik.uni-bremen.de/~mwiesner/ ) als perl script angeboten.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
grss dich, die problematik seh ich durchaus.
fr die sache gibts unter linux ja ein passendes tool - dhcping
damit kann ich wunderbar entsprechende dhcp anfragen abschicken und die antwort auswerten.
allerdings bringt das in dem fall nicht wirklich extrem viel, man kann davon ausgehen dass ein mitgebrachter dhcp server unter einer anderen ip-adresse luft und daher kann man nicht alle mglichen adressen durch-dhcping'en.
gleichzeitig ist es so dass man auf einem windows system welches die eigene adresse via dhcp empfngt keinen dhcp-server laufen lassen kann.
die einzig wirklich funktionierende variante wre alle mac-adresse aus dem traffic zu filtern und entsprechend an jede einzelne eine dhcping anfrage schicken, kommt eine adresse als antwort luft ein server, ansonsten passt's.
ich denke das wre dann was fr die nchste version.
das dhcp-problem lsst sich allerdings nie wirklich komplett lsen, sabotage gibt es leider und man kann sie nicht ganz ausschliessen.
bei einem normalen netzwerk (andrea server am hauptswitch) kann es allerdings nur alle teilnehmer an einem einzigen switch erwischen, alle anderen erhalten garantiert vom andrea server eine schnellere antwort!
an diesem switch sollte dann der schuldige auch recht schnell gefunden werden, zumeist handelt es sich ja um 12, 24 oder 32 mglichkeiten.
bisher hatten wir noch keinerlei probleme mit dhcp servern in unseren netzwerken, ich denke dass das problem auch mehr auf paranoia denn auf tatsachenberichten beruht :-)
vielen dank auf jeden fall dass du dich eingebracht hast, in der nchsten version werde ich den tcpdump entfernen - er hat sonst auch einen eher derben beigeschmack (wenn das interface kurz weg ist, dann ist auch der promiscuouse-mode aus und der tcpdump hinfllig...)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
dhcping testet nur, ob ein BESTIMTER server noch erreichbar ist. diesen gebe ich mit hilfe einer ip an. weiterhin stellt sich dabei wie du bereits angesprochen hast, das problem mit der ip.
mein angesprochener ansatz arbeitet jedoch nicht auf ip ebene.
ein normaler dhcp client sendet zuerst ein broadcast an die mac FF:FF:FF:FF:FF:FF mit der src seiner eigenen mac (dieses packet muss man kreieren und abschicken). danach schickt jeder dhcp server (und relays) im gleichen layer 2 netz eine antwort welche ein ip vorschlag beinhaltet. der dhcp client bearbeitet jedoch nur die erste antwort, aber mit hilfe von z.b. tcpdump kann man auch die anderen auswerten.
bezueglich deiner aussage, dass das problem nur an dem einen switch existieren wird, kann ich dir leider nicht recht geben (schon selbst erlebt). das netzwerk selbst sollte einiges schneller sein, als die antwort eines dhcp servers. es kommt also auf die reaktionszeit des dhcp servers an. wenn der andrea server mal irgendwas updated kann es durchaus sein, dass die antwort 5ms spaeter eintrifft und dies kann bereits zu spaet sein.
das problem mit dem tcpdump wird sich sicher loesen, sofern man nur die naechsten 5 sek (was vollkommen ausreicht) nach dem senden des "dummy packetes" auf dem netzwerkport lauscht. weiterhin muss ich dabei auch nicht im promiscuouse-mode sniffen (da das antwort packet des dhcp servers an mich gerichtet ist) was die cpu auch wieder ein wenig entlastet.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
ok, da hast du auch wieder recht dein ansatz ist da definitiv der bessere. ich spar's mir aber fr die nchste version auf! :-)
kann man nicht mit dhcping auch eine broadcast anfrage schicken? zumindest kann man das programm auch ohne angabe des zielservers starten, da msste es ja eigentlich dann broadcasten.
aber egal, wenn man da paket so schickt reicht das ja auch aus.
thx
grufo
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
bezueglich dem dhcping kann ich leider nicht aus erfahrung reden...hab mir nur schnell die manpage angeschaut und da ist die uebergabe der ip nicht in "[]" (optional). ev hast du ja eine aktuelle version.
"ich spar's mir aber fr die nchste version auf! :-)"
wollte auch nur mal drauf hinweisen...als enduser von andrea wuerde ich nicht auf die idee kommen, dass da doch noch unter umstaenden ein 2ter dhcp irgendwo im netz rumliegt (hab ja in meinem webinterface eine entsprechende anzeige). bei einem problem suche ich mich also zu tode :)
btw: eigentlich wollte ich euch ja mittels kontaktformular ( http://andrea.grufo.com/div/kontakt.php ) kontaktieren....scheint aber nicht zu funktionieren. haette da noch weitere infos/vorschlaege fuer euch.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
oh - danke fr den tip!
hab das formular bereits gefixt...
weitere anregungen sind gerne wilkommen, wie ich gesehen hab hast du auch ein smb-web-tool gebastelt - ich hab fr die zukunft geplant dass ich via andrea zumindest die links zu den entsprechenden freigaben der rechner zur verfgung stell - bzw. eine bersicht ber's netzwerk anzeige...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
das dhcpscan script ist ja echt gut, das ganze hat nur einen haken - es bentigt Net::RawIP und das wird bei suse nicht mitgeliefert!
da es ettliche lan's gibt die ohne internetverbindung arbeiten fllt ein nachtrglicher download leider flach.
und soweit ich das jetzt gecheckt hab baut sich Net::RawIP eine library fr das aktuelle system zusammen welche passen muss.
alles in allem macht das die integration in andrea praktisch unmglich, man msste da dann schon irgendwas bieten knnen mit dem die installation von Net:RawIP hnlich einfach wie die eines RPM pakets klappt.
die suche nach einer besseren lsung als tcpdump begleitet uns also doch noch eine weile...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
hallo zusammen.
bin selber was in richtung lan-party-network management am basteln. jedoch verfolge ich einen GAAAANZ anderen ansatz --> somit kein merge moeglich (gibt auch keine page).
aber darum schreib ich hier nicht. hab mir mal den code ein wenig angeschaut und da ist mir was bezueglich dem dhcplog.sh aufgefallen.
so wie ich das dort sehe, startet ihr einen tcpdump welcher einfach die dhcp packete captured. das problem ist aber, dass bei einem geswitchten netzwerk keine solche packete von einem anderen server ankommen werden (es sei denn, man arbeitet mit billigen switches, dann ist es unter umstaenden moeglich).
was man also machen muss ist ein dhcp request schicke und diesen danach auswerten. die auswertung macht in eurem fall das tcpdump. fehlt also noch das verschicken eines requests.
ein bsp dazu wird unter ( http://www.informatik.uni-bremen.de/~mwiesner/ ) als perl script angeboten.
grss dich, die problematik seh ich durchaus.
fr die sache gibts unter linux ja ein passendes tool - dhcping
damit kann ich wunderbar entsprechende dhcp anfragen abschicken und die antwort auswerten.
allerdings bringt das in dem fall nicht wirklich extrem viel, man kann davon ausgehen dass ein mitgebrachter dhcp server unter einer anderen ip-adresse luft und daher kann man nicht alle mglichen adressen durch-dhcping'en.
gleichzeitig ist es so dass man auf einem windows system welches die eigene adresse via dhcp empfngt keinen dhcp-server laufen lassen kann.
die einzig wirklich funktionierende variante wre alle mac-adresse aus dem traffic zu filtern und entsprechend an jede einzelne eine dhcping anfrage schicken, kommt eine adresse als antwort luft ein server, ansonsten passt's.
ich denke das wre dann was fr die nchste version.
das dhcp-problem lsst sich allerdings nie wirklich komplett lsen, sabotage gibt es leider und man kann sie nicht ganz ausschliessen.
bei einem normalen netzwerk (andrea server am hauptswitch) kann es allerdings nur alle teilnehmer an einem einzigen switch erwischen, alle anderen erhalten garantiert vom andrea server eine schnellere antwort!
an diesem switch sollte dann der schuldige auch recht schnell gefunden werden, zumeist handelt es sich ja um 12, 24 oder 32 mglichkeiten.
bisher hatten wir noch keinerlei probleme mit dhcp servern in unseren netzwerken, ich denke dass das problem auch mehr auf paranoia denn auf tatsachenberichten beruht :-)
vielen dank auf jeden fall dass du dich eingebracht hast, in der nchsten version werde ich den tcpdump entfernen - er hat sonst auch einen eher derben beigeschmack (wenn das interface kurz weg ist, dann ist auch der promiscuouse-mode aus und der tcpdump hinfllig...)
hallo
dhcping testet nur, ob ein BESTIMTER server noch erreichbar ist. diesen gebe ich mit hilfe einer ip an. weiterhin stellt sich dabei wie du bereits angesprochen hast, das problem mit der ip.
mein angesprochener ansatz arbeitet jedoch nicht auf ip ebene.
ein normaler dhcp client sendet zuerst ein broadcast an die mac FF:FF:FF:FF:FF:FF mit der src seiner eigenen mac (dieses packet muss man kreieren und abschicken). danach schickt jeder dhcp server (und relays) im gleichen layer 2 netz eine antwort welche ein ip vorschlag beinhaltet. der dhcp client bearbeitet jedoch nur die erste antwort, aber mit hilfe von z.b. tcpdump kann man auch die anderen auswerten.
bezueglich deiner aussage, dass das problem nur an dem einen switch existieren wird, kann ich dir leider nicht recht geben (schon selbst erlebt). das netzwerk selbst sollte einiges schneller sein, als die antwort eines dhcp servers. es kommt also auf die reaktionszeit des dhcp servers an. wenn der andrea server mal irgendwas updated kann es durchaus sein, dass die antwort 5ms spaeter eintrifft und dies kann bereits zu spaet sein.
das problem mit dem tcpdump wird sich sicher loesen, sofern man nur die naechsten 5 sek (was vollkommen ausreicht) nach dem senden des "dummy packetes" auf dem netzwerkport lauscht. weiterhin muss ich dabei auch nicht im promiscuouse-mode sniffen (da das antwort packet des dhcp servers an mich gerichtet ist) was die cpu auch wieder ein wenig entlastet.
ok, da hast du auch wieder recht dein ansatz ist da definitiv der bessere. ich spar's mir aber fr die nchste version auf! :-)
kann man nicht mit dhcping auch eine broadcast anfrage schicken? zumindest kann man das programm auch ohne angabe des zielservers starten, da msste es ja eigentlich dann broadcasten.
aber egal, wenn man da paket so schickt reicht das ja auch aus.
thx
grufo
bezueglich dem dhcping kann ich leider nicht aus erfahrung reden...hab mir nur schnell die manpage angeschaut und da ist die uebergabe der ip nicht in "[]" (optional). ev hast du ja eine aktuelle version.
"ich spar's mir aber fr die nchste version auf! :-)"
wollte auch nur mal drauf hinweisen...als enduser von andrea wuerde ich nicht auf die idee kommen, dass da doch noch unter umstaenden ein 2ter dhcp irgendwo im netz rumliegt (hab ja in meinem webinterface eine entsprechende anzeige). bei einem problem suche ich mich also zu tode :)
btw: eigentlich wollte ich euch ja mittels kontaktformular ( http://andrea.grufo.com/div/kontakt.php ) kontaktieren....scheint aber nicht zu funktionieren. haette da noch weitere infos/vorschlaege fuer euch.
oh - danke fr den tip!
hab das formular bereits gefixt...
weitere anregungen sind gerne wilkommen, wie ich gesehen hab hast du auch ein smb-web-tool gebastelt - ich hab fr die zukunft geplant dass ich via andrea zumindest die links zu den entsprechenden freigaben der rechner zur verfgung stell - bzw. eine bersicht ber's netzwerk anzeige...
das dhcpscan script ist ja echt gut, das ganze hat nur einen haken - es bentigt Net::RawIP und das wird bei suse nicht mitgeliefert!
da es ettliche lan's gibt die ohne internetverbindung arbeiten fllt ein nachtrglicher download leider flach.
und soweit ich das jetzt gecheckt hab baut sich Net::RawIP eine library fr das aktuelle system zusammen welche passen muss.
alles in allem macht das die integration in andrea praktisch unmglich, man msste da dann schon irgendwas bieten knnen mit dem die installation von Net:RawIP hnlich einfach wie die eines RPM pakets klappt.
die suche nach einer besseren lsung als tcpdump begleitet uns also doch noch eine weile...