dass ich bei nicht optimalen Lichtverhältnissen zurück in 2010 bin
sei froh dass es nicht 2040 is ![]()
dass ich bei nicht optimalen Lichtverhältnissen zurück in 2010 bin
sei froh dass es nicht 2040 is ![]()
Das kanst du mit Gigaset (Gigaset GX 4) bis auf dessen Gewicht und deren Gehäusestärke haben. Denn nach Einführung deren Geräte bekommt man ca. 10 Jahre für das OS Updates.
ist ein Schritt in die richtie Richtung, es stört halt, dass hier die Updates nicht direkt von Google - obwohl Android - sondern von Gigaset selbst kommen;
wobei wo liest Du das mit den 10 Jahren?
das hier
https://www.netzwelt.de/update-fahrplan/gigaset-android-updates-smartphones-tablets-ueberblick.html
läßt einem ja nicht wirklich positiv stimmen;
ah ja und es fällt ma noch was ein, wieso SPAM-Sender froh sein können, dass ich kein Jurist sondern nur IT-Mensch bin;
SPAM-Sender würde ich dazu verdonnern einen Schiffscontainer
von dem Zeug je nach Kalendertag nach Südamerika, nach Afrika od. nach Pakistan/Indien/Bangladesh zu liefern; ![]()
Im Sinne der Nachhaltigkeit kann es aber auch nicht sein, dass man alle 1-2 Jahre ein neues Telefon kaufen muss.
da bin ich bei Dir, dass so wie es momentan läuft alles andere als ökologisch nachhaltig ist;
wenn ich nur daran denke, was auf viele Firmen zukommt; die müssen - weil es Microsoft so will - gute Hardware wegschmeissen,
weil diese mit Win11 nicht supported wird;
es ist traurig; Notebook-Akkus sind mittlerweile auch fest verbaut;
es gibt Argumente, welche f. iPhones sprechen, aber diese gelten f. den Businessbereich;
weil alle eingesetzten iPhones immer den selben Patch-Level haben - aber das bezahlt man auch;
es gibt eine Geschichte, bei der kann man philosophieren, was besser ist;
G[oogle]Pay vs. ApplePay
bei iPhones ist die NFC-Schnittstelle im iOS fest verankert, bei Android erlaubt es Google,
dies mit Apps zu verwenden;
die Folge: ApplePay muss die Bank supporten, hingegen bei G[oogle]Pay braucht sie das nicht;
manche Banken handhaben das auch so; z.B. Raiffeisen in AT hat f. Androide eine eigene App RaiPay gestrickt;
das hat f. die Bank auch den Vorteil, weil sie f. damit getätigten Transaktionen keine Gebühr an Google bezahlen müssen;
hingegegen bei ApplePay kassiert Apple f. jede damit getätigte Transaktion eine Gebühr von der Bank;
würde das Verhältnis iPhone-Nutzer zu AndroidPhone-Nutzer umkippen kann sich damit dann jeder ausrechnen,
was das an Bankgebühren bedeutet;
es würde auch Google f. jede Transaktion, welche mit G[oogle]Pay getätigt wird, eine Gebühr von der Bank kassieren;
Soll das lustig sein?
irgendwie schon; weil dieses Argument höre ich öfters; dass man es aber auch bezahlt will sich dann aber niemand eingestehen;
soll heißen: während der Lebenszeit eines iPhones hat man vlt. 2-3 AndroidPhones,
aber in Summe mit den Androiden auch nicht mehr Geld ausgegeben als das eine iPhone gekostet hat;
nach einigen Jahren wo es bei einem Android schon lange keine Updates mehr gibt, ein iPhone immer noch mit Updates versorgt wird,
will sich auch niemand eingestehen, dass er es eigentlich nicht mehr haben will - Akku hat nicht mehr die Leistung, und ein neues hat Features welche man gerne hätte; von daher finde ich das dann schon lustig;
übrigens Dein Vergleich passt nicht ganz, weil beim Pass holst Dir einfach gegen eine gringe Gebühr einen neuen, und der gillt dann wieder x Jahre;
beim Phone hingegen hast mit einem Ersatzphone - des a bissi mehr als nur eine geringe Gebühr kostet - nicht viel angefangen;
Stichworte: pushTAN, eIDAS, OTP, ... u.a.m.
Uff, heute ist mein 2 Jähriges Jubiläum im Forum
102 klingt besser ![]()
..., da ich mein Plan hatte was mit sin beim Aufleiten passiert.
Hilfe ![]()
Wenn es um Haltbarkeit und lange Updates eines Gerätes geht, ist Apple genau die richtige Wahl.
wennst es in Zimmer 100 'runterspülst ist das egal ![]()
Paul genau so eine Erklärung liebe ich, nur wieso komm ich von den anderen Linuxen noch hin?
Für RSA und ECDSA gab es doch mal sicherheitstechnische Bedenken - allerdings kann ich das nicht genau beschreiben. Meine Keys mache ich seit Jahren mit Ed25519.
gibt dafür sogar 'ne Anleitung von Microsoft: https://learn.microsoft.com/en-us/windows-…-key-generation
wobei so 'ne seltsame unorthodoxe Geschichte, die ich da vor kurzem hatte ...
auf einer VM mit Fedora sind im authorized_keys so ein paar Keys abgelegt,
einer von der Win10 Wkst. selbst, diverse andere von anderen Linuxen; allesamt RSA 2048 Bit;
von überall gehts nur von Windows selbst wurde das partout nach Jahren fehlerfreier Funktion auf einmal nicht mehr akzeptiert¹;
hatte dann einen ED25519 Key im Windows generiert, und nun geht es wieder;
aber zu den anderen Linuxen passt das mit dem 2048-bit RSA Key weiterhin ...
ich unterstell hier mal, dass hier die Schuld bei beiden liegt: sowohl Microsoft als auch Fedora;
andreas. dem widerspricht folgendes:
habe ich nur eine IPv6-Adresse prefix::1, dann ist es das selbe wie wenn ich diese 4 IPv6-Adressen prefix::<1-4> hätte und bei den
zusätzlichen (2ndaries) folgende Änderung mache: /sbin/ip addr change prefix::... dev eth0 preferred_lft 0;
ausgehend wird immer prefix::1 verwendet, aber in einem Fall das traceroute6 mit den 8 Hops oben und im anderen Fall aber der mit 10 Hops;
Hab ich das richtig verstanden? Die zusätzlichen Hops sind irgendwo in der Mitte des Traces? Nicht am Anfang? Also ich meine, an dem "Ende" des Traces, wo der Server ist?
ja hast Du
und so sieht es aus, einmal Standard
[root@transalpin ~]# traceroute6 -I 6in4gate.tunnel
traceroute to 6in4gate.tunnel (2a0d:f302:101:x::1), 30 hops max, 80 byte packets
1 2a03:4000:f::3 (2a03:4000:f::3) 0.374 ms 0.468 ms 0.463 ms
2 2a00:11c0:47:3::20 (2a00:11c0:47:3::20) 3.123 ms 3.291 ms 3.283 ms
3 2a00:11c0:47:1:47::138 (2a00:11c0:47:1:47::138) 0.287 ms 0.329 ms 0.322 ms
4 2a00:11c0:47:1:47::136 (2a00:11c0:47:1:47::136) 9.178 ms 9.204 ms 9.198 ms
5 2a00:11c0:47:1:47::133 (2a00:11c0:47:1:47::133) 9.134 ms 9.296 ms 9.287 ms
6 vix.alwyzon.net (2001:7f8:30:0:2:1:4:994) 10.557 ms 9.197 ms 9.181 ms
7 2a0d:f302:8:11:: (2a0d:f302:8:11::) 15.730 ms 15.735 ms 15.728 ms
8 6in4gate.tunnel (2a0d:f302:101:x::1) 9.101 ms 9.074 ms 9.021 ms
[root@transalpin ~]#
Alles anzeigen
und einmal nachdem die 3 zusätlichen IPv6-Adresse des /64 mit /sbin/ip addr change prefix::... dev eth0 preferred_lft 0 geändert wurden
[root@transalpin ~]# traceroute6 -I 6in4gate.tunnel
traceroute to 6in4gate.tunnel (2a0d:f302:101:x::1), 30 hops max, 80 byte packets
1 2a03:4000:f::3 (2a03:4000:f::3) 0.348 ms 0.251 ms 0.237 ms
2 2a00:11c0:47:3::20 (2a00:11c0:47:3::20) 0.376 ms 0.403 ms 0.393 ms
3 2a00:11c0:47:1:47::141 (2a00:11c0:47:1:47::141) 3.514 ms 3.510 ms 3.498 ms
4 2a00:11c0:47:1:47::148 (2a00:11c0:47:1:47::148) 3.821 ms 3.812 ms 3.825 ms
5 2a00:11c0:47:1:47::146 (2a00:11c0:47:1:47::146) 3.719 ms 3.755 ms 3.783 ms
6 2a00:11c0:47:1:47::151 (2a00:11c0:47:1:47::151) 14.709 ms 14.987 ms 14.936 ms
7 2a00:11c0:47:1:47::134 (2a00:11c0:47:1:47::134) 11.961 ms 12.144 ms 12.116 ms
8 vix.alwyzon.net (2001:7f8:30:0:2:1:4:994) 11.954 ms 12.048 ms 11.978 ms
9 2a0d:f302:8:11:: (2a0d:f302:8:11::) 18.381 ms 18.367 ms 18.349 ms
10 6in4gate.tunnel (2a0d:f302:101:x::1) 11.898 ms 11.858 ms 11.836 ms
[root@transalpin ~]#
Alles anzeigen
diese Änderung findet auf [transalpin] statt, der steht hier bei netcup ...
und sieht die andere Richtung aus ... (unabhängig von der erwähnten Änderung)
[root@6in4gate ~]# traceroute6 -I transalpin.host
traceroute to transalpin.host (2a03:4000:f:x::1), 30 hops max, 80 byte packets
1 gw101.core1.vie.alwyzon.net (2a0d:f302:101::1) 11.202 ms 11.195 ms 11.190 ms
2 ae0.edge1.vie.alwyzon.net (2a0d:f302:8:11::1) 1.082 ms 1.103 ms 1.147 ms
3 et-2-0-5-1337.bbr01.anx03.vie.at.anexia-it.net (2001:7f8:30:0:1:1:4:7147) 0.462 ms 0.465 ms 0.462 ms
4 2a00:11c0:47:1:47::132 (2a00:11c0:47:1:47::132) 0.750 ms 0.749 ms 0.794 ms
5 2a00:11c0:47:1:47::137 (2a00:11c0:47:1:47::137) 9.170 ms 9.176 ms 9.174 ms
6 2a00:11c0:47:3::33 (2a00:11c0:47:3::33) 12.877 ms 12.506 ms 12.492 ms
7 transalpin.host (2a03:4000:f:x::1) 12.139 ms 11.969 ms 11.962 ms
[root@6in4gate ~]#
Hat jemand mehr als nur eine IPv6-Adresse des /64-Prefix am vServer-NIC in Verwendung?
ich hab auf einem vServer 4 IPv6-Adressen in Verwendung
prefix::1
prefix::2
prefix::3
prefix::4
und jetzt der AHA-Effekt, den ich überhaupt nicht erklären kann ...
ich hab folgendes laufen sobald das NIC aktiv ist
/sbin/ip addr change prefix::2 dev eth0 preferred_lft 0
/sbin/ip addr change prefix::3 dev eth0 preferred_lft 0
/sbin/ip addr change prefix::4 dev eth0 preferred_lft 0
bewirken soll das, dass ausgehender Traffic von nur einer IPv6 (prefix::1) gemacht wird;
dass sich hier dabei aber der traceoute6 verlängert, kann das jemand erklären warum?
und bekommt man das gewünschte Verhalten auch ohne der zusätzlichen Hops¹ im traceroute6 hin?
¹ diese sind irgendwo, und lassen echt nicht auf diese config schließen ...
Ja ich lebe, und die Welt hat Glück dass ich nur IT-Mensch bin und kein Jurist ![]()
ich würd die Betreiber von Sites die mit dem komischen Cookies-Zeugs daherkommen,
dazu zu verpflichten eine Palette Prinzenrolle [= Cookies] bei mir zu Hause abzuladen; ![]()
des Risiko, dass ma damit die Aussicht verstellt werden könnte nehme ich gerne in Kauf; ![]()
Moderatoren
es scheint ein seltsames Routing-Problem zu geben
2 vServer, einer hier in Nürnberg [shinkansen.host] und einer in bei jemand anders in Wien [6in4gate.tunnel]
einmal IPv4/IPv6 von Wien [6in4gate.tunnel] nach Nürnberg [shinkansen.host] - das passt
[root@6in4gate ~]# traceroute -I shinkansen.host
traceroute to shinkansen.host (194.55.15.x), 30 hops max, 60 byte packets
1 gw101.core1.vie.alwyzon.net (46.102.157.65) 5.980 ms 5.983 ms 5.979 ms
2 ae0.edge1.vie.alwyzon.net (46.102.157.10) 0.557 ms 0.567 ms 0.608 ms
3 et-2-0-5-1337.bbr01.anx03.vie.at.anexia-it.net (193.203.0.19) 0.446 ms 0.451 ms 0.503 ms
4 ae0-0.bbr02.anx03.vie.at.anexia-it.net (144.208.208.132) 9.388 ms 9.389 ms 9.411 ms
5 ae1-0.bbr02.anx84.nue.de.anexia-it.net (144.208.208.137) 9.065 ms 9.064 ms 9.061 ms
6 netcup-gw.bbr02.anx84.nue.de.anexia-it.net (144.208.211.11) 9.015 ms 10.005 ms 9.997 ms
7 shinkansen.host (194.55.15.x) 10.041 ms 10.368 ms 10.576 ms
[root@6in4gate ~]# traceroute6 -I shinkansen.host
traceroute to shinkansen.host (2a03:4000:31:x::1), 30 hops max, 80 byte packets
1 gw101.core1.vie.alwyzon.net (2a0d:f302:101::1) 15.824 ms 15.837 ms 15.778 ms
2 ae0.edge1.vie.alwyzon.net (2a0d:f302:8:11::1) 0.271 ms 0.299 ms 0.300 ms
3 et-2-0-5-1337.bbr01.anx03.vie.at.anexia-it.net (2001:7f8:30:0:1:1:4:7147) 0.588 ms 0.591 ms 0.590 ms
4 2a00:11c0:47:1:47::132 (2a00:11c0:47:1:47::132) 0.540 ms 0.579 ms 0.577 ms
5 2a00:11c0:47:1:47::137 (2a00:11c0:47:1:47::137) 9.023 ms 9.034 ms 9.030 ms
6 2a00:11c0:47:3::33 (2a00:11c0:47:3::33) 11.941 ms 11.855 ms 11.843 ms
7 shinkansen.host (2a03:4000:31:x::1) 9.262 ms 9.087 ms 9.093 ms
[root@6in4gate ~]#
Alles anzeigen
aber hier die andere Richtung von Nürnberg [shinkansen.host] nach Wien [6in4gate.tunnel], ebenfalls IPv4/IPv6
[root@shinkansen ~]# traceroute -I 6in4gate.tunnel
traceroute to 6in4gate.tunnel (46.102.157.x), 30 hops max, 60 byte packets
1 194.55.12.2 (194.55.12.2) 0.506 ms 1.153 ms 1.506 ms
2 ae3-4019.bbr02.anx84.nue.de.anexia-it.net (144.208.211.10) 1.677 ms 1.847 ms 2.007 ms
3 ae2-0.bbr02.anx03.vie.at.anexia-it.net (144.208.208.136) 10.684 ms 11.087 ms 11.258 ms
4 ae0-0.bbr01.anx03.vie.at.anexia-it.net (144.208.208.133) 10.147 ms 10.318 ms 10.858 ms
5 vix.alwyzon.net (193.203.0.75) 9.299 ms 9.847 ms 10.479 ms
6 ae19.core1.vie.alwyzon.net (46.102.157.11) 31.178 ms 28.883 ms 29.173 ms
7 6in4gate.tunnel (46.102.157.x) 9.347 ms 9.010 ms 9.166 ms
[root@shinkansen ~]# traceroute6 -I 6in4gate.tunnel
traceroute to 6in4gate.tunnel (2a0d:f302:101:x::1), 30 hops max, 80 byte packets
1 2a03:4000:31::2 (2a03:4000:31::2) 5.321 ms 5.298 ms 5.281 ms
2 2a03:4000:ff00:4::4 (2a03:4000:ff00:4::4) 0.375 ms 0.386 ms 0.379 ms
3 2a00:11c0:47:3::fa (2a00:11c0:47:3::fa) 66.031 ms 66.014 ms 65.994 ms
4 2a00:11c0:47:1:47::138 (2a00:11c0:47:1:47::138) 0.373 ms 0.355 ms 0.310 ms
5 2a00:11c0:47:1:47::136 (2a00:11c0:47:1:47::136) 9.150 ms 9.164 ms 9.160 ms
6 2a00:11c0:47:1:47::133 (2a00:11c0:47:1:47::133) 9.155 ms 9.419 ms 9.401 ms
7 vix.alwyzon.net (2001:7f8:30:0:2:1:4:994) 9.198 ms 9.181 ms 9.182 ms
8 2a0d:f302:8:11:: (2a0d:f302:8:11::) 11.784 ms 58.969 ms 58.911 ms
9 6in4gate.tunnel (2a0d:f302:101:x::1) 9.129 ms 9.058 ms 9.033 ms
[root@shinkansen ~]#
Alles anzeigen
hier passt das bei IPv6 nicht;
falls dies die selbe Ursache hat, iperf3 in Wien [6in4gate.tunnel] als Server gestartet
und iperf3 unterscheidet sich hier ebenfalls aber genau anders herum: bei IPv6 passt und bei IPv4 hackt es;
[root@shinkansen ~]# iperf3 -4 -c 6in4gate.tunnel -R
Connecting to host 6in4gate.tunnel, port 5201
Reverse mode, remote host 6in4gate.tunnel is sending
[ 4] local 194.55.15.x port 36128 connected to 46.102.157.x port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 24.1 MBytes 202 Mbits/sec
[ 4] 1.00-2.00 sec 24.3 MBytes 204 Mbits/sec
[ 4] 2.00-3.00 sec 24.8 MBytes 208 Mbits/sec
[ 4] 3.00-4.01 sec 25.4 MBytes 212 Mbits/sec
[ 4] 4.01-5.01 sec 25.3 MBytes 213 Mbits/sec
[ 4] 5.01-6.01 sec 21.6 MBytes 180 Mbits/sec
[ 4] 6.01-7.00 sec 24.3 MBytes 206 Mbits/sec
[ 4] 7.00-8.00 sec 29.3 MBytes 245 Mbits/sec
[ 4] 8.00-9.01 sec 22.3 MBytes 186 Mbits/sec
[ 4] 9.01-10.00 sec 23.6 MBytes 200 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 247 MBytes 207 Mbits/sec 42 sender
[ 4] 0.00-10.00 sec 245 MBytes 206 Mbits/sec receiver
iperf Done.
[root@shinkansen ~]# iperf3 -6 -c 6in4gate.tunnel -R
Connecting to host 6in4gate.tunnel, port 5201
Reverse mode, remote host 6in4gate.tunnel is sending
[ 4] local 2a03:4000:31:x::1 port 49364 connected to 2a0d:f302:101:x::1 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 85.0 MBytes 713 Mbits/sec
[ 4] 1.00-2.00 sec 105 MBytes 885 Mbits/sec
[ 4] 2.00-3.00 sec 102 MBytes 857 Mbits/sec
[ 4] 3.00-4.00 sec 83.0 MBytes 696 Mbits/sec
[ 4] 4.00-5.00 sec 87.5 MBytes 734 Mbits/sec
[ 4] 5.00-6.00 sec 91.3 MBytes 766 Mbits/sec
[ 4] 6.00-7.00 sec 93.1 MBytes 781 Mbits/sec
[ 4] 7.00-8.00 sec 95.2 MBytes 799 Mbits/sec
[ 4] 8.00-9.00 sec 78.3 MBytes 657 Mbits/sec
[ 4] 9.00-10.00 sec 72.7 MBytes 610 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 897 MBytes 753 Mbits/sec 367 sender
[ 4] 0.00-10.00 sec 895 MBytes 750 Mbits/sec receiver
iperf Done.
[root@shinkansen ~]#
Alles anzeigen
[netcup] Claudia H. ich hol da jetzt etwas weiter aus; da in den Medien von der Wahl in Nigeria die Rede war, und davon dass dieses Land
mehr als 200 Millionen Einwohner hat; muss man nicht wissen, ich wußte es bis vor ein paar Tagen auch nicht;
dacht nur: "Oups das nächste Land mit mehr als 200 Mio. Einwohner" [Liste von Staaten und Territorien nach Einwohnerzahl ist dann schon besorgniserregend]
sowie Rinderherden, wenn sie größer werden mehr Gras brauchen; braucht auch eine Volkswirtschaft, wenn sie auf Wachstum ausgelegt auch immer mehr Energie;
nur irgendwann gibt es eine Grenze - eine sogenannte rote Linie - welche dann doch nicht überschritten werden kann;
weil die Erklärung wie die Energiewende - jetzt mal ohne Verkehrswende betrachtet - gehen soll, hat noch niemand wirklich zu Tage gebracht ...
und wie die Verkehrswende funktionieren soll, ohne einem Umdenken welches aber zwingend stattfinden muss, hat ebenfalls noch niemand wirklich zu Tage gebracht ...
alleine der Austausch von PKWs mit Verbrennermotor in PKWs mit Elektromotor wird nicht funktionieren;
ich hätt halt gerne in 20 Jahren auch noch eine Umwelt vorgefunden, in der man leben kann ...
Ein Plus an Zulassungen findet man praktisch nur mehr bei eAutos.
Du meinst hoffentlich Neuzulassungen; dass dies politisch so gewollt ist, ist klar;
dass das aber das System gegen die Want fährt ein anderes Kapitel ...
Du weißt also nicht, wie viele Haushalte es in DE gibt,
ist auf Grund der Schätzung auch unerheblich ...; sagtest ja selbst dass ein Kochfeld zwischen 1 und 5½ kW braucht; wie man dann interpoliert ist dann egal;
Ebenso ist es aber auch kein Problem, eine größere Zahl von eAutos mit dem vorhandenen Netz und einem niedrigeren Gleichzeitigkeitsfaktor als eHerde abzudecken.
da wär ich mir nicht so sicher, vor allem im Hinblick auf die Strommenge;
glztg. f. eine sehr kurze Zeit mehrere Gigawatt Leistung anzufordern und mehrere (Zig)tausend GWh zu benötigen ist ein Unterschied;
Zu Deiner unnötigen persönlichen Beleidigung
das hast leider falsch aufgefasst
Werden dann auch konsequent E-Autos Remote stillgelegt, wenn es mal klemmt?
in České Budějovice wird tatsächlich wenn es mal klemmt beim öffentlichen Verkehr - zum Großteil Busse mit Fahrleitung - die Heizung abgedreht;
weil eines sei hier gesagt - hatte es schon mal erwähnt - eng wird es nur in der kalten Jahreszeit und daher ist das Blackout-Risiko auch nur im Winter gegeben;
horcht sich jetzt etwas komisch an, aber die Klimaanlagen, welche im Sommer dazukommen, fallen vergleichsweise zur Heizenergie im Winter und der im Sommer durch Niedrigwasser bei Laufkraftwerken bedingten niedrigeren Stromerzeugung weniger ins Gewicht;
Fürs Netz sind beides Stromverbraucher, die mehrere kW abfordern.
und zum Glück gibts nur eine verschwindend kleine Anzahl an E-KFZs; ![]()
weil eines sollte klar sein, wenn jeder E-Herd auch nur mit rund ¼ seiner Anschlußleistung
schlagartig zu Mittag diese Leistung anfordert heißt das bei dieser Größenordnung,
dass 50 Mio. mal 2½ kW macht 125 Gigawatt; da würden ma wirklich jeden Tag nur knapp am Blackout vorbeischrammen; ![]()
mögen es auch nur 25 Mio. E-Herde sein, sinds immer noch 65,5 Gigawatt od. mehr als 60 AKW-Äquivalente;
sind es nur 10 Mio. E-Herde welche die gesamte Anschlußleistung anfordern sind es 100 Gigawatt od. mehr als 90 AKW-Äquivalente;
Edit: Bild entfernt durch Moderation. Die Diskussion ist bitte sachlich zu führen. Danke.
da sieht mein Netzwerk zu Hause ja direkt einfach am Diagramm aus,
aber wenn es jemand anderes warten soll, fliegen die Haare weg (graue Haare waren gestern) ![]()
an der ISP Dose hängt ein Router, welcher im Bridge-Mode läuft
an dem steckt mein Router, welcher WANseitig die public IPv4 [mit DHCP] (Device eth1) hat,
und LANseitig hat er ein WLAN (Device wlan0) und ein LAN (Device eth0) beides zusammengefasst als Bridge (Device br0)
und am LAN hängt ein unmanaged Switch, an dem hängen diverse Devices,
u.a. auch ein WLAN Acces-Point und auf die Art hab ich 3 verschiedene WLANs [SSIDs],
aber alles hängt in einem einzigen RFC1918-IPv4-Subnet [172.16.0.0/16] bzw. /64-Prefix; und weil der ISP kein IPv6 liefert
spielt mein Router auch noch IPv6-in-IP Gateway (Device sit1)
Bohnen mit Zwiebeln!
Bohnengulasch!