Anleitungen:macOS - Versionsgeschichte

Fblaese: /* IPv6 und Router Advertisements */

2020-03-13T11:44:51Z

IPv6 und Router Advertisements

← Nächstältere Version		Version vom 13. März 2020, 13:44 Uhr
Zeile 3:		Zeile 3:
	== IPv6 und Router Advertisements ==		== IPv6 und Router Advertisements ==
	=== Problembeschreibung ===		=== Problembeschreibung ===
	Unter MacOS (aktuell getestet unter 10.14.5, es ist keine Version bekannt, in der es funktioniert) kommt es zu Problemen mit IPv6 und SLAAC. macOS vergisst die passende Subnetz-Route für in Router Advertisement ohne "default"-Lifetime angebotene Subnetze zu setzen; so auch beim fdff::/64, das von den Nodes kommt. Ein bereits ~~vor über einem Jahr~~ geöffneter Bugreport ~~blieb bisher unbeantwortet~~. Apple scheint sich für dieses Problem nicht zu interessieren.		Unter MacOS (aktuell getestet unter 10.14.5, es ist keine Version bekannt, in der es funktioniert) kommt es zu Problemen mit IPv6 und SLAAC. macOS vergisst die passende Subnetz-Route für in Router Advertisement ohne "default"-Lifetime angebotene Subnetze zu setzen; so auch beim fdff::/64, das von den Nodes kommt. Ein bereits geöffneter Bugreport wurde sinngemäß mit "Stimmt, ist kaputt. Ist uns egal, warum machst du es nicht $anders?" beantwortet. Apple scheint sich für dieses Problem nicht zu interessieren.

	Für die von den Gateways seit dem KeyxchangeV2 angebotenen fd43-Adressen gilt die gleiche Problematik. Soll auf Router außerhalb der eigenen Hood zugegriffen werden, braucht es aber zusätzlich noch eine fc00::/7 Route, die auch im Router Advertisement mitgesendet wird. Auch das funktioniert unter macOS NICHT. Dafür wurde bisher kein Bugreport geschrieben.		Für die von den Gateways seit dem KeyxchangeV2 angebotenen fd43-Adressen gilt die gleiche Problematik. Soll auf Router außerhalb der eigenen Hood zugegriffen werden, braucht es aber zusätzlich noch eine fc00::/7 Route, die auch im Router Advertisement mitgesendet wird. Auch das funktioniert unter macOS NICHT. Dafür wurde bisher kein Bugreport geschrieben.

Fblaese: /* IPv6 und Router Advertisements */

2019-07-27T11:10:39Z

IPv6 und Router Advertisements

← Nächstältere Version		Version vom 27. Juli 2019, 13:10 Uhr
Zeile 3:		Zeile 3:
	== IPv6 und Router Advertisements ==		== IPv6 und Router Advertisements ==
	=== Problembeschreibung ===		=== Problembeschreibung ===
	Unter MacOS (aktuell getestet unter 10.14.5, es ist keine Version bekannt, in der es funktioniert) kommt es zu Problemen mit IPv6 und SLAAC. macOS vergisst die passende Subnetz-Route für in Router Advertisement ohne "default"-~~Flag~~ angebotene Subnetze zu setzen, so auch beim fdff::/64, das von den Nodes kommt. Ein bereits vor über einem Jahr geöffneter Bugreport blieb bisher unbeantwortet. Apple scheint sich für dieses Problem nicht zu interessieren.		Unter MacOS (aktuell getestet unter 10.14.5, es ist keine Version bekannt, in der es funktioniert) kommt es zu Problemen mit IPv6 und SLAAC. macOS vergisst die passende Subnetz-Route für in Router Advertisement ohne "default"-Lifetime angebotene Subnetze zu setzen; so auch beim fdff::/64, das von den Nodes kommt. Ein bereits vor über einem Jahr geöffneter Bugreport blieb bisher unbeantwortet. Apple scheint sich für dieses Problem nicht zu interessieren.

	Für die von den Gateways seit dem KeyxchangeV2 angebotenen fd43-Adressen gilt die gleiche Problematik. Soll auf Router außerhalb der eigenen Hood zugegriffen werden, braucht es aber zusätzlich noch eine fc00::/7 Route, die auch im Router Advertisement mitgesendet wird. Auch das funktioniert unter macOS NICHT. Dafür wurde bisher kein Bugreport geschrieben.		Für die von den Gateways seit dem KeyxchangeV2 angebotenen fd43-Adressen gilt die gleiche Problematik. Soll auf Router außerhalb der eigenen Hood zugegriffen werden, braucht es aber zusätzlich noch eine fc00::/7 Route, die auch im Router Advertisement mitgesendet wird. Auch das funktioniert unter macOS NICHT. Dafür wurde bisher kein Bugreport geschrieben.

Fblaese: /* IPv6 und Router Advertisements */

2019-07-27T11:09:57Z

IPv6 und Router Advertisements

← Nächstältere Version		Version vom 27. Juli 2019, 13:09 Uhr
Zeile 3:		Zeile 3:
	== IPv6 und Router Advertisements ==		== IPv6 und Router Advertisements ==
	=== Problembeschreibung ===		=== Problembeschreibung ===
	Unter MacOS (aktuell getestet unter 10.13.6, es ist keine Version bekannt, in der es funktioniert) kommt es zu Problemen mit IPv6 und SLAAC. macOS vergisst die passende Subnetz-Route für in Router Advertisement ohne "default"-Flag angebotene Subnetze zu setzen, so auch beim fdff::/64, das von den Nodes kommt. Ein bereits vor über einem Jahr geöffneter Bugreport blieb bisher unbeantwortet. Apple scheint sich für dieses Problem nicht zu interessieren.		Unter MacOS (aktuell getestet unter 10.14.5, es ist keine Version bekannt, in der es funktioniert) kommt es zu Problemen mit IPv6 und SLAAC. macOS vergisst die passende Subnetz-Route für in Router Advertisement ohne "default"-Flag angebotene Subnetze zu setzen, so auch beim fdff::/64, das von den Nodes kommt. Ein bereits vor über einem Jahr geöffneter Bugreport blieb bisher unbeantwortet. Apple scheint sich für dieses Problem nicht zu interessieren.

	Für die von den Gateways seit dem KeyxchangeV2 angebotenen fd43-Adressen gilt die gleiche Problematik. Soll auf Router außerhalb der eigenen Hood zugegriffen werden, braucht es aber zusätzlich noch eine fc00::/7 Route, die auch im Router Advertisement mitgesendet wird. Auch das funktioniert unter macOS NICHT. Dafür wurde bisher kein Bugreport geschrieben.		Für die von den Gateways seit dem KeyxchangeV2 angebotenen fd43-Adressen gilt die gleiche Problematik. Soll auf Router außerhalb der eigenen Hood zugegriffen werden, braucht es aber zusätzlich noch eine fc00::/7 Route, die auch im Router Advertisement mitgesendet wird. Auch das funktioniert unter macOS NICHT. Dafür wurde bisher kein Bugreport geschrieben.

Fblaese: /* IPv6 und DHCP */

2018-09-05T10:48:31Z

IPv6 und DHCP

← Nächstältere Version		Version vom 5. September 2018, 12:48 Uhr
Zeile 1:		Zeile 1:
	__TOC__		__TOC__

	== IPv6 und ~~DHCP~~ ==		== IPv6 und Router Advertisements ==
	=== Problembeschreibung ===		=== Problembeschreibung ===
	Unter MacOS (aktuell getestet unter 10.13.6, es ist keine Version bekannt, in der es funktioniert) kommt es zu Problemen mit IPv6 und SLAAC. macOS vergisst die passende Subnetz-Route für in Router Advertisement ohne "default"-Flag angebotene Subnetze zu setzen, so auch beim fdff::/64, das von den Nodes kommt. Ein bereits vor über einem Jahr geöffneter Bugreport blieb bisher unbeantwortet. Apple scheint sich für dieses Problem nicht zu interessieren.		Unter MacOS (aktuell getestet unter 10.13.6, es ist keine Version bekannt, in der es funktioniert) kommt es zu Problemen mit IPv6 und SLAAC. macOS vergisst die passende Subnetz-Route für in Router Advertisement ohne "default"-Flag angebotene Subnetze zu setzen, so auch beim fdff::/64, das von den Nodes kommt. Ein bereits vor über einem Jahr geöffneter Bugreport blieb bisher unbeantwortet. Apple scheint sich für dieses Problem nicht zu interessieren.

Fblaese: /* Problembeschreibung */

2018-09-05T10:45:03Z

Problembeschreibung

← Nächstältere Version		Version vom 5. September 2018, 12:45 Uhr
Zeile 3:		Zeile 3:
	== IPv6 und DHCP ==		== IPv6 und DHCP ==
	=== Problembeschreibung ===		=== Problembeschreibung ===
	Unter MacOS (aktuell getestet unter 10.13.6, es ist keine Version bekannt, in der es funktioniert) kommt es zu Problemen mit IPv6 und SLAAC. macOS vergisst die passende Subnetz-Route für in Router Advertisement ohne "default"-Flag angebotene Subnetze zu setzen, so auch beim fdff::/64, das von den Nodes kommt. Ein bereits am geöffneter Bugreport blieb bisher unbeantwortet. Apple scheint sich für dieses Problem nicht zu interessieren.		Unter MacOS (aktuell getestet unter 10.13.6, es ist keine Version bekannt, in der es funktioniert) kommt es zu Problemen mit IPv6 und SLAAC. macOS vergisst die passende Subnetz-Route für in Router Advertisement ohne "default"-Flag angebotene Subnetze zu setzen, so auch beim fdff::/64, das von den Nodes kommt. Ein bereits vor über einem Jahr geöffneter Bugreport blieb bisher unbeantwortet. Apple scheint sich für dieses Problem nicht zu interessieren.

	Für die von den Gateways seit dem KeyxchangeV2 angebotenen fd43-Adressen gilt die gleiche Problematik. Soll auf Router außerhalb der eigenen Hood zugegriffen werden, braucht es aber zusätzlich noch eine fc00::/7 Route, die auch im Router Advertisement mitgesendet wird. Auch das funktioniert unter macOS NICHT. Dafür wurde bisher kein Bugreport geschrieben.		Für die von den Gateways seit dem KeyxchangeV2 angebotenen fd43-Adressen gilt die gleiche Problematik. Soll auf Router außerhalb der eigenen Hood zugegriffen werden, braucht es aber zusätzlich noch eine fc00::/7 Route, die auch im Router Advertisement mitgesendet wird. Auch das funktioniert unter macOS NICHT. Dafür wurde bisher kein Bugreport geschrieben.

Fblaese am 5. September 2018 um 10:42 Uhr

2018-09-05T10:42:41Z

← Nächstältere Version		Version vom 5. September 2018, 12:42 Uhr
Zeile 1:		Zeile 1:
	~~{{Entwurf}}~~

	__TOC__		__TOC__

	~~= MacOS X bis 10.11.x =~~
	~~Auch 10.11.6 scheint von der Problematik betroffen zu sein, die Maßnahmen für 10.12 sollten auch hier helfen.~~

	~~= MacOS 10.12.x =~~
	~~Bei der Verwendung von MacOS Sierra (10.12) kann es zu Abweichungen vom "normalen" Vorgehen geben.~~

	== IPv6 und DHCP ==		== IPv6 und DHCP ==
	=== Problembeschreibung ===		=== Problembeschreibung ===
	Unter MacOS ~~Sierra~~ (~~macOS 10.12,~~ aktuell getestet unter 10.12.6) kommt es zu Problemen mit IPv6 und SLAAC. macOS ~~weist sich scheinbar keine IPv6 Adresse aus einem Prefix~~ zu, ~~wenn sich der Router~~, ~~der~~ das ~~Prefix announced hat, nicht als Default Gateway~~ für dieses ~~Prefix announced~~. ~~Ein Service~~-~~Ticket~~ wurde ~~bei Apple geöffnet~~.		Unter MacOS (aktuell getestet unter 10.13.6, es ist keine Version bekannt, in der es funktioniert) kommt es zu Problemen mit IPv6 und SLAAC. macOS vergisst die passende Subnetz-Route für in Router Advertisement ohne "default"-Flag angebotene Subnetze zu setzen, so auch beim fdff::/64, das von den Nodes kommt. Ein bereits am geöffneter Bugreport blieb bisher unbeantwortet. Apple scheint sich für dieses Problem nicht zu interessieren.

			Für die von den Gateways seit dem KeyxchangeV2 angebotenen fd43-Adressen gilt die gleiche Problematik. Soll auf Router außerhalb der eigenen Hood zugegriffen werden, braucht es aber zusätzlich noch eine fc00::/7 Route, die auch im Router Advertisement mitgesendet wird. Auch das funktioniert unter macOS NICHT. Dafür wurde bisher kein Bugreport geschrieben.
			Hierfür gibt es aktuell auch keinen einfachen, sinnvollen Lösungsweg; außer natürlich ein OS zu verwenden, was mit IPv6 vernünftig umgehen kann. Beispielsweise Linux.

	=== Lösungansatz ===		=== Lösungansatz ===
Zeile 29:		Zeile 24:

	= Hinweise =		= Hinweise =
	Auch unter iOS kommt es zu den beschriebenen Problemen. Da hier die selbe Implementierung von IPv6 verwendet wird, scheint auch der selbe Bug aufzutreten.		Auch unter iOS kommt es ebenfalls zu den beschriebenen Problemen. Da hier die selbe Implementierung von IPv6 verwendet wird, scheint auch der selbe Bug aufzutreten.
	Unter Safari kann die Web GUI nicht aufgerufen werden, unter Firefox und Chrome ist das nicht der Fall. Das Format im Webbrowser ist wie folgend https://[fdff::98de:d0a8:c20e] im Terminal ssh root@fdff::98de:d0a8:c20e.		Unter Safari kann die Web GUI nicht aufgerufen werden, unter Firefox und Chrome ist das nicht der Fall. Das Format im Webbrowser ist wie folgend https://[fdff::98de:d0a8:c20e] im Terminal ssh root@fdff::98de:d0a8:c20e.

Fblaese: Router ist nicht Default Gateway

2017-09-13T22:07:49Z

Router ist nicht Default Gateway

← Nächstältere Version		Version vom 14. September 2017, 00:07 Uhr
Zeile 16:		Zeile 16:
	Folgende Schritte sind notwendig, um unter MacOS auf einen Router zuzugreifen. In den MacOS Systemeinstellungen -> Netzwerk beim verwendeten Netzwerk die Erweiterten Einstellungen bei IPv6 auf "Manuell" stellen		Folgende Schritte sind notwendig, um unter MacOS auf einen Router zuzugreifen. In den MacOS Systemeinstellungen -> Netzwerk beim verwendeten Netzwerk die Erweiterten Einstellungen bei IPv6 auf "Manuell" stellen

	[[Datei:~~MacOS_Settings~~.png\|400px\|thumb\|Einstellungen bei macOS]]		[[Datei:MacOS_ipv6_fdff.png\|400px\|thumb\|Einstellungen bei macOS]]

	* Router: ~~fdff:: + die Mac von dem FFF Router~~		* Router: leer lassen
	* IPv6 Adresse: fdff:: + MAC Adresse des LAN/WLAN Adapters		* IPv6 Adresse: fdff:: + MAC Adresse des LAN/WLAN Adapters (Zu finden unter "Hardware")
	* Präfix Länge: 64		* Präfix Länge: 64

Zeile 26:		Zeile 26:
	=== Beispiel ===		=== Beispiel ===
	Im Screenshot ist das Beispielfenster zu sehen.		Im Screenshot ist das Beispielfenster zu sehen.
	* ~~Router Mac-Adresse lautet 98:de:d0:a8:c2:0e und wird zu fdff::98de:d0a8:c20e~~		* MAC-Adresse der Netzwerkkarte lautet 90:2b:34:51:d3:3a und wird zu fdff::902b:3451:d33a
	* Mac-Adresse der Netzwerkkarte lautet 90:fd:61:ec:a4:a4 und wird zu fdff::~~90fd~~:~~61ec~~:~~a4a4~~

	= Hinweise =		= Hinweise =
	Auch unter iOS kommt es zu den beschriebenen Problemen. Da hier die selbe Implementierung von IPv6 verwendet wird, scheint auch der selbe Bug aufzutreten.		Auch unter iOS kommt es zu den beschriebenen Problemen. Da hier die selbe Implementierung von IPv6 verwendet wird, scheint auch der selbe Bug aufzutreten.
	Unter Safari kann die Web GUI nicht aufgerufen werden, unter Firefox und Chrome ist das nicht der Fall. Das Format im Webbrowser ist wie folgend https://[fdff::98de:d0a8:c20e] im Terminal ssh root@fdff::98de:d0a8:c20e.		Unter Safari kann die Web GUI nicht aufgerufen werden, unter Firefox und Chrome ist das nicht der Fall. Das Format im Webbrowser ist wie folgend https://[fdff::98de:d0a8:c20e] im Terminal ssh root@fdff::98de:d0a8:c20e.

Fblaese: /* Problembeschreibung */

2017-09-13T22:04:09Z

Problembeschreibung

← Nächstältere Version		Version vom 14. September 2017, 00:04 Uhr
Zeile 11:		Zeile 11:
	== IPv6 und DHCP ==		== IPv6 und DHCP ==
	=== Problembeschreibung ===		=== Problembeschreibung ===
	Unter MacOS Sierra (macOS 10.12, aktuell getestet unter 10.12.4) kommt es zu Problemen mit IPv6 und ~~DHCP~~. ~~Per DHCP bekommt der MAC von den Freifunk-Routern~~ keine ~~IPV6 zugewiesen~~, ~~weder per LAN noch per WLAN. Verbindet man~~ sich ~~jedoch mit einer FritzBox~~, ~~funktioniert die Zuweisung problemlos. Ob die Probleme von~~ der ~~Firmware oder dem OS verursacht werden kann zum jetzigen Zeitpunkt~~ nicht ~~sicher definiert werden~~. Ein Service-Ticket wurde bei Apple geöffnet.		Unter MacOS Sierra (macOS 10.12, aktuell getestet unter 10.12.6) kommt es zu Problemen mit IPv6 und SLAAC. macOS weist sich scheinbar keine IPv6 Adresse aus einem Prefix zu, wenn sich der Router, der das Prefix announced hat, nicht als Default Gateway für dieses Prefix announced. Ein Service-Ticket wurde bei Apple geöffnet.

	=== Lösungansatz ===		=== Lösungansatz ===

Wallenium am 24. April 2017 um 08:28 Uhr

2017-04-24T08:28:32Z

← Nächstältere Version		Version vom 24. April 2017, 10:28 Uhr
Zeile 4:		Zeile 4:

	= MacOS X bis 10.11.x =		= MacOS X bis 10.11.x =
	~~Die beschriebenen Probleme betreffen nach bisherigem Wissenstand nur macOS~~ 10.12~~, können jedoch~~ auch ~~bei früheren auftreten~~.		Auch 10.11.6 scheint von der Problematik betroffen zu sein, die Maßnahmen für 10.12 sollten auch hier helfen.

	= MacOS 10.12.x =		= MacOS 10.12.x =
Zeile 11:		Zeile 11:
	== IPv6 und DHCP ==		== IPv6 und DHCP ==
	=== Problembeschreibung ===		=== Problembeschreibung ===
	Unter MacOS Sierra (macOS 10.12, aktuell getestet unter 10.12.4) kommt es zu Problemen mit IPv6 und DHCP. Per DHCP bekommt der MAC von den Freifunk-Routern keine IPV6 zugewiesen, weder per LAN noch per WLAN. Verbindet man sich jedoch mit einer FritzBox, funktioniert die Zuweisung problemlos. Ob die Probleme von der Firmware oder dem OS verursacht werden kann zum jetzigen Zeitpunkt nicht sicher definiert werden. ~~Eventuell ist eine fehlerhafte Implementierung der Opaque Interface Identifiers (IETF RFC 7217) in 10.12 der Auslöser der Probleme~~.		Unter MacOS Sierra (macOS 10.12, aktuell getestet unter 10.12.4) kommt es zu Problemen mit IPv6 und DHCP. Per DHCP bekommt der MAC von den Freifunk-Routern keine IPV6 zugewiesen, weder per LAN noch per WLAN. Verbindet man sich jedoch mit einer FritzBox, funktioniert die Zuweisung problemlos. Ob die Probleme von der Firmware oder dem OS verursacht werden kann zum jetzigen Zeitpunkt nicht sicher definiert werden. Ein Service-Ticket wurde bei Apple geöffnet.

	=== Lösungansatz ===		=== Lösungansatz ===

Openreh: /* Hinweise */

2017-04-21T16:36:35Z

Hinweise

← Nächstältere Version		Version vom 21. April 2017, 18:36 Uhr
Zeile 31:		Zeile 31:
	= Hinweise =		= Hinweise =
	Auch unter iOS kommt es zu den beschriebenen Problemen. Da hier die selbe Implementierung von IPv6 verwendet wird, scheint auch der selbe Bug aufzutreten.		Auch unter iOS kommt es zu den beschriebenen Problemen. Da hier die selbe Implementierung von IPv6 verwendet wird, scheint auch der selbe Bug aufzutreten.
	Unter Safari kann die Web GUI nicht aufgerufen werden, unter Firefox und Chrome ist das nicht der Fall. Das Format im Webbrowser ist ~~folgender~~ https://[fdff::98de:d0a8:c20e]		Unter Safari kann die Web GUI nicht aufgerufen werden, unter Firefox und Chrome ist das nicht der Fall. Das Format im Webbrowser ist wie folgend https://[fdff::98de:d0a8:c20e] im Terminal ssh root@fdff::98de:d0a8:c20e.