philipp.hofmann

There is no handler assigned to the event. The handler is called. The port is set correctly between both methods in the Tethering implementation. It works perfectly with Windows, Android, iOS 13 and MacOS 10. But now we come to magic: Since today it's running fine on MacOS 11 and iOS 14 also. I haven't updated the code or the OS. But I've updated to newest XCode version this week. This is the only dependency I can imagine that this was the reason. But thanks for your help to get a better understanding of the technic below Tethering. If I run again into problems, this could help.

The OnBeforeBind is requested but not assigned. But this is also the case under Windows and seems to be no problem. The code you are asking for should be constructor TTetheringNetworkServerCommUDP.Create(AIPVersion: TCommIPVersion; const ABindToAddress: string); var I: Integer; LSocket: IIPSocketHandle; LSubnetTable: TArray<TIPv4Subnet>; begin inherited Create; FIPVersion := AIPVersion; FUDPServer := PeerFactory.CreatePeer('', IIPUDPServer, nil) as IIPUDPServer; FUDPServer.ThreadedEvent := True; FUDPServer.OnRead := DoUDPRead; FUDPServer.OnException := DoUDPException; FUDPServer.IPVersion := FIPVersion; if ABindToAddress <> '' then begin FSocketUDP := FUDPServer.Bindings.Add; FSocketUDP.IP := ABindToAddress; FSocketUDP.IPVersion := FIPVersion; end else begin LSubnetTable := GStackPeers.GetIPv4Subnets; if Length(LSubnetTable) < 2 then begin FSocketUDP := FUDPServer.Bindings.Add; FSocketUDP.IPVersion := FIPVersion; end else begin for I := Low(LSubnetTable) to High(LSubnetTable) do begin LSocket := FUDPServer.Bindings.Add; LSocket.IPVersion := FIPVersion; LSocket.IP := LSubnetTable[I].Address; if not assigned(FSocketUDP) then FSocketUDP := LSocket; end; end; end; end; function TTetheringNetworkServerCommUDP.DoStartServer: Boolean; begin Result := True; try FUDPServer.Active := True; except // This is a non conventional method to catch an exception that is in a library that we do not want to have a dependency. // This is considered a HACK and not a good sample of programming techniques. // We are going to let this code handle the exceptions until we add a proper mechanism to propagate the // Indy exceptions through the IPPeerAPI in an ordered and safe manner. on E: Exception do begin Result := False; if not (CheckExceptionName(E, 'EIdCouldNotBindSocket') or CheckExceptionName(E, 'EIdSocketError')) then // Do not translate raise; end; end; end; Do you have an example how to use TIdUDPServer directly? I'm using the Delphi Tethering implementation to hide such complicate issues from me. And now I'm in as I try to solve an error.

Hi Remy, a) I've checked now with "netstat -an". On MacOS10 I get the following entries: Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp4 0 0 *.2020 *.* LISTEN udp4 0 0 *.2020 *.* On MacOS11 I get the following entry only: Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp4 0 0 *.2020 *.* LISTEN but there is no entry for *.2020. I can see with Wireshark-Packet-Sniffer that the UDP package for Port 2020 is there but not read on MacOS11 computer. Best regards, Philipp

Hi Remy, do you have any other idea what to check on my side to solve the MacOS11 issue? Can you reproduce on your side the issue with MacOS11? Best regards, Philipp

The command "nc -vnzu 192.168.10.30 2020-2040" returns "[udp/*] succeeded!" for all ports. But also if the app is not running yet and it's the same response on MacOS 10 as on MacOS 11. I'm using the Delphi-Tethering-implementation and it looks like Start-Listing was successful. FAcceptWait contains the default value, so 1000. I'm wondering if there is any new setting to use for MacOS 11 (e.g. capabilities). I know the Multicast-capability yet but this is only for iOS14.x.

The question for me is now, why it works with your MacOS Big Sur? Is it a different setting for the Mac or a different setting in the provision profile? Can you see that the method TTetheringNetworkManagerCommunicationThread.DoOnReceiveData reached if you start the app on MacOS, equal if DesktopWWallApp or MobilePhotoApp?

Hi, I'm using TIdTime to synchronize the time for an online process but it's not working as expected: Documentation TIdTime.DateTime: - DateTime is a read-only TDateTime property that reflects the estimated current date and time according to a Time server. - DateTime is expressed in the timezone for the local computer. procedure TicTrainerF.syncTime(); var idTime:TIdTime; dtLocal1,dtLocal2,dtServer:TDateTime; begin idTime:=TIdTime.create(nil); idTime.Host:='time.nist.gov'; dtLocal1:=NOW; dtServer:=idTime.dateTime; dtLocal2:=NOW; mlog.info('syncTime: '+DateToStr(dtLocal1,myFormatSettings)+'/'+DateToStr(dtLocal2,myFormatSettings)+' vs '+DateToStr(dtServer,myFormatSettings)); ... It's fine for my windows-computers, so I can use it here. 1. But it's wrong for Android and iOS as the time is returned in UTC instead of the local time zone. -> Question A: Is there a fixed rule for this so that it's always in UTC for this OS? 2. On my Amazon FireHD-10 tablet (FireOS/Android) I get something completly different. -> Question B: Was is the reason for completly different results here? incorrect (timezone): --------------------- syncTime (Android): 2021-01-18 16:24:50.789-16:24:51.169 vs 2021-01-18 14:24:51.000 syncTime (Android): 2021-01-18 16:24:48.071-16:24:48.428 vs 2021-01-18 14:24:49.000 syncTime (iOS): 2021-01-18 16:24:49.658-16:24:49.996 vs 2021-01-18 14:24:50.000 incorrect (at all): ------------------- syncTime (FireOS/Android): 2021-01-18 16:24:48.606-16:24:49.028 vs 2021-01-18 14:40:02.000 correct: -------- syncTime (Windows): 2021-01-18 16:24:47.612-16:24:48.359 vs 2021-01-18 16:24:48.000 syncTime (Windows): 2021-01-18 16:24:46.014-16:24:46.771 vs 2021-01-18 16:24:47.000 It's important for me that I can rely on the synchronization, else it's better to skip it and ask the user to take care of it. Are there idea how to improve this synchronization? Best regards, Philipp

Yes, I've changed it in IdGlobalProtocols.TimeZoneBias. I've tested it only with Android but I'm very sure that it's fine for MacOS/iOS also. I can test a new version of the Indy-implementation without huge effort, if this helps you. You have to send me only the pas-file to replace.

Hi Remy, it's Result := -1 * (TTimeZone.Local.UtcOffset.TotalMinutes / 60 / 24);

The error occurs in IdGlobalProtocols.TimeZoneBias: function TimeZoneBias: TDateTime; {$IFNDEF FPC} {$IFDEF UNIX} var T: Time_T; TV: TimeVal; UT: {$IFDEF USE_VCL_POSIX}tm{$ELSE}TUnixTime{$ENDIF}; {$ELSE} {$IFDEF USE_INLINE} inline; {$ENDIF} {$ENDIF} {$ELSE} {$IFDEF USE_INLINE} inline; {$ENDIF} {$ENDIF} begin {$IFNDEF FPC} {$IFDEF UNIX} {from http://edn.embarcadero.com/article/27890 } gettimeofday(TV, nil); T := TV.tv_sec; localtime_r({$IFNDEF USE_VCL_POSIX}@{$ENDIF}T, UT); // __tm_gmtoff is the bias in seconds from the UTC to the current time. // so I multiply by -1 to compensate for this. Result := (UT.{$IFNDEF USE_VCL_POSIX}__tm_gmtoff{$ELSE}tm_gmtoff{$ENDIF} / 60 / 60 / 24); {$ELSE} ... If I replace this with the following it's fine: function TimeZoneBias: TDateTime; {$IFNDEF FPC} {$IFDEF UNIX} var nowDt:TDateTime; {$ELSE} {$IFDEF USE_INLINE} inline; {$ENDIF} {$ENDIF} {$ELSE} {$IFDEF USE_INLINE} inline; {$ENDIF} {$ENDIF} begin {$IFNDEF FPC} {$IFDEF UNIX} nowDt:=NOW; Result := TTimeZone.Local.ToUniversalTime(nowDt)-nowDt; {$ELSE} ... So it's fine for iOS and Android. For Android/FireOS there seems an additional issue with Delphi 10.3.3.

For me it's fine to compare with UTC time but the documentation of TIdTime says "DateTime is expressed in the timezone for the local computer". And for Windows it's matching the documentation and for Android/iOS it's not matching the documentation. That's the point. In my case I need to know the difference between the local timestamp and the server timestamp. That's the reason to use TIdTime. On Windows it's working fine, if the local time of computer A is 90 seconds ahead and of computer B it's 10 behind, I know that both computer's have a difference of 100 seconds and I have to keep this in mind for all synchronizations between both computers (it's a synchronization of video-play and it's should be insync with an accepted difference of +/-3 seconds. That's working as expected with my routine.

In this case I'm developing software for end consumer, so it's no solution if I have to use additional hardware or if I restrict the software to Sierra.

I can confirm, with Delphi 10.3.1 and MacOS Sierra (-> Xcode 9.2) the BLE implementation is up and running. So I don't have to use the old Delphi Version but have the problem that my clients have to use Sierra also (-> no use case for me).

I was able to use Delphi+BLE only in combination with MacOSX Sierra (or older) but not with High Sierra or Mojave -> this means it's not useable in my use case. If you know how I can use Delphi+BLE also with Mojave I'm extremly interested.

The next step is to downgrade my second MacBookAir to Sierra. But then I can use it internally but can't delivery it to end Consumer as I can't specify the OS-Version to use.

My software runs with all OS (Win32/Win64/MacOS/iOS/Android/Linux [fmxlinux]) but with MacOS the Delphi-BLE-implementation is not useable. P.S.: With Linux BLE is also not useable but there isn't any BLE implementation until now, under MacOS is an error in the existing BLE implementation.

I have now Delphi Berlin 10.1.2 installed, PA Server 18.0 and Xcode 9.4.1 but get still the exception "BluetoothDevice is not found or disconnected" if I request "TBluetoothLEManager.startDiscovery" after I have set TBluetoothLE.enabled:=true successfully. Any other tip?

Ok, to increase the Chance I vote for the following issues: https://quality.embarcadero.com/browse/RSP-21029 https://quality.embarcadero.com/browse/RSP-22905

Hi, is there any solution for this issue in meantime? I use a MacBookAir 2018 with Mojave and XCode 10.1 with Delphi 10.3.1 and get the same error message if I want to use Bluetooth-LE on my MacBook Air. Best regards, Philipp