Nochmal hi, folgendes Problem habe ich mit appletalk: Ich nutze appletalk version 1.5xx was halt bei Suse 7.3 dabei ist auf einem Rechner. Wenn der Rechner alleine im Netz ist habe ich extreme Probleme beim Connect vom Mac. Die Verbindung dauert einige Minuten bis er die Shares verbindet . Wenn ich einen noch vorhandenen WIN-NT Server mit Appletalk Unterstützung reinhänge der eine zone eingetragen hat, klappts ab und zu. Mit dem alten Rechner mit Suse 6.4 und atalk 1.42b gabs und gibts keine Probleme beim Connect. Sobald der neue drin hängt klappts nicht mehr. Kennt jemand das Problem ? mfg. jaochim -- the holiday-count-down Der Ferienbeginn Zufallssignatur Nr.: 78
Nochmal hi, folgendes Problem habe ich mit appletalk: Ich nutze appletalk version 1.5xx was halt bei Suse 7.3 dabei ist auf einem Rechner. Wenn der Rechner alleine im Netz ist habe ich extreme Probleme beim Connect vom Mac. Die Verbindung dauert einige Minuten bis er die Shares verbindet .
Stimmen die Einträge auf dem Mac? Speed, IP, Mask, Gateway.
Wenn ich einen noch vorhandenen WIN-NT Server mit Appletalk Unterstützung reinhänge der eine zone eingetragen hat, klappts ab und zu.
Gibt es denn mehrere Zonen bei Euch? Sonst brauchst Du keine Zoneneinträge bei Apple. Er verwendet dann automatisch die Standardzone '*'.
Mit dem alten Rechner mit Suse 6.4 und atalk 1.42b gabs und gibts keine Probleme beim Connect. Sobald der neue drin hängt klappts nicht mehr. Kennt jemand das Problem ?
Was passiert, wenn Du versuchst, Dich per IP-Adresse im Auswahlmenu anzumelden?
mfg. jaochim
From: "Martin Falley"
auf einem Rechner. Wenn der Rechner alleine im Netz ist habe ich extreme Probleme beim Connect vom Mac. Die Verbindung dauert einige
Hallo, ich hoffe, dich jetzt nicht in die Irre zu schicken, aber das Phänomen gibt es bei diversen Servern, wenn sie (aus Sicherheitsgründen oder whatever) eine Reversauflösung der IP machen. Beispiel Telnet, pop3,... Meines (Halb-)Wissens läuft AppleTalk doch auch erstmal über TCP/IP und schaltet nur dann auf "historisches" AppleTalk runter, wenn das nicht klappt? Versuch doch mal, den Client in /etc/hosts einzutragen. Ich verwende AppleTalk auf einem 7.0er und einem 7.2er ohne das beschriebene Phänomen. Gruß, Ratti
From: "Martin Falley"
auf einem Rechner. Wenn der Rechner alleine im Netz ist habe ich extreme Probleme beim Connect vom Mac. Die Verbindung dauert einige
Hallo,
ich hoffe, dich jetzt nicht in die Irre zu schicken, aber das
na, mich doch nicht ;)
Phänomen gibt es bei diversen Servern, wenn sie (aus Sicherheitsgründen oder whatever) eine Reversauflösung der IP machen. Beispiel Telnet, pop3,...
stimmt. Ich glaube, AppleTalk ist wohl nicht direkt routingfähig.
Meines (Halb-)Wissens läuft AppleTalk doch auch erstmal über TCP/IP und schaltet nur dann auf "historisches" AppleTalk runter, wenn das nicht klappt?
AppleTalk verwenden die ja heute noch, - vielleicht aus historischen Gründen. Aber abschalten läßt es sich bei MacOS bis OS 9.2.1 m.W. nicht. AT schleppt man bei jeder Verbindung mit (OpenTransport).
Versuch doch mal, den Client in /etc/hosts einzutragen.
Ich habe da keine Probleme. Bei mir funktionierts ja. (PPC 8100/80)
Ich verwende AppleTalk auf einem 7.0er und einem 7.2er ohne das beschriebene Phänomen.
s.o.
Gruß, Ratti
Gruß Martin
wenn ich mich nun mal hier hinzuschalten darf...
Meines (Halb-)Wissens läuft AppleTalk doch auch erstmal über TCP/IP und schaltet nur dann auf "historisches" AppleTalk runter, wenn das nicht klappt?
AppleTalk verwenden die ja heute noch, - vielleicht aus historischen Gründen. Aber abschalten läßt es sich bei MacOS bis OS 9.2.1 m.W. nicht. AT schleppt man bei jeder Verbindung mit (OpenTransport).
Erstmal ist AppleTalk ja nicht umbedingt ein schlechtes Protokoll... Das normale AppleTalk (das ohne TCP/IP) lässt sich dennoch mittels AppleTalk Kontrollfeld deaktivieren. Klar ist natürlich das eine Art von AppleTalk auch via TCP eine Verbindung herstellt. Allein mit TCP wären wir aber ja auch nicht glücklich... -> Fundament allein gibt ja auch kein Dach übern Kopf das problem was Joachim ja ursprünglich angesprochen hatte sieht nach einem Fehler im Scanprozess aus. Was ich damit meine: der Server bzw. der Client haben wohl Probleme mit der korrekten Zone in der sie sich suchen/finden. Ein abschalten des klassischen AppleTalks am Mac hilft vielleicht. Ansonsten müsstest du mal schauen was der netatalk ins log schreibt wenn er hochfährt. philon
Terving wrote:
wenn ich mich nun mal hier hinzuschalten darf...
Meines (Halb-)Wissens läuft AppleTalk doch auch erstmal über TCP/IP und schaltet nur dann auf "historisches" AppleTalk runter, wenn das nicht klappt?
AppleTalk verwenden die ja heute noch, - vielleicht aus historischen Gründen. Aber abschalten läßt es sich bei MacOS bis OS 9.2.1 m.W. nicht. AT schleppt man bei jeder Verbindung mit (OpenTransport).
Erstmal ist AppleTalk ja nicht umbedingt ein schlechtes Protokoll...
Das normale AppleTalk (das ohne TCP/IP) lässt sich dennoch mittels AppleTalk Kontrollfeld deaktivieren. Klar ist natürlich das eine Art von AppleTalk auch via TCP eine Verbindung herstellt. Allein mit TCP wären wir aber ja auch nicht glücklich... -> Fundament allein gibt ja auch kein Dach übern Kopf
das problem was Joachim ja ursprünglich angesprochen hatte sieht nach einem Fehler im Scanprozess aus. Was ich damit meine: der Server bzw. der Client haben wohl Probleme mit der korrekten Zone in der sie sich suchen/finden.
Tja wenn ich keine Zone eintrage und auch der NT-Rechner nicht läuft, dann klappts halt nur nach ewiglich. Der afpd schreibt ja seine conf selber. Wenn ich dort bei eth0 mit -zone "zonenname" das ganze von Hand eintrage wird das halt beim Start überschrieben.
Ein abschalten des klassischen AppleTalks am Mac hilft vielleicht. Ansonsten müsstest du mal schauen was der netatalk ins log schreibt wenn er hochfährt
Da gibts nicht besonderes zu berichten. Das Hochfahren klappt ohne Probleme. Das Konnektieren an sich auch. Appletalk schreibt schön ins log, daß der User sich eingeloggt hat. Nur die Shares werden nicht freigegeben. Da hängt er halt ewig. Aber nur mal zum Verständnis. Wenn ich Appletalk auf dem Apple abschalte, kann ich dann den appletalk-Server auch runterfahren, und wenn ja, wie verbindet sich der MAC dann auf die Laufwerke ? bis denne dann joachim -- the illness picture Das Krankheitsbild Zufallssignatur Nr.: 69
[...]
Tja wenn ich keine Zone eintrage und auch der NT-Rechner nicht läuft, dann klappts halt nur nach ewiglich. Der afpd schreibt ja seine conf selber. Wenn ich dort bei eth0 mit -zone "zonenname" das ganze von Hand eintrage wird das halt beim Start überschrieben.
Ein abschalten des klassischen AppleTalks am Mac hilft
vielleicht. Ansonsten
müsstest du mal schauen was der netatalk ins log schreibt wenn er hochfährt
Da gibts nicht besonderes zu berichten. Das Hochfahren klappt ohne Probleme. Das Konnektieren an sich auch. Appletalk schreibt schön ins log, daß der User sich eingeloggt hat. Nur die Shares werden nicht freigegeben. Da hängt er halt ewig. Aber nur mal zum Verständnis. Wenn ich Appletalk auf dem Apple abschalte, kann ich dann den appletalk-Server auch runterfahren, und wenn ja, wie verbindet sich der MAC dann auf die Laufwerke ?
Laß uns doch nochmal vergleichen: Alles im Ordner /etc/atalk AppleVolumes.default: # the user home directory # remove the options when you have old files without nls conversion ~ mswindows,codepage:maccode.iso8859-1 atalkd.conf: # This turns on transition routing between the le0 and le1 # interfaces on a Sun. It also causes atalkd to fail if other # routers disagree about it's configuration of le1. # eth0 -phase 2 -net 0-65534 -addr 65280.94 netatalk.conf: # Appletalk configuration # Change this to increase the maximum number of clients that can connect: AFPD_MAX_CLIENTS=20 # Change this to set the machine's atalk name and zone. # NOTE: if you're zone has spaces in it, you're better off specifying # it in afpd.conf #ATALK_ZONE=@zone ATALK_NAME=`echo ${HOSTNAME}|cut -d. -f1` # specify this if you don't want guest, clrtxt, and dhx # available options: uams_guest.so, uams_clrtxt.so, uams_dhx.so, # uams_randnum.so #AFPD_UAMLIST="-U uams_clrtxt.so,uams_randnum.so" # Change this to set the id of the guest user AFPD_GUEST=nobody # Set which daemons to run (papd is dependent upon atalkd): ATALKD_RUN=yes PAPD_RUN=yes AFPD_RUN=yes TIMELORD_RUN=no # Control whether the daemons are started in the background ATALK_BGROUND=no Gruß Martin
Ratti wrote:
From: "Martin Falley"
auf einem Rechner. Wenn der Rechner alleine im Netz ist habe ich extreme Probleme beim Connect vom Mac. Die Verbindung dauert einige
Hallo,
ich hoffe, dich jetzt nicht in die Irre zu schicken, aber das Phänomen gibt es bei diversen Servern, wenn sie (aus Sicherheitsgründen oder whatever) eine Reversauflösung der IP machen. Beispiel Telnet, pop3,...
Ich habe einen extra Rechner (fli4l) der den DNS macht, was auch funktioniert. Oder was soll ich unter Reverseauflösung verstehen?
Meines (Halb-)Wissens läuft AppleTalk doch auch erstmal über TCP/IP und schaltet nur dann auf "historisches" AppleTalk runter, wenn das nicht klappt?
Heißt das ich brauh das appletalk-Paket gar nicht ??
Versuch doch mal, den Client in /etc/hosts einzutragen.
Werds probieren. danke joachim -- the cow business Der Kuhhandel Zufallssignatur Nr.: 138
[...]
Meines (Halb-)Wissens läuft AppleTalk doch auch erstmal über TCP/IP und schaltet nur dann auf "historisches" AppleTalk runter, wenn das nicht klappt?
Das Protokoll heißt m.W. AppleTalk over IP, d.h., AppleTalk muß laufen.
Heißt das ich brauh das appletalk-Paket gar nicht ??
TCP/IP alleine nützt gar nichts. Damit kann Apple erst ab MacOS X was anfangen.
Versuch doch mal, den Client in /etc/hosts einzutragen.
Das ist nur gut, wenn man den Mac von Linux aus über deen Namen auflösen will. Umgekehrt bräuchte man eine Hosts-Datei auf dem Mac in der Systemerweiterung.
Werds probieren.
danke joachim
Gruß Martin
From: "Martin Falley"
Heißt das ich brauh das appletalk-Paket gar nicht ??
TCP/IP alleine nützt gar nichts. Damit kann Apple erst ab MacOS X was anfangen.
Das ist klar. Aber bei "AppleTalk über TCP/IP" ist eben nicht nur traditionelles AppleTalk im Spiel, sondern eben auch TCP/IP. So, und da hab ich 'ne Idee:
Versuch doch mal, den Client in /etc/hosts einzutragen.
Das ist nur gut, wenn man den Mac von Linux aus über deen Namen auflösen will. Umgekehrt bräuchte man eine Hosts-Datei auf dem Mac in der Systemerweiterung.
Aber genau das will ich ja: Linux soll den Mac auflösen. Etliche Server, beispielsweise das (inzwischen dahingegangene :-) ) Telnet meine Suse 7.0, oder der POP-Server eines von mir betreuten Cubes machen erstmal eine reverse Namensauflösung: "Klopf-Klopf!" "Wer da?" "192.168.12.34!" "Da muß ich erstmal in meine Gästeliste schauen... (Wer ist 192.168.12.34????)" Wenn er keinen Namen findet - auch gut, macht er trotzdem weiter. Aber das kostet Performance und anscheinend bei vielen Netzen zuviel Zeit: TimeOut, ohne das der Server überhaupt mit der eigentlichen Verbindung begonnen hätte. Das führte bei mir dazu, daß etliche Versuche meiner Kollegn, Post abzuholen, nach 60 Sekunden per TimeOut gekickt wurden. (Wir ignorieren jetzt mal die Frage, welcher Hirsch den DNS konfiguriert hat). Das hatte mit dem POPserver "gar nichts" zu tun, der wurde schon vor dem Login abgeschossen. Und ich habe mir den Wolf am POPper konfiguriert - dabei war der OK. Daher meine Idee: Der Mac versucht über TCP/IP zu verbinden, und der Server versucht, den Namen zur IP nachzuschauen. Ich habe seitdem unser gesamtes Netz auf Blödsinnsnamen aufgelöst (192.168.0.X = "clientX.domain.local") und seitdem geht etliches besser. Und bind hat dafür sogar eine Platzhalteroption. Gruß, Ratti
From: Ratti [mailto:ratti@gesindel.de]
From: "Martin Falley"
Hallo Martin,
ich glaube, da hast du nicht verstanden, worauf ich raus will. ;-)
Wahrscheinlich ist es so. Wir schreiben wohl aneinander vorbei. [...]
TCP/IP alleine nützt gar nichts. Damit kann Apple erst ab MacOS X was anfangen.
Das ist klar. Aber bei "AppleTalk über TCP/IP" ist eben nicht nur traditionelles AppleTalk im Spiel, sondern eben auch TCP/IP. So, und da hab ich 'ne Idee:
Versuch doch mal, den Client in /etc/hosts einzutragen.
Das ist nur gut, wenn man den Mac von Linux aus über deen Namen auflösen will. Umgekehrt bräuchte man eine Hosts-Datei auf dem Mac in der Systemerweiterung.
Aber genau das will ich ja: Linux soll den Mac auflösen.
Wenn ich Dich jetzt richtig verstehe, willst Du vom Linux-Rechner auf den Mac zugreifen? Das geht beim Mac nicht mit den standardmäßig mitgelieferten Tools. Dazu braucht man Fremdsoftware. Die gibt es teilweise als Freeware, aber überwiegend als Payware. z.B. Telnet-Server /-Daemon Wie genau die hosts-Datei auf dem Mac aussehen muß, kann ich aber jetzt nich sagen. Es gibt dort im Kontrollfeld 'TCP/IP' einen Button, der es erlaubt eine hosts-Datei (kann auch eine LMHOSTS-Datei sein) zu importieren.
Etliche Server, beispielsweise das (inzwischen dahingegangene :-) ) Telnet meine Suse 7.0, oder der POP-Server eines von mir betreuten Cubes machen erstmal eine reverse Namensauflösung: "Klopf-Klopf!" "Wer da?" "192.168.12.34!" "Da muß ich erstmal in meine Gästeliste schauen... (Wer ist 192.168.12.34????)" Wenn er keinen Namen findet - auch gut, macht er trotzdem weiter. Aber das kostet Performance und anscheinend bei vielen Netzen zuviel Zeit: TimeOut, ohne das der Server überhaupt mit der eigentlichen Verbindung begonnen hätte.
Das führte bei mir dazu, daß etliche Versuche meiner Kollegn, Post abzuholen, nach 60 Sekunden per TimeOut gekickt wurden. (Wir ignorieren jetzt mal die Frage, welcher Hirsch den DNS konfiguriert hat). Das hatte mit dem POPserver "gar nichts" zu tun, der wurde schon vor dem Login abgeschossen. Und ich habe mir den Wolf am POPper konfiguriert - dabei war der OK.
Daher meine Idee: Der Mac versucht über TCP/IP zu verbinden, und der Server versucht, den Namen zur IP nachzuschauen.
Es gibt beim Mac einen sog. Umgebungsassistenten. Hast Du den evt. mal benutzt, um dem Mac einen Namen zuzuweisen? Der Mac gibt sonst nur die freigegebenen Festplattennamen nach außen weiter. in einem reinen AppleTalk- Netz reicht das auch. Aber das ist ja nicht der Rechnername. Den gibt man eben im Umgebungsassistenten vor.
Ich habe seitdem unser gesamtes Netz auf Blödsinnsnamen aufgelöst (192.168.0.X = "clientX.domain.local") und seitdem geht etliches besser.
Und bind hat dafür sogar eine Platzhalteroption.
Gruß, Ratti
Gruß Martin
From: "Martin Falley"
ich glaube, da hast du nicht verstanden, worauf ich raus will. ;-)
Wahrscheinlich ist es so. Wir schreiben wohl aneinander vorbei.
Jepp. ;-) Erstmal eins vorweg: Du scheinst mich mit dem User zu verwechseln, der ein Problem hat. Bin ich nicht. Bei mir gehts.
Aber genau das will ich ja: Linux soll den Mac auflösen.
Wenn ich Dich jetzt richtig verstehe, willst Du vom Linux-Rechner auf den Mac zugreifen?
Nein. Bei vielen Serverdiensten ist es so, das der Server die Clients "nachschaut." Beispiel: Du gehst mit "telnet servername" auf deinen Server. Logischweise muß dazu der Servername auf dem Client aufgelöst werden. Der Server guckt aber auch nach, _wer_ ihn da anbaggert. Also muß auch der Client aufgelöst werden können! Und zwar revers. Der Server muß beantwortet bekommen, wer zu der IP gehört. Also: Client _und_ Server müssen über DNS auflösbar sein, vor- und rückwärts. Das ist bei telnet so, das ist beim popper so, und mein Vorschlag geht dahin, zu überprüfen, ob das auch beim atalkd so ist. Da mein System das sowieso kann, ist es eine Mutmaßung. Gruß, Ratti
From: Ratti [mailto:ratti@gesindel.de]
From: "Martin Falley"
Moin!
ich glaube, da hast du nicht verstanden, worauf ich raus will. ;-)
Wahrscheinlich ist es so. Wir schreiben wohl aneinander vorbei.
Jepp. ;-)
Erstmal eins vorweg: Du scheinst mich mit dem User zu verwechseln, der ein Problem hat. Bin ich nicht.
Habe den Tread nachgesehen. Stimmt. War aber irgendwie etwas verwirrend dadurch, daß hier auch PMs zu dem Thema ankamen.
Bei mir gehts.
Bei mir auch, Ich kann auch in beiden Richtungen. Allerdings kann ich vom Linux-Rechner aus gesehen mit den Mac-Daten nichts anfangen. Wenn man die von hier aus anfasst und zurückschreibt, ist die Recource-Fork futsch und die braucht der Mac, sonst kann der mit den meisten Daten nichts mehr anfangen.
Aber genau das will ich ja: Linux soll den Mac auflösen.
Wenn ich Dich jetzt richtig verstehe, willst Du vom Linux-Rechner auf den Mac zugreifen?
Nein.
kann ich aber, s.o., nutze ich aber nur zu Kontrollzwecken. Grund, s.o. [..]
Also: Client _und_ Server müssen über DNS auflösbar sein, vor- und rückwärts.
Ich löse allerdings _nicht_ über Namen, sondern nur über IP auf. Reicht auch, da das Netz, in dem die beiden Macs hängen, im 192.168.1.*-Netz liegen und es hier nur diesen Bereich gibt.
Das ist bei telnet so, das ist beim popper so, und mein Vorschlag geht dahin, zu überprüfen, ob das auch beim atalkd so ist.
Da mein System das sowieso kann, ist es eine Mutmaßung.
Soweit ich das atalkd bisher verstanden habe, dient es auf Linux nur dazu, den Mac-Rechnern die Möglichkeit zu geben, File- und Print-Services für die Mac-Rechner zur Verfügung zu stellen, jedoch nicht, ein gegenseitiges AppleTalk- Netz zu betreiben. Also nicht dazu, via AppleTalk auf die Macs zuzugreifen.
Gruß, Ratti
Gruß Martin
From: "Martin Falley"
Bei mir auch, Ich kann auch in beiden Richtungen. Allerdings kann ich vom Linux-Rechner aus gesehen mit den Mac-Daten nichts anfangen. Wenn man die von hier aus anfasst und zurückschreibt, ist die Recource- Fork futsch und die braucht der Mac, sonst kann der mit den meisten Daten nichts mehr anfangen.
Hallo, Kommt auf die Applikation an. Quark, SimpleText, Freehand, müsste alles gehen. Bei QuickTime kommt es auf das Format an. Und Screenfonts liegen ganz in der Ressourcefork, die sind dann ganz weg. ;-)
Soweit ich das atalkd bisher verstanden habe, dient es auf Linux nur dazu, den Mac-Rechnern die Möglichkeit zu geben, File- und Print-Services für die Mac-Rechner zur Verfügung zu stellen, jedoch nicht, ein gegenseitiges AppleTalk- Netz zu betreiben. Also nicht dazu, via AppleTalk auf die Macs zuzugreifen.
Ich probiere es nochmal: Wenn du mit einem Client auf einen Server zugreifst, versucht der Server u.U., den _NAMEN_ des Clients in Erfahrung zu bringen. Dafür muss er ihn auflösen, über reverses DNS. Damit er in sein Logbuch schreiben kann "Mac12.unsernetz.foo" statt "192.168.0.13". Das wars schon. Ich will in keinster Weise sagen, der Server würde auf den Client zugreifen. Er will ihn u.U. auflösen, und wenn das nicht geht, gibt es Timeouts über den DNS, und deswegen klappt der Login vom Client auf den Server nicht. Der Client kann gar nix dafür, er ist nichtmal beteiligt. Lösung 1: Den DNS-Server die Clients auflösen lassen Lösung 2: Dem Server die unsinnigen Auflösungsversuche abgewöhnen. Telnet und popper machen das so. Vom atalkd weiss ich es nicht.
Gruß Martin
Gruß, Ratti
From: Ratti [mailto:ratti@gesindel.de]
From: "Martin Falley"
[..]
Fork futsch und die braucht der Mac, sonst kann der mit den meisten Daten nichts mehr anfangen.
Hallo,
Kommt auf die Applikation an. Quark, SimpleText, Freehand, müsste alles gehen.
Bei QuickTime kommt es auf das Format an.
Und Screenfonts liegen ganz in der Ressourcefork, die sind dann ganz weg. ;-)
sag' ich doch, mit den meisten. Bei den anderen erstellen die jeweiligen Programme nach dem erneuten Abspeichern (meistens) eine neue ResourceFork.
Soweit ich das atalkd bisher verstanden habe, dient es auf Linux nur dazu, den Mac-Rechnern die Möglichkeit zu geben, File- und Print-Services für die Mac-Rechner zur Verfügung zu stellen, jedoch nicht, ein gegenseitiges AppleTalk- Netz zu betreiben. Also nicht dazu, via AppleTalk auf die Macs zuzugreifen.
Ich probiere es nochmal:
Hab' ich doch längst verstanden. Obiges war nur zusätzlich. [..] Gruß Martin
Martin Falley wrote:
Nochmal hi, folgendes Problem habe ich mit appletalk: Ich nutze appletalk version 1.5xx was halt bei Suse 7.3 dabei ist auf einem Rechner. Wenn der Rechner alleine im Netz ist habe ich extreme Probleme beim Connect vom Mac. Die Verbindung dauert einige Minuten bis er die Shares verbindet .
Stimmen die Einträge auf dem Mac? Speed, IP, Mask, Gateway.
IP, Mask und Gateway stimmen, aber was meinst du mit Speed??
Wenn ich einen noch vorhandenen WIN-NT Server mit Appletalk Unterstützung reinhänge der eine zone eingetragen hat, klappts ab und zu.
Gibt es denn mehrere Zonen bei Euch? Sonst brauchst Du keine Zoneneinträge bei Apple. Er verwendet dann automatisch die Standardzone '*'.
Das mag sein, nur dauert dann der connect ewig wenns überhaupt klappt. Deshalb der WIN-NT
Mit dem alten Rechner mit Suse 6.4 und atalk 1.42b gabs und gibts keine Probleme beim Connect. Sobald der neue drin hängt klappts nicht mehr. Kennt jemand das Problem ?
Was passiert, wenn Du versuchst, Dich per IP-Adresse im Auswahlmenu anzumelden?
Bei Kontrollfelder/Auswahl erscheint der Server mit Namen. Dort kann man nach Anklicken nur seinen Usernamen und das Passwort angeben. Oder hab ich was übersehen. Ich muß dazu sagen, ich bin kein Appleuser kenn nur die Grundeinstellungen für TCPIP und so. mfg. joachim -- the cow business Der Kuhhandel Zufallssignatur Nr.: 138
Martin Falley wrote:
Nochmal hi,
[...]
Stimmen die Einträge auf dem Mac? Speed, IP, Mask, Gateway.
IP, Mask und Gateway stimmen, aber was meinst du mit Speed??
Mit Speed meinte ich 10/100, wenn es die Karte nicht autmatisch macht. Das ist automatische Umschalten ist bei einigen Mac-Karten nicht üblich.
Wenn ich einen noch vorhandenen WIN-NT Server mit Appletalk Unterstützung reinhänge der eine zone eingetragen hat, klappts ab und zu.
[...]
Bei Kontrollfelder/Auswahl erscheint der Server mit Namen. Dort kann man nach Anklicken nur seinen Usernamen und das Passwort angeben. Oder hab ich was übersehen. Ich muß dazu sagen, ich bin kein Appleuser kenn nur die Grundeinstellungen für TCPIP und so.
Bei mir ist im Kontrollfeld TCP/IP (Bearbeiten/Benutzermmodus/Administratorfunktionen) folgendes eingestellt: Verbindung: Ethernet '802.3 benutzen' nicht angeklickt Konfigurationsmethode: Manuell IP-Adresse: 192.168.1.6 Teilnetzmaske: 255.255.255.0 Router-Adresse: 192.168.1.1 (Die kannst du aber auch leer lassen) Name Server Adresse: 213.191.74.18 213.191.74.19 Alle anderen Felder (rechte Kontrollfeldseite) sind nicht ausgefüllt. Eine Host-Datei ist nicht gewählt, da manuelle IP-Adressenvergabe und die Host-Datei beim Mac auch etwas anders aussieht als in der restlichen Welt. Apple hat da so seine eigenen Vorstellungen. Frag mich aber nichts genaueres. Ich habe das mal irgendwo gelesen. Dann gibt es im Kontrollfeld noch die Schaltfläche 'Optionen'. Draufklicken. TCP/IP für die Verbindung: aktivieren. 'Nur bei Bedarf laden' ist bei mir ausgeschaltet. So jedenfalls lauft es bei mir und ich kann mich mit jedem Benutzernamen und zugehörigem Passwort den es auf der Linux-Maschine gibt anmelden. Ich kann die Verbindung sogar speichern, sodaß der Mac sich automatisch anmeldet und mir das Netzlaufwerk auf dem Desktop zeigt. System bei mir ist D1-8.6 OpenTransport Version 2.0.3 AppleTalk Version 2.0.3 AppleTalk Treiber 60.0a6 Kannst ja mal vergleichen
mfg. joachim
Gruß Martin
participants (4)
-
Joachim Fossie Bär Reiter -
Martin Falley -
Ratti -
Terving＠t-online.de