Modem freischalten...
Sascha Toennies
Sascha Toennies alias Pu...@HCB.LEINE.DE
Sysop der *HCB*: *49-5137-74477* (V.34+ & X.75)
--------------------------------------------------------------------------
Halloechen liebe Linuxerinnen und Linuxer!!
Gibt es nuter Linux die Moeglichkeit, ein Modem freizuschalten und somit
dem kompletten Netzwerk zur Verfuegung zu stellen???
Das geht ja z.B. mit Samba fuer den Drucker!!!
Allerdings soll das Modem nicht nur anderen Linuxrechnern zur Verfuegung
stehen, sondern auch Win95 und WinNT Rechnern!!!
Cu Sascha
--------------------------------------------------------------------------
Hiermit verbiete ich jedem, mir auch nur eine nichtgewollte Werbemail
zuzuschicken!!!
Ich berufe mich hierbei auf folgendes Urteil: Az.: 2 HK 03755/97,
nachdem diese Art von Werbung wettbewerbswidrig und somit ungesetzlich ist!!
## CrossPoint v3.11 R ##
Thomas Andres
Sascha Toennies wrote in message <6xrUA...@pucki.hcb.leine.de>...
>Gibt es nuter Linux die Moeglichkeit, ein Modem freizuschalten und somit
>dem kompletten Netzwerk zur Verfuegung zu stellen???
>Das geht ja z.B. mit Samba fuer den Drucker!!!
>Allerdings soll das Modem nicht nur anderen Linuxrechnern zur Verfuegung
>stehen, sondern auch Win95 und WinNT Rechnern!!!
Ich glaube Du moechtest ein IP-Masquerading installieren. (Siehe
Maquerading HowTo, ...)
Bye
Thomas
--
mail: tan...@iiic.ethz.ch
http://www.vis.inf.ethz.ch/~tandres/
* <- Tribble è <- Tribble in cap and gown
Frank Kubitzky
Sascha Toennies schrieb in Nachricht <6xrUA...@pucki.hcb.leine.de>...
>Diese Mail schrieb:
>
> Sascha Toennies alias Pu...@HCB.LEINE.DE
>
> Sysop der *HCB*: *49-5137-74477* (V.34+ & X.75)
>--------------------------------------------------------------------------
>
>Halloechen liebe Linuxerinnen und Linuxer!!
>
>dem kompletten Netzwerk zur Verfuegung zu stellen???
>Das geht ja z.B. mit Samba fuer den Drucker!!!
>Allerdings soll das Modem nicht nur anderen Linuxrechnern zur Verfuegung
>stehen, sondern auch Win95 und WinNT Rechnern!!!
>
>
>
>
>--------------------------------------------------------------------------
>Hiermit verbiete ich jedem, mir auch nur eine nichtgewollte Werbemail
>zuzuschicken!!!
>Ich berufe mich hierbei auf folgendes Urteil: Az.: 2 HK 03755/97,
>nachdem diese Art von Werbung wettbewerbswidrig und somit ungesetzlich
ist!!
>## CrossPoint v3.11 R ##
Hallöle Sascha,
es gibt eine Möglichkeit, die ist aber etwas aufwendig.
Du mußt Dir einen Router basteln. Unter Linux mußt Du einen PPP-Zugang
einrichten und dann kannst Du über TCP/IP in deinem Netzwerk auch nach
aussen hin zugreifen.
Für die SUSE-Distibution gibt es unter http://www.suse.de in der
Supportdatenbank gute Unterstützung dafür, außerdem könntest Du in der
Zeitschrift PC-Online 1/98 eine komplette Anleitung für die DLD 5.2
nachlesen...
Tschaui
Kubi
This mail was send form:
Frank.K...@T-ONLINE.DE
Juergen Ilse
In ger.pc.linux Sascha Toennies <Pu...@hcb.leine.de> wrote:
>Gibt es nuter Linux die Moeglichkeit, ein Modem freizuschalten und somit
>dem kompletten Netzwerk zur Verfuegung zu stellen???
Meines Wissens nach so ohne weiteres nicht, aber wieso willst du das denn
ueberhaupt???
>Das geht ja z.B. mit Samba fuer den Drucker!!!
Das ist auch ein bischen was anderes. Da wird eine Print-Queue im Lanmanager-
Netz angemeldet. Leider ist im Lanmanager-Protokoll meines Wissens nach so
etwas wie eine "Modem-Queue" nicht vorgesehen ;-)
>Allerdings soll das Modem nicht nur anderen Linuxrechnern zur Verfuegung
>stehen, sondern auch Win95 und WinNT Rechnern!!!
Wie gesagt, mir ist keine Loesung bekannt. Wenn es allerdings darum gehen
sollte, allen Rechnern im Netz einen Internet-Zugang zur Verfuegung zu
stellen, kannst du den Linux-Rechner einfach als Gateway konfigurieren.
Auf den Windows-Rechnern benutzt du dann statt des DFUE-Netzwerks einfach
das Ethernet mit einer Default-Route auf den Linux-Rechner fuer den Inter-
netzugang. Bei Bedarf kann man den Linux-Rechner so konfigurieren, dass er
bei Bedarf automatisch die Verbindung aufbaut, aber Vorsicht! es duerfen
keine Lan-Manager-Pakete (Samba) nach draussen geroutet werden (Samba-Kon-
figuration ueberpruefen!!!), da sonst evt. die Modem-Verbindung dauernd
offen bleibt...
Tschuess,
Juergen Ilse (il...@asys-h.de)
st...@hagal.han.de
Juergen Ilse <il...@pop-hannover.de> wrote:
> In ger.pc.linux Sascha Toennies <Pu...@hcb.leine.de> wrote:
> >Gibt es nuter Linux die Moeglichkeit, ein Modem freizuschalten und somit
> >dem kompletten Netzwerk zur Verfuegung zu stellen???
> Meines Wissens nach so ohne weiteres nicht, aber wieso willst du das denn
> ueberhaupt???
Immer diese Sinnfragen .. ;)
> >Das geht ja z.B. mit Samba fuer den Drucker!!!
> Das ist auch ein bischen was anderes. Da wird eine Print-Queue im Lanmanager-
> Netz angemeldet. Leider ist im Lanmanager-Protokoll meines Wissens nach so
> etwas wie eine "Modem-Queue" nicht vorgesehen ;-)
Wäre mal ein interessantes Projekt ... Aber was ist eigentlich mit
Seriellen Druckern .. Man müßte den Queue nur transparent, also ohne
Filter schalten .. ?? Naja, ziemlich aufwendig, denke ich ...
> >Allerdings soll das Modem nicht nur anderen Linuxrechnern zur Verfuegung
> >stehen, sondern auch Win95 und WinNT Rechnern!!!
> Wie gesagt, mir ist keine Loesung bekannt. Wenn es allerdings darum gehen
> sollte, allen Rechnern im Netz einen Internet-Zugang zur Verfuegung zu
> stellen, kannst du den Linux-Rechner einfach als Gateway konfigurieren.
Das halte ich auch für die bessere Lösung. Außer man möchte normales DFÜ
betreiben, da hilf das auch nicht weiter. Am einfachsten wäre dann wohl
das kaufen von Modems ...
Grundsätzlich kann ich zu dem Thema sagen, daß ich irgendwo in einer C't
zu diesem Thema die Behauptung gelesen habe, das ginge mit einem einfachen
Script auf Linux. Für Windoof benötigt man allerdings ein
kommerzielles Programm, um auf die Modems zugreifen zu können ...
Wo das genau stand, möge der interessierte Leser bitte selber heraussuchen...
(Das muß in diese Jahr gewesen sein).
Aber andererseits habe ich noch eine interessante Idee:
Wenn man das "/dev" Verzeichnis per NFS von außen mounten würde, müßte
ich doch eigentlich auch auf die seriellen Devices (/dev/ttySx )
zugreifen können, oder nicht ?
Man bräuchte nur noch auf der Windowsseite entsprechende Software um auf
diesen Port zugreifen zu können .. (Natürlich auch nfs..)
Naja, ist nur so ein Gedanke..
Ciao, Stefan
--
========================================================================
Stefan Eilers I Dingelstedtstr.7 I Tel.: 0511-694517
I 30657 Hannover I
========================================================================
Michael Riepe
[...]
> Aber andererseits habe ich noch eine interessante Idee:
> Wenn man das "/dev" Verzeichnis per NFS von außen mounten würde, müßte
> ich doch eigentlich auch auf die seriellen Devices (/dev/ttySx )
> zugreifen können, oder nicht ?
Wieso kommt eigentlich jeder Unix-Newbie auf diese beknackte Idee?
Vergiss es ganz schnell wieder, sowas geht nicht. Man kann Devices nicht
per NFS exportieren. Klar, Du bekommst auf dem Client ein Verzeichnis mit
vielen Eintraegen drin - aber wenn Du dann /nfs/importiertes/dev/ttyS0
oeffnest, bekommst Du bestenfalls die serielle Schnittstelle vom *Client*,
wenn ueberhaupt.
--
Michael "Tired" Riepe <Michae...@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
st...@hagal.han.de
> st...@hagal.han.de wrote:
> [...]
> > Aber andererseits habe ich noch eine interessante Idee:
> > Wenn man das "/dev" Verzeichnis per NFS von außen mounten würde, müßte
> > ich doch eigentlich auch auf die seriellen Devices (/dev/ttySx )
> > zugreifen können, oder nicht ?
> Wieso kommt eigentlich jeder Unix-Newbie auf diese beknackte Idee?
Wieso beknackt ? Das hängt doch von der internen Struktur ab. Wer
sagt denn, daß NFS nicht als transparenter Kanal zwischen den beiden
Rechnern existieren kann ? Ich halte diesen Gedanken, auch wenn ich die
Funktionsfähigkeit nicht für sehr wahrscheinlich halte, jedenfalls nicht
für so abwegig.
> Vergiss es ganz schnell wieder, sowas geht nicht. Man kann Devices nicht
> per NFS exportieren.
Hast Du es mal ausprobiert ?
> Klar, Du bekommst auf dem Client ein Verzeichnis mit
> vielen Eintraegen drin - aber wenn Du dann /nfs/importiertes/dev/ttyS0
> oeffnest, bekommst Du bestenfalls die serielle Schnittstelle vom *Client*,
Das würde mich nun wirklich wundern .. :S
> wenn ueberhaupt.
Wie gesagt, es war ein Gedanke, nicht mehr ...
Juergen Ilse
In fido.ger.linux st...@hagal.han.de wrote:
>Michael Riepe <mic...@stud.uni-hannover.de> wrote:
>> st...@hagal.han.de wrote:
>> [...]
>> > Aber andererseits habe ich noch eine interessante Idee:
>> > Wenn man das "/dev" Verzeichnis per NFS von außen mounten würde, müßte
>> > ich doch eigentlich auch auf die seriellen Devices (/dev/ttySx )
>> > zugreifen können, oder nicht ?
>> Wieso kommt eigentlich jeder Unix-Newbie auf diese beknackte Idee?
>Wieso beknackt ? Das hängt doch von der internen Struktur ab. Wer
>sagt denn, daß NFS nicht als transparenter Kanal zwischen den beiden
>Rechnern existieren kann ? Ich halte diesen Gedanken, auch wenn ich die
>Funktionsfähigkeit nicht für sehr wahrscheinlich halte, jedenfalls nicht
>für so abwegig.
Ist es aber, denn ein Device-Eintrag im Filesystem ist ein Verweis auf einen
"Kernel-Entry-Point", sprich eine Art "Einsprungaddresse" um die Device-Funk-
tionen direkt aufzurufen. Der Kernel uebersetzt Zugriffe auf den Device-Ein-
trag (mehr oder weniger) direkt in Aufrufe des Device-Treibers.
>> Vergiss es ganz schnell wieder, sowas geht nicht. Man kann Devices nicht
>> per NFS exportieren.
>Hast Du es mal ausprobiert ?
Wozu, wo es doch ohnehin nicht funktioniert (nicht funktionieren kann, siehe
oben)...
>> Klar, Du bekommst auf dem Client ein Verzeichnis mit
>> vielen Eintraegen drin - aber wenn Du dann /nfs/importiertes/dev/ttyS0
>> oeffnest, bekommst Du bestenfalls die serielle Schnittstelle vom *Client*,
>Das würde mich nun wirklich wundern .. :S
Wenn man ueberhaupt an etwas ueber derartige Directory-Eintraege herankommt,
dann an das device des CLIENTS (fuer eine Erklaerung siehe oben). Ob man
ueberhaupt an devices darueber herankommt, haegnt von den mount-optionen ab
(z.B. "-o nodev", was fuer nfs meines Wissens nach der default ist).
>> wenn ueberhaupt.
>Wie gesagt, es war ein Gedanke, nicht mehr ...
...aber kein funktionstuechtiger...
Tschuess,
Juergen Ilse (il...@asys-h.de)
Urs Thuermann
> > Wieso kommt eigentlich jeder Unix-Newbie auf diese beknackte Idee?
>
> Wieso beknackt ? Das hängt doch von der internen Struktur ab. Wer
> sagt denn, daß NFS nicht als transparenter Kanal zwischen den beiden
> Rechnern existieren kann ?
Das NFS-Protokoll. RFC1094 und RFC1813.
> Ich halte diesen Gedanken, auch wenn ich die Funktionsfähigkeit
> nicht für sehr wahrscheinlich halte, jedenfalls nicht für so
> abwegig.
>
> > Vergiss es ganz schnell wieder, sowas geht nicht. Man kann Devices nicht
> > per NFS exportieren.
>
> Hast Du es mal ausprobiert ?
Ueberfluessig. Es kann nicht funktionieren. Der client sieht einen
inode, der ein device beschreibt. Wenn ein client mit ioctl() darauf
zugreift, wird der kernel versuchen, mit dem entsprechenden lokalen
Treiber zu reden. Der Treiber auf dem NFS server sieht nichts.
> > Klar, Du bekommst auf dem Client ein Verzeichnis mit
> > vielen Eintraegen drin - aber wenn Du dann /nfs/importiertes/dev/ttyS0
> > oeffnest, bekommst Du bestenfalls die serielle Schnittstelle vom *Client*,
>
> Das würde mich nun wirklich wundern .. :S
Mich nicht. Wenn der client einen device driver mit derselben major
number kennt, wird er mit dem reden. Wenn NFS client und NFS server
das gleiche OS fahren, wird sogar ein passender Treiber angesprochen,
aber eben nur auf der client Seite. Das ist also nicht, was Du
willst.
Uebrigens ist es tatsaechlich nicht unueblich, device special files
per NFS zu exportieren, naemlich fuer diskless clients. Aber auch
hier eben nur, damit der client auf seine *lokalen* devices zugreifen
kann. Auf remote devices kann man per NFS nicht zugreifen.
urs
Urs Thuermann
> Wäre mal ein interessantes Projekt ... Aber was ist eigentlich mit
> Seriellen Druckern .. Man müßte den Queue nur transparent, also ohne
> Filter schalten .. ?? Naja, ziemlich aufwendig, denke ich ...
Du weisst nicht, wie das Drucken auf remote printer funktioniert,
oder? Es ist dabei voellig unerheblich, ob der Drucker parallel,
seriell ueber TCP/IP, DECnet oder sonstwie angeschlossen ist.
Der Prozess, der den Druckjob abschickt, spricht nicht mit dem Drucker
(ganz gleich, ob der Drucker lokal oder remote ist), sondern mit lpd
(line printer daemon).
> Das halte ich auch für die bessere Lösung. Außer man möchte normales DFÜ
> betreiben, da hilf das auch nicht weiter. Am einfachsten wäre dann wohl
> das kaufen von Modems ...
Kommt drauf an, was man will. Mit 'nem relativ einfachen, selbst
gestrickten daemon koennte man auch von aussen auf Modems zugreifen.
> Wenn man das "/dev" Verzeichnis per NFS von außen mounten würde, müßte
> ich doch eigentlich auch auf die seriellen Devices (/dev/ttySx )
> zugreifen können, oder nicht ?
no way. siehe anderes posting.
urs
st...@hagal.han.de
Urs Thuermann <thue...@ibr.cs.tu-bs.de> wrote:
> <st...@hagal.han.de> writes:
> > > Wieso kommt eigentlich jeder Unix-Newbie auf diese beknackte Idee?
> >
> > Wieso beknackt ? Das h?ngt doch von der internen Struktur ab. Wer
> > sagt denn, da? NFS nicht als transparenter Kanal zwischen den beiden
> > Rechnern existieren kann ?
> Das NFS-Protokoll. RFC1094 und RFC1813.
Ich gebe zu, daß ich die Tiefen des NFS nicht kannte. Da ich von anderen
Betriebsystemen allerdings wußte, wo auf entferte Schnittstellen über das
verteilte Filesystem zugegriffen werden kann, hielt ich die Möglichkeit
jedenfalls nicht für so abwegig. So wie ich den Mechanismus allerdings
jetzt sehe, ist es tatsächlich nicht mögich ...
> Uebrigens ist es tatsaechlich nicht unueblich, device special files
> per NFS zu exportieren, naemlich fuer diskless clients. Aber auch
> hier eben nur, damit der client auf seine *lokalen* devices zugreifen
> kann. Auf remote devices kann man per NFS nicht zugreifen.
Tja, es wäre ja praktisch gewesen .. ;)
Urs Thuermann
> > Das NFS-Protokoll. RFC1094 und RFC1813.
>
> Ich gebe zu, daß ich die Tiefen des NFS nicht kannte. Da ich von anderen
> Betriebsystemen allerdings wußte, wo auf entferte Schnittstellen über das
> verteilte Filesystem zugegriffen werden kann, hielt ich die Möglichkeit
> jedenfalls nicht für so abwegig.
Keine Ahnung, was andere Betriebssysteme fuer Unsinn treiben,
jedenfalls macht NFS es richtig und unterstuetzt daher sowas nicht
(s.u.).
> > Uebrigens ist es tatsaechlich nicht unueblich, device special files
> > per NFS zu exportieren, naemlich fuer diskless clients. Aber auch
> > hier eben nur, damit der client auf seine *lokalen* devices zugreifen
> > kann. Auf remote devices kann man per NFS nicht zugreifen.
>
> Tja, es wäre ja praktisch gewesen .. ;)
Nein. Es waere Unsinn gewesen. Bei verteilten Systemen kann man nicht
davon ausgehen, dass alle Knoten im Netz die gleiche Hardware und das
gleiche Betriebssytem besitzen. Hardware-Schnittstellen oder
Treiber-Schnittstellen (ioctl's) sind hardware- bzw. OS-abhaengig und
es macht daher keinen Sinn, sie ueber ein hardware- und
OS-unabhaengiges file system wie NFS zu exportieren. NFS bietet eine
vom OS weitgehend unabhaengige Abstraktion, naemlich einfache files,
an. Da passen hardware-Treiber nicht rein.
Wenn man Resourcen wie ein bestimmtes Geraet ueber ein Netz anderen
Knoten zur Verfuegung stellen will, sollte dafuer ein Protokoll
entwickelt werden, dass vom OS und der darunterliegenden hardware
abstrahiert (so wie NFS das fuer Datei-Resourcen tut). Fuer serielle
oder parallele Schnittstellen beispielsweise kann man sich auch ein
Protokoll ueberlegen; das ginge aber weit ueber die Aufgabe eines
verteilten file system (NFS) hinaus.
Um noch mal auf Deine Bemerkung von oben einzugehen: Ich weiss nicht
welche Betriebssyteme Du da meinst, kenne auch kein file system, das
solche Dineste anbietet. Falls Du da irgendwas von M$ meinst, wuerde
mich das allerdings nicht wundern, da die haeufig so implementieren,
dass es irgendwie funktioniert, ohne dass das ganze aber Sinn und
Verstand und eine saubere Struktur hat.
urs
st...@hagal.han.de
> > Ich gebe zu, da? ich die Tiefen des NFS nicht kannte. Da ich von anderen
> > Betriebsystemen allerdings wu?te, wo auf entferte Schnittstellen ?ber das
> > verteilte Filesystem zugegriffen werden kann, hielt ich die M?glichkeit
> > jedenfalls nicht f?r so abwegig.
> Keine Ahnung, was andere Betriebssysteme fuer Unsinn treiben,
> jedenfalls macht NFS es richtig und unterstuetzt daher sowas nicht
> (s.u.).
Ich denke nicht, daß ich hier jetzt einen Glaubenskrieg anfangen will.
Aber "Richtig" und "Falsch" sind wohl kaum angemessene Begriffe, um
verschiedene Systemphilosophien zu betiteln ...
> Nein. Es waere Unsinn gewesen. Bei verteilten Systemen kann man nicht
> davon ausgehen, dass alle Knoten im Netz die gleiche Hardware und das
> gleiche Betriebssytem besitzen. Hardware-Schnittstellen oder
> Treiber-Schnittstellen (ioctl's) sind hardware- bzw. OS-abhaengig und
> es macht daher keinen Sinn, sie ueber ein hardware- und
> OS-unabhaengiges file system wie NFS zu exportieren. NFS bietet eine
> vom OS weitgehend unabhaengige Abstraktion, naemlich einfache files,
> an. Da passen hardware-Treiber nicht rein.
Da hast Du in diesem Zusammenhang sicherlich nicht unrecht.
> Um noch mal auf Deine Bemerkung von oben einzugehen: Ich weiss nicht
> welche Betriebssyteme Du da meinst, kenne auch kein file system, das
> solche Dineste anbietet.
RTOS-UH. Bei diesem Betriebsystem gilt aber Dein Argument nicht, daß ein
Filesystem Betriebsystemunabhängig implementiert sein muß. Unser
verteiltes Filesystem ist halt fest an dem Betriebsystem gekoppelt. Im
übrigend ist die Ansteuerung der Schnittstelle auf dem Zielrechner über
IO-Dämonen realisiert, was die Hardwareabhängigkeit auf den
lokalen Rechner, wie von Dir verlangt, begrenzt. Nach außen ist es eine
klar definierte Schnittstelle.
> Falls Du da irgendwas von M$ meinst, wuerde
> mich das allerdings nicht wundern, da die haeufig so implementieren,
> dass es irgendwie funktioniert, ohne dass das ganze aber Sinn und
> Verstand und eine saubere Struktur hat.
:))
Nö, ich würde ja niemals wagen, eine MS- Lösung überhaupt nur in die
Diskussion einzubringen. :)