Ubuntu - nach Stromausfall DSL-Zugang verloren

[Fitje Claasen]

moin,

gibt es ein einfaches Vorgehen, wie man Ubuntu wieder ins Netz bringt -
ähnlich vielleicht wie bei Win, per Neustart?

Ich hatte U im Ruhezustand und dann ist Strom ausgefallen.
Wenn ich jetzt boote, kommt U nicht mehr ins WWW, auch nicht
mehr an die Fritz-Box (an der kleinen Torte oben rechts sind 3rote
Punkte ...) - eben auch nach Neustart nicht.

Hat U die Zugangsdaten eliminiert???

Dank für Hilfen und Tipps,
Gruß Fitje

[Burkhard Ott]

On Fri, 16 Dec 2011 22:54:02 +0100, Fitje Claasen wrote:

> gibt es ein einfaches Vorgehen, wie man Ubuntu wieder ins Netz bringt -

Ja.

> ähnlich vielleicht wie bei Win, per Neustart?

Das hilft sicherlich auch nicht bei Windows.

> Ich hatte U im Ruhezustand und dann ist Strom ausgefallen.

Deshalb hat man UPS' erfunden (hat nochts mit Paketen zu tuen).

> Wenn ich
> jetzt boote, kommt U nicht mehr ins WWW, auch nicht mehr an die
> Fritz-Box (an der kleinen Torte oben rechts sind 3rote Punkte ...) -
> eben auch nach Neustart nicht.

Sowas kommt hin und wieder mal vor.

Hat denn Dein Rechner eine IP?

> Hat U die Zugangsdaten eliminiert???

Eher weniger.

cheers

[Arno Lutz]

Fitje Claasen schrieb:

>gibt es ein einfaches Vorgehen, wie man Ubuntu wieder ins Netz bringt - ähnlich
>vielleicht wie bei Win, per Neustart?

also unter KDE und OpenSuse dürfte ein "kdesu rcnetwork restart" helfen.
Sicher gibts für Ubuntu ähnliches.
Probier mal in Konsole (Xterm?) "sudo rcnetwork restart".


Gruß
Arno

--
Die Arbeit wird von den Mitarbeitern erledigt, die ihre Stufe der Inkompetenz noch
nicht erreicht haben.

[Fitje Claasen]

hi Burkhard,
> ...

>
> Hat denn Dein Rechner eine IP?

also Geräte > Netzwerkdiagnose:
da gibts die IPv4 mit 127.0.0.1. Bei IPv6 steht ::1

ping-Urls werden nit gefunden.

in "der Torte" oben rechts, unter "Verbindungen bearbeiten >
Netzwerkverbindungen", steht nix, kein Eintrag.


jammas
>>...

[Fitje Claasen]

hi Arno,
> ...

> also unter KDE und OpenSuse dürfte ein "kdesu rcnetwork restart" helfen.
> Sicher gibts für Ubuntu ähnliches.
> Probier mal in Konsole (Xterm?) "sudo rcnetwork restart".

ich habe wohl Gnome.

Danke. Checke ich, wenn ich wieder drüben bin ...

Gruß, Fitje
>
>
> ...
>

[Burkhard Ott]

On Sat, 17 Dec 2011 00:28:37 +0100, Fitje Claasen wrote:

> hi Burkhard,
>> ...
>>
>> Hat denn Dein Rechner eine IP?
> also Geräte > Netzwerkdiagnose:
> da gibts die IPv4 mit 127.0.0.1. Bei IPv6 steht ::1

Dann bekomst Du keine IP von Deiner FritzBox. Ich nehme mal an dort
laeuft Dein DHCP.
Schau mal ins Handbuch welche auf welche IP die die nach drinnen horcht,
setze Dir eine statische IP aus dem gleiche subnet auf Deinem Rechner und
Du kansst auf diese drauf, sieht so aus als hat diese ein Problem.

> ping-Urls werden nit gefunden.

Haeh, was sind denn Ping-URL's, ich kenne ping und bilde mir ein zu
wissen was eine URL ist, darum ergibt dieser Satz keinen Sinn fuer mich,
ist aber uch nicht wichtig.

> in "der Torte" oben rechts, unter "Verbindungen bearbeiten >
> Netzwerkverbindungen", steht nix, kein Eintrag.

Was weiss ich was Du fuer eine Torte auf Deinem Rechner hast, mach ne
console auf und rufe ipconfig oder ip sh addr auf, das zeigt an was Du
wissen must.

cheers

[Heiko Nocon]

Fitje Claasen wrote:

>Ich hatte U im Ruhezustand und dann ist Strom ausgefallen.

Im Ruhezustand ist ein Stromausfall völlig irrelavant, weil das Gerät
ohnehin ausgeschaltet ist. Du meinst also vermutlich den
Bereitschaftszustand.

>Wenn ich jetzt boote, kommt U nicht mehr ins WWW, auch nicht
>mehr an die Fritz-Box

[...]

>Hat U die Zugangsdaten eliminiert???

Wenn du über einen Router in Internet gehst, brauchst du auf dem
Client-Rechner keine Zugangsdaten. Es sei denn, die Ankopplung erfolgt
per WLAN. Wenn das so ist, hättest du es bei einer qualifizierten
Fehlerbeschreibung erwähnen sollen.

Und ja: bei einem erzwungenen Abbruch ohne sauberes Herunterfahren
können im Prinzip beliebige Daten verloren gehen. Auch WLAN-Zugangsdaten
natürlich.

>Dank für Hilfen und Tipps,

Tipp: Qualifizierte Fragestellungen umfassen im Minimum auch die
relevanten Logs oder die Augaben einschlägiger Analyse-Kommandos. Mit
irgendwelchen Punkten und Torten kann niemand etwas anfangen.

[Thomas Hochstein]

Heiko Nocon schrieb:

> Fitje Claasen wrote:
>
>> Ich hatte U im Ruhezustand und dann ist Strom ausgefallen.
>
> Im Ruhezustand ist ein Stromausfall völlig irrelavant, weil das Gerät
> ohnehin ausgeschaltet ist. Du meinst also vermutlich den
> Bereitschaftszustand.

Die Fehlerbeschreibung läßt als Möglichkeit auch offen, daß die
Fritz-Box den Stromausfall nicht gut vertragen hat (und daher DHCP und
ggf. DNS-Auflösung nicht funktionieren).

-thh

[Fitje Claasen]

...

>
> Danke. Checke ich, wenn ich wieder drüben bin ...
>

>...
so, ich war eben in Ubuntu:
sudo rcnetwork restart
ergab "natürlich"
"command not found"
mal schauen, obs was äquivalentes für Ub./Gnome gibt ...
G.F.

[Fitje Claasen]

Hi Burkhard , Danke
> ... Dann bekomst Du keine IP von Deiner FritzBox.
es ist doch n Hammer, dass sich Ub. so sahnemäßig installieren lässt und
jetzt während des Betriebs so einen "Aufstand" macht ...
wenn sich Ub das (Net-Zugang) beim Install. alles selbst zieht, ... wo
ist denn jetzt das Problem?

> Ich nehme mal an dort
> laeuft Dein DHCP.

? ... auf alles Fälle eine FB und die läuft, glaube ich, als Router.

> Schau mal ins Handbuch welche auf welche IP die die nach drinnen horcht,

also mir ist die 127er und eine 198er (IPs) bekannt.

> setze Dir eine statische IP aus dem gleiche subnet auf Deinem Rechner und
> Du kansst auf diese drauf, sieht so aus als hat diese ein Problem.

weiß nicht, was du meinst.

>
>> ping-Urls werden nit gefunden.
>
> Haeh, was sind denn Ping-URL's,

tja - ne hergenommene Url, an die ich ein ping schicke


> ...
>
>> ...

>
> Was weiss ich was Du fuer eine Torte auf Deinem Rechner hast,

ja - für Leute die Ubuntu und Gnome laufen haben.
Bei Mobils/handys ist das das Zeichen für WLAN.
Es ist so ne viertel Torte - 1/4 von 3-4 konzentrischen Ringen ...

> mach ne
> console auf und rufe ipconfig oder ip sh addr auf, das zeigt an was Du
> wissen must.

ipconfig gibt es nicht ...
(ip sh addr) hatte ich jetzte übersehen #| ... probier ich ...



>
> ...
G.F.

[Fitje Claasen]

> ipconfig gibt es nicht ...

ifconfig ergab:
lo Link encap:Lokale Schleife
inet Adresse:127.0.0.1 Maske:255.0.0.0
inet6-Adresse: ::1/128 Gültigkeitsbereich:Maschine
UP LOOPBACK RUNNING MTU:16436 Metrik:1
RX packets:108 errors:0 dropped:0 overruns:0 frame:0
TX packets:108 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:0
RX bytes:11161 (11.1 KB) TX bytes:11161 (11.1 KB)
>...

[Fitje Claasen]

Hallo Heiko,
> ...

> Im Ruhezustand ist ein Stromausfall völlig irrelavant, weil das Gerät
> ohnehin ausgeschaltet ist. Du meinst also vermutlich den
> Bereitschaftszustand.

nein, es war - wohl der Anfang vom - Ruhezustand.
Vielleicht war Ub noch nicht ganz drin?

>
>> Wenn ich jetzt boote, kommt U nicht mehr ins WWW, auch nicht
>> mehr an die Fritz-Box
> [...]
>> Hat U die Zugangsdaten eliminiert???
>
> Wenn du über einen Router in Internet gehst, brauchst du auf dem
> Client-Rechner keine Zugangsdaten.

ich hatte die zu meinem Provider ja vorher auch nicht eingegeben.
Die stehen in der FritzBox und die funkt. - hier mit Win - wie gehabt.

> Es sei denn, die Ankopplung erfolgt
> per WLAN.

per Kabel an die FB.


Gibts nicht so ein kleinen sudo-recover-command,
der den Zugang wieder herzaubert? (dachte ich ...)

> ...
>> ...
Gruß, Fitje

[Patrick Schueller]

Am 17.12.2011 22:03, schrieb Fitje Claasen:
>> Es sei denn, die Ankopplung erfolgt
>> per WLAN.
> per Kabel an die FB.
>
>
> Gibts nicht so ein kleinen sudo-recover-command,
> der den Zugang wieder herzaubert? (dachte ich ...)

1) Wenn Windows mit dem Router ins Netz kann und Ubuntu das vorher auch
konnte, liegt es eher nicht am Router. Auch wenn Du lieber ein
"magisches sudo-Kommand" hättest, würde ich erstmal unter Gnome
nachschauen, was der Network-Manager dazu sagt. Wenn das nicht geht,
kann man immer noch die Konsole bemühen. Das Folgende ist leider nur von
der ubuntuusers-Seite, da ich hier KDE habe, wo es zwar ähnlich, aber im
Detail anders ist.
Klick auf Networkmanager-Icon: Ist ein Häkchen bei [x] Netzwerk aktivieren?

Wenn es daran nicht lag, mal "Edit connections" aufrufen und unter
http://wiki.ubuntuusers.de/NetworkManager#Kabelgebundene-Verbindung
schauen. Es muss eine kabelgebundene Verbindung existieren ("Wired
connection" bzw "Auto eth0"), siehe
http://media.cdn.ubuntu-de.org/wiki/attachments/21/43/nm-einstellungen-wired.png
Als Verbindungsmethode unter "IPv4 Settings" muss "Automatisch (DHCP)"
ausgewählt sein.

2) Wenn das nicht geht, ggf. doch über die Konsole:

Erster Versuch mit einem "magischen" sudo-Kommando:

sudo dhclient


3) Zweiter Versuch (länger), wenn obiges nicht klappt:

Vorausgesetzt, die Info von oben mit dem Anfang Deiner Adresse
(192.168...) ist richtig (127.0.0.1 ist der localhost, der nützt hier
nichts), geht es für den Moment so:

sudo ifconfig eth0 192.168.x.y
sudo route add default gw 192.168.x.z

x, y und z findest Du so heraus:

Schau auf dem Windows-Rechner, der ins Netz kann, die Ausgabe von
"ipconfig /all" für die Netzwerkverbindung zu der Fritzbox an.

Aus der Zeile "IPv4-Adresse" nimmst Du folgende Zahlen:
x muss die gleiche Zahl sein wie bei der IP-Adresse des
Windows-Rechners, y muss eine andere Zahl von 0-255 sein (Adresse darf
in Deinem Netz noch nicht vergeben sein, die mit derselben Zahl hat ja
schon der Windowsrechner).

z entspricht der Zahl, die Windows bei "Standardgateway" angibt.

Das Ganze habe ich hier als "notnetz.sh", falls DHCP mal nicht geht.

Eine der Methoden (hoffentlich die erste) sollte funktionieren, sofern
nichts Ernstes an Ubuntu und/oder dem Router kaputtgegangen ist.

Gruß, Patrick
--
OS: Linux Mint Xfce Edition · Kernel: 3.1.0-1-amd64 · KDE: 4.7.2 (4.7.2)
CPU: AMD Turion(tm) Dual-Core Mobile ZM-82 · RAM: 491748kB/3803212kB
VGA: ATI RS780M/RS780MN [Mobility Radeon HD 3200] / ATI Mobility Radeon
HD 3400

[Arno Lutz]

Fitje Claasen schrieb:

>> Im Ruhezustand ist ein Stromausfall völlig irrelavant, weil das Gerät
>> ohnehin ausgeschaltet ist. Du meinst also vermutlich den
>> Bereitschaftszustand.
>nein, es war - wohl der Anfang vom - Ruhezustand.
>Vielleicht war Ub noch nicht ganz drin?

mir hat an nem anderen PC auch schon mal geholfen einfach (bei laufendem PC)
Netzstekcer(nicht der Strom.. sondern LAN!) raus und wieder einstecken.
Das System erkennt die Hardware aufs Neue und sollte sie eigentlich richtig
aktivieren.
Vielleicht gibt das deinem Ubuntu den nötigen Schubser.

[Michael Paul]

On 17.12.2011, Fitje Claasen wrote:


>> Wenn du über einen Router in Internet gehst, brauchst du auf dem
>> Client-Rechner keine Zugangsdaten.
> ich hatte die zu meinem Provider ja vorher auch nicht eingegeben.
> Die stehen in der FritzBox und die funkt. - hier mit Win - wie gehabt.

Gleicher Rechner?
Fall nein, dann teste bitte eine Live-CD/DVD/USB. Nicht, daß der
Stromausfall für das Ableben der Netzwerkkarte verantwortlich zu machen
wäre.

Michael
--
Ja sind wir hier auf'm Fussballplatz, oder was?

[Fitje Claasen]

Hi Michael,
> ...
> Gleicher Rechner?
ja.
>...
G.F.

[Fitje Claasen]

Hi Patrick,

Super! Danke! Hat mit dem 1. Versuch geklappt.
Wichtige Befehle ... :)
- wobei ich den 2x gemacht habe

sudo dhclient
Internet Systems Consortium DHCP Client V3.1.3
Copyright 2004-2009 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth0/00:18:f3:13:ca:fb
Sending on LPF/eth0/00:18:f3:13:ca:fb
Sending on Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3
DHCPOFFER of 192.168.178.20 from 192.168.178.1
DHCPREQUEST of 192.168.178.20 on eth0 to 255.255.255.255 port 67
DHCPACK of 192.168.178.20 from 192.168.178.1
bound to 192.168.178.20 -- renewal in 409552 seconds.
---
There is already a pid file /var/run/dhclient.pid with pid 1855
killed old client process, removed PID file
Internet Systems Consortium DHCP Client V3.1.3
Copyright 2004-2009 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth0/00:18:f3:13:ca:fb
Sending on LPF/eth0/00:18:f3:13:ca:fb
Sending on Socket/fallback
DHCPREQUEST of 192.168.178.20 on eth0 to 255.255.255.255 port 67
DHCPACK of 192.168.178.20 from 192.168.178.1
bound to 192.168.178.20 -- renewal in 369421 seconds.



da hat Ub die FB IP wieder 192.168.178.20 ...



Ich hatte zuvor vorm booten auch das Netzkabel aus dem PC
gezogen und als Ubuntu "da war" reingesteckt.
Das hatte aber nichts geholfen.
> ...
>>>...
Gruß, Fitje

[Dieter Schultheis]

Nach einem Stromausfall haben sich bei mir ein älterer analoger Sat
Receiver und der Router verabschiedet. Dem PC und dem Netbook (Akku war
ausgebaut) hat das "harte Ausschalten" nichts ausgemacht, obwohl das OS
hochgefahren war.

Kann dein Router denn noch mit einem anderen OS / Computer genutzt werden?

Mal mit einem Live Linux wie Knoppix (von CD) getestet?

Ein iso Image zum brennen einer "Live CD" findet man kostenfrei unter
www.knoppix.de bzw. www.knopper.net/knoppix

Für Geräten ohne CD/DVD Laufwerk (intern ext, USB) kann man Knoppix auch
als UPSB Version erhalten / auf dem Stick installieren.

--

MfG
Dieter

[Burkhard Ott]

On Sat, 17 Dec 2011 21:51:57 +0100, Fitje Claasen wrote:

> Hi Burkhard , Danke
>> ... Dann bekomst Du keine IP von Deiner FritzBox.
> es ist doch n Hammer, dass sich Ub. so sahnemäßig installieren lässt und
> jetzt während des Betriebs so einen "Aufstand" macht ... wenn sich Ub
> das (Net-Zugang) beim Install. alles selbst zieht, ... wo ist denn jetzt
> das Problem?
>
>
>> Ich nehme mal an dort
>> laeuft Dein DHCP.
> ? ... auf alles Fälle eine FB und die läuft, glaube ich, als Router.

Dynamic Host Protocol (DHCP), ist der service der Deinem Rechner eine IP
plus dns und rounting informationen verpasst,falls korrekt configuriert,
wenn Dein Client einen Request via arp broadcast ins angeschlossen Netz
bruellt.

>> Schau mal ins Handbuch welche auf welche IP die die nach drinnen
>> horcht,
> also mir ist die 127er und eine 198er (IPs) bekannt.
>
>
>
>> setze Dir eine statische IP aus dem gleiche subnet auf Deinem Rechner
>> und Du kansst auf diese drauf, sieht so aus als hat diese ein Problem.
> weiß nicht, was du meinst.

e.g.

FB IP: 192.168.1.1/24
Client: 192.168.1.2/24

Schon bist Du im gleichen Subnetz und kannst mit der FB 'quatschen'.

>>> ping-Urls werden nit gefunden.
>>
>> Haeh, was sind denn Ping-URL's,
> tja - ne hergenommene Url, an die ich ein ping schicke

Noe, das hat nichts mit ICMP echo request's zu tuen.

Wenn Dein DNS nicht funktioniert, bedeuted das nicht das Du nich im
selben Netz Daten rumschicken kannst, hast halt keinen Namen was eher
unerheblich ist wenn man payload loswerden will.

>> Was weiss ich was Du fuer eine Torte auf Deinem Rechner hast,
> ja - für Leute die Ubuntu und Gnome laufen haben. Bei Mobils/handys ist
> das das Zeichen für WLAN. Es ist so ne viertel Torte - 1/4 von 3-4
> konzentrischen Ringen ...

Und? Ausser das ich jetzt Hunger bekommen habe und zum Baecker gehe, hat
das nix zu bedueten.

>> mach ne
>> console auf und rufe ipconfig oder ip sh addr auf, das zeigt an was Du
>> wissen must.
> ipconfig gibt es nicht ...

Gibts unter jeden Linux, Ubuntu macht sicherlich viel Bleodsinn aber das
Canonical ipconfig aus der default Installation rausnimmt, halte ich eher
fuer unwahrscheinlich.
( /sbin/ipconfig )

cheers

[Juergen Ilse]

Hallo,

Burkhard Ott <news...@derith.de> wrote:
> On Sat, 17 Dec 2011 21:51:57 +0100, Fitje Claasen wrote:
>> Hi Burkhard , Danke

>>> mach ne
>>> console auf und rufe ipconfig oder ip sh addr auf, das zeigt an was Du
>>> wissen must.
>> ipconfig gibt es nicht ...

"ipconfig" gibt es unter Windows. Unter Linux ist es mir noch nue begegnet.

> Gibts unter jeden Linux, Ubuntu macht sicherlich viel Bleodsinn aber das
> Canonical ipconfig aus der default Installation rausnimmt, halte ich eher
> fuer unwahrscheinlich.
> ( /sbin/ipconfig )

---------------
ilse@ubuntu:~$ ls /sbin/ip*
/sbin/ip /sbin/ip6tables-save /sbin/iptables-restore
/sbin/ip6tables /sbin/ipmaddr /sbin/iptables-save
/sbin/ip6tables-multi /sbin/iptables /sbin/iptunnel
/sbin/ip6tables-restore /sbin/iptables-multi
ilse@ubuntu:~$
---------------

Gibt es hier nicht (Ubuntu 11.10). Oder meintest du evt. "/sbin/ifconfig"?

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname ist nur ein Name, nicht mehr und nicht weniger.
Wer mehr hineininterpretiert, hat das Domain-Name-System nicht
verstanden.

[Burkhard Ott]

On Mon, 19 Dec 2011 21:59:48 +0000, Juergen Ilse wrote:

> Hallo,
>
> Burkhard Ott <news...@derith.de> wrote:
>> On Sat, 17 Dec 2011 21:51:57 +0100, Fitje Claasen wrote:
>>> Hi Burkhard , Danke
>>>> mach ne
>>>> console auf und rufe ipconfig oder ip sh addr auf, das zeigt an was
>>>> Du wissen must.
>>> ipconfig gibt es nicht ...
>
> "ipconfig" gibt es unter Windows. Unter Linux ist es mir noch nue
> begegnet.

yep, ich meine ifconfig. Da ich mit nur ip hantiere... naja geraet es in
Vergessenheit.

> Gibt es hier nicht (Ubuntu 11.10). Oder meintest du evt.
> "/sbin/ifconfig"?

ln -s /sbin/ifconfig /sbin/ipconfig, siehste nun hastes ja.

cheers

[Christoph 'Mehdorn' Weber]

Hallo!

* Burkhard Ott <news...@derith.de>:

Hat mein Debian auch nicht, bzw. nur in /usr/lib/klibc/bin
(Paket klibc-utils), aber das hat normalerweise niemand einfach
so im Suchpfad. Meinst du möglicherweise "ifconfig" oder "ip"?
Die beiden gibt es hingegen häufiger.

Christoph

--
Kino ohne Popcorn ist wie Salz ohne Suppe.
(Volker Birk)

[Christoph 'Mehdorn' Weber]

Hallo!

* Burkhard Ott <news...@derith.de>:

> On Sat, 17 Dec 2011 00:28:37 +0100, Fitje Claasen wrote:

>> ping-Urls werden nit gefunden.
> Haeh, was sind denn Ping-URL's

Ich hätte jetzt auf ping://127.0.0.1/payload oder dergleichen
getippt, aber im Gegensatz zu "news:", "nntp:", "mailto:",
"telnet:" etc. finde ich dazu tatsächlich auf Anhieb kein RFC.

Aber ich behaupte nicht, daß ich übermäßig gründlich gesucht
hätte.

[Thomas 'PointedEars' Lahn]

Burkhard Ott wrote:

> On Sat, 17 Dec 2011 21:51:57 +0100, Fitje Claasen wrote:
>>> ... Dann bekomst Du keine IP von Deiner FritzBox.
>> es ist doch n Hammer, dass sich Ub. so sahnemäßig installieren lässt und
>> jetzt während des Betriebs so einen "Aufstand" macht ... wenn sich Ub
>> das (Net-Zugang) beim Install. alles selbst zieht, ... wo ist denn jetzt
>> das Problem?
>>
>>> Ich nehme mal an dort
>>> laeuft Dein DHCP.
>> ? ... auf alles Fälle eine FB und die läuft, glaube ich, als Router.
>
> Dynamic Host Protocol (DHCP), ist der service der Deinem Rechner eine IP

^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> plus dns und rounting informationen verpasst,falls korrekt configuriert,

^^^^^^^^^^^^

> wenn Dein Client einen Request via arp broadcast ins angeschlossen Netz
> bruellt.

JFTR:

- Dynamic Host _*C*onfiguration_ Protocol
- IP-_Adresse_
- _DNS- und Routing-Information(en)_
- _ARP_ (Adress Resolution Protocol) findet auf dem Link Layer statt und
hat AFAICS nicht zwingend etwas mit DHCP (Application Layer) zu tun.

<http://en.wikipedia.org/wiki/DHCP#DHCP_discovery>

--
PointedEars

Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[Burkhard Ott]

On Tue, 20 Dec 2011 19:30:19 +0100, Thomas 'PointedEars' Lahn wrote:

> Burkhard Ott wrote:
>> Dynamic Host Protocol (DHCP), ist der service der Deinem Rechner eine
>> IP
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> plus dns und rounting informationen verpasst,falls korrekt
>> configuriert,
>
^^^^^^^^^^^^
>> wenn Dein Client einen Request via arp broadcast ins angeschlossen Netz
>> bruellt.
>
> JFTR:
>
> - Dynamic Host _*C*onfiguration_ Protocol - IP-_Adresse_

Und? Gut habs C vergessen, funktioniert es nun anders?

> - _DNS- und Routing-Information(en)_

Der Client bekommt eine IP, eine Subnetmask und eins std gateway, das
sind die routing Informationen die er braucht. (alles ausserhalb des
subnets geht zum std gateway).
Plus einen oder mehrere DNS (optional), damit kann der namen zu IP's
aufloesen. Was willst Du mir sagen?

> - _ARP_ (Adress Resolution Protocol) findet auf dem Link Layer statt und
> hat AFAICS nicht zwingend etwas mit DHCP (Application Layer) zu tun.

dest ip 255.255.255.255 == MAC ff:ff:ff:ff:ff:ff

Ohne arp kein IP (ipv4 only).

cheers

[Thomas 'PointedEars' Lahn]

Burkhard Ott wrote:

> On Tue, 20 Dec 2011 19:30:19 +0100, Thomas 'PointedEars' Lahn wrote:
>> Burkhard Ott wrote:
>>> Dynamic Host Protocol (DHCP), ist der service der Deinem Rechner eine
>>> IP
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> plus dns und rounting informationen verpasst,falls korrekt
>>> configuriert,
>>
> ^^^^^^^^^^^^
>>> wenn Dein Client einen Request via arp broadcast ins angeschlossen Netz
>>> bruellt.
>>
>> JFTR:
>>
>> - Dynamic Host _*C*onfiguration_ Protocol - IP-_Adresse_
>
> Und? Gut habs C vergessen, funktioniert es nun anders?

So ist der Name _korrekt_.

>> - _DNS- und Routing-Information(en)_
>
> Der Client bekommt eine IP, eine Subnetmask und eins std gateway, das
> sind die routing Informationen die er braucht. (alles ausserhalb des
> subnets geht zum std gateway).
> Plus einen oder mehrere DNS (optional), damit kann der namen zu IP's
> aufloesen. Was willst Du mir sagen?

Dass Du in Deinen "Erklärungen" mindestens schludrig mit Orthographie und
(was gravierender ist) Terminologie umgehst. Zum Beispiel: IP ist das
Internet Protocol. Der Client bekommt durch den DHCP-Server u. a. eine IP-
_Adresse_, und Hostnamen werden per DNS zu IP-_Adressen_ aufgelöst.

>> - _ARP_ (Adress Resolution Protocol) findet auf dem Link Layer statt und
>> hat AFAICS nicht zwingend etwas mit DHCP (Application Layer) zu tun.
>
> dest ip 255.255.255.255 == MAC ff:ff:ff:ff:ff:ff

Wie bitte?

> Ohne arp kein IP (ipv4 only).

Für DHCP-Discovery wird (AFAICS) vom DHCP-Client _kein_ ARP-Paket versendet,
sondern (bei IPv4) ein UDP-Paket mit Zieladresse 255.255.255.255. Es findet
also _kein_ "arp broadcast" statt, sondern ein _IP_-Broadcast.

ARP *kann* (bzw. SOLLTE) *zusätzlich* vom Client benutzt werden, *nachdem*
er eine IP-Adresse erhalten hat (nach DHCP ACK, wieder ein UDP-Paket), um
durch überlappende Adresspools von DHCP-Servern verursachte IP-Adressen-
Konflikte zu vermeiden.

[Burkhard Ott]

On Wed, 21 Dec 2011 13:03:01 +0100, Thomas 'PointedEars' Lahn wrote:

>>> JFTR:
>>>
>>> - Dynamic Host _*C*onfiguration_ Protocol - IP-_Adresse_
>>
>> Und? Gut habs C vergessen, funktioniert es nun anders?
>
> So ist der Name _korrekt_.
>
>>> - _DNS- und Routing-Information(en)_

Gut und schoen, funktioniert deshalb auch nicht anders.

>
>> Der Client bekommt eine IP, eine Subnetmask und eins std gateway, das
>> sind die routing Informationen die er braucht. (alles ausserhalb des
>> subnets geht zum std gateway).
>> Plus einen oder mehrere DNS (optional), damit kann der namen zu IP's
>> aufloesen. Was willst Du mir sagen?
>
> Dass Du in Deinen "Erklärungen" mindestens schludrig mit Orthographie
> und (was gravierender ist) Terminologie umgehst. Zum Beispiel: IP ist
> das Internet Protocol. Der Client bekommt durch den DHCP-Server u. a.
> eine IP- _Adresse_, und Hostnamen werden per DNS zu IP-_Adressen_
> aufgelöst.

Ah ja.

>>> - _ARP_ (Adress Resolution Protocol) findet auf dem Link Layer statt
>>> und
>>> hat AFAICS nicht zwingend etwas mit DHCP (Application Layer) zu tun.
>>
>> dest ip 255.255.255.255 == MAC ff:ff:ff:ff:ff:ff
>
> Wie bitte?

Wie willst Du es anders abbilden, moege der Onkel Lehrer mal den Traffic
sniffen.

Das funktionierte schon so bei Token Ring.

>> Ohne arp kein IP (ipv4 only).
>
> Für DHCP-Discovery wird (AFAICS) vom DHCP-Client _kein_ ARP-Paket
> versendet, sondern (bei IPv4) ein UDP-Paket mit Zieladresse
> 255.255.255.255. Es findet also _kein_ "arp broadcast" statt, sondern
> ein _IP_-Broadcast.

Auf IP Layer ja, welches ohne arp nicht funktioniert, Du musst wenn Du
einen solchen IP broadcast sendest alle Bits setzen.

> ARP *kann* (bzw. SOLLTE) *zusätzlich* vom Client benutzt werden,
> *nachdem* er eine IP-Adresse erhalten hat (nach DHCP ACK, wieder ein
> UDP-Paket), um durch überlappende Adresspools von DHCP-Servern
> verursachte IP-Adressen- Konflikte zu vermeiden.

Ohne arp hast Du kein IP in Deinem Netz, an den Endpoints funktioniert es
nicht anders nur kommt da Deine MAC nicht durch sondern die des Routers.

cheers

[Burkhard Ott]

On Wed, 21 Dec 2011 13:03:01 +0100, Thomas 'PointedEars' Lahn wrote:

>>> - _ARP_ (Adress Resolution Protocol) findet auf dem Link Layer statt
>>> und
>>> hat AFAICS nicht zwingend etwas mit DHCP (Application Layer) zu tun.
>>
>> dest ip 255.255.255.255 == MAC ff:ff:ff:ff:ff:ff
>
> Wie bitte?

http://tools.ietf.org/html/rfc826

Dann musst Du keinen sniffer anwerfen.

cheers

[Thomas 'PointedEars' Lahn]

Burkhard Ott wrote:

> On Wed, 21 Dec 2011 13:03:01 +0100, Thomas 'PointedEars' Lahn wrote:
>>> Ohne arp kein IP (ipv4 only).
>>
>> Für DHCP-Discovery wird (AFAICS) vom DHCP-Client _kein_ ARP-Paket
>> versendet, sondern (bei IPv4) ein UDP-Paket mit Zieladresse
>> 255.255.255.255. Es findet also _kein_ "arp broadcast" statt, sondern
>> ein _IP_-Broadcast.
>
> Auf IP Layer ja, welches ohne arp nicht funktioniert, Du musst wenn Du
> einen solchen IP broadcast sendest alle Bits setzen.

Du schuldest mir 15 Minuten Freizeit.

Mir ist durchaus klar, dass man (bei IPv4) ARP dazu braucht. Dennoch halte
ich es für verfehlt, hier von einem "ARP-Broadcast" zu sprechen bzw. die
Verwendung von ARP zu betonen (auch weil ARP protokollabhängig ist, DHCP
hingegen nicht).

ARP-Broadcasts werden benutzt, um die MAC-Adresse der Kiste zu ermitteln,
die eine bestimmte IP (allgemeiner: Protokoll)-Adresse hat, damit man dann
an sie zielgerichtet (Ethernet-)Pakete senden kann. Das geht auch aus dem
RFC hervor.

Darum geht es aber bei DHCP gar nicht. Stattdessen sollen *alle* *DHCP-
Server*, die sich zuständig fühlen, dem DHCP-Client sagen, dass sie da sind
(DHCPOFFER), damit der anschliessend einige oder alle von diesen nach einer
Protokolladresse fragen kann (DHCPREQUEST). Die eigentliche Kommunikation
findet hier auf höheren Protokollebenen statt: der DHCP-Client sendet am
Anfang einen *IP*-Broadcast, ein UDP-Paket (DHCPDISCOVER), ins Netz.

[Burkhard Ott]

On Wed, 21 Dec 2011 18:49:16 +0100, Thomas 'PointedEars' Lahn wrote:

> Burkhard Ott wrote:
>
>> On Wed, 21 Dec 2011 13:03:01 +0100, Thomas 'PointedEars' Lahn wrote:
>>>> Ohne arp kein IP (ipv4 only).
>>>
>>> Für DHCP-Discovery wird (AFAICS) vom DHCP-Client _kein_ ARP-Paket
>>> versendet, sondern (bei IPv4) ein UDP-Paket mit Zieladresse
>>> 255.255.255.255. Es findet also _kein_ "arp broadcast" statt, sondern
>>> ein _IP_-Broadcast.
>>
>> Auf IP Layer ja, welches ohne arp nicht funktioniert, Du musst wenn Du
>> einen solchen IP broadcast sendest alle Bits setzen.
>
> Du schuldest mir 15 Minuten Freizeit.

Und Du Nerven.

>
> Mir ist durchaus klar, dass man (bei IPv4) ARP dazu braucht. Dennoch
> halte ich es für verfehlt, hier von einem "ARP-Broadcast" zu sprechen
> bzw. die Verwendung von ARP zu betonen (auch weil ARP protokollabhängig
> ist, DHCP hingegen nicht).

Was ist denn ff:ff:ff:ff:ff:ff, sieht genau wie ein Broadcast aus, gelle.
Um einen IP Broadcast (egal ob 255.255.255.255 oder 1.1.1.255/24) zu
senden *MUSST* Du alle Bits setzen, jetzt klar?

> ARP-Broadcasts werden benutzt, um die MAC-Adresse der Kiste zu
> ermitteln, die eine bestimmte IP (allgemeiner: Protokoll)-Adresse hat,
> damit man dann an sie zielgerichtet (Ethernet-)Pakete senden kann. Das
> geht auch aus dem RFC hervor.

Noe, dann solltest Du nochmal lesen. Es kann und wird zur Ermittlung der
IP Herangezogen, generell werde alle IP Broadcasts auf ff:ff:ff:ff:ff:ff
abgebildet, wie willst Du z.Bsp. einem switch sagen 'msg geht an alle im
Netz', mit 2 einigartigen MAC's schaltet der nur 2 Ports zusammen (darum
sind eigentlich Namen wie Layer 3 oder IP switch quark). Ein Broadcast
geht an alle Ports raus und jeder Client fuehlt sich angesprochen, ergo
kann ich schon herausfinden wieviele und welchen Clienten im Netz sind
ohne IP ueberhaupt zu sprechen.

> Darum geht es aber bei DHCP gar nicht. Stattdessen sollen *alle* *DHCP-
> Server*,

i.d.R. der authoritative, falls es mehr als einen gibt.

> die sich zuständig fühlen, dem DHCP-Client sagen, dass sie da
> sind (DHCPOFFER), damit der anschliessend einige oder alle von diesen
> nach einer Protokolladresse fragen kann (DHCPREQUEST). Die eigentliche
> Kommunikation findet hier auf höheren Protokollebenen statt: der
> DHCP-Client sendet am Anfang einen *IP*-Broadcast, ein UDP-Paket
> (DHCPDISCOVER), ins Netz.

Das bezweiflelte ich nie, der broadcast auf layer 2 bleibt jedoch
trotzdem. Wenn Du also auf IP 255.255.255.255 adressierst ist das nunmal
ff:ff:ff:ff:ff:ff und so wird Dein 'payload' uebermittelt. btw. IP hat
keine ports die gehoeren zu TCP und UDP.

cheers

[Juergen Ilse]

Hallo,

Burkhard Ott <news...@derith.de> wrote:

> On Wed, 21 Dec 2011 13:03:01 +0100, Thomas 'PointedEars' Lahn wrote:
>>>> - _ARP_ (Adress Resolution Protocol) findet auf dem Link Layer statt
>>>> und
>>>> hat AFAICS nicht zwingend etwas mit DHCP (Application Layer) zu tun.
>>> dest ip 255.255.255.255 == MAC ff:ff:ff:ff:ff:ff

Auch wenn es ungewoehnlich waere koennte man auch auf einem PPP-Link
mit einem /30 IPv4 Transfernetz die Adresse fuer ein Ende der Verbin-
dung von der anderen Seite aus per DGCP vergeben (ja, ich weiss, dass
das ueblicherweise eher per IPCP gemacht wird, aber DHCP waere auch
moeglich). Nun hast du aber auf dem PPP-Link weder Ethernet-MAC-Adressen
noch Link-Layer-Broadcasts noch ARP, wohl aber IP-Broadcasts und DHCP.
Die Welt ist etwas groesser als deine Ntzwerl-Erfahrung mit Ethernet.

>> Wie bitte?
> Wie willst Du es anders abbilden, moege der Onkel Lehrer mal den Traffic
> sniffen.

Mankann z.B. IP auch auf PPP-Links oder in Frame-Relaynetzen betreiben
(und so etwas wird sogar getan), aber beide Netzwerktopologien sind
"NBMA" (non-Broadcast-multi-Access).

> Das funktionierte schon so bei Token Ring.

Und was soll uns das sagen?

>>> Ohne arp kein IP (ipv4 only).

Wozu sollte man z.B. auf einem Poimz-zo-Point-Ethernetlink mit /31
Netzmaske (siehe RFC3021) arp benoetigen? Oder auf einem PPP-Link?
oder in einem ATM-Netz (mit IP over ATM Encapsulation gemaess RFC1483)?
Oder ...

>> Für DHCP-Discovery wird (AFAICS) vom DHCP-Client _kein_ ARP-Paket
>> versendet, sondern (bei IPv4) ein UDP-Paket mit Zieladresse
>> 255.255.255.255. Es findet also _kein_ "arp broadcast" statt, sondern
>> ein _IP_-Broadcast.
> Auf IP Layer ja, welches ohne arp nicht funktioniert,

Ich habe bereits ein paar Beispiele genannt, in denen IP ohne ARP
funktioniert ...

> Du musst wenn Du einen solchen IP broadcast sendest alle Bits setzen.

Du setzt offenbar Layer2-Broadcasts voraus, obwohl IP auch ohne das
funktionieren wuerde (und auch in manchen Umgebungen so funktioniert).

>> ARP *kann* (bzw. SOLLTE) *zusätzlich* vom Client benutzt werden,
>> *nachdem* er eine IP-Adresse erhalten hat (nach DHCP ACK, wieder ein
>> UDP-Paket), um durch überlappende Adresspools von DHCP-Servern
>> verursachte IP-Adressen- Konflikte zu vermeiden.
> Ohne arp hast Du kein IP in Deinem Netz, an den Endpoints funktioniert es
> nicht anders nur kommt da Deine MAC nicht durch sondern die des Routers.

???
MAC-Acressen verlassen *niemals* das Layer2-Netz in dem sie verwendet
werden. Beim routen (Layer3-Forwarding) wird *immer* die komplette
Layer2-Information entfernt und fuer das Netz in das das Paket weiter-
geleitet wird wieder neu aufgebaut. Nrigst du evt. dazu, die Netzwerk-
Layer etwas durcheinanderzuwuerfeln?

[Burkhard Ott]

On Wed, 21 Dec 2011 18:11:34 +0000, Juergen Ilse wrote:

> Hallo,
>
> Burkhard Ott <news...@derith.de> wrote:
>> On Wed, 21 Dec 2011 13:03:01 +0100, Thomas 'PointedEars' Lahn wrote:
>>>>> - _ARP_ (Adress Resolution Protocol) findet auf dem Link Layer statt
>>>>> und
>>>>> hat AFAICS nicht zwingend etwas mit DHCP (Application Layer) zu
>>>>> tun.
>>>> dest ip 255.255.255.255 == MAC ff:ff:ff:ff:ff:ff
>
> Auch wenn es ungewoehnlich waere koennte man auch auf einem PPP-Link mit
> einem /30 IPv4 Transfernetz die Adresse fuer ein Ende der Verbin- dung
> von der anderen Seite aus per DGCP vergeben (ja, ich weiss, dass das
> ueblicherweise eher per IPCP gemacht wird, aber DHCP waere auch
> moeglich). Nun hast du aber auf dem PPP-Link weder Ethernet-MAC-Adressen
> noch Link-Layer-Broadcasts noch ARP, wohl aber IP-Broadcasts und DHCP.

Ausnahmen bestaetigen die Regel, im OP war eine FB und ein Rechner
connected, duerfte sehr unwahrscheinlich sein das es per PPP terminiert
wird.

>>> Wie bitte?
>> Wie willst Du es anders abbilden, moege der Onkel Lehrer mal den
>> Traffic sniffen.
>
> Mankann z.B. IP auch auf PPP-Links oder in Frame-Relaynetzen betreiben
> (und so etwas wird sogar getan), aber beide Netzwerktopologien sind
> "NBMA" (non-Broadcast-multi-Access).

Ja kann man, und?

>>>> Ohne arp kein IP (ipv4 only).
>
> Wozu sollte man z.B. auf einem Poimz-zo-Point-Ethernetlink mit /31
> Netzmaske (siehe RFC3021) arp benoetigen? Oder auf einem PPP-Link? oder
> in einem ATM-Netz (mit IP over ATM Encapsulation gemaess RFC1483)? Oder

Das duerfte die Faehigkeiten einer FB weit ueberschreiten.
Man kann sich auch einen Knopf an die Backe neahen wenn man drauf steht.

>> Ohne arp hast Du kein IP in Deinem Netz, an den Endpoints funktioniert
>> es nicht anders nur kommt da Deine MAC nicht durch sondern die des

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

>> Routers.
>
> ???
> MAC-Acressen verlassen *niemals* das Layer2-Netz in dem sie verwendet
> werden. Beim routen (Layer3-Forwarding) wird *immer* die komplette
> Layer2-Information entfernt und fuer das Netz in das das Paket weiter-
> geleitet wird wieder neu aufgebaut. Nrigst du evt. dazu, die Netzwerk-
> Layer etwas durcheinanderzuwuerfeln?

read again, neigst Du dazu Deine Leseschwaeche zu offenbaren?

cheers

[Thomas 'PointedEars' Lahn]

Burkhard Ott wrote:

> On Wed, 21 Dec 2011 18:49:16 +0100, Thomas 'PointedEars' Lahn wrote:
>> ARP-Broadcasts werden benutzt, um die MAC-Adresse der Kiste zu
>> ermitteln, die eine bestimmte IP (allgemeiner: Protokoll)-Adresse hat,
>> damit man dann an sie zielgerichtet (Ethernet-)Pakete senden kann. Das
>> geht auch aus dem RFC hervor.
>
> Noe,

Doch.

> dann solltest Du nochmal lesen.

Du auch.

> Es kann und wird zur Ermittlung der IP Herangezogen,

Zum letzten Mal: Der IP-_Adresse_. Die interessiert hier aber gar nicht.

> generell werde alle IP Broadcasts auf ff:ff:ff:ff:ff:ff
> abgebildet, wie willst Du z.Bsp. einem switch sagen 'msg geht an alle im
> Netz', mit 2 einigartigen MAC's schaltet der nur 2 Ports zusammen (darum
> sind eigentlich Namen wie Layer 3 oder IP switch quark). Ein Broadcast
> geht an alle Ports raus und jeder Client fuehlt sich angesprochen, ergo
> kann ich schon herausfinden wieviele und welchen Clienten im Netz sind
> ohne IP ueberhaupt zu sprechen.

Darum geht es hier nicht. Es geht darum:

| Packet Reception:
| -----------------
|
| When an address resolution packet is received, the receiving
| Ethernet module gives the packet to the Address Resolution module
| which goes through an algorithm similar to the following.
| Negative conditionals indicate an end of processing and a
| discarding of the packet.
|
| ?Do I have the hardware type in ar$hrd?
| Yes: (almost definitely)
| [optionally check the hardware length ar$hln]
| ?Do I speak the protocol in ar$pro?
| Yes:
| [optionally check the protocol length ar$pln]
| Merge_flag := false
| If the pair <protocol type, sender protocol address> is
| already in my translation table, update the sender
| hardware address field of the entry with the new
| information in the packet and set Merge_flag to true.
| ?Am I the target protocol address?
| Yes:
| If Merge_flag is false, add the triplet <protocol type,
| sender protocol address, sender hardware address> to
| the translation table.
| ?Is the opcode ares_op$REQUEST? (NOW look at the opcode!!)
| Yes:
| Swap hardware and protocol fields, putting the local
| hardware and protocol addresses in the sender fields.
| Set the ar$op field to ares_op$REPLY
| Send the packet to the (new) target hardware address on
| the same hardware on which the request was received.

Die Sender-Protokolladresse ist bei IPv4-DHCPDISCOVER 0.0.0.0, die
Empfänger-Protokolladresse ist 255.255.255.255. Denn der Client will erst
eine IP-Adresse vom Server haben, und kennt die IP-Adresse des Servers
nicht.

Entscheidend ist hier nicht der ARP-Broadcast, sondern der IP-Broadcast.
Im Zweifelsfall wird ARP nicht einmal benutzt. Daher ist es irreführend,
hier die Betonung auf ARP zu legen.

[Burkhard Ott]

On Wed, 21 Dec 2011 20:22:57 +0100, Thomas 'PointedEars' Lahn wrote:

> Die Sender-Protokolladresse ist bei IPv4-DHCPDISCOVER 0.0.0.0, die
> Empfänger-Protokolladresse ist 255.255.255.255. Denn der Client will
> erst eine IP-Adresse vom Server haben, und kennt die IP-Adresse des
> Servers nicht.

Genau und deshalb brauchst Du arp:

Src: Client MAC
Dst: ff:ff:ff:ff:ff:ff == broadcast

> Entscheidend ist hier nicht der ARP-Broadcast, sondern der IP-Broadcast.
> Im Zweifelsfall wird ARP nicht einmal benutzt.

Das ist jetz Spass um mich zu aergern?
In der Umgebung des OP ist es sehr unwahrscheinlich das da z.Bsp. eine
PPP link zwischen Client Rechner und FB hergstellt worden ist, ergo
brauchst Du *IMMER* das arp.

> Daher ist es
> irreführend, hier die Betonung auf ARP zu legen.

Gut, dann eben die Media Access Control Addresse allgemein bekannt als
MAC.
Ohne die laeuft nichts im beschrieben Netz des OP.
Ausser bei speziellen Links wie eben ppp (da muss man das aber auch nicht
so machen), brauchst Du die Kommunikation via MAC's, um die in eine IP
aufzuloesen brauchst Du arp.
BTW. Seit ZeroConf hast Du immer eine IP, mit IPv6 erst recht, besser
gesagt Du hast gleich ein grosses link local Netz, dort gibts dann auch
kein arp mehr.

cheers

[Juergen Ilse]

Hallo,

Burkhard Ott <news...@derith.de> wrote:

> Was ist denn ff:ff:ff:ff:ff:ff, sieht genau wie ein Broadcast aus, gelle.

Bei Ethernet ist das eine Layer2-Broadcast-Adresse. IP setzt aber nicht
unbedingt Ethernet als Layer2-Protokoll voraus.

> Um einen IP Broadcast (egal ob 255.255.255.255 oder 1.1.1.255/24) zu
> senden *MUSST* Du alle Bits setzen, jetzt klar?

IP laesst sich ueber unterschiedliche Layer2-Protokolle transportieren,
und nicht auf allen davon sehen Layer2-Adressen so aus wie in deiner
Argumentation, nicht auf allen gibt es Link-Layer-Broadcasts zur Um-
setzung von IP-Broadcasts ...

>> ARP-Broadcasts werden benutzt, um die MAC-Adresse der Kiste zu
>> ermitteln, die eine bestimmte IP (allgemeiner: Protokoll)-Adresse hat,
>> damit man dann an sie zielgerichtet (Ethernet-)Pakete senden kann. Das
>> geht auch aus dem RFC hervor.
> Noe, dann solltest Du nochmal lesen.

RFC826 ist betitelt mit:

Converting Network Protocol Addresses
to 48.bit Ethernet Address
for Transmission on
Ethernet Hardware

Es geht bei arp (das spezifisch fuer Ethernet ist und eben nicht auf
allen moeglichen fuer IP verwendeten Layer2-Protokollen existiert)
also darum, die zu einer IP-Adresse gehoerende Layer2-Adresse zu er-
mitteln. Dein Vorredner hat also recht.

> Es kann und wird zur Ermittlung der IP Herangezogen,

Nein, ungekehrt wird ein Schuh draus. ARP dient dazu, bei IP over Ethernet
die zu einer Layer3- (IP-) Adresse gehoerende Layer2- (MAC-) Adresse zu er-
mitteln.

> generell werde alle IP Broadcasts auf ff:ff:ff:ff:ff:ff abgebildet,

Wie ist das in IP-Netzen, die auf einem anderen Layer2 als Ethernet
betrieben werden, und in denen Layer2-Adressen anders aussehen als
bei Ethernet?

> wie willst Du z.Bsp. einem switch sagen 'msg geht an alle im Netz',

Auch wenn di es nicht gemerkt haben solltest: du bist schon wieder bei
Ethernet, aber IP funktioniert auch auf anderem Layer2 als Ethernet ...

>> Darum geht es aber bei DHCP gar nicht. Stattdessen sollen *alle* *DHCP-
>> Server*,
> i.d.R. der authoritative, falls es mehr als einen gibt.

Welcher ist das, wenn es mehrere laufende gibt?

>> die sich zuständig fühlen, dem DHCP-Client sagen, dass sie da
>> sind (DHCPOFFER), damit der anschliessend einige oder alle von diesen
>> nach einer Protokolladresse fragen kann (DHCPREQUEST). Die eigentliche
>> Kommunikation findet hier auf höheren Protokollebenen statt: der
>> DHCP-Client sendet am Anfang einen *IP*-Broadcast, ein UDP-Paket
>> (DHCPDISCOVER), ins Netz.
> Das bezweiflelte ich nie, der broadcast auf layer 2 bleibt jedoch
> trotzdem. Wenn Du also auf IP 255.255.255.255 adressierst ist das nunmal
> ff:ff:ff:ff:ff:ff und so wird Dein 'payload' uebermittelt.

... in IP-Netzen auf Ethernet-Basis. Es gibt auch noch andere ...

> btw. IP hat keine ports die gehoeren zu TCP und UDP.

Ports 67 (fuer den DHCP-Server) und 68 (fuer den Client).

[Burkhard Ott]

On Wed, 21 Dec 2011 19:52:25 +0000, Juergen Ilse wrote:

> Hallo,
>
> Burkhard Ott <news...@derith.de> wrote:
>> Was ist denn ff:ff:ff:ff:ff:ff, sieht genau wie ein Broadcast aus,
>> gelle.
>
> Bei Ethernet ist das eine Layer2-Broadcast-Adresse. IP setzt aber nicht
> unbedingt Ethernet als Layer2-Protokoll voraus.

Das habe ich auch nicht behauptet, in der beschriebenen Umgebung des OP
ist es aber zwingend erforderlich.

>> Um einen IP Broadcast (egal ob 255.255.255.255 oder 1.1.1.255/24) zu
>> senden *MUSST* Du alle Bits setzen, jetzt klar?
>
> IP laesst sich ueber unterschiedliche Layer2-Protokolle transportieren,
> und nicht auf allen davon sehen Layer2-Adressen so aus wie in deiner
> Argumentation, nicht auf allen gibt es Link-Layer-Broadcasts zur Um-
> setzung von IP-Broadcasts ...

Ja es gibt Ausnahmen, habe aber auch nicht behauptet das es diese nicht
gibt, liese doch bitte erst das OP. Wie Du dann erkennen wirst ist dort
arp zwingend.

>>> ARP-Broadcasts werden benutzt, um die MAC-Adresse der Kiste zu
>>> ermitteln, die eine bestimmte IP (allgemeiner: Protokoll)-Adresse hat,
>>> damit man dann an sie zielgerichtet (Ethernet-)Pakete senden kann.
>>> Das geht auch aus dem RFC hervor.
>> Noe, dann solltest Du nochmal lesen.
>
> RFC826 ist betitelt mit:
>
> Converting Network Protocol Addresses
> to 48.bit Ethernet Address
> for Transmission on
> Ethernet Hardware
>
> Es geht bei arp (das spezifisch fuer Ethernet ist und eben nicht auf
> allen moeglichen fuer IP verwendeten Layer2-Protokollen existiert) also
> darum, die zu einer IP-Adresse gehoerende Layer2-Adresse zu er- mitteln.
> Dein Vorredner hat also recht.

Und wie sendest Du nun einen Broadcast? Genau alle Bits setzen.

>> Es kann und wird zur Ermittlung der IP Herangezogen,
>
> Nein, ungekehrt wird ein Schuh draus. ARP dient dazu, bei IP over
> Ethernet die zu einer Layer3- (IP-) Adresse gehoerende Layer2- (MAC-)
> Adresse zu er- mitteln.

Ja ermittelt wird die dazugehoerige MAC adresse, das habe ich etwas
unklar geschrieben.

>
>> generell werde alle IP Broadcasts auf ff:ff:ff:ff:ff:ff abgebildet,
>
> Wie ist das in IP-Netzen, die auf einem anderen Layer2 als Ethernet
> betrieben werden, und in denen Layer2-Adressen anders aussehen als bei
> Ethernet?

Dann wird es auf das entsprechende Protokoll abgebildet um IP zu
transportieren. Je nach Protokoll.

>> wie willst Du z.Bsp. einem switch sagen 'msg geht an alle im Netz',
>
> Auch wenn di es nicht gemerkt haben solltest: du bist schon wieder bei
> Ethernet, aber IP funktioniert auch auf anderem Layer2 als Ethernet ...

Der OP hat nunnmal ein IP/Ethernet, kann ich nichts dafuer. Glaube auch
nicht das seine FB nicht IP/Ethernet macht, das wird sicher im Handbuch
oder der Spezification zu finden sein, aber sehr unwahrscheinlich das man
im SOHO Bereich was anderes nutzt.

>>> Darum geht es aber bei DHCP gar nicht. Stattdessen sollen *alle*
>>> *DHCP- Server*,
>> i.d.R. der authoritative, falls es mehr als einen gibt.
>
> Welcher ist das, wenn es mehrere laufende gibt?

Der der als authorative konfiguriert ist. Das Packet bekommen zwar alle
ab, aber der Authoritative sendet die Antwort.

>>> die sich zuständig fühlen, dem DHCP-Client sagen, dass sie da sind
>>> (DHCPOFFER), damit der anschliessend einige oder alle von diesen nach
>>> einer Protokolladresse fragen kann (DHCPREQUEST). Die eigentliche
>>> Kommunikation findet hier auf höheren Protokollebenen statt: der
>>> DHCP-Client sendet am Anfang einen *IP*-Broadcast, ein UDP-Paket
>>> (DHCPDISCOVER), ins Netz.
>> Das bezweiflelte ich nie, der broadcast auf layer 2 bleibt jedoch
>> trotzdem. Wenn Du also auf IP 255.255.255.255 adressierst ist das
>> nunmal ff:ff:ff:ff:ff:ff und so wird Dein 'payload' uebermittelt.
>
> ... in IP-Netzen auf Ethernet-Basis. Es gibt auch noch andere ...

Das weiss ich auch, gehoert aber nicht hierher, lies das OP.

>> btw. IP hat keine ports die gehoeren zu TCP und UDP.
>
> Ports 67 (fuer den DHCP-Server) und 68 (fuer den Client).

Was nun wieder UDP over IP ist, und das koenntest Du auch anders
uebertragen, nur hat sich IP etabliert.

cheers

[Juergen Ilse]

Hallo,

Burkhard Ott <news...@derith.de> wrote:

> On Wed, 21 Dec 2011 20:22:57 +0100, Thomas 'PointedEars' Lahn wrote:
>> Die Sender-Protokolladresse ist bei IPv4-DHCPDISCOVER 0.0.0.0, die
>> Empfänger-Protokolladresse ist 255.255.255.255. Denn der Client will
>> erst eine IP-Adresse vom Server haben, und kennt die IP-Adresse des
>> Servers nicht.
> Genau und deshalb brauchst Du arp:

Nein. DHCP spielt sich auf Layer3 ab, du argumentierst hier aber immer
wieder mit Layer2 (und das auch noch beschraenkt auf Ethernet).

> Src: Client MAC
> Dst: ff:ff:ff:ff:ff:ff == broadcast

Auf Layer2. DHCP verwendet aber keine Layer2-Adressen, denn es spielt
sich komplett ab Layer3 aufwaerts ab.

>> Entscheidend ist hier nicht der ARP-Broadcast, sondern der IP-Broadcast.

Korrekt, der Layer3-Broadcast. Wie der im Endeffekt auf Layer2 transportiert
wird, ist fuer DHCP gleichgueltig, solange dieser Transport ueberhaupt
funktioniert (und azf Layer2 ungleich Ethernet gibt es noch nicht einmal
arp, aber DHCP funktioniert da trotzdem, solange IP-Broadcasts moeglich
sind ...).

>> Im Zweifelsfall wird ARP nicht einmal benutzt.
> Das ist jetz Spass um mich zu aergern?

Nein, voellig korrekt argumentiert. DHCP benoetigt kein ARP (interessanter-
weise noch nicht einmal auf Ethernet, wo es ARP durchaus gibt).

> In der Umgebung des OP ist es sehr unwahrscheinlich das da z.Bsp. eine
> PPP link zwischen Client Rechner und FB hergstellt worden ist, ergo
> brauchst Du *IMMER* das arp.

Das habe ich auch nicht behauptet. Es wurde (nicht nur von mir) allerdings
zurecht bemaengelt, dass du in ziemlich verwirrender (und verwirrter) Weise
Begriffe durcheinander wirfst, die nichts miteinander zu tun haben (DHCP
und ARP), munter Netzwerklayer durcheinanderwirfst (Layer2 und Layer3)
und deine Argumentation auf Ethernet aufbaust aber so tust, als sei sie
fuer jegliche IP-Netze gueltig (das ist sie nicht, denn es gibt IP auch
auf anderen Transportlayern als Ethernet).

> Ohne die laeuft nichts im beschrieben Netz des OP.
> Ausser bei speziellen Links wie eben ppp (da muss man das aber auch nicht
> so machen), brauchst Du die Kommunikation via MAC's, um die in eine IP
> aufzuloesen brauchst Du arp.

Schon wieder argumentierst du "falsch herum": ARP wird *nicht* verwendet,
um "MAC-Adressen in eine IP aufzuloesen" sondern um "IP-Adressen zu MAC-
Adressen aufzuloesen", sprich um zu einer IP-Adresse aus dem lokalen Netz
die zugehoerige Layer2-Adresse zu ermitteln (bei Ethernet als Layer2-
Protokoll).

> BTW. Seit ZeroConf hast Du immer eine IP, mit IPv6 erst recht, besser
> gesagt Du hast gleich ein grosses link local Netz, dort gibts dann auch
> kein arp mehr.

Bitte fang jetzt nicht auch noch an, IPv6 erklaeren zu wollen, die
Verwirrung ist auch so schon gross genug ...

[Juergen Ilse]

Hallo,

Burkhard Ott <news...@derith.de> wrote:
> On Wed, 21 Dec 2011 19:52:25 +0000, Juergen Ilse wrote:
>>>> Darum geht es aber bei DHCP gar nicht. Stattdessen sollen *alle*
>>>> *DHCP- Server*,
>>> i.d.R. der authoritative, falls es mehr als einen gibt.
>> Welcher ist das, wenn es mehrere laufende gibt?
> Der der als authorative konfiguriert ist.

Die Funktionsweise von DHCP ist anders: Wenn es tatsaechlich mehrere
laufende DHCP-Server gibt (viele Implentierungen schalten sich ab,
wenn sie einen weiteren laufenden DHCP-Server feststellen) antworten
im Tweifelsfall *alle* auf den DHCP-Request mit einem DHCP-Offer.
Anschliessend waehlt der *Client* eins von diesen Angeboten aus
und sendet an den Server, der das preferierte DHCP-offer angeboten
hat, die Anforderung, das entsprechende Lease zu registrieren.

Aufgrund dessen steht im DHCP-RFC auch:

o A DHCP client must be prepared to receive multiple responses
to a request for configuration parameters. Some installations
may include multiple, overlapping DHCP servers to enhance
reliability and increase performance.

Wenn grundsaetzlich nur einer antworten wuerde, waere dieser Satz
unsinnig, ist er aber nicht, weil eben nicht zwingend nur ein DHCP-
server antwortet, sondern *alle* *aktiven* DHCP-Server fuer das
lokale Netz.

>>> btw. IP hat keine ports die gehoeren zu TCP und UDP.
>> Ports 67 (fuer den DHCP-Server) und 68 (fuer den Client).
> Was nun wieder UDP over IP ist, und das koenntest Du auch anders
> uebertragen, nur hat sich IP etabliert.

DHCP ohne IP geht nicht (im Gegensatz zu IP ohne ARP), denn DHCP
arbeitet *nur* auf IP (mittels UDP), sonst waere es kein DHCP mehr.

[Burkhard Ott]

On Wed, 21 Dec 2011 20:17:07 +0000, Juergen Ilse wrote:

> Nein. DHCP spielt sich auf Layer3 ab, du argumentierst hier aber immer
> wieder mit Layer2 (und das auch noch beschraenkt auf Ethernet).

Es ging um einen Ethernet Broadcast.

>> In der Umgebung des OP ist es sehr unwahrscheinlich das da z.Bsp. eine
>> PPP link zwischen Client Rechner und FB hergstellt worden ist, ergo
>> brauchst Du *IMMER* das arp.
>
> Das habe ich auch nicht behauptet. Es wurde (nicht nur von mir)
> allerdings zurecht bemaengelt, dass du in ziemlich verwirrender (und
> verwirrter) Weise Begriffe durcheinander wirfst, die nichts miteinander
> zu tun haben (DHCP und ARP), munter Netzwerklayer durcheinanderwirfst
> (Layer2 und Layer3) und deine Argumentation auf Ethernet aufbaust aber
> so tust, als sei sie fuer jegliche IP-Netze gueltig (das ist sie nicht,
> denn es gibt IP auch auf anderen Transportlayern als Ethernet).

Nein so tue ich nicht, im Netz des OP ist nun aber mal Ethernet.

>> Ohne die laeuft nichts im beschrieben Netz des OP. Ausser bei
>> speziellen Links wie eben ppp (da muss man das aber auch nicht so
>> machen), brauchst Du die Kommunikation via MAC's, um die in eine IP
>> aufzuloesen brauchst Du arp.
>
> Schon wieder argumentierst du "falsch herum": ARP wird *nicht*
> verwendet, um "MAC-Adressen in eine IP aufzuloesen" sondern um
> "IP-Adressen zu MAC- Adressen aufzuloesen", sprich um zu einer
> IP-Adresse aus dem lokalen Netz die zugehoerige Layer2-Adresse zu
> ermitteln (bei Ethernet als Layer2- Protokoll).

Ich habe das nicht von unten nach oben gemeint.

arp fragt welche MAC hat IP adresse 1.1.1.1, responder sagt 1.1.1.1 hat
MAC irgednwas, jetzt klarer.

Von oben nach unten:

Um IP 1.1.1.1 zu erreich brauchst Du die MAC dieses Clients, dann tritt
o.g. ein.

>
>> BTW. Seit ZeroConf hast Du immer eine IP, mit IPv6 erst recht, besser
>> gesagt Du hast gleich ein grosses link local Netz, dort gibts dann auch
>> kein arp mehr.
>
> Bitte fang jetzt nicht auch noch an, IPv6 erklaeren zu wollen, die
> Verwirrung ist auch so schon gross genug ...

Noe das habe ich auch nicht vor.

Um zum OT zurueckzukommen, DHCP sendet an dst 255.255.255.255, welches
die MAC adresse ff:ff:ff:ff:ff:ff(ja Ethernet, ja man kann es auch
mittels anderer Protokolle transportieren aber das die FB des OT mit
Sicherheit nicht anders) alg. bekannt als Ethernetbroadcast.

cheers

[Burkhard Ott]

On Wed, 21 Dec 2011 20:41:41 +0000, Juergen Ilse wrote:

> Hallo,
>
> Burkhard Ott <news...@derith.de> wrote:
>> On Wed, 21 Dec 2011 19:52:25 +0000, Juergen Ilse wrote:
>>>>> Darum geht es aber bei DHCP gar nicht. Stattdessen sollen *alle*
>>>>> *DHCP- Server*,
>>>> i.d.R. der authoritative, falls es mehr als einen gibt.
>>> Welcher ist das, wenn es mehrere laufende gibt?
>> Der der als authorative konfiguriert ist.
>
> Die Funktionsweise von DHCP ist anders: Wenn es tatsaechlich mehrere
> laufende DHCP-Server gibt (viele Implentierungen schalten sich ab,
> wenn
> sie einen weiteren laufenden DHCP-Server feststellen) antworten im
> Tweifelsfall *alle* auf den DHCP-Request mit einem DHCP-Offer.

1. Wenn alle anderen sich bis auf einen Abschalten hast Du genau... ja
einen.

2. Nun versuchst Du mit DHCP HA setups zu argumentieren, warum?

Natuerlich sollte der Client darauf vorbereitet sein das er mehrere
antworten bekommt.

> Anschliessend waehlt der *Client* eins von diesen Angeboten aus und
> sendet an den Server, der das preferierte DHCP-offer angeboten hat, die
> Anforderung, das entsprechende Lease zu registrieren.
>
> Aufgrund dessen steht im DHCP-RFC auch:
>
> o A DHCP client must be prepared to receive multiple responses
> to a request for configuration parameters. Some installations
> may include multiple, overlapping DHCP servers to enhance
> reliability and increase performance.
>
> Wenn grundsaetzlich nur einer antworten wuerde, waere dieser Satz
> unsinnig, ist er aber nicht, weil eben nicht zwingend nur ein DHCP-
> server antwortet, sondern *alle* *aktiven* DHCP-Server fuer das lokale
> Netz.

Was ausser Zweifel steht.

>>>> btw. IP hat keine ports die gehoeren zu TCP und UDP.
>>> Ports 67 (fuer den DHCP-Server) und 68 (fuer den Client).
>> Was nun wieder UDP over IP ist, und das koenntest Du auch anders
>> uebertragen, nur hat sich IP etabliert.
>
> DHCP ohne IP geht nicht (im Gegensatz zu IP ohne ARP), denn DHCP
> arbeitet *nur* auf IP (mittels UDP), sonst waere es kein DHCP mehr.

Das macht ja nix, trotzdem bleibt ein ethernet broadcast ein broadcast
egal welches hoehere Protocoll ihn ausloest.

cheers

[Juergen Ilse]

Hallo,

Burkhard Ott <news...@derith.de> wrote:
> On Wed, 21 Dec 2011 20:41:41 +0000, Juergen Ilse wrote:
>> Die Funktionsweise von DHCP ist anders: Wenn es tatsaechlich mehrere
>> laufende DHCP-Server gibt (viele Implentierungen schalten sich ab,
>> wenn
>> sie einen weiteren laufenden DHCP-Server feststellen) antworten im
>> Tweifelsfall *alle* auf den DHCP-Request mit einem DHCP-Offer.
>
> 1. Wenn alle anderen sich bis auf einen Abschalten hast Du genau... ja
> einen.

Ja, und wenn sie sivj nicht abschalten, hast du mehrere. Und bei ordent-
lichen Implementierungen funktioniert es dennoch, selbst wenn sie alle
aus dem selben DHCP-Pool vergeben ...

> 2. Nun versuchst Du mit DHCP HA setups zu argumentieren, warum?

Weil es eben mehr als einen DHCP-Server im Netz geben kann, und genau
auf den Fall angesprochen hast du von irgendwelchen "authoritativen
DHCP-Servern" geschwafelt. Mehrere DHCP-Server im selben Netz ist
kein wirklich ungewoegbkiches Szenario, und etwas wie "nicht authoritative
DHCP-Server fuer ein Netzsegment" gibt es in dem Sinne eigentlich nicht.

>>>>> btw. IP hat keine ports die gehoeren zu TCP und UDP.
>>>> Ports 67 (fuer den DHCP-Server) und 68 (fuer den Client).
>>> Was nun wieder UDP over IP ist,

UDP ist *immer* IP und kann *niemals* etwas anderes sein.
UDP ist nicht "over IP" sondern eines von vielen IP-Protokollen
(genauer IP-Protokoll 17).

>>> und das koenntest Du auch anders uebertragen, nur hat sich IP etabliert.
>> DHCP ohne IP geht nicht (im Gegensatz zu IP ohne ARP), denn DHCP
>> arbeitet *nur* auf IP (mittels UDP), sonst waere es kein DHCP mehr.
> Das macht ja nix, trotzdem bleibt ein ethernet broadcast ein broadcast
> egal welches hoehere Protocoll ihn ausloest.

DHCP ist auf Layer3 definiert, nicht zwingend an Ethernet gebunden,
und das ein IP-Broadcast in Ethernet-Netzen in Form von Ethernet-
Broadcasts implementiert sind, ist ein Implementierungsdetail, was
im Zusammenhang mit DHCP keine Rolle spielt, denn der relevante Teil
spielt sich bei DHCP ab Layer3 aufwaerts ab.

Es wird mir zu duemmlich, deine wilde Vermischung verschiedener
Netzwerklayer zu korrigieren, daher fuer mich EOD.

[Burkhard Ott]

On Wed, 21 Dec 2011 22:18:27 +0000, Juergen Ilse wrote:

> UDP ist *immer* IP und kann *niemals* etwas anderes sein. UDP ist nicht
> "over IP" sondern eines von vielen IP-Protokollen (genauer IP-Protokoll
> 17).

Na klar kann man UDP als auch TCP auch ueber andere Protokolle
uebertragen, warum sollte das nicht gehen.

> DHCP ist auf Layer3 definiert, nicht zwingend an Ethernet gebunden, und
> das ein IP-Broadcast in Ethernet-Netzen in Form von Ethernet- Broadcasts
> implementiert sind, ist ein Implementierungsdetail, was im Zusammenhang
> mit DHCP keine Rolle spielt, denn der relevante Teil spielt sich bei
> DHCP ab Layer3 aufwaerts ab.

Genau, und ich sagte nur das sein (IP) Broadcast als Ethernetbroacast and
der FB ankommt. Was soll daran faslsch sein.

> Es wird mir zu duemmlich, deine wilde Vermischung verschiedener
> Netzwerklayer zu korrigieren, daher fuer mich EOD.

Wie woanders auch redest Du staendig am Thema vorbei und dann bist Du
wieder eingeschnappt. Mensch Juergen werd erwachsen.

cheers

[Burkhard Ott]

On Wed, 21 Dec 2011 22:18:27 +0000, Juergen Ilse wrote:

> Ja, und wenn sie sivj nicht abschalten, hast du mehrere. Und bei ordent-
> lichen Implementierungen funktioniert es dennoch, selbst wenn sie alle
> aus dem selben DHCP-Pool vergeben ...

Und macht ja nix, wenn die IP's nicht kollidieren.

>> 2. Nun versuchst Du mit DHCP HA setups zu argumentieren, warum?
>
> Weil es eben mehr als einen DHCP-Server im Netz geben kann, und genau
> auf den Fall angesprochen hast du von irgendwelchen "authoritativen
> DHCP-Servern" geschwafelt. Mehrere DHCP-Server im selben Netz ist kein
> wirklich ungewoegbkiches Szenario, und etwas wie "nicht authoritative
> DHCP-Server fuer ein Netzsegment" gibt es in dem Sinne eigentlich nicht.
>

s.o.

>>>>>> btw. IP hat keine ports die gehoeren zu TCP und UDP.
>>>>> Ports 67 (fuer den DHCP-Server) und 68 (fuer den Client).
>>>> Was nun wieder UDP over IP ist,
>
> UDP ist *immer* IP und kann *niemals* etwas anderes sein. UDP ist nicht
> "over IP" sondern eines von vielen IP-Protokollen (genauer IP-Protokoll
> 17).

Auch das ist mehr oder weniger Quatsch, sie Protokolle sind transparent
aufgebaut. Und im weitestgehen Sinne wird IPv4 mit IPv6 gerade
ausgetauscht, Du koenntes aber auch das Juergen Protokoll erfinden dann
waers halt udp over JP, muesste man eben nur an der Netzgrenze wieder in
IP austauschen dann kannst Du auch wieder mit dem Internet quarken.

cheers

[Juergen Ilse]

Hallo,

Burkhard Ott <news...@derith.de> wrote:

> On Wed, 21 Dec 2011 22:18:27 +0000, Juergen Ilse wrote:
>> UDP ist *immer* IP und kann *niemals* etwas anderes sein. UDP ist nicht
>> "over IP" sondern eines von vielen IP-Protokollen (genauer IP-Protokoll
>> 17).
> Auch das ist mehr oder weniger Quatsch,

Nein, UDP ist defniert als IP-Protokoll 17. Ein UDP-aehnliches "micht IP"
Protokoll waere kein UDP mehr.

[Burkhard Ott]

On Thu, 22 Dec 2011 21:57:02 +0000, Juergen Ilse wrote:

> Hallo,
>
> Burkhard Ott <news...@derith.de> wrote:
>> On Wed, 21 Dec 2011 22:18:27 +0000, Juergen Ilse wrote:
>>> UDP ist *immer* IP und kann *niemals* etwas anderes sein. UDP ist
>>> nicht "over IP" sondern eines von vielen IP-Protokollen (genauer
>>> IP-Protokoll 17).
>> Auch das ist mehr oder weniger Quatsch,
>
> Nein, UDP ist defniert als IP-Protokoll 17. Ein UDP-aehnliches "micht
> IP" Protokoll waere kein UDP mehr.

Aha, dann ist also der term TCP/IP demnach auch Bloedsinn, da es nur
ueber IP geht.

Traeum weiter.

cheers

[Stefan Nobis]

Burkhard Ott <news...@derith.de> writes:

> Aha, dann ist also der term TCP/IP demnach auch Bloedsinn, da es nur
> ueber IP geht.

Ich glaube, Du bringst die theoretische Sicht durch die OSI-Brille mit
der konkreten Definition und Implementierung von TCP/IP
durcheinander. Die OSI-Layer sind enorm hilfreich, um nicht die
Orientierung zu verlieren und systematischer zu arbeiten. TCP/IP ist
aber nicht wie das OSI-Modell ein sauber getrenntes Schichtenmodell
und die verschiedenen TCP/IP Protokoll lassen sich nur wirklich *grob*
in die OSI-Layer einordnen.

Wenn man sich das mal genau ansieht, dann ist TCP/IP quasi genau das
Gegenteil von OSI, nämlich ein wildes, spaghetti-ähnliches Gemenge eng
ineinander verschlungener Definitionen von Protokollen, also wirklich
eine einzelne große Protokollfamilie.

Die einzelnen Teile von TCP/IP sind schon ziemlich untrennbar
miteinander verwoben. Die OSI-Idee, jeder Layer ist in sich gekapselt
und jeweils unabhängig von anderen Layern austauschbar, gilt für
TCP/IP explizit nicht, wie man in einschlägiger Fachliteratur
ausgiebig nachlesen kann.

--
Stefan.

[Stefan Nobis]

Burkhard Ott <news...@derith.de> writes:

> Und wie sendest Du nun einen Broadcast? Genau alle Bits setzen.

Was hat das mit ARP zu tun? Wieso benötige ich für die simple
Umsetztung von 255.255.255.255 auf die MAC ff:ff:ff:ff:ff:ff ein
*Netzwerkprotokoll*, um die eine in die andere Adresse aufzulösen (ich
habe jetzt nicht in die RFCs gesehen, insofern bin ich mir nicht mal
sicher, ob man die Broadcast-Adresse via ARP überhaupt auflösen
kann)?

Verwechselst Du evtl. Algorithmus mit Netzwerkprotokoll und
interpretierst den Ausdruck "Address Resolution Protocol" etwas zu
allgemein?

> Was nun wieder UDP over IP ist, und das koenntest Du auch anders
> uebertragen, nur hat sich IP etabliert.

Ich glaube, Du hast da eine extrem abstrakte und etwas zu stark von
den konkreten Definitionen und RFCs losgelöste Sicht auf die Dinge.

--
Stefan.

[Juergen Ilse]

Hallo,

Stefan Nobis <sno...@gmx.de> wrote:
> Burkhard Ott <news...@derith.de> writes:
>> Und wie sendest Du nun einen Broadcast? Genau alle Bits setzen.
> Was hat das mit ARP zu tun? Wieso benötige ich für die simple
> Umsetztung von 255.255.255.255 auf die MAC ff:ff:ff:ff:ff:ff ein
> *Netzwerkprotokoll*, um die eine in die andere Adresse aufzulösen (ich
> habe jetzt nicht in die RFCs gesehen, insofern bin ich mir nicht mal
> sicher, ob man die Broadcast-Adresse via ARP überhaupt auflösen
> kann)?

Kann man nicht.

> Verwechselst Du evtl. Algorithmus mit Netzwerkprotokoll und
> interpretierst den Ausdruck "Address Resolution Protocol" etwas zu
> allgemein?

Vermutlich ja.

>> Was nun wieder UDP over IP ist, und das koenntest Du auch anders
>> uebertragen, nur hat sich IP etabliert.
> Ich glaube, Du hast da eine extrem abstrakte und etwas zu stark von
> den konkreten Definitionen und RFCs losgelöste Sicht auf die Dinge.

Ich habe einen aehnlichen Eindruck.

[Dieter Intas]

Heiko Schlenker schrieb:

[...]

> UDP-Pakete werden stets per IP übertragen, hingegen kann TCP auch auf
> ein anderes Protokoll als IP aufsetzen. Siehe Spezifikationen der
> Protokolle UDP und TCP.

Das User Datagram Protocol, kurz UDP, ist ein minimales,
verbindungsloses Netzwerkprotokoll, das zur Transportschicht der
Internetprotokollfamilie gehört. Aufgabe von UDP ist es, Daten, die
über das Internet übertragen werden, der richtigen Anwendung zukommen
zu lassen.

Quelle: http://de.wikipedia.org/wiki/User_Datagram_Protocol

[Marc Haber]

Thomas 'PointedEars' Lahn <Point...@web.de> wrote:
>Für DHCP-Discovery wird (AFAICS) vom DHCP-Client _kein_ ARP-Paket versendet,
>sondern (bei IPv4) ein UDP-Paket mit Zieladresse 255.255.255.255. Es findet
>also _kein_ "arp broadcast" statt, sondern ein _IP_-Broadcast.

Und was für ein Ethernetframetyp ist so ein "IP-Broadcast", mit
welcher (Ethernet) Zieladresse?

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[Marc Haber]

Heiko Schlenker <hsc...@gmx.de> wrote:
>UDP-Pakete werden stets per IP übertragen, hingegen kann TCP auch auf
>ein anderes Protokoll als IP aufsetzen.

Und das wäre zum Beispiel?

> Siehe Spezifikationen der
>Protokolle UDP und TCP.

Bitte genauer.

[Claus-Dieter Schulmann]

Marc Haber wrote:

> Thomas 'PointedEars' Lahn <Point...@web.de> wrote:
>>Für DHCP-Discovery wird (AFAICS) vom DHCP-Client _kein_ ARP-Paket
>>versendet,
>>sondern (bei IPv4) ein UDP-Paket mit Zieladresse 255.255.255.255. Es
>>findet also _kein_ "arp broadcast" statt, sondern ein _IP_-Broadcast.
>
> Und was für ein Ethernetframetyp ist so ein "IP-Broadcast", mit
> welcher (Ethernet) Zieladresse?

Falls das keine rhetorische Frage ist: Bei DHCP-Discover: ff:ff:ff:ff:ff:ff

Claus-Dieter

[Claus-Dieter Schulmann]

Juergen Ilse wrote:

> Burkhard Ott <news...@derith.de> wrote:

>> 1. Wenn alle anderen sich bis auf einen Abschalten hast Du genau... ja
>> einen.
>
> Ja, und wenn sie sivj nicht abschalten, hast du mehrere. Und bei ordent-
> lichen Implementierungen funktioniert es dennoch, selbst wenn sie alle
> aus dem selben DHCP-Pool vergeben ...

Sie dürfen aber nicht die gleichen Adressen vergeben sonst benötigt man HA
oder ähnliches.

>> 2. Nun versuchst Du mit DHCP HA setups zu argumentieren, warum?
>
> Weil es eben mehr als einen DHCP-Server im Netz geben kann, und genau
> auf den Fall angesprochen hast du von irgendwelchen "authoritativen
> DHCP-Servern" geschwafelt. Mehrere DHCP-Server im selben Netz ist
> kein wirklich ungewoegbkiches Szenario, und etwas wie "nicht authoritative
> DHCP-Server fuer ein Netzsegment" gibt es in dem Sinne eigentlich nicht.

Nicht authoritative DHCP-Server (im Sinne von ISC) gibt es prinzipiell
schon. In einer professionellen Umgebung machen sie aber IMHO keinen Sinn.

Claus-Dieter

[Claus-Dieter Schulmann]

Burkhard Ott wrote:

> On Wed, 21 Dec 2011 19:52:25 +0000, Juergen Ilse wrote:
>

>> Burkhard Ott <news...@derith.de> wrote:

>>>> Darum geht es aber bei DHCP gar nicht. Stattdessen sollen *alle*
>>>> *DHCP- Server*,
>>> i.d.R. der authoritative, falls es mehr als einen gibt.
>>
>> Welcher ist das, wenn es mehrere laufende gibt?
>
> Der der als authorative konfiguriert ist. Das Packet bekommen zwar alle
> ab, aber der Authoritative sendet die Antwort.

Das ist falsch wenn man ISC zugrunde legt.

Der Unterschied zwischen authoritativ und nicht authoritativ ist:
Nur authoritative DHCP-Server verschicken DHCP-NAKs.
Das kann man auf http://www.isc.org/files/auth.html nachlesen.

Deshalb ist es sehr oft sinnvoll mindestens 2 authoritative DHCP-Server für
die gleichen Bereiche einzusetzen.
Ansonsten müsste man DHCP-Failover oder HA oder ähnliches aktivieren wenn
man keinen SPOF haben möchte.

Claus-Dieter

[Juergen Ilse]

Hallo,

Marc Haber <mh+usene...@zugschl.us> wrote:
> Thomas 'PointedEars' Lahn <Point...@web.de> wrote:
>>Für DHCP-Discovery wird (AFAICS) vom DHCP-Client _kein_ ARP-Paket versendet,
>>sondern (bei IPv4) ein UDP-Paket mit Zieladresse 255.255.255.255. Es findet
>>also _kein_ "arp broadcast" statt, sondern ein _IP_-Broadcast.
> Und was für ein Ethernetframetyp ist so ein "IP-Broadcast", mit
> welcher (Ethernet) Zieladresse?

Ob es ueberhaupt Ethernet ist, haengt vom verwendeten Layer2 ab (der
durchaus nicht immer und ueberall Ethernet sein muss, auch nicht bei
Verwendung von DHCP). Ein wesentlicher Teil der Diskussion drehte
sich gerade darum, dass es auch anseits von Ethernet funktionieren
wuerde, und dass man seine Betrachtung daher besser nicht ausschliess-
lich auf Ethernet als Layer2 beschraenken sollte (insbesondere sich
bei Erklaerungen der Funktionsweise nicht auf Ethernet beschraenken
sollte). Zwar wird bei Ethernet ein IP-Broadcast normalerweise durch
einen Link-Layer Broadcast implementiert, aber das ist ein Implemen-
tierungsdetail, dass fuer die Erklaerung der Funktionsweise von DHCP
irrelevant ist.

[Thomas 'PointedEars' Lahn]

Claus-Dieter Schulmann wrote:

> Juergen Ilse wrote:
>> Burkhard Ott <news...@derith.de> wrote:
>>> 1. Wenn alle anderen sich bis auf einen Abschalten hast Du genau... ja
>>> einen.
>>
>> Ja, und wenn sie sivj nicht abschalten, hast du mehrere. Und bei ordent-
>> lichen Implementierungen funktioniert es dennoch, selbst wenn sie alle
>> aus dem selben DHCP-Pool vergeben ...
>
> Sie dürfen aber nicht die gleichen Adressen vergeben sonst benötigt man HA
> oder ähnliches.

"HA"? DHCP-Server *dürfen* *dieselben* Protokolladressen vergeben. Jedoch
muss der DHCP-Client entscheiden, auf welches DHCPOFFER er DHCPREQUESTed,
und kann/SOLLTE *anschliessend* ARP benutzen, um IP-Adresskonflikte zu
vermeiden.

>>> 2. Nun versuchst Du mit DHCP HA setups zu argumentieren, warum?
>>
>> Weil es eben mehr als einen DHCP-Server im Netz geben kann, und genau
>> auf den Fall angesprochen hast du von irgendwelchen "authoritativen
>> DHCP-Servern" geschwafelt. Mehrere DHCP-Server im selben Netz ist
>> kein wirklich ungewoegbkiches Szenario, und etwas wie "nicht
>> authoritative DHCP-Server fuer ein Netzsegment" gibt es in dem Sinne
>> eigentlich nicht.
>
> Nicht authoritative DHCP-Server (im Sinne von ISC) gibt es prinzipiell
> schon. In einer professionellen Umgebung machen sie aber IMHO keinen Sinn.

"ISC"? Der DHCP-Client entscheidet, auf welches DHCPOFFER er DCHPREQUESTed,
und ob er das DHCPACK des jeweiligen Servers DHCPDECLINEd. Es gibt also
keinen DHCP-Server, der per se mehr zu sagen hätte als andere.

Es heisst im Deutschen übrigens "es ergibt Sinn" oder "es ist sinnvoll";
nicht "es macht Sinn".

--
PointedEars

Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[Claus-Dieter Schulmann]

Thomas 'PointedEars' Lahn wrote:

> Claus-Dieter Schulmann wrote:
>
>> Juergen Ilse wrote:

>>> Ja, und wenn sie sivj nicht abschalten, hast du mehrere. Und bei ordent-
>>> lichen Implementierungen funktioniert es dennoch, selbst wenn sie alle
>>> aus dem selben DHCP-Pool vergeben ...
>>
>> Sie dürfen aber nicht die gleichen Adressen vergeben sonst benötigt man
>> HA oder ähnliches.
>
> "HA"? DHCP-Server *dürfen* *dieselben* Protokolladressen vergeben.
> Jedoch muss der DHCP-Client entscheiden, auf welches DHCPOFFER er
> DHCPREQUESTed, und kann/SOLLTE *anschliessend* ARP benutzen, um
> IP-Adresskonflikte zu vermeiden.

Du würdest zwei unabhängige DHCP-Server in Betrieb nehmen, die die gleichen
IP-Adressen vergeben?
Also in der Art:
DHCP-Server 1: Pool von 192.168.1.44 -192.168.1.96
DHCP-Server 2: Pool von 192.168.1.44 -192.168.1.96

Adresskonflikte würdest Du nur dadurch vermeiden, dass die DHCP-Clients das
mit Hilfe von ARP erkennen?
Oder würdest Du dann dafür auch noch Ping-Tests der DHCP-Server einsetzen?

Oder habe ich Dich jetzt falsch verstanden?

>>>> 2. Nun versuchst Du mit DHCP HA setups zu argumentieren, warum?
>>>
>>> Weil es eben mehr als einen DHCP-Server im Netz geben kann, und genau
>>> auf den Fall angesprochen hast du von irgendwelchen "authoritativen
>>> DHCP-Servern" geschwafelt. Mehrere DHCP-Server im selben Netz ist
>>> kein wirklich ungewoegbkiches Szenario, und etwas wie "nicht
>>> authoritative DHCP-Server fuer ein Netzsegment" gibt es in dem Sinne
>>> eigentlich nicht.
>>
>> Nicht authoritative DHCP-Server (im Sinne von ISC) gibt es prinzipiell
>> schon. In einer professionellen Umgebung machen sie aber IMHO keinen
>> Sinn.
>
> "ISC"? Der DHCP-Client entscheidet, auf welches DHCPOFFER er

ISC: http://www.isc.org

> DCHPREQUESTed,
> und ob er das DHCPACK des jeweiligen Servers DHCPDECLINEd. Es gibt also
> keinen DHCP-Server, der per se mehr zu sagen hätte als andere.

Ich wüsste nicht wo ich anderes geschrieben hätte.

> Es heisst im Deutschen übrigens "es ergibt Sinn" oder "es ist sinnvoll";
> nicht "es macht Sinn".

Danke, Du darfst diesen Fehler auch gerne rot anmahlen. ;-)

Claus-Dieter

[Sieghard Schicktanz]

Hallo Claus-Dieter,

Du schriebst am Wed, 28 Dec 2011 21:46:05 +0100:

> > Es heisst im Deutschen übrigens "es ergibt Sinn" oder "es ist sinnvoll";
> > nicht "es macht Sinn".
>
> Danke, Du darfst diesen Fehler auch gerne rot anmahlen. ;-)

^
Also da muß ich doch schon sehr bitten - um _die_ Zeit habe ich meine
Schuhe zwar schon ausgezogen, aber es wäre doch deutlich freundlicher,
Mitlesern _solche_ Haken zu ersparen!

--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

[Helmut Hullen]

Hallo, Sieghard,

Du meintest am 29.12.11:

>>> Es heisst im Deutschen übrigens "es ergibt Sinn" oder "es ist
>>> sinnvoll"; nicht "es macht Sinn".

>> Danke, Du darfst diesen Fehler auch gerne rot anmahlen. ;-)

> Also da muß ich doch schon sehr bitten - um _die_ Zeit habe ich meine
> Schuhe zwar schon ausgezogen, aber es wäre doch deutlich
> freundlicher, Mitlesern _solche_ Haken zu ersparen!

"Hacken", bitteschön!
Dass höhrt und liesst mann doch immer wider! Du hasst verlohren!

Viele Gruesse
Helmut

"Ubuntu" - an African word, meaning "Slackware is too hard for me".

[Ralph Aichinger]

Thomas 'PointedEars' Lahn <Point...@web.de> wrote:

> Es heisst im Deutschen übrigens "es ergibt Sinn" oder "es ist sinnvoll";
> nicht "es macht Sinn".

Eine andere Meinung dazu:

http://www.iaas.uni-bremen.de/sprachblog/2007/10/01/sinnesfreuden-i/index.html

/ralph

[Andreas Kneib]

* Thomas 'PointedEars' Lahn:

> Es heisst im Deutschen übrigens "es ergibt Sinn" oder "es ist
> sinnvoll"; nicht "es macht Sinn".

Er sannt, ich sanne, du sönnest, sie sind gesönnt worden. Das ergibt
Sonne.


Gruß,
Andreas

[Helmut Hullen]

Hallo, Ralph,

Du meintest am 29.12.11:

>> Es heisst im Deutschen übrigens "es ergibt Sinn" oder "es ist
>> sinnvoll"; nicht "es macht Sinn".

> Eine andere Meinung dazu:

> <http://www.iaas.uni-bremen.de/sprachblog/2007/10/01/sinnesfreuden-i/index.html>

Das macht Freude, das macht Spass! Das macht Sinn ...

[Juergen Ilse]

Hallo,

Claus-Dieter Schulmann <Claus-Diete...@web.de> wrote:
> Du würdest zwei unabhängige DHCP-Server in Betrieb nehmen, die die gleichen
> IP-Adressen vergeben?
> Also in der Art:
> DHCP-Server 1: Pool von 192.168.1.44 -192.168.1.96
> DHCP-Server 2: Pool von 192.168.1.44 -192.168.1.96

Ich habe schon einmal eine so etwas konfiguriert, und es funktioniert
seit Jahren einwandfrei (die DHCP-Server sind die in 2 Cisco 6500 Switches).
Und es handelt sich jeweils um groessere Netze mit mehreren hundert
Clients. Ja, das funktioniert.

[Sieghard Schicktanz]

Hallo Andreas,

Du schriebst am Thu, 29 Dec 2011 11:32:25 +0000 (UTC):

> Er sannt, ich sanne, du sönnest, sie sind gesönnt worden. Das ergibt
> Sonne.

Jaja, die Krahmattick... und dann noch die Ausschbracheregeln!

Sind die Deutschen inzwischen wirklich alle gehörlos und leseunfähig?

[Sieghard Schicktanz]

Hallo Helmut,

Du schriebst am 29 Dec 2011 07:40:00 +0100:

> Dass höhrt und liesst mann doch immer wider! Du hasst verlohren!

Bist Du für die schlechten Beispiele bei Deinen Schulservern zuständig?
];->
Aber Du hast die Katastrophe leider recht gut getroffen...

BTW, wie hoch liegt der Prozentsatz der Analphabeten derzeit in Deutschland?
Und wie hoch der Prozentsatz der Legastheniker vom Rest?

Nichts gegen Legastheniker, die nichts dafürkönnen - aber müssen die alle
ausgerechnet Programmierer werden? Oder sind das gar keine _echten_
Legastheniker, sondern bloß schlampig? Warum müssen die dann alle
ausgerechnet Programmierer werden?

[Peter Köhlmann]

Sieghard Schicktanz wrote:

> Hallo Helmut,
>
> Du schriebst am 29 Dec 2011 07:40:00 +0100:
>
>> Dass höhrt und liesst mann doch immer wider! Du hasst verlohren!
>
> Bist Du für die schlechten Beispiele bei Deinen Schulservern zuständig?
> ];->
> Aber Du hast die Katastrophe leider recht gut getroffen...
>
> BTW, wie hoch liegt der Prozentsatz der Analphabeten derzeit in
> Deutschland? Und wie hoch der Prozentsatz der Legastheniker vom Rest?
>
> Nichts gegen Legastheniker, die nichts dafürkönnen - aber müssen die alle
> ausgerechnet Programmierer werden? Oder sind das gar keine _echten_
> Legastheniker, sondern bloß schlampig? Warum müssen die dann alle
> ausgerechnet Programmierer werden?
>

Sei nicht so streng.

Ich habe Beispiele von Schreibfehlern in meinen Programmen erlebt, die über
Jahre hinweg hunderten von Anwendern nicht aufgefallen sind.

Der Grund ist einfach: Derjenige, der die Programme erstellt ist von allen
Personen am schlechtesten geeignet, Schreibfehler zu finden. Er *erwartet*
einen bestimmten Text und sieht selbst schlimme Schreibfehler nicht.

Ich habe in den letzten 2 Jahren ein Programm komplett neu geschrieben, das
vor über 15 Jahren angefangen wurde.
Und ich habe darin Schreibfehler gefunden, die von Anfang an vorhanden
waren.

Andererseits sind andere Leute auch nicht unbedingt viel besser geeignet.
Wenn sie den Programm-Kontext kennen, dann haben sie ebenfalls eine
bestimmte Erwartung, welche Texte sie vorfinden werden.

Deswegen sollten am Besten immer Leute ein Programm auch auf Schreibfehler
hin testen, die es *nicht* kennen.

[Bernd Hohmann]

On 29.12.2011 22:23, Peter Köhlmann wrote:

> Ich habe Beispiele von Schreibfehlern in meinen Programmen erlebt, die über
> Jahre hinweg hunderten von Anwendern nicht aufgefallen sind.

Dann sind Deine Programme gut denn sie leiten den Anwender so durch,
dass er nach einer Weile die Software "Blind" bedienen kann.

Kritisch wirds erst bei Fehlermeldungen, aber die liest auch wiederum
keiner ;-)

Bernd

[Helmut Hullen]

Hallo, Sieghard,

Du meintest am 29.12.11:

>> Dass höhrt und liesst mann doch immer wider! Du hasst verlohren!

> Bist Du für die schlechten Beispiele bei Deinen Schulservern
> zuständig?
];->>

Klar!

> Nichts gegen Legastheniker, die nichts dafürkönnen - aber müssen die
> alle ausgerechnet Programmierer werden? Oder sind das gar keine
> _echten_ Legastheniker, sondern bloß schlampig? Warum müssen die dann
> alle ausgerechnet Programmierer werden?

Das fasziniert mich immer wieder: ausgerechnet Leute (Männer/Jünglinge),
die programmieren, schlampen bei der deutschen Sprache.

[Helmut Hullen]

Hallo, Bernd,

Du meintest am 29.12.11:

> Dann sind Deine Programme gut denn sie leiten den Anwender so durch,
> dass er nach einer Weile die Software "Blind" bedienen kann.

> Kritisch wirds erst bei Fehlermeldungen, aber die liest auch wiederum
> keiner ;-)

Auch wenn es nix mit Linux zu tun hat: vor einigen Tagen hat mich ein
Telekom-Hotliner (geduldig, aber bestimmt) durch die Wieder-
Inbetriebnahme meines UMTS-Sticks geführt. Vor einigen Monaten hatte der
schon mal brav funktioniert, und nach 2 Monaten Nichtbenutzung hatte ich
den 1 Trick vergessen.

Kern: die Stick-Software meldete während des Hochlaufens "PIN gesperrt";
da hatte ich (nach der Vergessens-Pause) natürlich abgebrochen. Bei der
vom Hotliner geführten Wieder-Inbetriebnahme kam ich nicht dazu, wieder
"abbrechen" zu drücken, weil der Hotliner mir nicht glauben wollte, dass
dort "gesperrt" stand; also lief der Start weiter, die Meldung wurde
durch schönere abgelöst. Und dann erschien ein zweites Mal "PIN
gesperrt", wieder zum Erstaunen des Hotliners. Auch die verschwand nach
kurzer Zeit wieder ...

Der Hotliner und ich haben uns darauf geeinigt, dass nur die Meldung
falsch sei ...

[Bernd Hohmann]

On 29.12.2011 22:45, Helmut Hullen wrote:

> Das fasziniert mich immer wieder: ausgerechnet Leute (Männer/Jünglinge),
> die programmieren, schlampen bei der deutschen Sprache.

Du kennst die Leistungsfähigkeit aktueller Entwicklungsumgebungen und
Compiler nicht - da wird selbst angemotzt wenn Du mit Mundgeruch vor dem
Editor sitzt.

Sobald es aber um den Bereich zwischen " und " geht, alten sie alle die
Klappe :-)

Bernd

[Gernot Zander]

Hi,

in de.comp.os.unix.linux.misc Peter Köhlmann <peter-k...@t-online.de> wrote:
> Sei nicht so streng.

> Ich habe Beispiele von Schreibfehlern in meinen Programmen erlebt, die über
> Jahre hinweg hunderten von Anwendern nicht aufgefallen sind.

Die Überschrift einer Webseite... ich weiß nicht, wie viele Besucher,
aber gemeldet hat es keiner.

> Deswegen sollten am Besten immer Leute ein Programm auch auf Schreibfehler
> hin testen, die es *nicht* kennen.

Das gilt für Selbstgeschriebenes generell. Texte lässt man auch dann
korrekturlesen, wenn man es selbst eigentlich könnte.

mfg.
Gernot

--
<hi...@gmx.de> (Gernot Zander) *Keine Mailkopien bitte!*
UNIX(R) - Fungizid einer neuen Wirkstoffklasse gegen Halmbruch und
Halmbasiskrankheiten. Mit guten Nebenwirkungen gegen Mehltau und
Rhynchosporium (http://www.novartis-agro.de/produkte/frueh/produkt8.htm)

[Bernd Hohmann]

On 29.12.2011 23:19, Gernot Zander wrote:

> Das gilt für Selbstgeschriebenes generell. Texte lässt man auch dann
> korrekturlesen, wenn man es selbst eigentlich könnte.

Dafür bräuchte man aber erstmal die Kompetenz, seine eigene Inkompetenz
zu erkennen - siehe "Dunning Kruger Effekt".

Das erinnert mich immer wieder an eine Bekannte, die mit aller Gewalt
Schriftstellerin werden will. Ihre Kurzgeschichten sind im Prinzip gut,
nur verhaut sie stets irgendwas. Ein Lektorat könnte das im Einvernehmen
mit dem Autor ausbügeln, nur lehnt sie jedwelche Eingriffe in ihre Texte ab.

Bernd

[Peter Köhlmann]

Bernd Hohmann wrote:

> On 29.12.2011 22:23, Peter Köhlmann wrote:
>
>> Ich habe Beispiele von Schreibfehlern in meinen Programmen erlebt, die
>> über Jahre hinweg hunderten von Anwendern nicht aufgefallen sind.
>
> Dann sind Deine Programme gut denn sie leiten den Anwender so durch,
> dass er nach einer Weile die Software "Blind" bedienen kann.

Ich gebe mir große Mühe, die Programme "narrensicher" zu machen

Und es ist ein erheblicher Aufwand nötig, die Ablaufsteuerung so zu
gestalten, dass keine Fehlbedienungen möglich sind.
Das macht es so problematisch: Jemand, der um die Voraussetzungen weiss,
wird das Programm richtig bedienen.
Aber nur jemand der völlig ahnungslos ist wird Lücken in der Steuerung
aufdecken

> Kritisch wirds erst bei Fehlermeldungen, aber die liest auch wiederum
> keiner ;-)

Auch dort werden Schreibfehler eher nicht entdeckt

[Claus-Dieter Schulmann]

Sieghard Schicktanz wrote:

> Du schriebst am Wed, 28 Dec 2011 21:46:05 +0100:
>
>> > Es heisst im Deutschen übrigens "es ergibt Sinn" oder "es ist
>> > sinnvoll"; nicht "es macht Sinn".
>>
>> Danke, Du darfst diesen Fehler auch gerne rot anmahlen. ;-)
> ^
> Also da muß ich doch schon sehr bitten - um _die_ Zeit habe ich meine
> Schuhe zwar schon ausgezogen, aber es wäre doch deutlich freundlicher,
> Mitlesern _solche_ Haken zu ersparen!

Das Abschalten des Ironie-Detektors mit dem Ausziehen der Schuhe zu kuppeln
ist nicht immer hilfreich. :-)

Claus-Dieter

[Claus-Dieter Schulmann]

Juergen Ilse wrote:

> Claus-Dieter Schulmann <Claus-Diete...@web.de> wrote:
>> Du würdest zwei unabhängige DHCP-Server in Betrieb nehmen, die die
>> gleichen IP-Adressen vergeben?
>> Also in der Art:
>> DHCP-Server 1: Pool von 192.168.1.44 -192.168.1.96
>> DHCP-Server 2: Pool von 192.168.1.44 -192.168.1.96
>
> Ich habe schon einmal eine so etwas konfiguriert, und es funktioniert
> seit Jahren einwandfrei (die DHCP-Server sind die in 2 Cisco 6500
> Switches). Und es handelt sich jeweils um groessere Netze mit mehreren
> hundert Clients. Ja, das funktioniert.

Damit verschenkst Du eine Sicherheitsebene.
Du musst Dich dann darauf verlassen, dass entweder die DHCP-Clients mit ARP
oder die DHCP-Server mit Ping aktive Adressen erkennen.
Da DHCP-Declines bei dieser Methode selbst im Regelbetrieb vorkommen sind
sie für die Fehlererkennung nicht mehr nutzbar.

Woher weisst Du eigentlich, dass Deine Methode funktioniert?
Folgerst Du das aus der Tatsache, dass sich niemand beklagt und Du bisher
keine Fehlfunktionen festgestellt hast, die offensichtlich auf doppelte IP-
Adressen zurückzuführen sind?

Nach Deiner Methode hat sich ISC mit DHCP-Failover unnötig Arbeit gemacht.
Ich folgere daraus: Du gehst davon aus, dass Du Dich mit DHCP besser
auskennst als ISC.
Liege ich da richtig?

Da ich genügend Geräte gesehen habe, die noch nicht einmal mit Lease-
Verlängerungen umgehen können will ich mich auch lieber nicht darauf
verlassen, dass alle DHCP-Clients ARP-Tests machen.

Auf die Ping-Tests der DHCP-Server will ich mich auch nicht verlassen seit
Microsoft bei seiner Firewall Pings standardmässig abschaltet.

Zudem habe ich schon DHCP-Clients gesehen, die selbst nach dem DHCP-Release
noch auf ein Ping antworten. Solche Geräte haben wir zu Hunderten im
Einsatz (leider).

Ich persönlich trenne deshalb die Pools der DHCP-Server.
Dann signalisiert wenigstens jedes DHCP-Decline einen Fehler, dem ich
nachgehen kann. Ich habe also eine Chance, Fehler zu erkennen.

Ich habe mir (in Anlehnung an das Robustheitsprinzip von Jon Postel in RFC
793) einfach angewöhnt, unnötige Risiken zu vermeiden.

Claus-Dieter

[Juergen Ilse]

Hallo,

Claus-Dieter Schulmann <Claus-Diete...@web.de> wrote:

> Juergen Ilse wrote:
>> Claus-Dieter Schulmann <Claus-Diete...@web.de> wrote:

>>> Du wï¿œrdest zwei unabhï¿œngige DHCP-Server in Betrieb nehmen, die die

>>> gleichen IP-Adressen vergeben?
>>> Also in der Art:
>>> DHCP-Server 1: Pool von 192.168.1.44 -192.168.1.96
>>> DHCP-Server 2: Pool von 192.168.1.44 -192.168.1.96
>> Ich habe schon einmal eine so etwas konfiguriert, und es funktioniert
>> seit Jahren einwandfrei (die DHCP-Server sind die in 2 Cisco 6500
>> Switches). Und es handelt sich jeweils um groessere Netze mit mehreren
>> hundert Clients. Ja, das funktioniert.
> Damit verschenkst Du eine Sicherheitsebene.

Nein.

> Du musst Dich dann darauf verlassen, dass entweder die DHCP-Clients mit ARP
> oder die DHCP-Server mit Ping aktive Adressen erkennen.

Letzteres macht die Cisco-Implementierung ohnehin.

> Woher weisst Du eigentlich, dass Deine Methode funktioniert?

In dem Netz befinden sich Hunderte von IP-Telefonen, die nicht sauber
funktionieren wuerden, wenn es einen Adresskonflikt geben wuerde, und
der Kunde hat davon noch nie etwas bemerkt. Ausserdem habe ich in der
Liste der DGCP-Leases beider Switches noch nie einen Eintrag fuer die
selbe Adresse auf beiden Switches gesehen.

> Zudem habe ich schon DHCP-Clients gesehen, die selbst nach dem DHCP-Release

> noch auf ein Ping antworten. Solche Gerï¿œte haben wir zu Hunderten im
> Einsatz (leider).

Warum sollte das ein Peoblem sein, solange das Netz gross genug ist um
noch genuegend freie Adressen zu bieten?

[Claus-Dieter Schulmann]

Juergen Ilse wrote:

> Claus-Dieter Schulmann <Claus-Diete...@web.de> wrote:
>> Juergen Ilse wrote:
>>> Claus-Dieter Schulmann <Claus-Diete...@web.de> wrote:

>>>> Du würdest zwei unabhängige DHCP-Server in Betrieb nehmen, die die

>>>> gleichen IP-Adressen vergeben?
>>>> Also in der Art:
>>>> DHCP-Server 1: Pool von 192.168.1.44 -192.168.1.96
>>>> DHCP-Server 2: Pool von 192.168.1.44 -192.168.1.96
>>> Ich habe schon einmal eine so etwas konfiguriert, und es funktioniert
>>> seit Jahren einwandfrei (die DHCP-Server sind die in 2 Cisco 6500
>>> Switches). Und es handelt sich jeweils um groessere Netze mit mehreren
>>> hundert Clients. Ja, das funktioniert.
>> Damit verschenkst Du eine Sicherheitsebene.
>
> Nein.

Doch weil Du Dich auf die (nicht immer funktionierende) automatische
Fehlererkennung verlassen musst und weil es unnötige Fehlermeldungen gibt;
Windows-DHCP-Server melden dann "Bad address".

>> Du musst Dich dann darauf verlassen, dass entweder die DHCP-Clients mit
>> ARP oder die DHCP-Server mit Ping aktive Adressen erkennen.
>
> Letzteres macht die Cisco-Implementierung ohnehin.

Bei Windows-DHCP-Servern kann man Ping-Tests abschalten.
Ich vermute, Microsoft hatte einen Grund dafür, das abschaltbar zu machen.

>> Woher weisst Du eigentlich, dass Deine Methode funktioniert?
>
> In dem Netz befinden sich Hunderte von IP-Telefonen, die nicht sauber
> funktionieren wuerden, wenn es einen Adresskonflikt geben wuerde, und
> der Kunde hat davon noch nie etwas bemerkt. Ausserdem habe ich in der
> Liste der DGCP-Leases beider Switches noch nie einen Eintrag fuer die
> selbe Adresse auf beiden Switches gesehen.

Du machst es also an der Tatsache fest, dass der Kunde nichts meldet.
Ich bin sicher, dass es sehr viele Endanwender gibt, die doppelte IP-
Adressen nicht als doppelte IP-Adressen erkennen.
Da nach dem Neustart alles funktioniert werden solche Fehler oft gar nicht
erst gemeldet.

Bei einem Netz mit IP-Telefonen, Windows- und Linux-DHCP-Clients in
verschiedenen Versionen mit und ohne Firewall und dazu noch Drucker von
einer Handvoll Hersteller in mehr als 20 Modellen ziehe ich jede Möglichkeit
der Risikominimierung in Erwägung.
Die Entflechtung der IP-Adressbereiche ist da hilfreich.
Du siehst es offensichtlich anders.

>> Zudem habe ich schon DHCP-Clients gesehen, die selbst nach dem

>> DHCP-Release noch auf ein Ping antworten. Solche Geräte haben wir zu

>> Hunderten im Einsatz (leider).
>
> Warum sollte das ein Peoblem sein, solange das Netz gross genug ist um
> noch genuegend freie Adressen zu bieten?

Ein Problem ist das nicht wenn man davon absieht, dass es unnötige
Fehlermeldungen "Bad address" o. ä. gibt.
Diese unnötigen Fehlermeldungen erhöhen die Wahrscheinlichkeit, die
relevanten Fehlermeldungen zu übersehen.

Claus-Dieter

[Marc Haber]

Heiko Schlenker <hsc...@gmx.de> wrote:
>Aus RFC 768 'User Datagram Protocol':
>| This protocol assumes that the Internet Protocol (IP) is used as
>| the underlying protocol.

Dagegen sprechen Dinge wie RFC1791.

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[Fitje Claasen]

Hi,
Mist,
Ubuntu grad mal wieder nutzen wollten und es
hatte eben schon wieder kein Netz :-((
- und ich vergessen, wies zu aktivieren und
muss wieder nach Win um hier reinzuschauen ...

das lief Mal stabiler. Irgendwas geht da schief.
Ub ist als Konsumer-Os m.E. jedenfalls immer noch nur grenzwertig
nutzbar ...
> ...
Gruß, Fitje

[Volker Gringmuth]

Fitje Claasen wrote:

> Ubuntu grad mal wieder nutzen wollten und es
> hatte eben schon wieder kein Netz :-((

Wie wird denn dein Netzwerkadapter (=NW-Karte) verwaltet, über den
Gnome-Networkmanager (Icon in der Taskleiste) oder mit Systemmitteln
(Eintrag in der /etc/network/interfaces und so weiter)?

Wenn der GUI-NW-Manager sie verwalten will, aber da was verstellt ist, dann
kannst du sie natürlich immer noch wie beschrieben von Hand starten, aber
beim nächsten Booten versucht es der NW-Manager wieder.

Schau dir also mal die Einstellungen des Gnome-Network-Managers an.

Und wirf ergänzend einen Blick in die /etc/network/interfaces: Ein
NW-Adapter, der vom NW-Manager verwaltet werden soll (bei dir also
wahrscheinlich eth0), darf in der interfaces nicht vorkommen.
Überhaupt gar nicht. Sonst faßt der NW-Manager den nicht an.


vG

[Fitje Claasen]

hi,
> ...

das verstehe ich nur mit viel Phantasie ... hab im Alltag mit anderem,
Tiefbau oder Philosophie oder ... zu tun ...
gibts nicht irgendwo Button + Haken "autom. einwählen", "per Hand
einwählen"? :-) wäre schön, wenns so wäre.

Was steht den wo nach ner Standard-Installation?
- da Ubuntu ja ein gutes Jahr stabil ins Netz kam und es das aus irgend
einem Grund plötzlich nicht mehr macht.

mir fällt nur auf, dass an einem "Icon in der Taskleiste" -
"Viertelkreise", die bei Smartphones WLAN anzeigen - ein rotes
Ausrufezeichen nebensteht. Das war damals _glaube_ ich nicht.


soweit Danke! werd schauen/suchen, wenn ich wieder "drüben" bin.
Grüße, Fitje
> ...

[Volker Gringmuth]

Fitje Claasen wrote:

> gibts nicht irgendwo Button + Haken "autom. einwählen", "per Hand
> einwählen"? :-) wäre schön, wenns so wäre.

Hier mißverstehst du Linux wirklich. Das System ist nicht als geschlossenes
Ganzes entwickelt (und kann auch nicht, solange es modular bleiben soll,
d.h. solange man jeden Unterbau mit jeder Benutzerschnittstelle kombinieren
kann).

Der "ursprüngliche" Weg ist der "zu Fuß" über die Konfigurationsdatei.
Schließlich kann Linux auch ganz ohne grafische Oberfläche laufen (ist bei
praktisch jedem Serversystem sogar der Fall, wozu sollte man dafür
Ressourcen verbraten). Das war den Schöpfern von Gnome zu kompliziert für
Otto Normal, und sie erschufen den Network-Manager, der das automatisch
kann. Damit es aber keine Konflikte gibt, kümmert sich der NW-Manager nur
um die Schnittstellen, die in der Zu-Fuß-Konfiguration nicht vorkommen.

Einsehbar?

Das sind Dinge, die der Linux-Neuling wirklich erfragen muß, da führt kein
Weg dran vorbei. Ist also keine Schande, andererseits, wir mußten das alle
erst lernen.

> Was steht den wo nach ner Standard-Installation?
> - da Ubuntu ja ein gutes Jahr stabil ins Netz kam und es das aus irgend
> einem Grund plötzlich nicht mehr macht.

Nach der Installation von (K)Ubuntu steht in der /etc/network/interfaces
keine der "normalen" Netzwerkschnittstellen (sondern nur das
loopback-Interface "lo"). Die werden alle vom NW-Manager verwaltet.


vG

[Gernot Fink]

In article <jemg21$oh3$1...@online.de>,

Fitje Claasen <fi...@nomail.invalid> writes:
> - da Ubuntu ja ein gutes Jahr stabil ins Netz kam und es das aus irgend
> einem Grund plötzlich nicht mehr macht.

Default ist dass sich der Networkmanager per DHCP die Daten vom Router holt
und dann online ist.
Falls du von einer liveCD installiert hast Boote einfach mal von der die
bei der Installation erwendet wurde.
Geht die auch nicht ist es vermutlich ein Hardwareproblem.

--
MFG Gernot