Afrihost APN high battery drain - EXPLAINED (not solved)

I recently moved to AirMobile and the new IOS version and was completely shocked on why every morning when I woke up my Iphone is dead. I initially thought this was because of the IOS update, logged a ticket with Afrihost to change my IP to CGNAT. I just hope this fixed the issue, starting to wonder if my Iphone 11 was the culprit.
 
I was just told by an Afrihost call centre agent (after he consulted with his manager on a 25-minute call), that the myBroadband article is inconclusive and that Afrihost do not in fact switch customers to CGNAT addresses.
Hi, please send me a PM with your account details, and I will assist you further. I do apologise for the inconvenience caused during this period.
 
I recently moved to AirMobile and the new IOS version and was completely shocked on why every morning when I woke up my Iphone is dead. I initially thought this was because of the IOS update, logged a ticket with Afrihost to change my IP to CGNAT. I just hope this fixed the issue, starting to wonder if my Iphone 11 was the culprit.

There are 2 issues here.

We agree that there is battery drain on certain public IP's allocated to clients but it also seems like the new iOS version has a battery drain. We have been getting a lot of requests from clients blaming the APN for battery drain just to find out that a natted IP is allocated and always has been.

It's a good idea to check the network status on the phone itself to see what IP address is allocated. If it's a 100.97 IP then this is a natted IP and the drain is not from this issue. If you are getting an IP of 102.182 , 169.1 or 192.143 on your phone then you have a public IP and might be affected by this issue.
 
Kudos @Jason-ZA

And I'll point this out to all those haters who say NAT is rubbish as a firewall.:laugh::ROFL:

Well this is a happy side effect of NAT but it still complicates a lot of things. Much, much better to do this with an actual firewall.
It got me thinking about IPv6... The plan is to give every device a routable IP, no?

Given this behaviour on LTE that seems like a really bad idea.

Should be an easy fix if the networks deploy a firewall and can be way more intelligent than a NAT. The networks will have to become more intelligent as well in both directions in any case over the next few years - we haven't seen a DDoS based on compromised cellphones to a bring a network down, but that will be coming in future years :-)
 
There are 2 issues here.

We agree that there is battery drain on certain public IP's allocated to clients but it also seems like the new iOS version has a battery drain. We have been getting a lot of requests from clients blaming the APN for battery drain just to find out that a natted IP is allocated and always has been.

It's a good idea to check the network status on the phone itself to see what IP address is allocated. If it's a 100.97 IP then this is a natted IP and the drain is not from this issue. If you are getting an IP of 102.182 , 169.1 or 192.143 on your phone then you have a public IP and might be affected by this issue.
Afrinatic I have send you a PM, I do have a 192 address.
 
Well this is a happy side effect of NAT but it still complicates a lot of things. Much, much better to do this with an actual firewall.
Here we go again! What is an actual firewall and would you implement that solving the problem by not using CGNAT? The firewall that google uses maybe?

All that will happen is that you will have expensive tin that will break things, especially when ICMP is blocked. Never met a firewall administrator that understands ICMP. Most are stuck in a world predating the turn of the century where the ping of death was a thing and seem to discount the fact that a fix has already been implemented for two decades.
 
Here we go again! What is an actual firewall and would you implement that solving the problem by not using CGNAT? The firewall that google uses maybe?

All that will happen is that you will have expensive tin that will break things, especially when ICMP is blocked. Never met a firewall administrator that understands ICMP. Most are stuck in a world predating the turn of the century where the ping of death was a thing and seem to discount the fact that a fix has already been implemented for two decades.
HA. Interesting that you mentioned ICMP. You can't ping devices behind a NAT and in this case you want to block ICMP traffic on the firewall to prevent the device waking up when IP ranges are scanned.

I also don't see much difference in implementing a firewall over a GCNAT. Except for NAT you need more powerful hardware and a configuration issue with a NAT is far, far harder to solve. And we have essentially disabled ourselves to make sure things work over NAT - most traffic now goes over HTTP and it stops innovation. We would have had much, much more efficient protocols if NAT wasn't a thing, and new protocols are next to impossible because you must have all NATs supporting it. And you end up with nasty techniques like hole-punching just to get some things to work.

My biggest problem with NATs is that it centralizes control. Peer-to-peer protocols (in the general sense, not file-sharing like bittorrent) are pretty much hamstrung as well having to use servers and not getting all participants be equal in the mesh.
 
HA. Interesting that you mentioned ICMP. You can't ping devices behind a NAT and in this case you want to block ICMP traffic on the firewall to prevent the device waking up when IP ranges are scanned.

I also don't see much difference in implementing a firewall over a GCNAT. Except for NAT you need more powerful hardware and a configuration issue with a NAT is far, far harder to solve. And we have essentially disabled ourselves to make sure things work over NAT - most traffic now goes over HTTP and it stops innovation. We would have had much, much more efficient protocols if NAT wasn't a thing, and new protocols are next to impossible because you must have all NATs supporting it. And you end up with nasty techniques like hole-punching just to get some things to work.

My biggest problem with NATs is that it centralizes control. Peer-to-peer protocols (in the general sense, not file-sharing like bittorrent) are pretty much hamstrung as well having to use servers and not getting all participants be equal in the mesh.
Ping is 1/255 of ICMP. You can do all ICMP outgoing and it works. Incoming works to the public IP. Never disable ICMP anything, it's stupid. That breaks the Internet. If you want to protect the inside use client isolation.
There is no reason to have a firewall on the NAT layer. The use case is not for a person to host it's to consume internet resources.
If you have to share something it's best to use a VPS and reverse port.
NAT breaks all the rubbish protocols. It's not the fault of NAT but the poor implementation of those protocols whose implementation is by nature insecure. These ALGs have patches that are often exploited, the worst being H323 and WebRTC. With or without NAT they are bad. Without NAT they are trivial to exploit. That they are still being used is laziness. Best to use SSL/TLS.
Security consists of bundling techniques. It's not a single magic bullet firewall even if you give it a fancy name and market it till the cows come home. Although a relevant security tool it becomes a poor crutch when it's the only thing being used to monkey wrench solutions.
 
Last edited:
IPv6 is a really bad idea and everyone has painted themselves into a corner just like Liz Truss. All that was needed was to keep IPv4 and add one extra octet.

The fundamental problem is it messes with the ethernet frame and reduces payload. All round a kuk idea. Get rid of it and as you pointed out its going to be a hackers paradise. (It already is for those fools stupid enough to implement it).
World wide adoption of IPv6 now at 40 odd% and growing. Just be like water..... and accept IPv4 will never have another octet :-)
 
There are 2 issues here.

We agree that there is battery drain on certain public IP's allocated to clients but it also seems like the new iOS version has a battery drain. We have been getting a lot of requests from clients blaming the APN for battery drain just to find out that a natted IP is allocated and always has been.

It's a good idea to check the network status on the phone itself to see what IP address is allocated. If it's a 100.97 IP then this is a natted IP and the drain is not from this issue. If you are getting an IP of 102.182 , 169.1 or 192.143 on your phone then you have a public IP and might be affected by this issue.
So I also checked and I get a 102.182 Address.

Battery drain in insane, can charge phone to 100% set it down and go to sleep and wake up it’s 55%
 
So I also checked and I get a 102.182 Address.

Battery drain in insane, can charge phone to 100% set it down and go to sleep and wake up it’s 55%

Please can send me a pm with the number in question so I can have a look for you?
 
@AfriNatic I logged a ticket two days ago to take me off the CGNAT, today I followed up 3 times on the WhatsApp support line with no success. I would appreciate assistance. Can I send you a DM with my support ticket?

Thanks
 
There are 2 issues here.

We agree that there is battery drain on certain public IP's allocated to clients but it also seems like the new iOS version has a battery drain. We have been getting a lot of requests from clients blaming the APN for battery drain just to find out that a natted IP is allocated and always has been.

It's a good idea to check the network status on the phone itself to see what IP address is allocated. If it's a 100.97 IP then this is a natted IP and the drain is not from this issue. If you are getting an IP of 102.182 , 169.1 or 192.143 on your phone then you have a public IP and might be affected by this issue.

Recently got afrihost data on my mtn sim for my phone. I was wondering what on earth was going on.

My battery went from 75% to 2% in 8 hours overnight just idling. Previously my battery at 80% will last about 36 hours if I don't use it much.

I checked my IP is 192.143.xxx.xxx
 
Top
Sign up to the MyBroadband newsletter
X