MS-DOS clients mit NetBIOS an Linux?
Bernd Laengerich
ich habe schon etwas im Web gesucht, aber nichts gefunden. Konkrete
Frage:
MS-DOS Clients haben lediglich eine Ethernet-Karte und NetBIOS (_KEIN_
IP-Stack). Gibt es eine Möglichkeit diese an Linux anzubinden? Soweit
ich es verstanden habe, setzt NetBIOS direkt auf LLC auf.
Ich habe nur SMB und NetBIOS/IP für Linux gefunden, das ist mir klar daß
das geht (läuft hier).
Danke, Bernd
--
// c.a.r.u.s. Information Technology AG POS EFT Systeme //
// Bernd Längerich Bernd.La...@carus.de //
// Bornbarch 9 Phone: +49-40-51435-0 //
// D-22848 Norderstedt Fax: +49-40-51435-111 //
Patrick Kursawe
> ich habe schon etwas im Web gesucht, aber nichts gefunden. Konkrete
> Frage:
>
> MS-DOS Clients haben lediglich eine Ethernet-Karte und NetBIOS (_KEIN_
> IP-Stack).
Du verwechselst NetBIOS und NetBEUI.
NetBEUI ist so toll, daß Microsoft selbst es bei Windows XP nicht mehr
unterstützt.
> Gibt es eine Möglichkeit diese an Linux anzubinden?
Es gibt TCP/IP für DOS. Zumindest bei NT4 Server wars unter "Clients" dabei.
Tschüs, Patrick
Bernd Laengerich
> > MS-DOS Clients haben lediglich eine Ethernet-Karte und NetBIOS (_KEIN_
> > IP-Stack).
>
> Du verwechselst NetBIOS und NetBEUI.
Kann sein. Ich kenne das Zeugs nicht. Laut www.protocols.com:
"A NetBIOS session is a logical connection between any two names on the
network. It is described in IBM - Local Area Network Technical Reference
1990 DA-30/31 Protocol Operating Manual. It is usually encapsulated over
LLC."
Da dort auch ein Framing beschrieben ist, habe ich es mal als Protokoll
eingeordnet. Mag sein, daß der Rahmen nur die Softwareschnittstelle ist.
> NetBEUI ist so toll, daß Microsoft selbst es bei Windows XP nicht mehr
NetBEUI ist doch NetBIOS extended user interface, also nur eine
komfortablere Oberfläche? Laut einer Protokolltapete setzt NetBEUI auf
RAS oder NDIS auf.
Weiterhin sind doch inzwischen wohl alle NetBIOS-Sachen in TCP/IP selbst
mit drin, und MS benutzt inzwischen für alle Sachen ja IP als Basis (mit
der tollen Geschichte alles mögliche mit Broadcasts zu posaunen).
> Es gibt TCP/IP für DOS. Zumindest bei NT4 Server wars unter "Clients" dabei.
Fällt aus. Rahmenbedingungen z.B. aus Speicherplatzgründen.
Ich hatte auch nix gefunden aber dachte mir ich frage mal die Experten.
Bernd
Patrick Kursawe
> NetBEUI ist doch NetBIOS extended user interface, also nur eine
> komfortablere Oberfläche? Laut einer Protokolltapete setzt NetBEUI auf
> RAS oder NDIS auf.
> Weiterhin sind doch inzwischen wohl alle NetBIOS-Sachen in TCP/IP selbst
> mit drin, und MS benutzt inzwischen für alle Sachen ja IP als Basis (mit
> der tollen Geschichte alles mögliche mit Broadcasts zu posaunen).
Ich kenn das ungefähr so, wie es auf http://www.mouse.demon.nl/ckp/lanwan/msnetb.htm
beschrieben ist.
Was WinDOSen meistens machen ist NetBIOS over TCP/IP - also ein anderer
"Unterbau". Mit "drin sein" hat das nicht viel zu tun.
Tschüs, Patrick
Michael Prinzing
>Patrick Kursawe schrieb:
>
>> NetBEUI ist so toll, daß Microsoft selbst es bei Windows XP nicht mehr
>
>NetBEUI ist doch NetBIOS extended user interface, also nur eine
>komfortablere Oberfläche? Laut einer Protokolltapete setzt NetBEUI auf
>RAS oder NDIS auf.
Mit einer Benutzeroberfläche hat NetBEUI nichts zu tun. Es päppelt
vielmehr nur die NetBIOS-Pakete soweit auf, daß sie sich über ein
Netzwerk verschicken lassen. Dabei fehlt aber beispielsweise jede
softwaremäßige Adreßvergabe (vgl. IP-Adressen bei TCP/IP), stattdessen
wird direkt die Hardwareadresse der Netzwerkkarte benutzt. Routen läßt
sich NetBEUI daher auch nicht, aber dafür ist es schnell. Zumindest
schneller als NetBIOS über TCP/IP.
>Weiterhin sind doch inzwischen wohl alle NetBIOS-Sachen in TCP/IP selbst
>mit drin, und MS benutzt inzwischen für alle Sachen ja IP als Basis (mit
>der tollen Geschichte alles mögliche mit Broadcasts zu posaunen).
Bei NetBIOS über TCP/IP übernimmt TCP/IP lediglich den Transport der
NetBIOS-Pakete, so wie es auch andere Daten transportieren kann. Aber
wie TCP/IP für sich alleine noch keine Dienste zur Verfügung stellt,
übernimmt es auch keine der NetBIOS-Funktionen.
Michael
Jens Link
> Patrick Kursawe schrieb:
> > Es gibt TCP/IP für DOS. Zumindest bei NT4 Server wars unter
> > "Clients" dabei.
>
> Fällt aus. Rahmenbedingungen z.B. aus Speicherplatzgründen.
Wie waere es mit IPX? Der alte Netware Client verbraucht deutlich
weniger Speicher als der MS IP Stack. Auf der Linux Seite koennte man
marsnwe nehmen.
Jens
--
I just found out that the brain is like a computer.
If that's true, then there really aren't any stupid people.
Just people running Windows.
Bernd Laengerich
> Ich kenn das ungefähr so, wie es auf http://www.mouse.demon.nl/ckp/lanwan/msnetb.htm
> beschrieben ist.
Das deckt sich mit dem was ich so gelesen habe.
> "Unterbau". Mit "drin sein" hat das nicht viel zu tun.
Ich meinte: Wenn man bei M$ TCP/IP als Protokoll installiert, so ist
dabei der ganze NetBIOS-Krempel dabei.
Bernd
Bernd Laengerich
> Wie waere es mit IPX? Der alte Netware Client verbraucht deutlich
> weniger Speicher als der MS IP Stack. Auf der Linux Seite koennte man
> marsnwe nehmen.
Gute Frage. Hatte ich auch schon angeregt. Mal sehen was dabei
herauskommt. Leider dürfen die Clients wohl nicht angefasst werden. Der
Auftraggeber scheint wohl evtl. so weit zu gehen, diese Protokoll
implementieren zu lassen. Leider habe ich dazu noch überhaupt keine
Ahnung, wie ich das einbinden könnte. Und irgendwie müsste das ja wohl
auf ein socket-interface abgebildet werden, so a la
PROTO_NETBIOS/AF_NETBIOS. Mal sehen, wenn es eine bezahlte Einarbeitung
in Linux-Network-Development wird, warum nicht ;-)
Bernd
Bernd Laengerich
> Wie waere es mit IPX? Der alte Netware Client verbraucht deutlich
Ein neues Stichwort ist aufgetaucht: LANtastic, was auch immer dies ist.
Schon wieder googeln...
Bernd
Bernd Laengerich
> Dann weiss ich nicht, was das fuer eine Protokoll-Tapete ist, denn
> RAS und NDIS sind keine Protokolle.
Die scheint auch nix zu taugen. "Protokolle und Dienste der
Informationstechnologie" vom Interest-Verlag. Hängt bei uns einige Räume
weiter bei Kollegen.
> Ich habe den Eindruck, dass Du grundsaetzlich nicht ganz
> trittsicher in Netzwerkprotokollen bist. Das verstaerkt meinen
> Rat, dass Du nicht gleich einen Kunden als Versuchskaninchen
> fuer Deine erste Implementierung eines solchen nehmen solltest...
Danke für Deine Ratschläge, auch aus den Parallelpostings. Ich würde
mich nur freuen, wenn Du etwas die Schärfe aus der Diskussion nähmest.
Ich bin keineswegs trittsicher in Netzwerkprotokollen, dies habe ich
auch nie behauptet. Wäre ich das, würde ich hier nicht fragen. Ich gehe
auch keineswegs davon aus, daß ich diese Implementierung vornehmen
werde. Ich möchte nur verstehen, um überhaupt die Machbarkeit
einschätzen zu können. Unser Verkauf (Vertrieb klingt so negativ)
verkauft dem Kunden natürlich alles was er möchte (es geht IMHO darum
n>10.000 clients _NICHT_ umstellen zu müssen/dürfen) und ist derzeit
tatsächlich der Meinung, Alan Cox persönlich für diese Implementierung
einzukaufen. Ich sage da nichts zu. Ich verstehe allerdings, daß der
Kunde mit Sicherheit bereit ist einiges für den gesparten
Umstellungsaufwand dann zentralseitig auszugeben.
Bernd
Bernd Laengerich
> Das ist doch dummes Zeug, entschuldige bitte.
Das erzähle ich unserem Verkauf auch.
> Was ist denn das fuer ein Auftraggeber?
Den Namen werde ich hier nicht nennen.
> Weil Du Dich ueberschaetzt,
Ja? Wo?
> die Aufgabe unterschaetzt und derweil
Ja? Wo?
> Deinen Ruf ruinierst und vernuenftige Kunden nicht bedienen kannst.
Mein Ruf kann nicht ruiniert werden weil ich keinen habe. So einfach ist
das.
> Zu einem serioesen Programmierer gehoert es auch, unserioese
> Kunden auch mal abzulehnen.
Definiere seriös. Wenn die Hermes-Bürgschaft positiv ist, nimmt die
Firma in der ich beschäftigt bin IMHO jeden Auftrag an, der irgendwie
abwickelbar ist. Auch in meinen oder den Augen anderer unsinnige. Wenn
das Projektteam einen Aufwand schätzt und der Kunde bereit ist diesen zu
zahlen, why not? Pech, wenn die Schätzung arg daneben liegt.
[snip]
Den Rest habe ich mal weiter nach oben geleitet, vielleicht beeinflusst
das die Entscheidungsfindung dort jedenfalls etwas. Der Prophet im
eigenen Land taugt bekanntlich nichts.
Bernd
Georg Kreyerhoff
> Danke für Deine Ratschläge, auch aus den Parallelpostings. Ich würde
> mich nur freuen, wenn Du etwas die Schärfe aus der Diskussion nähmest.
> Ich bin keineswegs trittsicher in Netzwerkprotokollen, dies habe ich
> auch nie behauptet. Wäre ich das, würde ich hier nicht fragen. Ich gehe
> auch keineswegs davon aus, daß ich diese Implementierung vornehmen
> werde. Ich möchte nur verstehen, um überhaupt die Machbarkeit
> einschätzen zu können. Unser Verkauf (Vertrieb klingt so negativ)
> verkauft dem Kunden natürlich alles was er möchte (es geht IMHO darum
> n>10.000 clients _NICHT_ umstellen zu müssen/dürfen) und ist derzeit
> tatsächlich der Meinung, Alan Cox persönlich für diese Implementierung
> einzukaufen.
Es gibt wohl schon eine NetBEUI-Implementierung fuer Linux:
http://www.heise.de/newsticker/data/ps-29.02.00-000
Auf der Homepage des dort erwaehnten Herstellers finde ich allerdings
nichts darueber. Ausserdem muessten die natuerlich noch Programme
wie samba etc. netbeui-faehig gemacht werden.
Georg
Michael Prinzing
>mi...@gmx.net meinte am 13.11.01
>zum Thema "Re: MS-DOS clients mit NetBIOS an Linux?":
>>
>> Mit einer Benutzeroberflaeche hat NetBEUI nichts zu tun. Es paeppelt
>> vielmehr nur die NetBIOS-Pakete soweit auf, dass sie sich ueber ein
>> Netzwerk verschicken lassen. Dabei fehlt aber beispielsweise jede
>> softwaremaessige Adressvergabe (vgl. IP-Adressen bei TCP/IP),
>> stattdessen wird direkt die Hardwareadresse der Netzwerkkarte
>
>Das ist bei jedem Protokoll so, dass die Dienste der Schicht 2
>nutzt. Uebrigens auch bei IP, IPX, Appletalk, Vines IP....
Aber bei IP haben die darüberliegenden Protokolle nichts mehr mit
MAC-Adressen zu tun, sondern verwenden nur noch die IPs, also die
softwaremäßig vergebenen Adressen.
>Was Du als softwaremaessige Adressvergabe bezeichnist, ist wohl
>die Tatsache, dass IP fuer aufliegende Protokolle einen vollstaendig
>eigenen Adressraum definiert.
Ich denke, wir meinen dasselbe.
Bei IP kann ich Adressen softwaremäßig vergeben, eben die IP-Adressen.
Dasselbe geht beispielsweise bei IPX über Netzwerk- und Knotennummer.
Diese Adressen sind frei wählbar, also insbesondere unabhängig von der
MAC der Netzwerkkarte. Im Gegensatz zu MAC-Adressen, die zufällig und
fest vergeben sind, kann man die softwaremäßigen Adressen wie z.B. IPs
daher systematisch vergeben und so mehrere Teilnehmer zu einem
logischen Netzwerk zusammenfassen (bei IP über den Netzwerk-Teil der
IP, bei IPX über die Netzwerknummer). Erst das ermöglicht es, Router zu
bauen, die für jede beliebige Zieladresse zumindest den nächsten Router
auf dem Weg dorthin kennen.
Bei NetBEUI entfällt diese Adreßvergabe, und man kann weder aus einem
NetBIOS-Rechnernamen auf die MAC-Adresse des Empfängers schließen noch
ist es möglich, anhand einer MAC-Adresse das Netz herauszufinden, in
dem der dazugehörige Rechner liegt. Daher kann auch keine Route dorthin
bestimmt werden.
Das führt im Endeffekt dazu, daß sich per NetBEUI nur Rechner innerhalb
derselben Broadcast-Domain unterhalten können.
>Der Grund dafuer ist, dass in einem
>Internetwork die Adressraeume der Subnetze durchaus nicht einheitlich
>sein muessen und sich daher die Notwendigkeit ergibt, einen einheitlichen
>Adressraum zu schaffen, damit die Rechner innerhalb eines Internetwork
>ueberhaupt miteinander kommunizieren koennen. Sonst koennte z.B.
>eine Ethernetstation, deren Adressen aus 48 Bit bestehen, etwas schlecht
>mit einer ISDN Station, deren Adressen aus bis zu 16 (? wie ist die
>gaengige ITU Vorschrift?) Dezimalziffern besteht, gar nicht kommunizieren.
Damit die beiden miteinander reden können, braucht man einen Router,
und um einen Router bauen zu können, braucht man frei festzulegende
Adressen. Insofern Zustimmung.
Michael
Juergen P. Meier
>Jein. AFAIK ist bei IPX die Knotennummer die Hardware-Adresse.
>Das waere ein wesentlicher Nachteil von IPX, weil da eben unterschiedlich
>lange Hardwareadressen unterschiedlich lange IPX-Adressen zur
>Folge haetten. Man haette eben _keine_ einheitliche Adressierung
>auf Schicht 3. Mit Ethernet und TR klappt das ja alles. Aber dann...
Vielleicht kann Lutz hier mehr Licht in die Sache bringen ;)
>hardwaremaessig vergebene Adresse ist, und dann noch eine innerhalb
>des Firmenadressraumes weltweit eindeutige Nummer.
Leider nicht bei allen Herstellern... (ich denk da z.b. an 3com, aber
auch an SUN [z.b. bei Netras mit dual-HME, QFEs haben ja individuelle
und eindeutige MACs])
>> softwaremaessigen Adressen wie z.B. IPs daher systematisch vergeben
>> und so mehrere Teilnehmer zu einem logischen Netzwerk
>> zusammenfassen (bei IP ueber den Netzwerk-Teil der IP, bei IPX ueber
>> die Netzwerknummer). Erst das ermoeglicht es, Router zu bauen, die
>
>Wobei der Netzwerkteil der IP-Adresse eben variabel lang sein kann.
>Halt bis zu 31 bit.
>Eben _dadurch_ kann ich die Dinge strukturieren (im Gegensatz
>zu IPX, wo ich die Netznummern _nicht_ strukturieren kann).
Deswegen meinte ich ja auch, das sich IPX nicht in aehnlicher weise
skalieren laesst wie dies bei IP mit dem Internet der Fall ist, aber
Lutz war da anderer Meinung. Leider(?) habe ich mich mit IPX nie wirklich
ausfuehrlich befasst, um das abschaetzen zu koennen.
>> fuer jede beliebige Zieladresse zumindest den naechsten Router auf
>> dem Weg dorthin kennen.
>
>Wobei das Netznummerngefummel mit IPX jedes sinnvolle Aggregieren
>von vornherein unmoeglich macht.
>
>> Bei NetBEUI entfaellt diese Adressvergabe, und man kann weder aus
>> einem NetBIOS-Rechnernamen auf die MAC-Adresse des Empfaengers
>> schliessen noch ist es moeglich, anhand einer MAC-Adresse das Netz
>> herauszufinden, in dem der dazugehoerige Rechner liegt. Daher kann
>> auch keine Route dorthin bestimmt werden.
>
>Es entfaellt da nicht nur die Adressvergabe.
>
>Es entfaellt vor allem die Adresstransparenz, die ich hier zu
>erlaeutern versucht habe. Es ist nicht nur die Frage, ob
>ich ein Netz rauskriegen kann oder nicht. Der Punkt ist doch,
>dass ohne Adresstransparenz (in dem Sinne, dass anhand der Adresse
>die Art des Subnetzes _nicht_ erkennbar ist, meinethalben nenne
>das Subnetztransparenz, das waere richtiger) Internetworking
>gar nicht geht.
Ich fuerchte da hast du nicht mehr ganz recht (und ich glaube jetzt
auch Lutz aussage nachvollziehen zu koennen), Diese Subnetztransparenz,
die ja durch Classfull routing eingefuehrt wurde, existiert defacto
laengst nicht mehr (im Internet). Du kannst eben nicht mehr davon
ausgehen, das 1.2.3.123/28 ueber die gleichen Routen erreichbar ist,
wie 1.2.4.91/24. Wie ein Netz erreichbar ist, legen die ASe fest,
und da die Transparenz laengst nicht mehr Existent ist, brauchen Backbone
und Corerouter riesige Mengen Speicher fuer ihre Routingtabellen und fette
CPUs fuer ihre Routingprotokolle.
Das was mir persoenlich an IP so gut gefallen hat ist die Tatsache, das
es sich ohne groessere probleme so leicht vom Transparenten Classfull
auf CIDR umstellen liess.
Bei IPX haette man nur von Anfang an Routingprotokolle, viel Speicher und CPU
in den Routern benoetigt. (sprich: wo das noch sehr viel teurer war als heute)
>> Das fuehrt im Endeffekt dazu, dass sich per NetBEUI nur Rechner
>> innerhalb derselben Broadcast-Domain unterhalten koennen.
>
>Den Begriff habe ich hier vermieden. Zumal NetBEUI natuerlich
>auch ueber Switches geht. Aber es ist richtig. Jetzt muessten
>wir dann allerdings noch sauber zwischen Broadcast-Domain
>und Collision-Domain unterscheiden, letztere kann naemlich
>unterschiedlich sein. Die Broadcast-Domain natuerlich nicht.
Switches trennen keine Broadcastdomains. Switches trennen lediglich
Collisiondomains. NetBEUI funktioniert eben _nur_ in einer Broadcastdomain.
Es ist eben nicht Routbar.
>> [ethernet NIC redet mit ISDN NIC]
>> Damit die beiden miteinander reden koennen, braucht man einen
>> Router, und um einen Router bauen zu koennen, braucht man frei
>
>Man braucht erstmal einheitlich definierte Adressen, weil
>die sich sonst nicht ansprechen koennen. Im skizzierten Szenario
>ist _das_ das Problem.
Addressen, die dann aber auch geroutet werden koennen muessen.
>Ueber Router rede ich hier bewusst erst in zweiter Instanz. Erstmal
>geht es darum, die Probleme auf den Punkt zu bringen, die
>IP ueberhaupt notwendig machen und daraus abzuleiten, was ein
>Internetworkingprotokoll ueberhaupt leisten muss.
Das laesst sich bei IP halt wunderschoen in der Praxis anschauen ;)
IPX hab ich selbst nur einmal geroutet gesehen, das ist schon lange her.
Juergen
--
J...@lrz.fh-muenchen.de
"This World is about to be Destroyed!"
Bernd Laengerich
> Wenn Bernds Auftraggeber 10.000 Knoten hat, ist zu vermuten,
> dass die nicht alle an einem Ort sind. Und dass man diese
Richtig.
> Knoten nicht alle ueber genau ein einziges Subnetz erreicht,
> sondern auch mal ueber Weitverkehrsnetze an die jeweiligen
> Standorte ranmuss. Wenn ich hier _kein_ routefaehiges Protokoll,
Nein. Es geht um etwa 1000 Standorte mit jeweils etwa 10 clients.
Die Standorte werden dann über IP zu einer Zentrale vernetzt. Zugriff
auf die clients ist nicht erforderlich, es braucht nichts geroutet zu
werden. Es geht darum, die vorhandenen clients nicht anzufassen.
Ich habe bereits über Alan Cox den Kontakt zu dem derzeitigen
"Maintainer" Arnaldo Carvalho de Melo der Kernelpatches für NetBEUI
hergestellt, seiner Aussage nach wird zumindest der LLC-stack wohl in
den Kernel integriert und es gibt wohl einen grösseren Releasewechsel in
samba, er spricht mit Andrew über die Abstraktion vom Transport
protokoll. Die Kenntnis über diese Patches selbst ist wohl ziemlich rar
gesät, auch gängige Suchmaschinen haben da nichts zu herausgespuckt. Der
Link zu Procom verläuft im Sande.
> Wenn man sich diese Socketschnittstelle mal etwas naeher ansieht,
> und auch sieht, dass dort verschiedene Adressklassen vorgesehen
> sind (was freilich AFAIK nicht genutzt wird), so faellt auf,
Doch doch, unter HP/UX wird damit z.B. auch X.25 (AF_CCITT)
angesprochen, das funktioniert wunderbar.
Unter MS-DOS ist die NetBIOS-Schnittstelle auch nur der Interrupt 0x5C,
den kamm man auch problemlos auf ein ioctl() legen. Das Zusammenbasteln
der NCB-requests ist auch unter DOS selbst zu erledigen.
> Und eine Anwendung auf Linux, die gegen eine solche API programmiert
> waere, muesste so programmiert sein, dass sie genau mit den NetBIOS
> Funktionen von DOS zurechtkommt.
>
> So etwas zu machen, ist nicht unmoeglich. Es ist aber ein schlichter
> Irrsinsaufwand.
Sehe ich nicht so. Wir haben die NetBIOS-Schnittstelle von DOS damals
benutzt, die Sourcen gibt es, die lassen sich leicht umsetzen. Die
DOS-Version war übrigens schon portiert, das Erstimplantat war unter
AOS/VS auf einer DG.
> fuer Serverprogramme hast, und wie man die ueberhaupt auf Linux
> portieren will. Oder will man die neu schreiben? Oder woran
Das (Serverprogramm) haben wir bereits. Läuft auf DOS, Windows
(3.1/95/NT/2000), HP/UX, AIX, Linux, SCO-Unix, Sinix, OS/2
Bernd
Holger Marzen
> Den Rest habe ich mal weiter nach oben geleitet, vielleicht beeinflusst
> das die Entscheidungsfindung dort jedenfalls etwas. Der Prophet im
> eigenen Land taugt bekanntlich nichts.
Dann engagiere jemanden von außerhalb (=Experte) für einen Workshop.
Sorge dafür, dass er mindestens 2000 EUR verlangt. Dessen Meinung wird
dein Boss akzeptieren. Willst du sicher gehen, sage dem Experten, dass
er 4000 EUR verlangen soll.
Immo 'FaUl' Wehrenberg
> Der Lutz, der immer meine Sprueche sammelt? (Nebst Spruechen anderer
> Leute?) Der Lutz, zu dem gerade (d.h. seit mehreren Jahren)
> eine Man-Page geschrieben wird?
[...]
> Wer ist denn jetzt bloss Lutz? Irgendwie kriege ich da die
> Kurve nicht. Ich denke jetzt immer an Lutz Donnerhacke...
Ich denke genau der ist gemeint.
FaUl
end
This article does not support incompatible and broken newsreader.
--
.... der Geschäftskundenvertrieb trägt den Namen
weil er aktiv Geschäftskunden vertreibt .....
Michael Prinzing
>Wobei ich mich gestern spontan gefragt habe, ob OS/2 nicht schon
>eine NetBIOS Schnittstelle drin hat, das wuerde ich naemlich ganz
>massiv erwarten.
OS/2 beherrscht unter anderem NetBEUI und NetBIOS over TCP/IP, und
selbstverständlich gibt es dazu auch die entsprechenden APIs. Um diese
in eigenen Programmen verwenden zu können, braucht man lediglich das
'Developer's Toolkit for OS/2 Warp Version 4' von IBM, das die
entsprechenden Include-Dateien und Import-Bibliotheken enthält.
Michael
Michael Prinzing
>mi...@gmx.net meinte am 15.11.01
>zum Thema "Re: MS-DOS clients mit NetBIOS an Linux?":
>
>Wenn ich mir dann aber wieder die regelmaessig auftauchenden
>T-DSL-Debatten hier anschaue, na, dann geht es zwar nicht
>mehr um MAC-Adressen auf IP-Ebene, dafuer aber um MTUs auf
>TCP Segmentebene, das ist aehnlich schlimm.
>
>Es gibt eben TCP/IP-Implementierungen, und es gibt eben
>kompletten Schrott. Und das, was hier im Zusammenhang
>mit T-DSL immer wieder dargestellt wird, scheint fuer mich
>in die Kategorie Schrott zu gehoeren. Eben _weil_ es die
>Schichten nicht so realisiert, wie sich das gehoert.
Wobei hier das Problem meines Wissens in der defekten Software der
Telekom-Router liegt, die zu große Pakete einfach in die Tonne treten,
anstatt dem Absender per ICMP 'destination unreachable, must fragment'
die richtige MTU zukommen zu lassen.
>> Bei IP kann ich Adressen softwaremaessig vergeben, eben die
>> IP-Adressen. Dasselbe geht beispielsweise bei IPX ueber Netzwerk-
>> und Knotennummer. Diese Adressen sind frei waehlbar, also
>
>Jein. AFAIK ist bei IPX die Knotennummer die Hardware-Adresse.
Stimmt, die Knotennummer kann man bei IPX nicht frei vergeben. Bleibt
also nur die frei wählbare Netzwerknummer, aber die genügt immerhin, um
mehrere Rechner zu einem Netz zusammenzufassen und um ein Routing
definieren zu können.
>Das waere ein wesentlicher Nachteil von IPX, weil da eben unterschiedlich
>lange Hardwareadressen unterschiedlich lange IPX-Adressen zur
>Folge haetten.
Ich bin mir nicht ganz sicher, aber nach der mir vorliegenden
Dokumentation gibt es keine unterschiedlich langen IPX-Adressen.
Zumindest die Doku von Novell spricht nur von genau 6 Bytes langen
Knotennummern.
>> insbesondere unabhaengig von der MAC der Netzwerkkarte. Im Gegensatz
>> zu MAC-Adressen, die zufaellig und fest vergeben sind, kann man die
>
>Na, sie sind weder zufaellig noch fest vergeben. Eine MAC Adresse
>kann ich auf fast jedem NIC frei programmieren. Was
>fest vergeben ist, ist die Hardwareadresse, die defaultmaessig
>MAC Adresse ist. Und die ist nicht zufaellig sondern hat einen
>festen Aufbau. Wie jede MAC-Adresse.
Mit "zufällig" meinte ich, daß es bei den MAC-Adressen der Rechner
eines logischen Netzen im Normalfall keine Gemeinsamkeiten gibt und daß
es daher nicht möglich ist, anhand der MAC-Adresse zu entscheiden, in
welchem Netz sich der entsprechende Rechner befindet oder welche Route
gar zu diesem Netz führt. Es war nicht gemeint, daß es _keinerlei_
System bei der Vergabe der MAC-Adressen gibt.
>> softwaremaessigen Adressen wie z.B. IPs daher systematisch vergeben
>> und so mehrere Teilnehmer zu einem logischen Netzwerk
>> zusammenfassen (bei IP ueber den Netzwerk-Teil der IP, bei IPX ueber
>> die Netzwerknummer). Erst das ermoeglicht es, Router zu bauen, die
>
>Wobei der Netzwerkteil der IP-Adresse eben variabel lang sein kann.
>Halt bis zu 31 bit.
>
>Eben _dadurch_ kann ich die Dinge strukturieren (im Gegensatz
>zu IPX, wo ich die Netznummern _nicht_ strukturieren kann).
Warum ist es wichtig, _unterschiedlich_ lange Netznummern haben zu
können (auf Layer 3)? Gut, bei TCP/IP entscheidet die Länge der
Netznummer über die maximale Anzahl der möglichen Rechner in diesem
Netz. Aber die konstant langen Netznummern bei IPX tun das nicht.
Die Struktur, die ich hier gemeint habe, besteht darin, eine
Gemeinsamkeit zwischen den Rechnern eines logischen Netzes zu schaffen,
damit man schon anhand ihrer Adresse feststellen kann, in welchem Netz
sie liegen und welche Route ggf. dorthin führt. Und dafür eignen sich
auch die Netznummern bei IPX, aber nicht die MAC-Adressen.
>> >koennen. Sonst koennte z.B. eine Ethernetstation, deren Adressen
>> >aus 48 Bit bestehen, etwas schlecht mit einer ISDN Station, deren
>> >Adressen aus bis zu 16 (? wie ist die gaengige ITU Vorschrift?)
>> >Dezimalziffern besteht, gar nicht kommunizieren.
>>
>> Damit die beiden miteinander reden koennen, braucht man einen
>> Router, und um einen Router bauen zu koennen, braucht man frei
>
>Man braucht erstmal einheitlich definierte Adressen, weil
>die sich sonst nicht ansprechen koennen. Im skizzierten Szenario
>ist _das_ das Problem.
Ich denke, man kann das Problem von beiden Seiten sehen. Du sagst, man
braucht softwaremäßig zu vergebende Adressen, damit man einen
einheitlichen Adreßraum hat, weil sich die beiden sonst gar nicht
adressieren können.
Ich sage, wenn die beiden miteinander reden können sollen, brauche ich
sowieso einen Router, und für diesen brauche ich ein routingfähiges
Protokoll, was auf Layer 3 (nicht: zwischen Layer 2 und 3) eine
Adressierung auf MAC-Ebene ausschließt und ebenfalls softwaremäßig
vergebene Adressen erfordert.
Michael
frank paulsen
> Wobei hier das Problem meines Wissens in der defekten Software der
> Telekom-Router liegt, die zu große Pakete einfach in die Tonne treten,
> anstatt dem Absender per ICMP 'destination unreachable, must fragment'
> die richtige MTU zukommen zu lassen.
du irrst.
--
frobnicate foo
Michael Prinzing
>mi...@gmx.net meinte am 17.11.01
>zum Thema "Re: MS-DOS clients mit NetBIOS an Linux?":
>
>Es hat einfach keinen Sinn, wenn man ein Privat-TCP/IP machen
>will und die einschlaegigen Standards nicht kennt. Und wer
>hier Pakete mit DF-Bit durch die Gegend schickt, und dann
>noch hofft, dass _irgend_ etwas funktioniert, der kennt
>eben die einschlaegigen Standards nicht, sondern hat
>drei bis vier falsche Handbuecher von Laien fuer Laien gelesen
>und huckt nun in der Ecke und ist mukschig, weil er es nicht
>verkraftet, dass er auf den Poller geknallt ist.
Ich hab mich ja nicht beklagt, und ich kann mit dem Problem auch ganz
gut leben. Allerdings mache ich hier kein Privat-TCP/IP, und trotzdem
verläßt die überwiegende Anzahl aller Pakete meinen Rechner mit
gesetztem DF-Bit. Das habe ich mir aber nicht ausgesucht, und ich kann
auch recht wenig daran ändern.
>> Stimmt, die Knotennummer kann man bei IPX nicht frei vergeben.
>> Bleibt also nur die frei waehlbare Netzwerknummer, aber die genuegt
>> immerhin, um mehrere Rechner zu einem Netz zusammenzufassen und um
>> ein Routing definieren zu koennen.
>
>Die Rechner in einem Subnetz sind zunaechst einmal
>durch das Subnetz "zusammengefasst". Da muss ich nicht mehr
>extra etwas "zusammenfassen".
Und wie außer über die Netzwerknummer definierst Du ein Subnetz?
>> >Das waere ein wesentlicher Nachteil von IPX, weil da eben
>> >unterschiedlich lange Hardwareadressen unterschiedlich lange
>> >IPX-Adressen zur Folge haetten.
>>
>> Ich bin mir nicht ganz sicher, aber nach der mir vorliegenden
>> Dokumentation gibt es keine unterschiedlich langen IPX-Adressen.
>> Zumindest die Doku von Novell spricht nur von genau 6 Bytes langen
>> Knotennummern.
>
>Und wie sind diese definiert? Nach meiner Kenntnis durch
>die hardwaremaessige Knotenadresse.
Richtig. Zumindest bei Ethernet und Token Ring.
>Nun kann man natuerlich dem religioesen Glauben verfallen, alle
>Netzwerke der Welt wuerden mit Token Ring und Ethernet laufen,
>inklusive ATM Netze, Telefonnetze, Funknetze, Kartoffelnetze....
>
>Meine Guete, solche Patzer in "Dokumentationen" sind es,
>die mich regelmaessig auf sauer fahren. Salt Lake City ist
>zwar ein wenig aus der Welt, aber meines Wissens hat man
>sogar in Utah schon Telefon, da _weiss_ man, dass ein Rechner
>nicht zwingend 6 Byte lange Adressen hat.
Ich hatte noch keinen Grund, mich mit IPX auf Hardware mit nicht 6
Bytes langen Hardwareadressen zu beschäftigen, daher kann ich dazu
nichts genaues sagen. Aber es spricht doch nichts dagegen, auf Layer 3
sechs Bytes lange Adressen zu verwenden, auch wenn dies nicht die Länge
der Adressen der darunterliegenden Hardware ist. Bei Ethernet stimmen
diese Längen überein, daher ist es naheliegend, die MAC-Adresse auch
auf Layer 3 zu verwenden, und die Implementierungen, die ich kenne,
machen das auch so. Aber zwingend ist es IMHO nicht.
>Und wenn man sich
>schon auf Ethernet und Token Ring kapriziert, weil man was
>anderes nicht koennen will, dann redet man wenigstens von 48 bit,
>weil man dann in der Schule gelernt hat, dass bei Ethernet und
>Token Ring die Adressbits im A.-Byte genau gegenlaeufig interpretiert werden
>und daher eine Definition mit Bytes die Adresssyntax nicht praezise
>definiert.
Es ging ja nur um die Länge der Adresse, da spielt die Anordnung der
Bytes zunächst keine Rolle. Und zu der Angabe der Bytes einer
Knotennummer gehört selbstverständlich ein 'M' oder ein 'L' für MSB
bzw. LSB first. Das erwähnt die Dokumentation von Novell, aber das ist
hier doch nicht entscheidend.
>Wirklich. Diese "Dokumentationen" werden mir von Mal zu Mal
>lieber. Gross das Maul aufreissen, man haette was "dokumentiert",
>1000 Seiten Papier vollfurzen, und wenn man dann reinschaut,
>dann riecht das zwar etwas streng, aber drinstehen tut nichts,
>und das, _was_ drinsteht ist auch noch falsch oder ungenau.
>
>Es ist schon kein Zufall, dass Jon Postel allein fuer IP mehrere
>Dutzend Seiten gebraucht hat, um das _sauber_ zu definieren.
Moment. Ich hatte doch geschrieben, daß ich aufgrund der mir
vorliegenden Dokumentationen nichts genaueres sagen kann. Und bei der
Dokumentation handelt es sich lediglich um die mit Netware 3.12
gelieferten Unterlagen, noch dazu in einer fürchterlichen deutschen
Übersetzung. Diese nehmen für sich nicht in Anspruch, IPX perfekt zu
definieren, sondern dienen nur dazu, einen Netware-Rechner aufzusetzen.
Sorry, aber mehr habe ich zu IPX eben nicht.
>> Mit "zufaellig" meinte ich, dass es bei den MAC-Adressen der Rechner
>> eines logischen Netzen im Normalfall keine Gemeinsamkeiten gibt und
>
>Die gibt es auch im Ausnahmefall nicht. Wenn der Hersteller
>nicht geschlampt hat, darf es keine doppelt vergebene Hardwareadresse
>geben.
Wieso doppelt? Eine Gemeinsamkeit könnte doch auch sein, daß die ersten
x Bits der Hardwareadresse bei allen Rechnern in einem logischen Netz
übereinstimmen, so wie es die ersten x Bits der IP-Adresse tun. Dann
könnte man nämlich diese ersten gemeinsamen Bytes der Hardwareadresse
als Netzwerknummer betrachten. Und dann wäre selbst NetBEUI
routingfähig.
>> dass es daher nicht moeglich ist, anhand der MAC-Adresse zu
>> entscheiden, in welchem Netz sich der entsprechende Rechner
>> befindet oder welche Route gar zu diesem Netz fuehrt. Es war nicht
>
>Wie bitte? Allein dadurch, dass eine MAC-Adresse weltweit
>eindeutig ist, ist es _gerade_ moeglich, dass Du weisst, wo
>der Rechner steht, wenn Du seine MAC-Adresse kennst.
Wir reden aneinander vorbei. Wenn ich Dir die MAC-Adresse
00:02:B3:17:A8:D3 gebe, dann kannst Du mir was über den Hersteller der
Karte sagen, aber Du weißt nicht, wo sie steckt und auf welchem Weg Du
ein Paket zu dieser Karte bringen kannst. Nicht alleine anhand der
MAC-Adresse.
Zu einer x-beliebigen IP kannst Du aber sagen, wohin Du Pakete für
diese Adresse schicken mußt.
>> gemeint, dass es _keinerlei_ System bei der Vergabe der MAC-Adressen
>> gibt.
>
>Du, das System ist sogar meist geradezu erschuetternd einfach:
>Da wird einfach von Karte zu Karte ein Zaehler hochgezaehlt.
Wie oben: ein System in diesem Zusammenhang wäre beispielsweise, daß
die ersten x Bits der Adresse bei allen Rechnern eines Netzes
übereinstimmen. Daß hinter den Hardwareadressen ein System steckt, ist
schon klar. Aber dieses System hat mit der Struktur des Netzes nichts
zu tun, und in diesem Sinne sind die in einem bestimmten Netz
vorkommenden MAC-Adressen zufällig.
>Es geht nicht um die Laenge der Netznummer, es geht darum,
>dass ich in ein und derselben Adresse den Netzteil und den
>Hostteil mit unterschiedlicher Granularitaet interpretieren
>kann. Ein Backbonerouter sieht moeglicherweise nur 8 bit
>als Netznummer an und sieht den Rest als Hostadresse,
>ein Router drei Hops weiter trifft die Aufteilung ganz
>anders.
>
>Hier koennen Routen aggregiert bzw. Netze unterteilt werden.
>Die Netznummern von IPX erlauben keine Aggregation.
>
>Konsequenz: Routingtabellen werden sehr gross, das Routing
>skaliert schlecht.
Mir leuchtet immer noch nicht so recht ein, wieso das mit IPX nicht
gehen soll. Vorausgesetzt die Netzwerknummern bei IPX würden ebenso
systematisch vergeben wie bei TCP/IP, dann spricht aus meiner Sicht
nichts dagegen, einen Router zu bauen, der beispielsweise nur anhand
der ersten 2 Bytes der Netzwerknummer routet. Der darauffolgende Router
könnte die ersten 3 Bytes betrachten und den Datenstrom feiner
aufteilen. Andersherum könnte man so auch mehrere Routen
zusammenführen. Wie gesagt, vorausgesetzt, daß die Netzwerknummern
systematisch vergeben wurden und die Nummern der zusammenzuführenden
Routen beispielsweise mit denselben Bytes beginnen. Oder was übersehe
ich da?
>Was Du tust, ist, Loesungen anzubieten, in der Hoffnung,
>dass irgendwelche Probleme dazu passen.
Es war und ist nicht meine Absicht, Lösungen anzubieten. Wenn wir mal
an den Anfang des Threads zurückgehen, dann habe ich lediglich
beschrieben, was NetBEUI ist und erklärt, daß es keine softwaremäßig
vergebenen Adresse kennt.
Michael
Bernd Laengerich
> Na, dann wird es da halt genutzt, warum auch nicht, X.25 ist ja auch
> ein schoenes altes Protokoll (die Dokumentation ist ca. 20 Minuten
> zu Fuss von mir auf dem Uff-Kirchhof verfuegbar und auch noch auf
> weiteren Friedhoefen, daher heisst das ja auch "Verteilte Datenbank"),
> warum sollte das nicht gehen? Klar. Tut.
Ich weiß zwar nicht, was Du nun wieder gegen X.25 hast.
> Du brauchst keinen Kernel anzufassen, sparst Dir also das Geld
> fuer Alan Cox. (Und Alan Cox kann in der Zeit was vernuenftiges machen.)
Hättest Du gelesen, wüsstest Du, daß Alan nichts dabei programmiert.
> Da Du das ganze ohnehin fuer genau drei Anwendungen programmierst,
> naemlich die erste, die letzte und die einzige Anwendung, die
> das je braucht, implementierst Du NetBEUI / NetBIOS genau
Es scheint mehr Leute zu geben die das gebrauchen können. Sonst hätte
das nicht schon jemand gemacht.
> Abstuerzen leben muessen. Es sind diese ueberaus kurzweiligen
> Reboots, die das Leben von Kernelprogrammierern so angenehm bereichern :-)
Schade, komme ich darum herum.
> Na, dann klopf das Zeug doch in Euer Anwendungsprogramm rein,
> setze Frame Sockets drunter, und dann seid Ihr doch gluecklich :-)
Häh? Dann fehlt ja der ganze LLC/NetBEUI-Krempel. Bei Dir wird es auch
wirr.
Unter MS-DOS, OS/2 und Win gibt es ein NetBIOS-API welches den Zugang zu
NetBEUI bereitstellt. Genau diese Interface bedienen wir in den
Varianten, die NetBIOS/NetBEUI nutzen. Ich hab' jetzt noch einmal extra
nachgesehen, wir nutzen:
MS-DOS OS/2 AOS/VS
NetBiosOpen init5c
NetBiosClose
NetBios(*) NetBiosSubmit int5c
(*) Assembler-Source, Aufruf von Int 5Ch
Genutzte Requests:
ADDNAM_P
DLTNME_P
CALL_P
RESET_P
HANGUP_P
ADPRES_P
0xF8 (? FindName)
LISTEN_P
SEND_P
RCV_P
Ansonsten ist unsere favorisierte Schnittstelle ein TCP/IP stream
socket.
> mit OS/2 nicht out of the box? Dann packt Ihr auf Eure Server
> halt OS/2 drauf mitsamt existierendem Programm und NetBIOS
> und einem durchaus kalkulierbaren (weil nicht vorhandenem)
> Portierungsaufwand?
Weil wir OS/2, MS-DOS und Win3.1/95 nicht mehr als Serverbetriebssystem
für neue Projekte unterstützen. Seit einigen Jahren. Trotzdem laufen
Installationen weiterhin beim Kunden. Allerdings mit teilweise
veralteter Software.
Ich habe keine Lust mit Dir zu streiten, ich hoffe, das richtige
gefunden zu haben, werde es testen und dann sehen, was unser Kunde sagt.
Andere Lösungen bleiben selbstverständlich weiterhin im Rennen.
Bernd
frank paulsen
>> mit OS/2 nicht out of the box? Dann packt Ihr auf Eure Server
>> halt OS/2 drauf mitsamt existierendem Programm und NetBIOS
>> und einem durchaus kalkulierbaren (weil nicht vorhandenem)
>> Portierungsaufwand?
>
> Weil wir OS/2, MS-DOS und Win3.1/95 nicht mehr als Serverbetriebssystem
> für neue Projekte unterstützen. Seit einigen Jahren. Trotzdem laufen
> Installationen weiterhin beim Kunden. Allerdings mit teilweise
> veralteter Software.
ich verstehe das jetzt richtig: erst kappt ihr den kunden den support
fuer ihre funktionierenden server, und dann sucht ihr haenderingend
nach einer moeglichkeit, einen buzzword-server ans humpeln zu bringen,
um die kunden dann zu migration zu bewegen?
sigh.
--
frobnicate foo
Bernd Laengerich
> ich verstehe das jetzt richtig: erst kappt ihr den kunden den support
> fuer ihre funktionierenden server, und dann sucht ihr haenderingend
> nach einer moeglichkeit, einen buzzword-server ans humpeln zu bringen,
> um die kunden dann zu migration zu bewegen?
<eg>
Darauf bin ich noch gar nicht gekommen. Sehr gute Idee! ;-)
Aber im Ernst: Wir haben Kunden teilweise Windows-NT-Server inkl.
Hardware geschenkt, damit wir endlich die veralteten Systeme ablösen
konnten. Die Pflege mehrerer Jahre alter MS-DOS basierter Softwarestände
wäre teurer für uns gewesen als die Hardware plus OS. Einige haben sich
dieses Schrittes verweigert, die nutzen die alte Software ohne
Softwarepflege unsererseits weiter.
Dieser Kunde ist übrigens neu für uns, wahrscheinlich hat er bei allen
anderen auf Granit gebisen mit seiner Anforderung "Client nicht
anfassen".
Bernd
frank paulsen
> Aber im Ernst: Wir haben Kunden teilweise Windows-NT-Server inkl.
> Hardware geschenkt, damit wir endlich die veralteten Systeme ablösen
> konnten. Die Pflege mehrerer Jahre alter MS-DOS basierter Softwarestände
> wäre teurer für uns gewesen als die Hardware plus OS. Einige haben sich
> dieses Schrittes verweigert, die nutzen die alte Software ohne
> Softwarepflege unsererseits weiter.
ihr praktiziert da was, was in der aktuellen EDV-welt nicht unueblich
ist: ihr diktiert eine komponente eines systemes, ohne die
auswirkungen auf bereits existierende installationen zu analysieren,
fallt salopp gesagt auf die schnauze, und wollt jetzt mit viel geld
irgendwas geradeziehen.
ich habe deiner signatur entnommen, dass ihr wohl im POS bereich
taetig seid, und ich kenne die situation da hinreichend genau um sagen
zu koennen: wenn der kunde nicht leichtfertig seine clients umbumsen
will, dann hat er fuer einen durchschnittlichen EDV-kunden schon
erstaunlich viel verstanden. wenn er kein TCP/IP auf seinen POS-kisten
haben will, dann hat er sogar ne verdammte menge verstanden.
an der stelle hinzugehen, ein Server-OS zu waehlen, dann zu merken,
dass es nicht tut, und dann das Server-OS zu patchen ist einfach
humbug.
ich kenne jetzt nicht genug von aktuellen NT-versionen, aber ich
bezweifle stark, dass MS wirklich die Netbios-schnittstelle
hingerichtet haben soll: zumindest unter NT4 war sie noch da und
funktionierte auch.
wenn NT da jetzt wirklich was fehlt, bleibt immer noch OS/2, das ist
als Server noch nicht abgekuendigt, Mama Blue vertickt dir ab 100
Lizenzen das teil mit kusshand (und problemlos funktionierendem
supportvertrag), die kisten unterstuetzen dann auch TCP/IP und
hastenichtgesehen und weissnichwas, was um himmels willen soll es da
bringen, ein OS da reinzudruecken, dem eine elementare schnittstelle
fehlt?
das ist keine technisch sinnvolle entscheidung, die ihr da getroffen
habt, das sind die auswirkungen sogenannter 'strategischer'
entscheidungen auf schlipsebene, und sowas fuehrt im regelfall zu
maximaler kundenunzufriedenheit mit anschliessendem aufkauf oder
insolvenz.
der typische spruch eines POS-kunden ist doch: "Ich will ganz einfach
kassieren". der will keine buzzwords und 'technologien', der will das
seine kisten 24/7 mitzaehlen, was so an geld rein und rauslaeuft, und
das moeglichst pfennig^wcentgenau und mit minimalen personalaufwand.
der hat jetzt auch ganz andere probleme als 'Linux', der hat drei bis
fuenf monate doppeltes geld durchzuschleusen, und seine modifikationen
an den clients wird er tunlichst darauf beschraenken, vernuenftige
kassenladen da hinzubekommen. der waere mit dem klammerbeutel
gepudert, wenn er gerade jetzt (d.h. innerhalb in der naechsten sechs
monate) auch noch die software und damit zwingend das userinterface
wechselt, die kassierer kommen naemlich vom weihnachtsstress nahtlos
in den eurostress.
das ist ein beschissener zeitpunkt fuer bastelloesungen, wobei es fuer
bastelloesungen eh keinen vernuenftigen zeitpunkt gibt.
--
frobnicate foo
Patrick Kursawe
> ich kenne jetzt nicht genug von aktuellen NT-versionen, aber ich
> bezweifle stark, dass MS wirklich die Netbios-schnittstelle
> hingerichtet haben soll: zumindest unter NT4 war sie noch da und
> funktionierte auch.
Davon war auch nie die Rede. NetBEUI ist eingemottet worden.
Kann man aber trotzdem noch benutzen, selbst bei NT 5.1:
http://support.microsoft.com/support/kb/articles/Q301/0/41.ASP
Tschüs, Patrick
Bernd Laengerich
Ich antworte jetzt noch _einmal_ auf den allgemeinen Thread hier. Frank,
nimm daher nicht alles was ich hier schreibe persönlich. Es gilt auch
für andere.
Zunächst glaube ich nicht, daß ich mich für irgendwelche Entscheidungen
die andere treffen hier rechtfertigen muß. Schon gar nicht wenn ein
Kunde anfragt, ob wir etwas bestimmtes realisieren können, und ich mich
daraufhin nach bestem Wissen und Gewissen versuche zu informieren, ob
die Lösung, die er favorisiert, vernünftig, umsetzbar und dem Problem
adäquat ist. Es ist eigentlich schade, daß die Diskussion, die ich als
technisch angefangen hatte, so sehr auf die Schiene "Was ihr macht ist
Mist/veraltet/unseriös. Keiner will das." abdriftet, ohne daß überhaupt
Randbedingungen und Hintergrundinformationen bekannt sind.
> ihr praktiziert da was, was in der aktuellen EDV-welt nicht unueblich
> ist: ihr diktiert eine komponente eines systemes, ohne die
> auswirkungen auf bereits existierende installationen zu analysieren,
> fallt salopp gesagt auf die schnauze, und wollt jetzt mit viel geld
> irgendwas geradeziehen.
Nein, nein und nocheinmal nein. Bitte lies meine Postings genauer. Wir
haben in der Vergangenheit z.B. MS-DOS als Serverbetriebssystem
unterstützt. D.h. wir haben Software die Serverdienste bereitstellt auf
MS-DOS basierten Rechnern betrieben. Seit einiger Zeit haben wir die
Entwicklung für MS-DOS eingestellt. Es waren auch nur noch wenige
Kunden. Wir haben den Kunden dann gesagt, daß zukünftige Versionen nicht
mehr unter MS-DOS arbeiten werden. D.h. Erweiterungen, die vom Kunden
beauftragt werden, müssen mit einer Migration einhergehen. Die Wahl der
Serverplattform blieb dem Kunden überlassen. Einigen guten Kunden haben
wir im Rahmen von beauftragen Erweiterungen die Hardware und Windows NT
als Low-End-Server mit dem Auftrag verrechnet, d.h. effektiv hat der
Kunde den Rechner geschenkt bekommen.
Und ja: Dem Kunden ist das OS weitgehend egal. Weitgehend deshalb, weil
einige Rahmenbedingungen die Wahl einschränken, so haben z.B. Kunden die
eine AS/400 als client einsetzen derzeit lediglich die Möglichkeit über
das Paket ClientAccess/400 Windows als Serverplattform zu wählen.
Und wenn ein Kunde sagt: ich möchte die Software auf Plattform xyz mit
dem Schlamassel-OS 2.7 haben, und er bezahlt die Portierung, machen wir
auch das. Er bekommt allerdings vorher gesagt, daß es sich dann um eine
kundenspezifische Lösung handelt und diese nicht im normalen
Produktrelease wiederspiegelt, d.h. spätere Versionen sind evtl. neu zu
portieren.
> ich habe deiner signatur entnommen, dass ihr wohl im POS bereich
Upps, ist die wohl irgendwo mit durchgerutscht.
> taetig seid, und ich kenne die situation da hinreichend genau um sagen
> zu koennen: wenn der kunde nicht leichtfertig seine clients umbumsen
> will, dann hat er fuer einen durchschnittlichen EDV-kunden schon
> erstaunlich viel verstanden. wenn er kein TCP/IP auf seinen POS-kisten
> haben will, dann hat er sogar ne verdammte menge verstanden.
Dann weißt Du auch, das sehr viele clients eben noch mit MS-DOS
arbeiten. Wobei immer mehr Linux mit großem Erfolg im Kassenbereich
eingesetzt wird. _Dieser_ Kunde hat eben auch MS-DOS mit einem
peer-to-peer Netzwerk zu Backupzwecken. Einen Server gibt es da noch
nicht. Und unsere Software schon gar nicht. Auch nicht unter einem von
uns nicht mehr für Neuinstallationen unterstützten OS. Es kann also -wie
bereits gesagt- keine Rede davon sein, dem Kunden die Pistole auf die
Brust zu setzen.
> an der stelle hinzugehen, ein Server-OS zu waehlen, dann zu merken,
> dass es nicht tut, und dann das Server-OS zu patchen ist einfach
> humbug.
Siehe oben.
> wenn NT da jetzt wirklich was fehlt, bleibt immer noch OS/2, das ist
OS/2 ist eine der vorgeschlagenen Alternativen. Obwohl wir es offiziell
nicht mehr unterstützen.
> das ist keine technisch sinnvolle entscheidung, die ihr da getroffen
'Wir' haben keine Entscheidung getroffen. Punkt. siehe oben. Die
Entscheidungsphase steht noch aus. Zu Schlipsträgern: Es entscheiden
ohnehin _nur_ die Strategen. Letztlich ist ohnehin immer das Management
schuld. Die Techniker können nur beraten.
> der typische spruch eines POS-kunden ist doch: "Ich will ganz einfach
> kassieren". der will keine buzzwords und 'technologien', der will das
Das erzähle mal den Kunden. Die sind teilweise sowas von
Spielzeugvernarrt, da wird von den Schlipsträgern das bunteste und
lauteste Gerät gekauft. Die letzte Vorführung einer anderen Abteilung
hier im Hause habe ich auch mit einem Zucken der Augenbrauen zur
Kenntnis genommen: Mindestanforderung der Kasse (Touchscreen) 512MB
Hauptspeicher. Proz. 1GHz. Soviel möchte ich mal in einer meiner
Entwicklungsmaschinen haben. Ich 'kämpfe' gerade mit einem Kundensystem
um unsere neueste Software einigermaßen performant laufen zu lassen:
486SX25, 8MB RAM, SCO-Unix. Es geht so. Die 8MB sind zu wenig, deshalb
wird geswappt. Das versuche ich einigermaßen in den Griff zu bekommen.
Ist natürlich Mist, der Kunde wurde falsch beraten (von SNI Mitte der
80er als er das Kassensystem anschaffte), keiner will das wirklich, wir
zocken den ab usw. Andere Kunden haben die gleiche Software auf einer
Mehrprozessor-RS6000 unter AIX. Soviel zur Bandbreite.
> das ist ein beschissener zeitpunkt fuer bastelloesungen, wobei es fuer
> bastelloesungen eh keinen vernuenftigen zeitpunkt gibt.
Danke daß Du ohne uns zu kennen unsere Projekte und Produkte als
Bastellösungen klassifizierst. Unsere Kunden denken sicherlich alle auch
so.
Wie gesagt, das war jetzt mein letztes Posting auf diesen Thread.
Weiterempfehlen mag ich diese Newsgroup irgendwie nicht, aus anderen NG
bin ich einen anderen Tonfall gewohnt. Beschimpfen lassen kann ich mich
auch woanders.
Bernd
M. Buchenrieder
[...]
>ich kenne jetzt nicht genug von aktuellen NT-versionen, aber ich
>bezweifle stark, dass MS wirklich die Netbios-schnittstelle
>hingerichtet haben soll: zumindest unter NT4 war sie noch da und
>funktionierte auch.
[...]
Kleine Korrektur am Rande: Es geht um NetBEUI. Das ist in
XP nicht mehr als Installationsoption vorhanden, kann aber
mit etwas Tricksen weiterhin genutzt werden. Siehe Microsoft KB.
>das ist ein beschissener zeitpunkt fuer bastelloesungen, wobei es fuer
>bastelloesungen eh keinen vernuenftigen zeitpunkt gibt.
Wie wahr.
Michael
--
Michael Buchenrieder * mi...@scrum.greenie.muc.de * http://www.muc.de/~mibu
Lumber Cartel Unit #456 (TINLC) & Official Netscum
Note: If you want me to send you email, don't munge your address.
Michael Prinzing
>mi...@gmx.net meinte am 18.11.01
>zum Thema "Re: MS-DOS clients mit NetBIOS an Linux?":
>> >Die Rechner in einem Subnetz sind zunaechst einmal
>> >durch das Subnetz "zusammengefasst". Da muss ich nicht mehr
>> >extra etwas "zusammenfassen".
>>
>> Und wie ausser ueber die Netzwerknummer definierst Du ein Subnetz?
>
>Das muss ich nicht definieren, das ist einfach _da_.
>Da _ist_ ein Ethernet. Da _ist_ ein Token Ring.
Das ist aber erst eine Hälfte des Netzwerks. Zusätzlich mußt Du eine
für Software erkennbare Gemeinsamkeit unter den angeschlossenen
Rechnern _eines_ Netzwerks schaffen. Bei TCP/IP durch Vergabe
entsprechender IPs und einer passenden Netmask, bei IPX durch die
Vergabe einer einheitlichen Netzwerknummer. In diesem Sinne war das mit
dem "Rechner zu einem Netz zusammenfassen" gemeint.
[Knotenadresse bei IPX]
>> >Und wie sind diese definiert? Nach meiner Kenntnis durch
>> >die hardwaremaessige Knotenadresse.
>>
>> Richtig. Zumindest bei Ethernet und Token Ring.
>
>Und sonst?
>
>Ich weiss es jetzt nicht. Was sagt da die Dokumentation?
Ok, ich habe mich inzwischen bei Novell nach einer IPX-Dokumentation
umgesehen und auch etwas gefunden. In
http://www.novell.com/documentation/lg/nias41/pdfdoc/10412531.pdf
ist zu lesen:
"The node number is the 6-byte hexadecimal address that identifies a
device on an IPX network. This device can be a file server, router,
workstation, or printer. The node number is identical to the physical
address assigned to the interface board that connects the device to the
network."
Als mögliche MAC-Protokolle werden nur Ethernet, Token Ring und ARCnet
genannt.
Ich hatte noch nicht die Zeit, mich wirklich intensiv einzulesen, aber
ich würde das so deuten, daß IPX auf anderer Hardware nicht
funktioniert.
>> Ich hatte noch keinen Grund, mich mit IPX auf Hardware mit nicht 6
>> Bytes langen Hardwareadressen zu beschaeftigen, daher kann ich dazu
>> nichts genaues sagen. Aber es spricht doch nichts dagegen, auf
>
>Nun, auf diese Frage stoesst man doch schon, wenn man nur zwei
>IPX-Netze ueber eine ISDN-Verbindung koppelt!
Dafür gibt es zwei Möglichkeiten:
1.) einen IP-Tunnel
2.) die Verwendung von IPXWAN, wie es in RFC1634 beschrieben ist.
>Ich schrieb ja: Anfangen tut die ganze Geschichte mit der Notwendigkeit
>einer einheitlichen Adressierung.
Nicht unbedingt. Wenn man IPX-Pakete beispielsweise über eine
ISDN-Verbindung schicken will, dann steht auf jeder Seite ein Router.
Die Workstations in jedem Netz müssen auf Layer 2 nur den Router in
ihrem eigenen Netz adressieren können, und der hat ja ein IPX-Interface
mit einer geeigneten Hardwareadresse. Über die ISDN-Strecke müssen sich
nur die beiden Router adressieren können, und dafür ist keine
IPX-Knotennummer nötig. Die Adressierung ist also unterschiedlich, je
nachdem, ob sich eine Workstation mit einem Router oder zwei Router
unter sich unterhalten wollen.
>> Bei Ethernet stimmen diese Laengen ueberein, daher ist es
>> naheliegend, die MAC-Adresse auch auf Layer 3 zu verwenden, und die
>
>MAC = Media Access Control.
>
>MAC Adressen dienen dem Medienzugriff und haben mit der Schicht 3
>weder etwas zu tun noch haben sie darauf etwas zu suchen.
Man verwendet genaugenommen nicht die MAC-Adresse auf Layer 3, sondern
man verwendet auf Layer 3 eine Adresse, die der MAC-Adresse entspricht.
>Zudem habe ich versucht, zu verdeutlichen, dass sich ein ISDN-Endgeraet
>und ein Ethernet-Endgeraet ueber ihre Adressen nicht wirklich verstehen,
>sie koennen die gegenseitigen Adressen schon rein formal nicht einmal
>darstellen. Ich habe das auch am Beispiel aufgezeigt, indem ich
>die unterschiedlichen syntaktischen Formen der Adressen dargestellt
>habe.
Ein Ethernet-Gerät und ein ISDN-Gerät müssen ja auch nicht direkt
miteinander reden können, da ist immer ein Router dazwischen. Alles,
was ich brauche, sind also einheitliche Adressen auf Layer 3. Und warum
soll man bei Ethernet auf Layer 3 nicht eine Adresse nehmen, die mit
der MAC-Adresse übereinstimmt, während man beim ISDN-Gerät auf Layer 3
eine Adresse benutzt, die nichts mit der Layer2-Adresse zu tun hat?
>> Es ging ja nur um die Laenge der Adresse, da spielt die Anordnung
>> der Bytes zunaechst keine Rolle. Und zu der Angabe der Bytes einer
>
>Es spielt beim Internetworking eine sehr grosse Rolle, wie
>ich die Bits (nicht Bytes) anordne. Spaetestens wenn Du
>TR und Ethernet Verkehr mit irgendwelchen geeigneten Techniken
>"bridged", solltest Du wissen, ob Du die Werte drehen musst
>oder nicht. Sonst hast Du eine Gegenstelle, die sich
>dauernd als C4 C4 C4 ... darstellt, und Du rufst bei
>der entfernten Stelle an und jagst denen wegen eines Hackerangriffs
>die Nationalgarde auf den Hals, weil Du mit 23 23 23 ....
>als Gegenstellenadresse gerechnet hast.
Richtig, aber wir haben uns nicht über die Implementierung einer
Bridge, sondern lediglich über die Länge der Adresse unterhalten. Und
dabei ist 23L == C4M.
>> >Die gibt es auch im Ausnahmefall nicht. Wenn der Hersteller
>> >nicht geschlampt hat, darf es keine doppelt vergebene
>> >Hardwareadresse geben.
>>
>> Wieso doppelt? Eine Gemeinsamkeit koennte doch auch sein, dass die
>> ersten x Bits der Hardwareadresse bei allen Rechnern in einem
>> logischen Netz uebereinstimmen, so wie es die ersten x Bits der
>
>Die Hardwareadressen haben nichts mit dem logischen Netz zu tun.
Genau das hatte ich doch in <zvcevtzkarg.g...@mp1.albnet.de>
geschrieben: "Mit 'zufällig' meinte ich, daß es bei den MAC-Adressen
der Rechner eines logischen Netzen im Normalfall keine Gemeinsamkeiten
gibt [...]"
>Die _Hardware_adressen werden auf der _Hardware_ bwz. der Firmware
>der Karte bei der Herstellung der Karte definiert. Da weiss
>die Karte bei der Herstellung in Malaysia noch nicht, in welchem
>logischen Netz sie dermaleinst in der Ukraine eingesetzt
>wird.
Eben. Und daher brauche ich eine softwaremäßig zu vergebende Adresse,
um die Rechner _eines_ Netzwerks kenntlich zu machen. Jedenfalls dann,
wenn ich eine Route zu diesem _Netz_ definieren will.
>> IP-Adresse tun. Dann koennte man naemlich diese ersten gemeinsamen
>> Bytes der Hardwareadresse als Netzwerknummer betrachten. Und dann
>> waere selbst NetBEUI routingfaehig.
>
>Das waere dann nicht Routing, das waere Bridging, das geht jetzt
>schon.
Eine Bridge kennt keine logischen Netze, sondern merkt sich jede
einzelne Hardware-Adresse. Wenn Du dagegen zwei Netze hättest, und im
einen würden alle Hardwareadressen mit 00:01: beginnen, im anderen alle
mit 00:02:, dann könnte man darauf etwas wie einen NetBEUI-Router
definieren. Könnte. Daß das mit der Realität nichts zu tun hat, ist
natürlich klar.
>So ist das Leben. Vor allem in Rechnernetzen ist es manchmal
>mies. Da wuenscht man sich immer, man waere Politiker geworden.
>Selbst Parteifreunde sind nicht so gemein, wie Netze das manchmal sind.
Wenn ich mich derzeit so in der Politik umsehe, dann würde ich diese
Aussage nochmal überdenken :).
>> Wie oben: ein System in diesem Zusammenhang waere beispielsweise,
>> dass die ersten x Bits der Adresse bei allen Rechnern eines Netzes
>
>Welche?
>
>Steht da im ersten Oktett nun 0x23? Oder steht da 0xC4?
23L oder C4M.
IP-Adressen werden auch unterschiedlich dargestellt, je nachdem ob Dein
Rechner bei 32-Bit Integern das Low-Byte oder das High-Byte
voranstellt. Trotzdem ist eine IP auch ohne diese Angabe eindeutig. Sie
ist allerdings nicht eindeutig, wenn man sich nur die 4 Bytes im
Speicher anschaut.
>> Mir leuchtet immer noch nicht so recht ein, wieso das mit IPX nicht
>> gehen soll. Vorausgesetzt die Netzwerknummern bei IPX wuerden ebenso
>> systematisch vergeben wie bei TCP/IP, dann spricht aus meiner Sicht
>> nichts dagegen, einen Router zu bauen, der beispielsweise nur
>> anhand der ersten 2 Bytes der Netzwerknummer routet. Der
>
>Du routest anhand der Netzwerknummer.
Richtig, und dazu auch noch dynamisch.
>Nicht anhand ihrer ersten zwei Bytes.
>
>Woher sollte der IPX-Router auch wissen, wieviel Netzwerknummernbits
>relevant sind?
>
>Eben.
>
>Er weiss es nicht.
_Wenn_ die Netzwerknummern systematisch vergeben wären, _dann_ könnte
man ihm das sagen.
>Was brauchen wir dafuer?
>
>Richtig. Die Netzmaske. _Dafuer_ ist die da: Um die fuer
>die Netzwerkadresse relevanten Bits auszuzeichnen.
Aber eine entsprechende Angabe könnte man doch in der Routingtabelle
unterbringen, genau so wie man es bei TCP/IP auch macht. Im Gegensatz
zu TCP/IP gibt es in einem IPX-Netz nur sehr wenige Rechner, die
überhaupt in der Lage sind, Pakete zu routen. Eine normale Workstation
kann das nicht, und so würden sich die erforderlichen Änderungen
alleine auf die Router (in einem Netware-Netz also üblicherwiese auf
die Server) beschränken.
Michael
Michael Prinzing
>mi...@gmx.net meinte am 22.11.01
>zum Thema "Re: MS-DOS clients mit NetBIOS an Linux?":
>
>>
>> Das ist aber erst eine Haelfte des Netzwerks. Zusaetzlich musst Du
>> eine fuer Software erkennbare Gemeinsamkeit unter den
>
>Diese ist sowohl bei Ethernet als auch bei Token Ring durch
>die jeweiligen Spezifikationen gegeben.
Du bist schon wieder auf Layer 2. Wir reden hier aber von softwaremäßig
vergebenen Adressen, vom Routing und von IPX. Das findet alles auf
Layer 3 statt.
>Ich habe gesagt, dass man da nichts zusammenfassen muss.
Wenn Du mal begründen würdest, wieso Du dieser Auffassung bist, anstatt
nur zu sagen, daß es so ist und daß Du es gesagt hast, dann würde ich
mich ja vielleicht überzeugen lassen. Aber Beweis durch Behauptung
bringt nichts. Meine Begründung steht weiter unten.
>> "The node number is the 6-byte hexadecimal address that identifies
>> a device on an IPX network. This device can be a file server,
>> router, workstation, or printer. The node number is identical to
>> the physical address assigned to the interface board that connects
>> the device to the network."
>>
>> Als moegliche MAC-Protokolle werden nur Ethernet, Token Ring und
>> ARCnet genannt.
>>
>> Ich hatte noch nicht die Zeit, mich wirklich intensiv einzulesen,
>> aber ich wuerde das so deuten, dass IPX auf anderer Hardware nicht
>> funktioniert.
>
>
>So wuerde ich das auch deuten.
Ok, wenn wir uns mal in einem Punkt einig sind, dann halten wir das
doch fest: zu einem, nein, zu _jedem_ IPX-Interface gehört eine 6 Bytes
(oder 48 Bit, wenn Dir das lieber ist) lange Knotenadresse auf Layer 3.
Die werden wir weiter unten nämlich brauchen.
>(Und ich weiss jetzt nicht, wie man das auf ISDN macht, vermutlich
>ueber dummy ARP Adressen.)
ARP kommt bei IPX nicht zum Einsatz. Und zum Thema ISDN: ich habe hier
inzwischen eine Tabelle mit allen möglichen Protokollen, und dort
steht:
Frame ID: 13
Frame Type String: ISDN
Protocol: IPX/SPX
Protocol ID: N/A
Description: Integrated Services Digital Network (Not available)
Das stammt aus der 'IPX Router Specification' von Novell, Part Number
107-000029-001, zu finden auf netlab2.usu.edu unter
/ODI/IPXRTR/IPXRTR.EXE und stellt den Stand von 1993 dar. Wenn sich
hier mittlerweile etwas geändert haben sollte und Du eine entsprechende
Quelle nennen kannst, dann lasse ich mich natürlich gerne eines
Besseren belehren.
>> >Nun, auf diese Frage stoesst man doch schon, wenn man nur zwei
>> >IPX-Netze ueber eine ISDN-Verbindung koppelt!
>>
>> Dafuer gibt es zwei Moeglichkeiten:
>>
>> 1.) einen IP-Tunnel
>> 2.) die Verwendung von IPXWAN, wie es in RFC1634 beschrieben ist.
>
>Ich habe aber nach IPX gefragt, und IPX hat nichts mit RFCs oder
>gar der Internet Engineering Task Force zu tun.
Bitte? Also wenn ich Dir die Spezifikationen, nach denen Du gefragt
hast, schon auf dem Silbertablett serviere, dann hättest Du wenigstens
mal einen Blick hineinwerfen können, anstatt mir vorzuwerfen, ich würde
auf Deine Fragen nicht genügend Zeit verwenden. Schon im ersten Absatz
von RFC1634 hättest Du dann gelesen:
"Network Working Group M. Allen
Request For Comments: 1634 Novell, Inc.
Obsoletes: 1551, 1362 May 1994
Category: Informational
Novell IPX Over Various WAN Media (IPXWAN)
[...]
Abstract
This document describes how Novell IPX operates over various WAN media.
Specifically, it describes the common "IPX WAN" protocol Novell uses to
exchange necessary router to router information prior to exchanging
standard IPX routing information and traffic over WAN datalinks."
Und als WAN-Links werden dann erläutert:
1.1 Operation Over PPP
1.2 Operation Over X.25 Switched Virtual Circuits
1.3 Operation Over X.25 Permanent Virtual Circuits
1.4 Operation Over Frame Relay
1.5 Operation Over Other WAN Media
>Zumal ich jetzt nicht weiss, wann RFC 1634 geschrieben wurde,
>aber zu dem Zeitpunkt ist IPX schon bald wieder ausgefuehrt worden.
>Das muss schon bald nach 1990 gewesen sein, ich muesste jetzt
>nachgucken.
Anfang der 90er Jahre wurde IPX mitnichten "ausgeführt". 1993
beispielsweise war Netware 3.12 aktuell, und dort war IPX das einzig
mögliche Protokoll. Selbst bei Netware 4 war es noch Standard, und erst
bei Netware 5 wurde es allmählich durch TCP/IP abgelöst. Abgesehen
davon hatte RFC1634 bereits Vorgänger, und zudem interessiert mich
nicht der Stand der Dinge vor mehr als 10 Jahren, sondern der heutige.
>> >Ich schrieb ja: Anfangen tut die ganze Geschichte mit der
>> >Notwendigkeit einer einheitlichen Adressierung.
>>
>> Nicht unbedingt. Wenn man IPX-Pakete beispielsweise ueber eine
>> ISDN-Verbindung schicken will, dann steht auf jeder Seite ein
>> Router. Die Workstations in jedem Netz muessen auf Layer 2 nur den
>
>Und wenn da ein Gummihuhn steht, die Frage ist, wie sich die
>Peers einer Verbindung gegenseitig addressieren, und dazu brauche
>ich ein eindeutiges Adressierungsschema.
Könntest Du Dich bitte mal festlegen, ob Du nun von Layer 2 oder von
Layer 3 sprichst? Auf Layer 3 brauchst Du ein eindeutiges
Adressierungsschema, das ist die IPX-Adresse. Auf Layer 2 brauchst Du
es nicht, weil ein Ethernet-Gerät auf Layer 2 kein ISDN-Gerät
adressieren muß, eben weil da ein Router dazwischen ist.
>Die Peers haben von den Routern keine Kenntnis.
Doch, haben sie. Siehe weiter unten, Stichwort RIP.
>> Router in ihrem eigenen Netz adressieren koennen, und der hat ja ein
>
>Ich habe Dich danach gefragt, wie sich die Peers einer Verbindung
>adressieren.
>
>Kannst Du mir diese Frage jetzt bitte mal beantworten?
Gerne. Obwohl das haarklein in den Dokumenten erklärt ist, die ich Dir
bereits genannt habe. Noch genauer wird es in den oben erwähnten 'IPX
Router Specifications' erläutert.
Also: eine Workstation möchte ein Paket zu einer anderen Workstation
schicken. Wenn sich die Zielworkstation im selben Netz befindet
(Netzwerknummer der IPX-Adresse ist gleich), dann schickt sie das Paket
direkt zu dieser Workstation.
NB: Um entscheiden zu können, ob sich die Zielworkstation im selben
Netz befindet, ist es also erforderlich, die Rechner _eines_ Netzes
über eine gemeinsame Netzwerknummer zu einem _logischen_ Netz
zusammenzufassen, was Du ja vehement bestritten hast.
Wenn die Netzwerknummer nicht gleich ist, sendet die Workstation einen
RIP-Request in ihrem eigenen Netzwerk, um die Route zum Zielnetz zu
erfahren. Der Router mit der kürzesten Route zum Ziel beantwortet
diesen Request und schickt dabei seine eigene Knotennummer (die der
MAC-Adresse entspricht) im IPX-Header zurück an die Workstation.
Nun sendet die Workstation das IPX-Paket an diesen Router. Dabei
schreibt sie als Absender ihre eigene Netzwerk-, Knoten- und
Socketnummer als 'Source' in den IPX-Header (diesen findest Du einige
Absätze weiter unten). Als 'Destination' werden im IPX-Header Netzwerk,
Knoten- und Socketnummer der Zielworkstation im anderen Netz
eingetragen. In den MAC-Header trägt die sendende Workstation die
IPX-Knotennummer des Routers ein, die sie dem IPX-Header der Antwort
auf ihren RIP-Request entnimmt und schickt das Paket an diesen Router.
Der Router prüft zunächst, ob das Paket an ihn selbst adressiert ist.
In diesem Fall leitet er das Paket intern an den entsprechenden Socket.
Wenn das Paket nicht direkt an den Router adressiert ist, wird geprüft,
ob es an eine Workstation adressiert ist, die direkt mit dem Router
verbunden ist, der also die gleiche Netzwerknummer wie der Router hat.
Nehmen wir zunächst an, es ist an eine Workstation mit einer anderen
Netzwerknummer adressiert. In diesem Fall schreibt der Router die
IPX-Knotennummer des nächsten Routers, den er seiner Routingtabelle
entnimmt, als Empfänger in den MAC-Header. Als Absender schreibt er
seine eigene IPX-Knotennummer in den MAC-Header, außerdem wird das
'Transport Control' Feld im IPX-Header um 1 erhöht. So geht das Paket
an den nächsten Router, und zwar so lange, bis es auf einem Router
ankommt, der über ein IPX-Interface verfügt, dessen Netzwerknummer mit
der Netzwerknummer der Ziel-Workstation übereinstimmt.
Dieser letzte Router schreibt die Knotennummer aus dem IPX-Header als
Empfänger in den MAC-Header und seine eigene Knotennummer als Absender
in den MAC-Header. Damit geht das Paket an die Ziel-Workstation.
Falls unterwegs das Feld 'Transport Control' einen Wert von 16
erreicht, bevor es am Ziel angekommen ist, wird es verworfen.
>Wir sprachen ueber die Adressierung der Peers, nicht irgendwelcher
>Routeradressen dazwischen.
Die Adressierung der Router untereinander ist das einzig Interessante
an dem eben beschriebenen Vorgang. Sowohl die sendende als auch die
empfangende Workstation am Ende der Verbindung verfügen über ein
IPX-Interface und somit auch über eine geeignete Hardware wie
beispielsweise Ethernet, so daß die Adressierung der beiden
untereinander über die IPX-Adresse kein Problem ist.
Es geht also einzig und alleine darum, wie sich die Router
untereinander unterhalten, und hier kannst Du wie bereits erwähnt
IPXWAN nach RFC1634 oder notfalls einen IP-Tunnel einsetzen.
Zudem existiert das sogenannte "IPX Address Mapping Gateway", das
http://www.novell.com/documentation/lg/nias41/pdfdoc/10412531.pdf ab
Seite 36 wie folgt beschreibt:
"IPX Address Mapping Gateway
Using the IPX Address Mapping Gateway (IAMG) offers the following three
advantages:
- Your hosts can connect to a backbone network even when your local
network numbers are not compatible with the backbone addressing scheme.
- [...]"
Da würde ich Dich aber wirklich bitten, daß Du das selbst nachliest.
>Ich habe Dir das klar und praezise erlaeutert, worum es geht,
>und ich habe allmaehlich das unbestimmte Gefuehl, dass Du mich
>hier aergern moechtest.
Glaubst Du wirklich, ich könnte mit meiner knappen Zeit nichts besseres
anfangen?
>Auch bei Zwischenfragen kannst Du auch mal 5 Minuten nachdenken,
>und nicht Dinge, die ich Dir schon dreimal erklaert habe, noch
>4 mal fragen.
Nachdem wir uns beide nicht so ganz sicher waren, wie die ganze
Geschichte genau funktioniert, habe ich mich auf die Suche nach
brauchbaren Informationen gemacht, und Du kannst mir glauben, daß das
wesentlich länger als 5 Minuten gedauert hat. Eigentlich hatte ich
gehofft, wir könnten gemeinsam etwas Licht in die Sache bringen, aber
nachdem Du nichtmal in die Dokumente hineingeschaut hast, die ich Dir
genannt habe, scheinst Du daran ja leider kein Interesse zu haben.
>> >MAC Adressen dienen dem Medienzugriff und haben mit der Schicht 3
>> >weder etwas zu tun noch haben sie darauf etwas zu suchen.
>>
>> Man verwendet genaugenommen nicht die MAC-Adresse auf Layer 3,
>> sondern man verwendet auf Layer 3 eine Adresse, die der MAC-Adresse
>> entspricht.
>
>
>Man verwendet nicht nur genaugenommen nicht die MAC Adressen
>auf Layer 3 sondern man verwendet ueberhaupt keine MAC-Adressen
>auf Layer 3.
Ein IPX-Header ist folgendermaßen aufgebaut:
+------------------------------+
|Checksum (2 Bytes) |
+------------------------------+
|Packet Length (2 Bytes) |
+------------------------------+
|Transport Control (2 Bytes) |
+------------------------------+
|Packet Type (1 Byte) |
+------------------------------+
|Destination Network (4 Bytes) |
+------------------------------+
|Destination Node (6 Bytes) |
+------------------------------+
|Destination Socket (2 Bytes) |
+------------------------------+
|Source Network (4 Bytes) |
+------------------------------+
|Source Node (6 Bytes) |
+------------------------------+
|Source Socket (2 Bytes) |
+------------------------------+
Kannst Du mir unter der Voraussetzung, daß die IPX-Knotenadresse der
MAC-Adresse entspricht, erklären, was in den Feldern 'Destination Node'
und 'Source Node' anderes stehen soll als die MAC-Adresse bzw. eine
Adresse, die der MAC-Adresse entspricht?
Und um auch mit diesem Mißverständnis aufzuräumen: nein, ich erwarte
keine Antwort auf diese Frage. Sie ist genauso rhetorisch wie bestimmt
schon ein Dutzend andere vorher.
>Also nur so just for info, ich habe meine letzten
>IP-Header haendisch im C-Code heute vormittag zusammengefrickelt.
>Ich _weiss_, was da im Header drinsteht. Und zwar auf Bitebene.
>Und da steht genau und praezise ueberhaupt keine MAC-Adresse.
Du schreibst doch oben, daß Du nach IPX gefragt hast. Dann sehe ich
keinen Sinn darin, einen IP-Header zu zerlegen.
>> Ein Ethernet-Geraet und ein ISDN-Geraet muessen ja auch nicht direkt
>> miteinander reden koennen, da ist immer ein Router dazwischen.
>
>Ja und?
>
>Woher wissen die das?
>
>Bitte beantworte mir kurz und konkret diese Frage: Woher _wissen_
>die das?
Zwei Stationen, die an zwei unterschiedlichen Netzwerksegmenten (hier
ist jetzt das Kabel oder besser die Broadcast-Domain gemeint)
angeschlossen sind, was ja sicher der Fall ist, wenn es sich um ein
Ethernet- und um ein ISDN-Gerät handelt, müssen unterschiedliche
IPX-Netzwerknummern haben. Zwei Stationen, die an dasselbe Segment
angeschlossen sind, müssen(!) dagegen auch dieselbe IPX-Netzwerknummer
haben. Es ist also auch für die Workstations schon anhand der
IPX-Adresse ersichtlich, daß die Verbindung nur über einen Router
zustandekommen kann.
>> Alles, was ich brauche, sind also einheitliche Adressen auf Layer
>
>Das versuche ich Dir seit zwei Wochen zu verdeutlichen,
Bitte kürze meine Texte so, daß der Sinn erhalten bleibt. Da stand
"auf Layer 3". Und genau das ist der Punkt: Du erklärst die ganze Zeit
die Unterschiede auf Layer 2, wie z.B. die unterschiedliche Reihenfolge
der Bits bei Ethernet und Token Ring. Dabei ignorierst Du aber völlig,
daß ich geschrieben habe, daß die Adresse auf Layer 3 durchaus
identisch sein kann, auch wenn es solche Unterschiede auf Layer 2 gibt,
weil man dies bei der Angabe der Layer 3 Adresse berücksichtigen kann,
indem man beispielsweise dazuschreibt, ob das LSB oder das MSB vorne
steht.
So, und jetzt will ich zum Abschluß noch auf eine Sache aus einem der
vorherigen Artikel zurückkommen. Dort hattest Du geschrieben:
|Die Netznummern von IPX erlauben keine Aggregation.
Das ist falsch. Siehe
http://www.novell.com/documentation/lg/nias41/pdfdoc/10412531.pdf,
Kapitel "IPX Route Aggregation" ab Seite 33:
"IPX Route Aggregation enables you to introduce routes learned through
RIP into an NLSP backbone in a summarized form. Route aggregation
compactly describes many IPX network numbers simultaneously by using an
address and mask pair. For example, all addresses from C9000000 to
C9FFFFFF can be represented using the address C9000000 and the mask
FF000000."
Genau das hatte ich ja vorgeschlagen, übrigens bevor ich das eben
zitierte Kapitel gelesen hatte. Darauf hast Du behauptet:
|Du routest anhand der Netzwerknummer.
|
|Nicht anhand ihrer ersten zwei Bytes.
|
|Woher sollte der IPX-Router auch wissen, wieviel Netzwerknummernbits
|relevant sind?
|
|Eben.
|
|Er weiss es nicht.
Was offensichtlich auch falsch ist.
In diesem Licht betrachtet finde ich Deine Äußerung von wegen
"_dermassen_ unverstaendig hat sich nun wirklich ueberhaupt noch
niemand angestellt" schon sehr befremdlich.
Überhaupt habe ich hier Deine persönlichen Angriffe und
Unverschämtheiten im Interesse einer sachlichen Diskussion noch ein
letztes Mal übergangen, und ich denke, es sollte auch Dir möglich sein,
ohne solche verbalen Entgleisungen auszukommen.
Michael