iOS only showing lo0 adapter when using LTE

I have an iOS device that's showing some weird output.


On a working device, when I'm connected to wifi, I'm seeing these two adapters active


lo0  - I'm assuming this is the loopback adapter
en0  - The wifi adapter


On the same working device, when I'm connected over LTE, I'm seeing these two adapters active


lo0     - The loopback adapter
pdp_ip0 - The LTE adapter


However, on this strange device When I'm connected over LTE I'm only seeing


lo0 - The loopback adapter


However, I'm still able to make connections, brows the web, etc while on LTE and the LTE icon is still displayed at the top of the device.


I'm trying to understand why this is happening with this device. It's causing issues with the transition of a VPN process as it technically thinks there is no reachability over LTE when it transitions from WiFi to LTE. It's also causing issues with server lookup as my NSURLSession and NSURLRequest are timing out on API calls.


This transition works perfectly on most other devices. It's only on this device that it is acting this way.




Any help?

Replies

What's the make, model, and iOS version of the aberrant iOS device?

Other important questions:

- What's your bug report number?

- Can you offer more details on what conditions the device in question exhibits the defect?

- Have you attempted resolving the issue through a hard power cycle of the device?


Disclaimer: I have an iPad where the file system malfunctioned, rendering originally one and now two apps zombie undeletable.

iPhone 7, Model: A1778, iOS version: 10.3.1 (I believe it was purchased in Malta)
I'm not aware of any bug report number, nor would I know where to obtain one


I've attempted a hard reset with no changes.


Essentially, I'm trying to make a post request using NSURLSession and NSURLRequest in the app and it's unable to complete the request (as it times out). However, when I run the same request from a web browser I have no problems. This same request works on other iOS devices, all of the nessecary configurations are in place to make it.


I only noticed the missing adapter after doing some debugging.


Also, I did some more debugging and all of the pdp_ip adapters have this address even though they are not active: `IP: 255.7.0.0`. I'm not sure if that's relevant.

To be clear, the presence and name of the WWAN interface is not considered API. I know you’re not using it as such — you’re just trying to debug a problem — but I want to be clear about this because identifying specific network interfaces is a common problem with no good solution (and a lot of bad ones!).

Coming back to your actual issue, it sounds like this device is kinda broken. If I were in your shoes I woulde:

  1. Create a small test app that issues a simple network request

  2. Run it on a normal device to verify that it works

  3. Run it on this device to verify that it fails

  4. File a bug report with the following:

  5. Back up the device

  6. Reset its network settings to see if that fixes things

  7. If not, reset all its settings to see if that fixes things

  8. If not, restore it

  9. If that doesn’t fix it, sheesh, I’ve no idea (-: [Well, actually, take it to AppleCare.]

Finally, you can try restoring your backup to see if that restores the problem. If it does, and the backup doesn’t include anything too sensitive, you could include the backup in your bug report.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

So, I've tried resetting the phones network settings with no changes. I'm reluctant to restore the phone as I don't want to make the error go away, I want to fix it. It's esspecially perplexing that only this ONE app seems to be being effected. I created a test app that's using identical code to perform the post request. Using `rvictl` and Wireshark, i've verified that i can see the traffic flowing and the post request works in the test app even on the phone that is acting strange. (As does all network traffic on every other app, it's only this app that isn't working properly) However, the other app (that's again, using identical code) times out and Wireshark is showing absolutely no traffic from it. I've checked multiple things such as Network Link Conditioning, the "Use Cellular For" toggles in the Cellular section of Settings, all of the build settings for the application, etc. I can't for the life of me figure out why this ONE app refuses to send the post requests.


This is all being executed in a PacketTunnelProvider (if tihat makes a difference). I've also tried running it on multiple threads, main_queue, and my custom vpn queue.


The code I'm using is as follows:


- (void) performRequest {
    NSLog(@"Vrazo-Info: Performing API Request on %@, with reachability %@", intern_url, [Reachability reachabilityAsString:[Reachability reachabilityForInternetConnection].currentReachabilityStatus]);
  
    NSMutableURLRequest *req = [[NSMutableURLRequest alloc] init];
  
    NSData *reqD = [intern_req_d getRequestData]; // This returns a properly fomatted string, converted to an NSData using NSUTF8StringEncoding of 'key=value' (there is only one value being sent in the post request)
    NSURL *url = [[NSURL alloc] initWithString:intern_url]; // intern_url is a NSString
  
    [req setURL:url];
    [req setHTTPMethod:@"POST"];
    [req setValue:[NSString stringWithFormat:@"%@", @([reqD length])] forHTTPHeaderField:@"Content-Length"];
    [req addValue:@"application/x-www-form-urlencoded" forHTTPHeaderField:@"Content-Type"];
    [req setHTTPBody:reqD];
    [req setTimeoutInterval:10];
  
    NSURLSession *session = [NSURLSession sessionWithConfiguration:[NSURLSessionConfiguration defaultSessionConfiguration] delegate:self delegateQueue:[NSOperationQueue currentQueue]];
  
    NSURLSessionDataTask *task = [session dataTaskWithRequest:req completionHandler:^(NSData * _Nullable data, NSURLResponse * _Nullable response, NSError * _Nullable error) {
        if (error != nil) {
            NSLog(@"Vrazo-Info: Error while sending API Request: %@", error.localizedDescription); // This always outputs "Timed Out"
            NSString *respData = [[@"{\"response\":{\"error\":\"" stringByAppendingString:@"An internet connection is required to use Vrazo VPN."] stringByAppendingString:@"\"}}"];
            intern_resp_h([[SynfulResponse alloc] initWithData:respData]);
        } else {
            intern_resp_h([[SynfulResponse alloc] initWithData:[[NSString alloc] initWithData:data encoding:NSASCIIStringEncoding]]);
        }
    }];
  
  
  
    [task resume];
}

One app? Sorry if I missed it - how many devices?

Check the ATS settings of your app.

Where do I check these settings?

I have "Allow Arbitrary Loads" enabled (just for testing, but regardless it's there)

bump

bump

I’m not sure what other input you’re looking for here; from my perspective my response from 3 May stands.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

WWDC runs Mon, 5 Jun through to Fri, 9 Jun. During that time all of DTS will be at the conference, helping folks out face-to-face. http://developer.apple.com/wwdc/

I'm trying to avoid reloading the phone as I want to know what's causing this issue.


However, I've made some progress. I've figured out that it's an issue in the App Transport Security. But only with my application. I'm able to get the request to work if I use a domain name for the request, but it will always fail if I use an IP adress. And since this is only happening with my specific extension in my specifical application, could there be a remnant configuration for the app transport security from a previous version of the application that is bricking the phones network settings? And if so, is there a way to check if this is causing an issue.


I'm only curious because now that I've gotten the domain name working with the API, my VPN Conection is failing when trying to connect using an IP adress and C style sockets, I feel the two are probably related.

Since this is only happening on LTE, I thought it might have something to do with POSIX sockets not automatically bringing up the cellular adapter, so I tried opening an NSStream using TCP on another port while the connection is open, but this didn't seem to make a difference.

"... is there a way to check if this is causing the issue?"

I think what you really need to do is examine the contents of the application directory on the device. To do that, you pretty much either need to use an unsupported device inspection program (I've seen a few third party utilities for this, but I don't want to suggest any in particular) or add code to your app to inspect and traverse your app's application directory.


Then go through and compare the contents of the malfunctioning app to the contents of the working app, optionally trying to make the working app as similar as you can until it also stops working.

To do that, you pretty much either need to use an unsupported device inspection program (I've seen a few third party utilities for this, but I don't want to suggest any in particular) or add code to your app to inspect and traverse your app's application directory.

There’s a third choice here: if the app is development signed, you can grab a snapshot of its container using Xcode’s Organizer (select the device on the left, the app from the list on the main part of the panel, then use the gear menu).

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

WWDC runs Mon, 5 Jun through to Fri, 9 Jun. During that time all of DTS will be at the conference, helping folks out face-to-face. http://developer.apple.com/wwdc/

Ah, that is a much better choice. 🙂

I didn't realize that XCode let developers download the entire app container now, and thought that it still just downloaded the sandbox contents.


Download the malfunctioning app's container, and the working app's container, and compare everything. If something got frankenstained together due to successive versions accumulating on top of each other, that's how you're going to need to look at.