# Verbingungsart ermitteln



## Sunchezz (18. Nov 2012)

Moin moin 

folgende Frage:

Ist es möglich die Verbindungsart zu ermitteln? Ist Host mit Kabel, WiFi oder auf Smartphones sogar mit Mobile-Netz verbunden.
Ich schätze mal, Letzteres wird dann wohl vom OS des Smartphones geliefert, wie bei Android.
Aber gibt es schon darüber, also in reinem Java, eine Möglichkeit die Verbindungsart zu ermitteln?
Im NetworkInterface bin ich nicht fündig geworden und meine Googlesuche lieferte nicht wirklich viel, bis garnichts, wohl auch weil ich nicht weiß nach welchen Stichworten ich genau suchen soll.

Danke schön für Antworten 

Gruß Sunchezz


----------



## trääät (18. Nov 2012)

erstmal würde ich ganz einfach sagen : nein , sowas wird wohl selbst mit native-libs eher unmöglich sein ..

grund : das OS selbst kennt zwar den typ seiner verbindung ... und dieser lässt sich auch sicher irgendwie über native-libs in java abbilden ... aber es gibt sonderfälle wo das ganze ziemlich krachen würde ... z.b. wenn man ein smartphone (gleich ob Android oder Apple) mit dem rechner verbindet und dieses dann als "modem" nutzt ...
ich weis zwar nicht wie das unter unix ablaufen würde ... aber zumindest unter windows dürfte es doch schwer werden diese art von anbindung von einem 56k-dail-up zu unterscheiden ...

außerdem ist es eigentlich eher weniger relevant ob man via W-Lan mit seinem netz verbunden ist oder direkt übers kabel geht ...
man dürfte es zwar rausbekommen ... aber gestatte mir mal die gegenfrage : WOZU ?

welchen sinn hätte es wenn du ermitteln könntest wie ein rechner mit seinem lan / dem netz gekoppelt ist ... und was würdest du in unterschiedlichen fällen anders machen ?

auch ist die annahme das irgendwer irgendwelche daten sendet falsch ...
wenn du jetzt von einem browser ausgehst stimmt es zwar das diese den sog. User-Agent mitliefern ... dieser lässt sich aber 1) meist manipulieren und 2) bewusst ändern um dem server nicht zu sagen das man z.b. von nem smartphone bewusst auf die nicht-smartphone version zugreifen will ...
gehst du aber von einer ganz normalen TCP/IP verbindung aus gibt es diese informationen nicht mehr ...

auch sind mir fälle bekannt in denen BlueTooth als kopplung verwendet wird ... und das rauszubekommen dürfte wohl sehr witzig werden ...

die einzige idee die mir jetzt spontan einfällt ist das auslesen der MAC des genutzten adapters und dann nachschlagen in einer liste zu welcher gruppe dieser gehört ...
laut Wikipedia ist eine MAC in zwei teile getrennt : den hersteller-code sowie die von ihm selbst festgelegte geräte-id ... die hersteller-codes soll man wohl größtmöglich einsehen können ... in wie weit dann NIC-hersteller ihre eigenen listen preisgeben anhand der man dann nachsehen könnte ob WLAN , LAN , UMTS , GPRS , LTE , BlueTooth usw ist nicht bekannt ...
aber selbst dafür bräuchte man riesige listen wenn man bedenkt das eine MAC 48bit lang ist ...
außerdem wären dann "virtuelle" systeme wie Hamachi und andere V-Lan software nicht eindeutig zu erkennen da diese dem beschriebene schema meist nicht folgen ...


von daher also noch mal : welchen sinn hätte es um diesen aufwand zu rechtfertigen ?


----------



## Bernd Hohmann (18. Nov 2012)

Sunchezz hat gesagt.:


> Aber gibt es schon darüber, also in reinem Java, eine Möglichkeit die Verbindungsart zu ermitteln?



Der TCP/IP-Verbindung sieht man nicht an, auf welche Art- und Weise sie zustande gekommen ist. Man kann sich das wohl aus den Logfiles des jeweiligen Connectionmanagers herauslesen, aber das schon auf einer einzelnen Plattform kaum generalisierbar.

Wenn Du mal über ein Icon stolperst was zb. heisst "WLAN-Verbindung" dann ist das ein Text, den der Connectionmanager für das Icon generiert hat (dh. das Icon selbst weiss nichts von seinem Glück).

Bernd


----------



## Sunchezz (18. Nov 2012)

Danke für den technischen Background^^
Sowas wollte ich in etwa wissen.

Also wenn, dann nur extrem schwer und kaum platformunabhängig (von der sehr aufwendigen MacListe mal abgesehen).



> außerdem ist es eigentlich eher weniger relevant ob man via W-Lan mit seinem netz verbunden ist oder direkt übers kabel geht ...
> man dürfte es zwar rausbekommen ... aber gestatte mir mal die gegenfrage : WOZU ?



das dürften manche leute wohl auch zur Idee "mobile Webseiten" gesagt haben... und Menschen im 18Jhr zur Idee "Computer"...
Nicht das meine Idee bahnbrechend und neu ist, nein... aber ich finde es schon sinnvoll in einem Netz, dem ServerAdministrator die Optionen zu lassen:
-Daten von diesem Typ nur von "stehenden Geräten" (Kabel).
-Was anderes nur/nicht von schneller räumlich wechselnden WLAN-Geräten.
-MobileClients garnicht annehmen.
oder oder oder...
(Das es Ausnahmen gibt war mir von vornherein bewusst! Solche Informationen sollen lediglich Warscheinlichkeiten eingrenzen oder zumindest dem Endanwender Informationen bereit stellen und ihm Entscheidungen überlassen)


Sorry, aber Möglichkeiten gibts genug, um mit diesen Infos etwas sinnvolles anzustellen!


----------



## Bernd Hohmann (18. Nov 2012)

Sunchezz hat gesagt.:


> Nicht das meine Idee bahnbrechend und neu ist, nein... aber ich finde es schon sinnvoll in einem Netz, dem ServerAdministrator die Optionen zu lassen:
> -Daten von diesem Typ nur von "stehenden Geräten" (Kabel).
> -Was anderes nur/nicht von schneller räumlich wechselnden WLAN-Geräten.
> -MobileClients garnicht annehmen.



Das hättest Du gleich sagen können.

Diese Selektion lässt sich zum Teil schon anhand der Browser/OS Kennung im HTTP-Protokoll durchführen (und wird auch schon länger angewendet).

Feinheiten standen zwar schon zur Diskussion, führen aber am eigentlichen Problem (schlechte INet-Verbindung) vorbei.

Bernd


----------



## Sunchezz (19. Nov 2012)

> Das hättest Du gleich sagen können.



Hätte ich, wäre aber meiner meinung nach nicht Zielführend gewesen 
Was ich vielleicht hätte erwähnen können wäre, es geht nicht um Webseiten Programmierung, sondern um Socketverbindungen 
Und da hilft mir weder der Browser, noch das OS.

Aber danke.


----------



## trääät (19. Nov 2012)

sorry ... aber das mit dem "server-admin die wahlt geben wer was bekommt" wird so nun wirklich nicht umsetzbar sein ...

grund : der server selbst kann nicht erkennen ob das gerät via LAN , W-LAN , 3G oder was auch immer mit dem netz verbunden ist ... und auch ne MAC-liste bringt hier nichts weil der server ja auf MAC-ebene nur den letzten router sieht über den das paket gelaufen ist ... nicht aber die MAC des direkten clienten ...
ohne client-software ist das vorhaben also schon mal überhaupt nicht umsetzbar ... zumindest nicht wenn es nicht um website-programmierung gehen soll wo man noch irgendwas mit dem User-Agent machen könnte (und auch hier nur die unterscheidung zwischen Browser/OS , NICHT aber der verbindungs-art) sondern um direkt socket-anwendungen müsste wenn die logik schon auf dem client implementiert werden ...

und wenn du jetzt mit so nem beispiel kommst ... sorry : dann gibt es für mich nicht mal auch nur einen einzigen sinnvollen einsatzzweck für sowas ...
selbst wenn du es ermitteln könntest und dem server nun sagen kannst : dieser client ist über W-LAN an sein netz gekoppelt ... wird daraus aber immer noch nicht klar wie der access-point ans netz gekoppelt ist ... es kann genau so gut sein das der rechner sagt : ich bin über ein lan-kbel verbunden ... aber am anderen ende des lan-kabels hängt ne drahtlose verbindung zum netz ... oder weis der teufel ...

daraus folgt : es ist NICHT möglich herauszubekommen wie nun die wirkliche physische verbindung zwischen dem client und dem server aussieht ... weder mit java noch mit anderen mitteln ... denn sowas kann man als end-user einfach nicht ermitteln ...

nach dem du nun etwas präziser geworden bist wie du das ganze meinst und wofür in etwa du sowas verwenden würdest muss ich dir jedoch leider antworten : sowas geht nicht !


----------



## Sunchezz (19. Nov 2012)

Wer sprach denn davon das es der Server erkennen soll?

Ob DIR dafür ein sinnvoller Einsatzzweck einfällt ist mir egal, habe ich danach gefragt?
Ich HABE einen... Ob du den jemals als sinnvoll erachten wirst, fraglich, fakt: es gibt Gründe, deshalb frag ich nach den technischen Möglichkeiten!

Das der Client diese Informationen dem Server bereit stellen muss, ist mir von vorn herein klar gewesen und ich bin auch sehr stark der Meinung nichts davon gesagt zu haben das diese Information vom Server ermittelt werden soll!

Ich habe eine technisch konkrete Frage gestellt und du erzählst mir sonstwas was von "sinnlos".
Ich habe im übrigen auch nicht gefragt wie die Hundertprozentig richtige tatsächliche physische Verbindung zu ermitteln ist, sondern ob es möglich ist die Verbindungsart des HOSTs heraus zu finden. Also ist es mir faktisch egal wie der AccesPoint dann weiterhin verbunden ist, wie gesagt, danach habe ich NICHT gefragt.


----------



## trääät (20. Nov 2012)

gehen wir doch mal folgedenen fall durch

client via w-lan an einen hot-spot
hot-spot via lan an größeres lan
größeres lan via bluetooth-bridge mit einem 3G-modem gekoppelt

und beim server ähnlich in vielleicht anderer reihenfolge ...

auch wenn das zugegeben sehr wirr wäre und so sicher niemand freiwillig umsetzen würde

dann hättest du fast alle möglichen verbindungs-arten drin ... daraus ergibt sich die frage : welchen sinn macht es jetzt festzustellen wie welches gerät mit seinem jeweiligen nachbar verbunden ist ? mal von abgesehen das es wie oben bereits gesagt extrem aufwändig bis eigentlich nicht möglich ist

wenn du einen einsatzzweck dafür hast würde ich den gerne mal wissen ... gleich wie ich ihn dann betrachte ...
für mich ist halt nur nicht nachvollziehbar was die verbindungs-art eines gerätes über die gesamte verbindung auskunft geben und/oder was sich danach richten soll ...

in bezug auf deinen letzten satz mal deutlich : wenn es dir egal ist wie z.b. der access-point eines via w-lan mit diesem verbunden clienten weiter ans netz angebunden ist warum ist es dann wichtig zu wissen das der client via w-lan mit einem access-point kommuniziert ? ich bezweifel stark das es dafür (sinnvolle) einsatzgebiete gibt ... gleich ob mir was dazu einfällt oder nicht


----------

