@IvoKainKrieg: Genau das ist doch der Plan von dem D-DHCP-Server, den tcatm gerade entwickelt. Dann werden die IPs lokal vergeben, das sollte deutlich schneller gehen.
1 „Gefällt mir“
Vor allem gibt es dann endlich auch DHCP wenn das Gateway nicht erreichbar ist oder Internet in der Freifunkwolke mal komplett ausgefallen sein sollte.
1 „Gefällt mir“
Ich hab gestern Mal ein wenig experimentiert.
Laptop auf Kanal1 in den Monitormodus, alles von oder zu der Mac-Adresse meines S4 mitgeschnitten. Dann das Ding zugeklappt (natürlich so eingestellt, dass es anbleibt), in die Tasche gesteckt und damit Mal eine typische Situation nachgestellt, in der das immer auftritt.
Vom Parkplatz, dort habe ich das WLAN vom S4 eingeschaltet, nach Hause gelaufen. Dabei verbindet er sich zuerst mit meiner Picostation, dann, wenn ich nach drinnen gehe, roamt er zum Freifunk meines Nachbarn im Erdgeschoss und wenn ich die Treppen hochgehe zu meinem WR841.
Dabei habe ich draußen zunächst eine gute Verbindung, aber schon beim ersten roamen ist ipv4 weg. Ipv6 geht dann noch (z.B. heise.de), aber reiner ipv4-Verkehr geht nicht (z.B. Whatsapp oder Sip zu meiner FritzBox).
Zunächst habe ich mir die DHCP-Pakete angesehen. Das ist ein Holzweg. Wir roamen auf Layer 2, das hat nichts mit DHCP zu tun.
Und an der Stelle bin ich noch nicht weiter gekommen. Mein Laptop hat das Problem definitiv nicht.
Grüße
MPW
1 „Gefällt mir“
Ohne dass ich jetzt tiefer im Thema stecke: Ich kann bei meinem Samsung Galaxy S4 mit Android 5.0.1 definitiv Roaming-Probleme auch für eduroam bestätigen. Ich muss immer erst das WLAN aus und wieder an machen, damit ich wieder eine Verbindung bekomme.
Das scheint ein Samsung-Problem zu sein.
1 „Gefällt mir“
@JoBu: Hast du Mal Cyanogen Mod probiert?
Ich finde, das hat sich mit dem Update zu 5.0.1 neu deutlich verstärkt. Mit 4.x.x lief es besser.
Wird auf mein nächstes Handy wohl draufkommen.
Auch die Verschlechterung kann ich subjektiv bestätigen.
Ich kenne mich mit der Materie auch nicht so gut aus, aber bezüglich Android 5.0 habe ich noch folgendes gefunden:
In Android 5.0 and above, configurations that are expected to work are SLAAC + DHCPv4 (this has worked since 2009), SLAAC DHCPv4 + RDNSS, and SLAAC+RDNSS with no IPv4. DHCPv6 is not supported and will be ignored.
Configurations that currently do not work are:
- Setting link-local (i.e., inside fe80::/64) DNS servers via RDNSS
- Sending RAs that configure only a default route but do not provide SLAAC (e.g., if the network uses DHCPv6 for addressing.)
Google Issue Tracker
Hm, keiner der Punkte lässt sich auf das Problem hier anwenden. Da es Samsung spezifisch zu sein scheint, denke ich auch nicht, dass es ein Problem in Android an sich ist, sondern, dass im Treiber ein Problem vorliegt.
So, wieder neue Erkenntnisse zum Samsung IP Handshake Problem.
Im gleichen Ort hat es bei einem 50 Mbit Anschluss beim 2ten Versuch geklappt.
Bei meinem 16 Mbit Anschluss klappt es immer noch nicht.
www.speed.io hat aber auch nur
Down: 4.778 Kbit/s
Up:126 Kbit/s
Ping: 56 ms
angezeigt.
Das hat mir bis jetzt immer gereicht.
Aber was sind die Mindestwerte die ein Anschluss für unsern FF-Router braucht?
Gruß
Ivo
Moin,
auch auf die Gefahr hin, mich hier unbeliebt zu machen. 
Hier, Domäne Möhne, hab ich, mit drei eigenen Samsungs und zwei von Bekannten, null Probleme mit irgendwelchen Freifunk-Einwahlen, IP-Vergaben oder sonstigem.
S5, S3, ein kleines Tab, ein S4 und ein Galaxy Tab 10.1 glaub ich.
Alles auf den neusten Stand.
Klar dauerts schonmal länger, ~ 10 sek … aber damit kann man leben oder ?
Also ich seh da kein Samsung Problem, sondern denke eher, dass adorfer da richtig liegt.
Gruß
Chris
1 „Gefällt mir“
oft muss ich mein note3 auch booten weil es keine ip hohlt … das aber auch an einer FB
Ich habe mir erlaubt, den Thread-Titel mal anzuspassen, damit er auch gefunden wird.
(Und nicht nur als Belustigung bei Freifunkerstammtischen dient „wie blöd Foristen sind.“)
1 „Gefällt mir“
Neue Lösungs-Idee für das IP-Verteilungsproblem, wie ich es verstehe:
Mein Modem-Router: „TD-W8961NB, vor dem FF-Router verwendet eine NAT- und eine SPI(Stateful Packet Inspection)-Firewall, die den Inhalt eingehender Pakete inspiziert, bevor diese hereingelassen werden. Für den zusätzlichen Komfort wird eine Zugangskontrolle unterstützt, die auf der MAC-Adresse, der IP-Adresse, dem Domänennamen oder auf Anwendungen wie MSN und Yahoo Messenger basiert.“ (Aus der Bedienungsanleitung)
Hier ein paar Insider Erklärungen. Besonders Bild 5-14 folgende beschreiben was ich ahne.
http://www.cisco.com/c/en/us/td/docs/security/asa/asa93/configuration/firewall/asa-firewall-cli/nat-reference.html
Heißt das, dass ich damit dem Verbindungs-Handshake zum FF-VPN Vorrang einräumen kann?
Was müsste ich da eintragen?
Danke für Euer Mitdenken.
Ich sehe keinerlei Zusammenhang zu irgendetwas, was hier bislang besprochen wurde.
Oder um es deutlicher zu sagen: Es ist sicher auch vorteilhaft, wenn sichergestellt ist, dass Dein Freifunkrouter mit Strom versorgt ist und das Netzteil nicht zufällig aus der Dose fällt. (Hätte etwa genauso viel mit den DHCP-Problemen bestimmter(?) Clients auf dem br-client-Wifi zu tun)