Tethering: Demo stürzt im Release-Modus ab und findet im Debug-Modus nicht den Server

[philipp.hofmann]

Hi,

ich teste gerade ein wenig mit dem Tethering rum. Ich habe es zuerst mit dem MediaPlayerHD-Demo ausprobiert. Da kam immer eine Fehlermeldung beim Start der Client.
Etwas weiter komme ich mit der PhotoWall-Demo, sprich der Client startet zumindest.

Aber leider wird der Server nicht gefunden, somit kann ich auch die beiden Apps nicht miteinander verbinden.
Dazu kommt, dass der Client beim Aufruf von DiscoverManagers abstürzt, wenn ich die App in den Release-Modus setze (statt Debug).

Beides passiert beim Client auf meinem Android-10-Tablet und meinem 14.4-iPad.

Wenn ich Bluetooth als Protokoll anstelle, stürzt es zumindest unter Android nicht mehr ab, aber gefunden wird trotzdem nichts und soweit ich es verstanden habe, ginge dies unter iOS eh nicht.
Bluetooth als Protokoll ist daher keine Alternative.

Hat jemand Tethering via IP mit Delphi 10.4.2 erfolgreich am Laufen? Am Besten sogar die Demo so angepasst, dass sie läuft.

Grüße, Philipp

[philipp.hofmann]

Ich bin ein Stück weiter. Wenn ich Client und Server auf einem bzw. zwei Windows-Rechnern laufen lasse und sowohl Client als auch Server als Ausnahme in meiner Firewall zulasse (dies muss ich manuell tun, ich werde leider nirgends danach gefragt), dann finden sich Client und Server.

Nur die iOS-Client-Version findet leider weiterhin nichts (egal ob Debug oder Release) und die Android-Debug-Client-Version findet auch nichts (die Android-Release-Client-Version stürzt ab).
Wie gesagt, wir sind hier beim offiziellen Delphi Beispiel Photo-Wall.

Wie bekommt man das mit den Firewalls besser hin?

[Michael II]

Zitat:

Zitat von philipp.hofmann (Beitrag 1489703)

Wie bekommt man das mit den Firewalls besser hin?

Das mit der Firewall liegt wahrscheinlich an deinen Windows Einstellungen. Ich habe die VCL Media Receiver App gestartet und die Windows Firewall hat brav gefragt "Zulassen?". Ich hab's getan und "DesktopWallVCLApp.exe" wurde in der Liste der Ausnahmen eingetragen.

Wenn du deine Windows App veröffentlichst, könntest du die Firewallregel(n) während der Installation automatisch hinzufügen (und während dem Deinstallieren wieder löschen).

Ich kann die MobilePhotoApp zwar kompilieren und auf meinem mobilen Gerät laufen lassen. Es treten aber leider beim Klicken auf "Foto" die folgenden zwei Probleme auf:

Debugger-Exception

Zitat:

Im Projekt MobilePhotoApp.apk ist eine Exception der Klasse EJNIException mit der Meldung 'java.lang.NullPointerException: Attempt to invoke virtual method 'android.content.res.XmlResourceParser android.content.pm.ProviderInfo.loadXmlMetaData(an droid.content.pm.PackageManager, java.lang.String)' on a null object reference' aufgetreten.

Im Projekt MobilePhotoApp.apk ist eine Exception der Klasse EIdSocketError mit der Meldung 'Socket-Fehler # 9Falsche Dateinummer.' aufgetreten.

Vielleicht liegt es an meinem SM-G770F. Falls ich ein anderes Gerät finde, dann teste ich noch einmal.

[philipp.hofmann]

Das mit dem App zulassen, fragt mich Windows leider nicht, weil ich eine Avast-Firewall nutze und diese fragt leider nicht.
Wenn ich diese deaktiviere, dann fragt mich auch die Windows-Firewall und ich kann es zulassen.
Ein Grund mehr mittlerweile nur noch Windows-Defender und Windows-Firewall zu verwenden. Aber ich habe ja nicht im Griff, was der Kunde benutzt.
Ich kann es dann nur in der Dokumentation benennen.

[Michael II]

Zitat:

Zitat von philipp.hofmann (Beitrag 1489707)

Ein Grund mehr mittlerweile nur noch Windows-Defender und Windows-Firewall zu verwenden. Aber ich habe ja nicht im Griff, was der Kunde benutzt.
Ich kann es dann nur in der Dokumentation benennen.

Ich kenne das Problem nur zu gut... selbst bei einem VP von jährlich CHF124 bis CHF150 gibt es ab und zu Firewall-Situationen, in welchen ich echt denke "wieso tu ich mir das an" ;-). (Wie hier schon oft besprochen: Hersteller von Sicherheitslösungen bieten alle Hilfe an [Downloadlink hinterlegen, ftp Upload etc.]. Je nach Situation kann sich dieser Weg lohnen.)
Es wäre gut, wenn eine App X via Windows eine "Willst du X zulassen?" Frage anstossen könnte und die installierte Sicherheitslösung darauf reagieren müsste. Falls dies nicht bereits in Windows eingebaut ist (???), dann wäre dies DAS Feature... - Oder gibt's das bereits? Und wenn Ja, wie lautet das Zauberwort?

Nun konnte ich noch auf einem Galaxy S8+/Android 9 testen. Fehlermehldung 1 tritt auch dort auf.

[philipp.hofmann]

So, Android connected sich nun auch und stürzt im Release-Modus nicht mehr ab.
Zumindest in meiner neu aufgesetzen Demo-Anwendung, keine Ahnung, was da in der EMBT-Demo anders ist.
Dann muss morgen nur noch iOS klappen.

[himitsu]

Zitat:

Zitat von philipp.hofmann (Beitrag 1489709)

keine Ahnung, was da in der EMBT-Demo anders ist.

Das will man manchmal nicht wissen, was sich da jemand gedacht hat,
sonst bekommt man noch Mordgelüste.

https://www.delphipraxis.net/207802-...e-android.html

[Der schöne Günther]

Ich kann nur als iOS Nutzer sprechen, mit Delphi habe ich schon zu lange nicht smehr dafür gemacht. Aber ich meine iOS fragt, ähnlich wie die Windows Firewall, danach ob eine App "Mit Geräten im Netzwerk kommunizieren und finden darf". Ich denke damit ist Traffic im lokalen Netz gemeint, insbesondere Ports aufmachen um dort eventuelle UDP-Broadcasts zu hören. Denn damit wird App Tethering intern wohl aufbauen, würde ich erwarten.

PS: Kann natürlich sein dass man so eine "Capability" erst in einem Manifest explizit für seine App aktivieren muss. Und ich wäre auch nicht super-überrascht wenn Embarcadero hier in seinem App Tethering eventuelle Fehler des Betriebssystems einfach nur schluckt und nicht zurückgibt.

[Rollo62]

Bei iOS ist wieder was dazugekommen, vielleicht liegt es daran.
Habe noch nichts damit zu tun gehabt, bis jetzt.
https://developer.apple.com/forums/thread/660485

[philipp.hofmann]

Ich kämpfe leider noch sowohl mit iOS als auch MacOS. Für MacOS sind schon mal die folgenden beiden Entitlements notwendig, sonst lässt sich der AppManager nicht auf enabled setzen:

Delphi-Quellcode:

   <key>com.apple.security.network.client</key>
   <true/>
   <key>com.apple.security.network.server</key>
   <true/>

Trotzdem finden sowohl die iOS- als auch die MacOS-Version sein Gegenstück nicht.
Die Android- und Windows-Version ist soweit fertig.

[Rollo62]

Hast Du schonmal mit ganz simplen Tcp Client/Server Echo-Demos versucht ob man überhaupt Verbindung bekommt ?
... und wo genau es scheitert, vielleicht gibt es da sinnvolle Fehlermeldungen.
https://en.delphipraxis.net/topic/10...latform-tcpip/

[philipp.hofmann]

Ein wenig weiter bin ich schon mal mit MacOS. Wenn man den CommandManager enabled, wird zuerst ein Port gesucht und dann einmal Daten versendet (BroadcastData):

Delphi-Quellcode:

procedure TTetheringNetworkServerCommUDP.BroadcastData(const AData: TBytes; const AHost: string;

Unter Windows kommt dann eine Antwort zurück (DoOnReceiveData), welche die eigene IP-Adresse enthält, dies wird gesetzt und danach dann bei allen anderen Kommandos verwendet.

Unter MacOS fehlt diese Antwort und dementsprechend wird auch keine IP-Adresse gesetzt und somit gehen alle weiteren Kommandos in's Leere.
Setze ich die lokale IP-Adresse in TTetheringNetworkManagerCommunicationThread.Execut e manuell, funktioniert alles.
Jetzt muss ich entweder verstehen, warum das eigene Request nicht mit einer Antwort ankommt oder ob dies ein gangbarer Workaround ist und ob er auch das Problem bei iOS löst (wo es aber wohl noch zusätzlich das Problem gibt, dass es Probleme mit Tethering und iOS 14 gibt, wenn Mobile Daten an sind, d.h. auf jeden Fall bei dem Zielgerät Smartphone). Aber eins nach dem anderen.

[TurboMagic]

Schön, dass du schrittweise weiter kommst.
Schaust du, falls du Dinge findest die nach Bug riechen,
ob die in QP gemeldet sind und falls nicht trägst die ein?

[philipp.hofmann]

Ja, ich kenne die relevanten QP-Einträge schon und werde dort meine Erkenntnisse reinschreiben.

Aktuell habe ich mich entschieden, dass ich die IP-Adresse lieber manuell setze. Ich habe teilweise auf den Rechnern neben dem WLAN-Network (192...) ein zweites Netzwerk für irgendwelche technischen Zwecke (169...). Die Standard-Implementierung von EMBT findet teilweise dieses Netzwerk auf Windows- und MacOS-Büchsen und dann funktioniert Tethering nicht.
Da ist mir nur etwas unklar, wie man da allgemein gültigen Code draus macht. So richtig prickelnd finde ich das Auspicken der IP-Adresse auch nicht. Wenn man dies tut, darf man im Formular-Designer bei TetheringProfile keinen Manager setzen, sondern muss dies erst zur Laufzeit setzen. Sonst hat man keine Chance das PreferredNetwork irgendwie vorab zu setzen:

Delphi-Quellcode:

class function TStringUtils.getIPv4Address():String;
var
  AAddresses: TIdStackLocalAddressList;
  LAddr: TIdStackLocalAddress;
  I: Integer;
  prefNetwork,IP: String;
begin
  mlog.info('setIPAddressManual');
  AAddresses:=TIdStackLocalAddressList.Create();
  prefNetwork:='192.';
  Result:='';
  try
    GStack.GetLocalAddressList(AAddresses);
    for I := 0 to AAddresses.Count-1 do
    begin
      LAddr:=AAddresses[I];
      IP:=LAddr.IPAddress;
      if ((IP<>'127.0.0.1') and ((Result='') or ((prefNetwork>'') and (pos(prefNetwork,IP)>0) and (pos(prefNetwork,Result)<=0)))) then
      begin
        case LAddr.IPVersion of
          Id_IPv4:
          begin
            mlog.info('Found IP-address*: '+IP);
            Result:=IP;
          end;
          Id_IPv6:
          begin
            mlog.info('Found IP-address: '+IP);
          end;
        end;
      end else
        mlog.info('Found IP-address: '+IP);
    end;
  finally
    AAddresses.Free;
  end;
end;

[philipp.hofmann]

Bei iOS muss ich jetzt erst einmal die Ursache für folgenden Fehler identifizieren:

23:43:22.688 1867755520-Info BroadcastData (2020-2039): TetheringNewManager|192.168.10.81$2020|1|{46432E8F-34BF-EB11-A66A-1F9FA441D777}|CommandManager|icTrainer_TetheringMa nagerRemote|2020~
23:43:22.697 1867755520-Info BroadcastData-Exception: Socket-Fehler # 65Keine Route zum Host.

Aber zuerst heute Abend mal iOS 14.6 installieren.