Post not yet marked as solved
When switch the net network from 5G to 4G in Setting->Cellular->Primary(the current card using for WANN) -> voice & data -> change to 4G.
The iOS API
SCNetworkReachabilitySetCallback
not callback.
I try using CTServiceRadioAccessTechnologyDidChangeNotification to get the notification, but won't work too.
And using addObserver:forKeyPath to observer the CTTelephonyNetworkInfo
instance's
currentRadioAccessTechnology value, it not change too.
But if you create a new CTTelephonyNetworkInfo instance, the currentRadioAccessTechnology will return a new value which is correct.
So it seems the only way to get the new currentRadioAccessTechnology in time, is to start a timer.
Is there a graceful way to get it ?
Post not yet marked as solved
My App use NEPacketTunnelProvider to start a VPN service for iOS device.
And sometimes, after App Process call startTunnelWithOptions success, iOS system won't start the VPN process successfully.
And it need to reinstall the IPA to make it work find again.
After Recurrence problem and catch system log.
We found this log
Feb 14 10:09:22 nesessionmanager[13722] <Notice>: NESMVPNSession[Primary Tunnel:SecureLink:CFA3ACD5-6A37-44DD-8BE9-DB3317285D03:(null)]: Re-setting policies because the installed apps changed Feb 14 10:09:22 nesessionmanager[13722] <Notice>: NESMVPNSession[Primary Tunnel:CDNetwork:B5F6D081-F37E-4A27-B7A7-596C4AA03118:(null)]: Resetting VPN On Demand Feb 14 10:09:22 nesessionmanager[13722] <Notice>: NESMVPNSession[Primary Tunnel:SecureLink:CFA3ACD5-6A37-44DD-8BE9-DB3317285D03:(null)]: Resetting VPN On Demand Feb 14 10:09:22 nesessionmanager[13722] <Notice>: Found 0 (0 active) registrations for com.CDNetworks.ESA.packettunnel (com.apple.networkextension.packet-tunnel) Feb 14 10:09:22 nesessionmanager[13722] <Notice>: Found 0 (0 active) registrations for com.wangsu.securelink.packettunnel (com.apple.networkextension.packet-tunnel) Feb 14 10:09:22 nesessionmanager[13722] <Notice>: NESMVPNSession[Primary Tunnel:CDNetwork:B5F6D081-F37E-4A27-B7A7-596C4AA03118:(null)]: Plugin is installed Feb 14 10:09:22 nehelper[11452] <Error>: Denying connection from nesessionmanager (13722) because it is missing the com.apple.private.network.socket-delegate entitlement Feb 14 10:09:22 nesessionmanager[13722] <Notice>: NESMVPNSession[Primary Tunnel:SecureLink:CFA3ACD5-6A37-44DD-8BE9-DB3317285D03:(null)]: Plugin is installed Feb 14 10:09:22 nesessionmanager(libsystem_networkextension.dylib)[13722] <Notice>: UUID cache generation changed from 351 to 353 Feb 14 10:09:22 nesessionmanager(libsystem_networkextension.dylib)[13722] <Notice>: UUID cache miss for com.apple.VoiceMemos Feb 14 10:09:22 nesessionmanager(libsystem_networkextension.dylib)[13722] <Notice>: UUID cache generation changed from 353 to 354 Feb 14 10:09:22 nesessionmanager(libsystem_networkextension.dylib)[13722] <Notice>: UUID cache miss for com.apple.Translate Feb 14 10:09:22 nehelper[11452] <Error>: Denying connection from nesessionmanager (13722) because it is missing the com.apple.private.network.socket-delegate entitlement
So could somebody tell me, what is com.apple.private.network.socket-delegate entitlement
and how to fix that.
Post not yet marked as solved
APP start VPN process code:
BOOL suc = [self.providerManager.connection startVPNTunnelWithOptions:options andReturnError:&amp;startError];
if (startError) {
SLTunWarn(@"start tun error %@ %@", startError, startError.localizedDescription);
SLAPPError *err = (SLAPPError *)[SLAPPError fromSystemError:startError];
callback(err);
return;
}
SLTunInfo(@"call startTunnelWithOptions success, start wait tun status");
startVPNTunnelWithOptions return success, and then the app log is
[TUN] system notify: [Disconnect]
[TUN] sys tun status [1]=&gt;[2]
[TUN] system notify: [Connecting]
[TUN] system notify: [Connecting]
[TUN] system notify: [Connecting]
[TUN] sys tun status [2]=&gt;[1]
can see that VPN state changed, from disconnect to connecting and finally disconnect
VPN Process Code:
- (instancetype)init
{
self = [super init];
if (self) {
[[SLEGlobalData shared] onLaunch];
NSLog(@"PacketTunnelProvider init");
self.wormhole = [SLEWormhole shared];
}
NSLog(@"init end");
return self;
}
the log "PacketTunnelProvider init" in init func shows, but not any other logs. So near certain startTunnelWithOptions not be called.
And app process did not receive any errors.
this problem occur occasionally。
Most of the time, VPN process start successfully.
So Any suggestions?
Post not yet marked as solved
Since iOS has double sim card devicesHow can I konw the user is using which sim to provide the 3G or 4G network ?The function: serviceSubscriberCellularProviders only provide a way to get sim card info, but not any info about the network.
Post not yet marked as solved
Is there any way to change the dns resolve result for NSURLSession or CFStreamCreatePairWithSocketToHost?
for example:
set abcd.com DSN resolve to 127.0.0.1 ?
Post not yet marked as solved
Is there any way to get CFNetwork version number?
Post not yet marked as solved
Hi , we are a network SDK develop company, our SDK is helping other apps optimize their network performance. We start a proxy server in the iOS device, and app's network request via our proxy server.Recently, we found request sometimes happen -1200 error (error NSURLErrorDomain / -1200 /) . After capture package between app and our proxy server. Found something strange:(please see the .pcap file https://github.com/icefirewang/share_file)After handshake success, app receive h2`s setting frame then initiate terminate the connection. ( see No.14 package) Then, retry, and failed, same as first time (see No. 15 package). After second failed, app try to handshake again, but failed. The fail reason is handshake agreement decline from 1.2 to 1.0 (out proxy server log: "handshake libssl error: error:140A1175:SSL routines:ssl_bytes_to_cipher_list:inappropriate fallback" , see No.16 package)The app request is started by URLSession in a NSURLProtocol. Out proxy server is base on openssl. Could you help us, find out what causeURLSession close the connection twice. And why the https agreement decline.