"Android"-Handys am Command online
Hallo Leute,
welche Erfahrungen habt Ihr mit Android-Handys am Command Online?
Funktioniert der Onlinezugang?
Die Info auf der entspr. MB-Seite sagt ja nicht besonders viel dazu aus.
VG
Andreas
Beste Antwort im Thema
Ich habe die Online-Funktionalität mal ausprobiert mit:
Samsung Galaxy S i9000
Android Version 2.3.3
Gerät ist auf Werkseinstellungen
Ich mußte nur 2 Dinge tun:
- Gerät per Bluetooth mit COMAND verbinden
- Am COMAND unter Menü "Online" (Kugel oben rechts neben SYSTEM) unter Einstellungen den Anbieter auswählen (in meinem Fall O2)
Eintippen einer URL, z.B. www.heute.de
COMAND konfiguriert und erstellt die Datenverbindung und nach einer Wartezeit wird www.heute.de angezeigt.
Ähnliche Themen
160 Antworten
Also geht es nicht bei ntg4?
Zitat:
@0nafanja0 schrieb am 27. August 2015 um 16:59:41 Uhr:
Also geht es nicht bei ntg4?
Comand Online gibt es erst ab dem Mopf und NGT 4.5
Hat jemand hier die TCP Fehler "gelöst" bekommen? Recht viele Homepages kommen wohl nicht mit UDP klar und irgendwie will BluDun keine TCP Verbindung aufbauen...liegt das an BluDun oder am Comand Online?
Zitat:
@STFighter schrieb am 12. Dezember 2015 um 14:41:51 Uhr:
Recht viele Homepages kommen wohl nicht mit UDP klar und irgendwie will BluDun keine TCP Verbindung aufbauen...liegt das an BluDun oder am Comand Online?
HTTP verwendet immer TCP, nicht nur "viele Homepages". Wie kommst Du auf UDP?
Sap V3 Modul mit Samsung S4Mini oder S5Mini funktioniert einwandfrei. Wobei man nicht wirklich von online sprechen kann. Die Möglichkeiten sind beschränkt und das Comand sehr langsam. Lte wird anscheinend nicht unterstützt...bei mir steht immer 3g.
Whatsapp funktioniert in dem Zeitraum der Verbindung mit dem Fahrzeug nicht, weil das handy dann im remote sim modus läuft.
In das sap v3 modul kan man theoretisch auch eine simkarte einstecken.
Als Vorbereitung braucht das fahrzeug aber die uhi -Schnittstelle.
Das sap v2 modul funktioniert für telefonie auch, aber es unterstützt kein internet!
Zitat:
@Tutzi85 schrieb am 13. Dezember 2015 um 08:01:11 Uhr:
Sap V3 Modul mit Samsung S4Mini oder S5Mini funktioniert einwandfrei. Wobei man nicht wirklich von online sprechen kann.
Nein, beim SAPv3 kann man generell nicht von online sprechen, das kann naemlich erst das SAPv4!
Zitat:
Lte wird anscheinend nicht unterstützt...bei mir steht immer 3g.
Auch UMTS wird erst vom SAPv4 unterstuetzt, ein LTE-faehiges SAP-Modul gibt es bis jetzt noch gar nicht.
Zitat:
Als Vorbereitung braucht das fahrzeug aber die uhi -Schnittstelle.
Und ab MJ2014 braucht man auch zum Telefonieren zwingend das SAPv4, weil da die klassische Komforttelefonie-Schnittstelle entfallen ist.
Zitat:
Das sap v2 modul funktioniert für telefonie auch, aber es unterstützt kein internet!
Nochmal die korrekte Zusammenfassung:
SAPv2: Nur Telefonie, Geraete-Telefonbuch-Import nur mit Nokia-Telefonen.
SAPv3: Ebenfalls nur Telefonie, mehr als der eine grauenhafte Klingelton konfigurierbar, BT-PBAP-Unterstuetzung, z.B. fuer Android-Telefonbuecher.
SAPv4: Datenfaehig, UMTS, direktes Pairing mit der Head Unit (ab MJ2014 und fuer die Online-Funktionen), je nach Head Unit volle Telefonbuch-Unterstuetzung incl. Adressen.
Und generell gilt bei BT-SAP, dass das Telefon es unterstuetzen muss. Das gilt z.B. fuer die Samsung Galaxy S- und Note-Serie (mit Ausnahme des S3 mini) und fuer (fast?) alle Blackberry-Geraete, nicht jedoch fuer das teure Spielzeug mit Apfel.
Zitat:
@Zak_McKracken schrieb am 12. Dezember 2015 um 15:49:05 Uhr:
Zitat:
@STFighter schrieb am 12. Dezember 2015 um 14:41:51 Uhr:
Recht viele Homepages kommen wohl nicht mit UDP klar und irgendwie will BluDun keine TCP Verbindung aufbauen...liegt das an BluDun oder am Comand Online?
HTTP verwendet immer TCP, nicht nur "viele Homepages". Wie kommst Du auf UDP?
Das ist falsch. UDP wird nur extrem selten für HTTP verwendet. Ich komme darauf, weil BluDun nur UDP Verbindhtml udpungen anzeigt und keine TCP Verbindung.
Bin da jetzt auch schon ein wenig weiter, anscheinend spielt BluDun so etwas wie DNS und schickt das ganze per UDP ans Comand. Das ist für die Apps auch kein Problem - die laufen damit problemlos, der Browser bekommt aber keine TCP Pakete zurück, die erwartet werden und Timed aus. Und die meisten Webserver können mit UDP Anfragen nicht um gehen, weil die Pakete nicht übers gleiche Protokoll zurück kommen. (Logisch bei UDP...)
Auf gut Deutsch: Liegt sowohl an BluDun, als auch am Browser im Comand UND manchen Servern bzw. Konfigurationen (UDP ist bei manchen auch einfach gesperrt). Google und Spiegel Online können z.B. mit UDP anfragen umgehen, Facebook und Motor-Talk nicht 
Zitat:
@STFighter schrieb am 13. Dezember 2015 um 14:42:27 Uhr:
Das ist falsch. UDP wird nur extrem selten für HTTP verwendet.
Ich wiederhole es nochmal: HTTP verwendet immer TCP.
RFC 1945 (HTTP 1.0) und 2616 (HTTP 1.1) lassen zwar prinzipiell die Moeglichkeit anderer "reliable transports" offen, aber dazu gehoert UDP nunmal nicht, und HTTP enthaelt auch keinerlei Massnahmen, um mit Packet Loss oder einer nicht eingehaltenen Paketreihenfolge umzugehen, das macht alles der TCP-Stack des Betriebssystems.
Was es lediglich gibt, sind HTTP-aehnliche Protokolle, die via UDP gefahren werden, z.B. SSDP als Bestandteil von UPnP, aber das ist eine ganz andere Baustelle. 
Zitat:
Ich komme darauf, weil BluDun nur UDP Verbindhtml udpungen anzeigt und keine TCP Verbindung.
Siehst Du da evtl. die DNS-Requests, also UDP Port 53?
Zitat:
Bin da jetzt auch schon ein wenig weiter, anscheinend spielt BluDun so etwas wie DNS und schickt das ganze per UDP ans Comand.
Du verruehrst da gerade Aepfel und Birnen.
Aus Sicht des Clients (also hier des COMANDs) ist ein BT-DUN-Server ein per Bluetooth angebundenes serielles Modem. Sobald eine Verbindung steht, werden PPP-Frames uebertragen, darin dann IP-Pakete, egal ob in denen TCP, UDP, ICMP oder sonstwas steckt.
BlueDUN duerfte (um keinen Root-Access zu brauchen) die Verbindungen selbst NATen, indem es aus dem normalen Android-Userland Verbindungen aufbaut, was fuer TCP und UDP problemlos funktioniert.
Fuer einen normalen HTTP-Request siehst Du i.d.R. zwei Verbindungen:
1. Sofern das COMAND den DNS-RR nicht im Cache hat: DNS-Request auf Port 53/udp.
2. TCP-Connection auf Port 80/tcp.
Allerdings ist es beim COMAND noch komplizierter: Zumindest beim NTG4.5 der 1. Generation, mit dem ich das getestet habe, liefen alle Verbindungen ueber einen per VPN angebundenen Mercedes-Proxy, das waere aus Sicht von BlueDUN vermutlich alles UDP gewesen.
Zitat:
Auf gut Deutsch: Liegt sowohl an BluDun, als auch am Browser im Comand UND manchen Servern bzw. Konfigurationen (UDP ist bei manchen auch einfach gesperrt). Google und Spiegel Online können z.B. mit UDP anfragen umgehen, Facebook und Motor-Talk nicht
...und dieses Pseudo-Wissen vergisst Du jetzt bitte ganz schnell wieder.
Ein typischer Grund dafuer, dass einige Websites erreichbar sind und andere nicht, sind MTU/MSS-Probleme. Ich weiss aber nicht, ob es in BlueDUN Einstellmoeglichkeiten dafuer gibt, und wie weiter oben erwaehnt, haengt vermutlich ohnehin noch der MB-Proxy dazwischen.
Sehe ich auch so, HTTP kann nicht simples UDP verwenden, weil:
UDP = verbindungsloses Protokoll
TCP = verdindungsorientiert.
Unterschied verbindungslos und verbindungsorientiert:
Bei allen wichtigen Diensten gibt es, mehr oder weniger abgewandelt, den sog. "Handshake". Handshake bedeutet, dass das Gerät, welches Information sendet, und das Gerät, welches Information anfragt, miteinander "reden". Nach dem Motto "hey du, ich schicke dir jetzt gleich Datenpaket 1, sage mir danach, ob du es empfangen hast, denn falls nciht, dann schicke ich es dir nochmal". Wäre das bei HTTP nicht der Fall, dann gäbe es des öfteren Homepages, bei denen ein Teil fehlt (zB eingebettet Bilder, eingebettete Textbausteine etc.).
UDP handelt nach dem Motto "fire and forget", eine Info wird rausgehauen, aber es wird nicht geprüft, ob sie auch wirklich angekommen ist. Das geht dann insgesamt logischerweise schneller, ist aber halt nicht immer sinnvoll, denn manchmal geht Qualität über Quantität.
Es wird geschätzt, dass ein niedriger zweistelliger Prozentsatz des gesamten Datenverkehrs "im Nichts verpufft", da es in Netzwerken auch viele Kollisionen gibt, deshalb macht TCP Sinn, denn es verifiziert das, was gesendet werden soll, und verlässt sich nicht darauf, dass es schon ankommen wird.
Zitat:
@Cizzle schrieb am 13. Dezember 2015 um 18:43:42 Uhr:
Es wird geschätzt, dass ein niedriger zweistelliger Prozentsatz des gesamten Datenverkehrs "im Nichts verpufft"
Ein Packet Loss im zweistelligen Prozentbereich, ohne dass die Leitung voellig ueberlastet ist, waere ganz klar eine Stoerung. Aber bei WLAN-Verbindungen ist es z.B. ziemlich normal, dass ab und zu mal das eine oder andere Paket fehlt.
Vieles laeuft ja auch tatsaechlich per UDP, neben DNS und schnellen Onlinespielen z.B. auch VoIP. Aber da sind dann die Protokolle darauf ausgelegt, damit klarzukommen. Beim Telefonieren hoert man z.B. lieber einen kleinen Aussetzer, als dass das Telefonat durch Resends verzoegert oder gleich ganz beendet wird.
Aber wir schweifen vom Thema ab.
Stimmt wohl, ich hatte das noch im Kopf von meiner Ausbildung damals. Hatte ich falsch im Kopf, hab gerade etwas nachgelesen, es liegt im niedrigen-mittleren einstelligen Bereich.
Sorry, my bad ;-(