Kay Martinen <usenet@martinen.de> wrote:
>Am 12.05.24 um 08:52 schrieb Ralph Aichinger:
>> Marco Moock <mm+solani@dorfdsl.de> wrote:
>>> Um Ethernet zu verstehen ist ein Blick in die Vergangenheit - da ist
>>> der Hub ja noch relativ neu - erforderlich.
>>> Sonst fragt man sich halt öfter mal, warum bestimmte Sachen da so sind,
>>> wie sie sind.
>
>Zum Beispiel warum es Halb-Duplex je gegeben hat und die
>Kollisions-domäne sich über mehrere solcher Geräte erstrecken konnte,
>warum es die 5-4-3 Regel gab u.s.w.
>
>Ja, wenn man das nie benutzt hat könnte man sich diese Fragen stellen.

Bis auf die Frage nach Halbduplex ist das für die heutige Praxis aber
auch völlig irrelevant.

>Habe ich jetzt einige die das können. Aber, ich habe/Musste es noch nie
>benutzt(en). Und du?

Ich versuche möglichst auch bei der Arbeit ohne Mirrorport
auszukommen. Das liegt im Wesentlichen daran, dass die
Switchhersteller in diesem Bereich immer für Überraschungen sorgen.

Manche Dinge sind auch offensichtlich, nämlich dass man bei einem
Mirrorport, der "nur" dieselbe Geschwindigkeit hat wie die zu
monitorende Verbindung, nie sicher sein kann dass man wirklich alles
ausgeleitet bekommt, weil hier die Datenrate zweier Richtungen durch
_einen_ Port herausgequetscht wird, und das reicht halt nicht. Abhilfe
ist hier nur die nächstgrößere Technologie, die nicht immer vorhanden
ist.

Die Möglichkeit zur Zusammenfassung zweier Ports zu einem
Mirror-Trunk, damit man die doppelte Datenrate ausleiten kann, habe
ich noch nie in der Praxis gesehen, und im Switch einen Filter
eingeben um die auszuleitende Datenmenge zu reduzieren auch nie.

Und dann gibt es noch so nette Switches, die Dir die Pakete genau so
ausleiten wie sie in den Switch _hineingehen_, Du also nicht sagen
kannst "gib mir den Traffic von Port 23", sondern eher "gib mir den
Trafic der auf Port 23 reinkommt und den Traffic der für Port 23
reinkommt". Das macht den kleinen aber feinen Unterschied, wenn Port
23 ein Accessport ist, und man sich für Traffic interessiert, dessen
andere Seite über einen VLAN-Trunk erreichbar ist. Dann hat man
bestenfalls die eine Richtung tagged, die andere Richtung untagged im
ausgeleiteten Datenstrom und verliert, wenn man die Daten nicht
aufwendig nachbearbeiten möchte, den Großteil von Wirehsharks
automatischer Analyse¹.

Da freut man sich wenn der Traffic noch über einen dritten Switch
läuft, dann ist das Verkehr von einem VLAN-Trunk zu einem VLAN-Trunk
und in beide Richtungen getagged, aber dafür muss man sich darauf
verlassen können, dass der Traffic wirklich komplett dort vorbeikommt
und sowas hat man doch in heutigen Netzen wegen Redundanz eher
seltener. Außerdem sind viele Backbones heute schon im Gebäude
geroutet und nicht mehr geswitcht.

Aus diesen Gründen ist ein Mirrorport für mich beim Netzwerkdebugging
nur dritte Wahl. Mein Favorit ist tcpdump auf einem der Zielsysteme
(geht technisch nicht immer und macht oft genug Schnappatmung bei den
Regisseuren des Securitytheaters) oder das Einschleifen eines Taps in
die Zuleitung eines der Zielsysteme (macht Unterbrechung, braucht
örtliche Präsenz, löst Heisenberg aus).

Grüße
Marc

¹ oder kann Wireshark inzwischen VLAN-Tags ignorieren?

--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

On 5/13/24 13:46, Marco Moock wrote:
> Am 13.05.2024 13:16 Uhr schrieb Gerrit Heitsch:
>
>> On 5/13/24 06:26, Marco Moock wrote:
>>> Am 12.05.2024 23:23 Uhr schrieb Michael Landenberger:
>>>
>>>> Warum sollte man in einem Heimnetzwerk einen managebaren Switch
>>>> einsetzen? Was für Vorteile bringt der da?
>>>
>>> Dass man da Logging und Einstellmöglichkeiten (z.B. zu
>>> Autonegotiation) hat.
>>
>> Hardware die Probleme mit Autonegotiation hat sollte es nur noch
>> ähnlich oft wie Ethernet-Hubs geben.
>
> Sollte...

Mir ist schon SEHR lange nichts mehr in der Richtung untergekommen.

>
>> Selbst Cisco bekommt das inzwischen hin.
>
> Gab es damit früher Probleme?
> Die 2950er, die ich habe, machten da keine. Oder war das noch früher?

Keine Ahnung wie die hiessen, aber so 2000 rum wurde immer empfohlen bei
Cisco 100FDX fest einzustellen.

Gerrit

Am 15.05.2024 07:45 Uhr schrieb Gerrit Heitsch:

> On 5/13/24 13:46, Marco Moock wrote:
> > Am 13.05.2024 13:16 Uhr schrieb Gerrit Heitsch:
> >
> >> On 5/13/24 06:26, Marco Moock wrote:
> >>> Am 12.05.2024 23:23 Uhr schrieb Michael Landenberger:
> >>>
> >>>> Warum sollte man in einem Heimnetzwerk einen managebaren Switch
> >>>> einsetzen? Was für Vorteile bringt der da?
> >>>
> >>> Dass man da Logging und Einstellmöglichkeiten (z.B. zu
> >>> Autonegotiation) hat.
> >>
> >> Hardware die Probleme mit Autonegotiation hat sollte es nur noch
> >> ähnlich oft wie Ethernet-Hubs geben.
> >
> > Sollte...
>
> Mir ist schon SEHR lange nichts mehr in der Richtung untergekommen.
>
>
> >
> >> Selbst Cisco bekommt das inzwischen hin.
> >
> > Gab es damit früher Probleme?
> > Die 2950er, die ich habe, machten da keine. Oder war das noch
> > früher?
>
> Keine Ahnung wie die hiessen, aber so 2000 rum wurde immer empfohlen
> bei Cisco 100FDX fest einzustellen.

Dann waren das Vorgängermodelle.
Ob es schon der 2900XL war?

--
Gruß
Marco

Spam und Werbung bitte an
1715751924ichwillgesperrtwerden@nirvana.admins.ws

Am 15.05.24 um 07:54 schrieb Marco Moock:
> Am 15.05.2024 07:45 Uhr schrieb Gerrit Heitsch:
>
>> On 5/13/24 13:46, Marco Moock wrote:
>>> Am 13.05.2024 13:16 Uhr schrieb Gerrit Heitsch:
>>>
>>>> On 5/13/24 06:26, Marco Moock wrote:
>>>>> Am 12.05.2024 23:23 Uhr schrieb Michael Landenberger:
>>>>>
>>>>>> Warum sollte man in einem Heimnetzwerk einen managebaren Switch
>>>>>> einsetzen? Was für Vorteile bringt der da?
>>>>>
>>>>> Dass man da Logging und Einstellmöglichkeiten (z.B. zu
>>>>> Autonegotiation) hat.
>>>>
>>>> Hardware die Probleme mit Autonegotiation hat sollte es nur noch
>>>> ähnlich oft wie Ethernet-Hubs geben.

>> Mir ist schon SEHR lange nichts mehr in der Richtung untergekommen >>>
>>>> Selbst Cisco bekommt das inzwischen hin.
>>>
>>> Gab es damit früher Probleme?
>>> Die 2950er, die ich habe, machten da keine. Oder war das noch
>>> früher?
>>
>> Keine Ahnung wie die hiessen, aber so 2000 rum wurde immer empfohlen
>> bei Cisco 100FDX fest einzustellen.

Hatten die denn alle schon autonegotiation? Oder etwas cisco-eigenes
N-Way-tralala Gedöns. Mit ISL haben die ja auch etwas eigenes gebacken.

> Dann waren das Vorgängermodelle.
> Ob es schon der 2900XL war?

Möglicherweise, obwohl ich mich daran nicht mehr erinnere ob ich
Probleme hatte. Ich hab hier 2924XL und 2924M-XL noch liegen. AFAIR
waren die sehr ähnlich zu den 3500XL von denen ich auch noch 2 habe.

Die Modellnummern bei Cisco sind ja nun auch nicht unbedingt
Chronologisch aufsteigend, manche gab es parallel und höhere Nummer =
Neuer trifft gewöhnlich eher nicht zu.

Bye/
/Kay

--
nix

Am 13.05.24 um 08:18 schrieb Marc Haber:
> "Michael Landenberger" <spamwirdgefiltert@web.de> wrote:
>> "Marc Haber" schrieb am 12.05.2024 um 18:19:02:
>>

>>> Bis auf den nicht managebaren switch nicht, nein.
>>
>> Warum sollte man in einem Heimnetzwerk einen managebaren Switch einsetzen? Was
>> für Vorteile bringt der da?
>
> Man ist halt nicht auf irgendwelche unzuverlässigen Automatismen
> angewiesen. Siehe das vorliegende Problem, das sich durch einen Blick
> auf die auslesbaren¹ Fehlerzähler direkt offenbart hätte.

> ¹ Fehlerzähler hat das Silizium in Deien Switchen sicher auch, Du
> kommst halt nur nicht ran

Darum meine Frage ob das ein TL-SG105E ist. Bei DEM kommt man an die
Zähler. Und auch an die Port-Konfig, Multicast-Liste (wenn IGMP-Snoop
aktiv ist) u.s.w.. Man kann dummerweise nur keinen Port vom Default-VLAN
befreien, das ist IMMER mit dabei. Aber da dieses eh nur "untagged" ist...

Bye/
/Kay

--
nix

Am 13.05.24 um 23:25 schrieb Ralph Aichinger:
> Thomas Einzel <usenet-2024@einzel.de> wrote:
>>> Je nachdem halt kann auch Port Mirroring bei der Fehlersuche hilfreich
>>> sein.
>>
>> Habe ich im privaten Umfeld noch nicht benutzt, du?

Hier: Auch nicht.

> Ja, wenn man z.B. nicht weiß ob aus einem Gerät wirklich ein Paket
> rein/rauskommt, man aber keine Möglichkeit hat sich aufs betroffene Gerät
> einzuloggen und tcpdump oder was in der Art zu starten.
Im "Privaten" Umfeld? Da dürfte normalerweise KEIN Gerät 100m Entfernt
sein und man selbst nicht Admin(wider willen) ist.

Und Marc's Antwort nebenan erinnerte mich auch dran das es eben nicht so
trivial sein kann. Früher hab ich nur theoretisch überlegt das der
mirrorport idealerweise schneller ist als der von dem die Daten
gespiegelt werden sollen.

Bye/
/Kay

--
nix

Kay Martinen <usenet@martinen.de> wrote:
> Im "Privaten" Umfeld? Da dürfte normalerweise KEIN Gerät 100m Entfernt
> sein und man selbst nicht Admin(wider willen) ist.

Ob das Gerät 100m entfernt ist oder auf meinem Schreibtisch ist, wenn
ich Fehler suche, dann hilft mir dabei z.B. Portmirroring. Weil zu
wissen, was tatsächlich übers Kabel geht oft sehr hilfreich ist.

Soll heißen: Hat nicht unbedingt was mit der Entfernung zu tun.

/ralph

Kay Martinen <usenet@martinen.de> wrote:
>Am 13.05.24 um 23:25 schrieb Ralph Aichinger:
>> Ja, wenn man z.B. nicht weiß ob aus einem Gerät wirklich ein Paket
>> rein/rauskommt, man aber keine Möglichkeit hat sich aufs betroffene Gerät
>> einzuloggen und tcpdump oder was in der Art zu starten.
>Im "Privaten" Umfeld? Da dürfte normalerweise KEIN Gerät 100m Entfernt
>sein und man selbst nicht Admin(wider willen) ist.

Aber wenn beide Geräte nicht tcpdump-fähig sind, z.B. ein NAS und eine
Settopbox?

Grüße
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Am 15.05.24 um 15:46 schrieb Marc Haber:
> Kay Martinen <usenet@martinen.de> wrote:
>> Am 13.05.24 um 23:25 schrieb Ralph Aichinger:
>>> Ja, wenn man z.B. nicht weiß ob aus einem Gerät wirklich ein Paket
>>> rein/rauskommt, man aber keine Möglichkeit hat sich aufs betroffene Gerät
>>> einzuloggen und tcpdump oder was in der Art zu starten.
>> Im "Privaten" Umfeld? Da dürfte normalerweise KEIN Gerät 100m Entfernt
>> sein und man selbst nicht Admin(wider willen) ist.
>
> Aber wenn beide Geräte nicht tcpdump-fähig sind, z.B. ein NAS und eine
> Settopbox?

Oder mein SAT-Receiver hier. Hat LAN, könnte WLAN aber "Wake" on LAN
kennt er nicht. Aktuell keine 3 Meter entfernt von mir, aber an einem
dummen switch hängend der wiederum an einem SmartSwitch hängt. Der
Mirroring könnte. Aber WoL bekäme ich auch damit nicht zum laufen - wenn
man mal annimmt das der Receiver es tatsächlich nicht kann. Ok, ich
"könnte" das durch Mirroring verifizieren ob das Magic Packet bis dahin
käme. Bei den o.g. 3 Metern spare ich mir das. ;)

Ja, solche Blackboxes hatte ich nicht auf der Liste. Ich wollte mit
obigem eher auf PCs u.ä. administrierbare Geräte zielen. Die man ja auch
in einem Firmennetz hätte - wo sie deutlich weiter auseinander liegen
könnten und man evtl. nicht mal admin-recht drauf hätte.

Von den genannten Ausnahmen hat man im Privaten LAN aber eher immer die
Zugangsmöglichkeit. Und bevor der Einwand kommt: Möglichkeit! Nicht
unbedingt auch die Befähigung. :) Preis der ONU-Tauglichkeit.

Bye/
/Kay

--
nix

Am 15.05.24 um 15:00 schrieb Ralph Aichinger:
> Kay Martinen <usenet@martinen.de> wrote:
>> Im "Privaten" Umfeld? Da dürfte normalerweise KEIN Gerät 100m Entfernt
>> sein und man selbst nicht Admin(wider willen) ist.
>
> Ob das Gerät 100m entfernt ist oder auf meinem Schreibtisch ist, wenn
> ich Fehler suche, dann hilft mir dabei z.B. Portmirroring. Weil zu
> wissen, was tatsächlich übers Kabel geht oft sehr hilfreich ist.
>
> Soll heißen: Hat nicht unbedingt was mit der Entfernung zu tun.
Schon richtig, auch Marc's Einwand (Settop Box o.a.) aber ich nahm an es
wäre im Firmen-umfeld wichtiger und sinnvoller.

Zu Hause ist man entweder admin auf dem Gerät oder könnte solche
Speziellen Kisten ggf. auch mal über einen Hub mit dem Notebook zusammen
an klemmen. Dann sieht man auch jedes Bit.

Oder, ähh, hattest DU gesagt das du deinen Letzten Hub verschrottet
hattest? :)

Wenn ich bei meinem (SAT-Receiver ohne WoL) Beispiel bliebe: Das Tool
starten um einen der nur 5 Switchports auf mirror zu schalten und dann
noch einen Laptop hin tragen und anschließen... ich glaub da ist's
einfacher den ersten Schritt aus zu lassen, den Hub dazwischen zu
stecken und direkt zu lauschen.

Bye/
/Kay

--
nix

Kay Martinen <usenet@martinen.de> wrote:
> Zu Hause ist man entweder admin auf dem Gerät oder könnte solche
> Speziellen Kisten ggf. auch mal über einen Hub mit dem Notebook zusammen
> an klemmen. Dann sieht man auch jedes Bit.

Ja, genau, der managed Switch ist der Ersatz für den historischen Hub ;)

Praktisch kann auch die Überwachung einzelner Ports für irgendwelche
Automatisierungen sein, oder das aus/einschalten von Geräten per PoE
oder solche Dinge.

/ralph -- nein, Mainstreamprogramm ist das alles nix, aber in
Einzelfällen ganz praktisch

Am 15.05.24 um 18:03 schrieb Ralph Aichinger:
> Kay Martinen <usenet@martinen.de> wrote:
>> Zu Hause ist man entweder admin auf dem Gerät oder könnte solche
>> Speziellen Kisten ggf. auch mal über einen Hub mit dem Notebook zusammen
>> an klemmen. Dann sieht man auch jedes Bit.
>
> Ja, genau, der managed Switch ist der Ersatz für den historischen Hub ;)

Und umgekehrt - wenn man noch einen hat. ;)

> Praktisch kann auch die Überwachung einzelner Ports für irgendwelche
> Automatisierungen sein, oder das aus/einschalten von Geräten per PoE
> oder solche Dinge.

Du meinst, dauerhaftes Mirroring um aus empfangenen Paketen
schaltbefehle ab zu leiten?

Dazu muß der Port am Zielhost des mirroring doch im Promiscuos mode
bleiben. Und wie fängst du dort dann die passenden Datenpakete ein? Mit
einem tcpdump in dauerschleife, irgendwas mit 'netcat' oder ???

> /ralph -- nein, Mainstreamprogramm ist das alles nix, aber in
> Einzelfällen ganz praktisch

Ja, an diese Möglichkeit habe ich auch noch nicht gedacht. Eher an eine
(per IP, USB, ???) Schaltbare Steckdosenleiste. Ich hab so eine deren
Windows-Tool z.b. dem Drucker den strom an werfen könnte wenn der
Spooler daten bekommt. Oder eine Externe Platte an wirft wenn drauf
zugegriffen werden soll. Das war noch XP so weit ich erinnere und das
tool quitschbunt wie damals üblich.

Das sispmctl für linux kann das nicht, aber es bringt einen Webserver
mit über den man das manuell per Web-Click an werfen kann. Hatte ich
eine Zeitlang an einem raspi um im Keller Aktionen (fern) aus zu lösen.
Aber sispmctl ist ein shell tool das parameter kennt. Also z.b. auch aus
einem Script, crontab o.a. zu starten.

Nur falls du ne Alternative suchtest...

Bye/
/Kay

--
nix

Kay Martinen <usenet@martinen.de> wrote:
> Du meinst, dauerhaftes Mirroring um aus empfangenen Paketen
> schaltbefehle ab zu leiten?

Nein, neben dem Mirroring kann man auch mit Portüberwachung (z.B. Link
an Port X-> Y machen) oder per PoE lustige Dinge machen.

Z.B. kannst du Home Assistant ein Licht einschalten lassen, wenn jemand
irgendwas in einen bestimmten Netzwerkport steckt, oder solche Dinge,
oder das Licht nach der Downloadgeschwindigkeit einfärben oder so.

/ralph

Am 15.05.2024 15:46 Uhr schrieb Marc Haber:

> Aber wenn beide Geräte nicht tcpdump-fähig sind, z.B. ein NAS und eine
> Settopbox?

Solche Geräte meide ich wo es nur geht.

--
Gruß
Marco

Spam und Werbung bitte an
1715780768ichwillgesperrtwerden@nirvana.admins.ws

Am 15.05.24 um 19:51 schrieb Ralph Aichinger:
> Kay Martinen <usenet@martinen.de> wrote:
>> Du meinst, dauerhaftes Mirroring um aus empfangenen Paketen
>> schaltbefehle ab zu leiten?
>
> Nein, neben dem Mirroring kann man auch mit Portüberwachung (z.B. Link
> an Port X-> Y machen) oder per PoE lustige Dinge machen.

Hmm, linkstatus via snmp abfragen? Dann hab ich dich wohl falsch
verstanden das es mittels mirroring ginge. Das der mirrorport dem
linkstatus seines quellports folgt hätte ich nicht erwartet?

Vor jahren las ich mal eine Anleitung wie man mittels µC den Linktraffic
via snmp ausließt und dann ein Analoginstrument ansteuert. ;)

> Z.B. kannst du Home Assistant ein Licht einschalten lassen, wenn jemand
> irgendwas in einen bestimmten Netzwerkport steckt, oder solche Dinge,
> oder das Licht nach der Downloadgeschwindigkeit einfärben oder so.

Naja, mit SchmartHome Kram kann man einiges machen. Letzteres würde ich
hier aber nicht versuchen. Das hätte einen Dunkelbirnen-Effekt (Beim
Einschalten wird es dunkler) ;)

Bye/
/Kay

--
nix

Marco Moock <mm+solani@dorfdsl.de> wrote:
>Am 15.05.2024 15:46 Uhr schrieb Marc Haber:
>> Aber wenn beide Geräte nicht tcpdump-fähig sind, z.B. ein NAS und eine
>> Settopbox?
>
>Solche Geräte meide ich wo es nur geht.

Geht halt nicht immer.

Grüße
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Marco Moock schrieb am 15/5/2024 21:07:

> Am 15.05.2024 15:46 Uhr schrieb Marc Haber:
>
>> Aber wenn beide Geräte nicht tcpdump-fähig sind, z.B. ein NAS und eine
>> Settopbox?
>
> Solche Geräte meide ich wo es nur geht.

Verwendest du keinen Drucker?

--
Gerald

Am 16.05.2024 17:50 Uhr schrieb Gerald E¡scher:

> Marco Moock schrieb am 15/5/2024 21:07:
>
> > Am 15.05.2024 15:46 Uhr schrieb Marc Haber:
> >
> >> Aber wenn beide Geräte nicht tcpdump-fähig sind, z.B. ein NAS und
> >> eine Settopbox?
> >
> > Solche Geräte meide ich wo es nur geht.
>
> Verwendest du keinen Drucker?

Doch, aber mit LPT oder USB.
Per Netzwerk könnte ich den per lpr erreichbar machen, habe ich aber
nicht, da ich so selten drucke, dass ich da den Laptop mit in den
Keller nehme und gut.

--
Gruß
Marco

Spam und Werbung bitte an
1715874612ichwillgesperrtwerden@nirvana.admins.ws

Am 16.05.24 um 20:02 schrieb Marco Moock:
> Am 16.05.2024 17:50 Uhr schrieb Gerald E¡scher:
>
>> Marco Moock schrieb am 15/5/2024 21:07:
>>
>>> Am 15.05.2024 15:46 Uhr schrieb Marc Haber:
>>>
>>>> Aber wenn beide Geräte nicht tcpdump-fähig sind, z.B. ein NAS und
>>>> eine Settopbox?
>>>
>>> Solche Geräte meide ich wo es nur geht.
>>
>> Verwendest du keinen Drucker?
>
> Doch, aber mit LPT oder USB.
> Per Netzwerk könnte ich den per lpr erreichbar machen, habe ich aber
> nicht,

Den Drucker selbst direkt per LAN mit lpr - oder doch nur über eine
lpr-freigabe auf dem host an dem er hängt?

> da ich so selten drucke, dass ich da den Laptop mit in den
> Keller nehme und gut.

Ich bin mir FAST sicher er meinte damit ob die Firmware in deinem
Drucker dir die Möglichkeit bietet eine shell auszuführen in der du ein
tcpdump starten könntest.... Wie es oben auch schon steht.

Ich drucke auch nur noch selten aber dazu gehe ich nicht mit dem Laptop
in den Keller. Dort habe ich Server - aber keinen Drucker. ;-)

Bye/
/Kay

--
nix

Marco Moock schrieb am 16/5/2024 20:02:

> Am 16.05.2024 17:50 Uhr schrieb Gerald E¡scher:
>
>> Marco Moock schrieb am 15/5/2024 21:07:
>>
>> > Am 15.05.2024 15:46 Uhr schrieb Marc Haber:
>> >
>> >> Aber wenn beide Geräte nicht tcpdump-fähig sind, z.B. ein NAS und
>> >> eine Settopbox?
>> >
>> > Solche Geräte meide ich wo es nur geht.
>>
>> Verwendest du keinen Drucker?
>
> Doch, aber mit LPT oder USB.

LPT ist voriges Jahrtausend und USB vorvoriges Jahrzehnt. Für dich muss
sich das etwa so anfühlen, als würde ich einen seriell angeschlossenen
Kettendrucker benutzen ;-)

> Per Netzwerk könnte ich den per lpr erreichbar machen,

Kein CUPS vorhanden? Mit CUPS lässt sich ein Drucker watscheneinfach im
Netzwerk freigeben.
Ist der Drucker so alt, dass er keinen Netzwerkanschluss hat? Wie auch
immer, tcpdump kann man bei Druckern eher nicht verwenden.

--
Gerald

Am 17.05.2024 18:38 Uhr schrieb Gerald E¡scher:

> Marco Moock schrieb am 16/5/2024 20:02:
>
> > Am 16.05.2024 17:50 Uhr schrieb Gerald E¡scher:
> >
> >> Marco Moock schrieb am 15/5/2024 21:07:
> >>
> >> > Am 15.05.2024 15:46 Uhr schrieb Marc Haber:
> >> >
> >> >> Aber wenn beide Geräte nicht tcpdump-fähig sind, z.B. ein NAS
> >> >> und eine Settopbox?
> >> >
> >> > Solche Geräte meide ich wo es nur geht.
> >>
> >> Verwendest du keinen Drucker?
> >
> > Doch, aber mit LPT oder USB.
>
> LPT ist voriges Jahrtausend und USB vorvoriges Jahrzehnt.

Noch heute gibt es Drucker nur mit USB. Ist an jedem normalen Rechner
vorhanden und erfüllt die Funktion.

> > Per Netzwerk könnte ich den per lpr erreichbar machen,
>
> Kein CUPS vorhanden? Mit CUPS lässt sich ein Drucker watscheneinfach
> im Netzwerk freigeben.

Doch, war sogar der lpr-Dienst vom CUPS, als ich das damals
eingerichtet hatte. Grund war, dass mein Rechner kein LPT hatte und ich
dann einen anderen Rechner als Druckserver eingerichtet hatte. Jetzt
nicht mehr nötig, da mein neuer Rechner wieder LPT hat.

Das Tolle daran: Man hat Kontrolle über das Zeug.

> Ist der Drucker so alt, dass er keinen Netzwerkanschluss hat?

Der eine ja (OfficeJet 350), der andere ist von 2014 und hat nur USB.
Die Netzwerk-Variante gibt es auch, aber dieses Modell hat das halt
nicht. Wurde deswegen aussortiert und ich bekam den kostenlos. Musste
zwar erstmal auslüften und beim Drucken merkt man noch immer, dass der
mal in ner Raucherwohnung stand, aber egal. Hat zwar wegen des Samsung
uld auch schon Ärger gemacht, tut aber aktuell.

--
Gruß
Marco

Spam und Werbung bitte an
1715963888ichwillgesperrtwerden@nirvana.admins.ws