Potential fix for iOS devices sucking up BW - iptables fix - need testing

[sfx2000]

On another thread, but this is a common occurrence with many AsusWRT users with iPhone/iPads and those devices impacting network performance...

Apple introduced Multi-path TCP in IOS7 and later - it's a nice feature when it works, but with AsusWRT, it seems to have a negative impact...

Working with a forum member on a thread.... and with RMerlin's assistance, we might have a way to improve performance using iptables...

Need some testing from the collective...

in a nutshell - the rules I propose disable the MPTCP handshake, and forces the iOS device to use regular TCP for it's communication with the iCloud and it's various services...

proposed fix below... the iptables are mine, the rest is RMerlin on how to get this working on AsusWRT...

=============

Connect over SSH, and copy/paste the following, this is per RMerlin's insight here - I can't test this directly at the moment as I don't have a device capable of running AsusWRT.

cat << EOF > /jffs/scripts/firewall-start
#!/bin/sh
iptables -I INPUT -p tcp --tcp-option 30 -m state --state NEW -j DROP
iptables -I OUTPUT -p tcp --tcp-option 30 -m state --state NEW -j DROP
EOF
chmod a+rx /jffs/scripts/firewall-start
nvram set jffs2_scripts=1
nvram commit
service restart_firewall

This will create the script that sets up the rules, and restart the firewall.
Do not run this if you already created a firewall-start script, as it will overwrite it!
Use -I instead of -A for the rules, to ensure that they get processed before any ACCEPT rule.​

==============

Initial feedback is positive here - as the iOS devices no longer suck up bandwidth when they're backing up to the iCloud or other activities, e.g. downloading app updates, whatever...

Need more testing however... make sure Siri still works if you can.

==============

for those more technically inclined - here's a test case, and one doesn't need an iOS device to do this.... but one does need perhaps Ubuntu, either baremetal or VM (or VPS perhaps)

To test the iptables change - one can enable mptcp on ubuntu, and then grab a pcap with a filter similar to below;

tcpdump –i eth0 ‘tcp[13] & 0x12 = 0x12’ and tcp[40] = 0x1e

To enable mptcp on ubuntu, check sysctl

sysctl –w net.mptcp.mptcp_enabled=1​

(set the bit to 0 to disable afterwords)

===============

Anyways, give it a try and see - the IPtables entry here only takes action on MPTCP packets, nothing else...

 

[jrmwvu04]

Interesting. That's a problem I had tackled with QoS but I'll probably try this out.

 

[kvic]

You now block the landline (through the router) and all iPhone/iPad traffic going through LTE/cellular connections?

 

[IronSchramm]

I apologize as i'm new to the scripting aspects of AsusWRT, but I would like to test out this script as I have a network full of iOS devices. A noobish question if i may, I've connected via SSH to my AC87U, do I copy and paste the entire script at once, or line by line with a return press after each line? Again I apologize as i'm sure this has been answered a million times before. But I really want to put this fix through it's paces.

I believe i have it running, thanks;
May 9 07:46:09 rc_service: service 11048:notify_rc restart_firewall
May 9 07:46:09 miniupnpd[10988]: shutting down MiniUPnPd
May 9 07:46:09 kernel: registering ipv6 ROUTE target
May 9 07:46:09 start_nat_rules: apply the nat_rules(/tmp/nat_rules_ppp0_eth0)!
May 9 07:46:10 custom script: Running /jffs/scripts/firewall-start (args: ppp0)
May 9 07:46:10 miniupnpd[11088]: HTTP listening on port 37377
May 9 07:46:10 miniupnpd[11088]: Listening for NAT-PMP/PCP traffic on port 5351

 

[Adamm]

From what I read, this will disable the ability for Siri (and other services) to seamlessly switch from Wifi > Cellular. MPTCP indirectly also makes snooping on traffic harder.

What kind of "negative impact" have you seen besides high bandwidth usage?

 

[sfx2000]

You now block the landline (through the router) and all iPhone/iPad traffic going through LTE/cellular connections?

Shouldn't block anything - as iOS falls back to TCP if MPTCP can't be negotiated...

Might impact Apple's WiFI Assist function - which might not be a bad thing, as this can run people past their LTE/4G data caps and that can be $pendy fast..

 

[sfx2000]

In any event, not sure if this will fix the data hogging that can happen with iCloud backup (and recently iPhoto cloud backup) - it's a multi-faceted problem - corrupt backups can cause a lot of heartache here...

Personally, I don't use either of these "features" as I back up to iTunes on the desktop.

This is an attempt to address at least part of the problem for forum members that might be impacted.

 

[RMerlin]

This is an attempt to address at least part of the problem for forum members that might be impacted.

If those are bringing the network down on its knees, I'd say a cleaner solution would be to handle that traffic through Linux's tc, giving it a lower priority or throttling it. Tc might require using packet marking at the iptables level tho, for it to know which traffic to process. That means disabling CTF might be necessary then.

 

[MarCoMLXXV]

I already have a firewall-start script, generated by dnscrypt during install:

#!/bin/sh

[ -x /jffs/dnscrypt/dnscrypt-fw-rules ] && /jffs/dnscrypt/dnscrypt-fw-rules

Should I copy and paste the lines:

iptables -I INPUT -p tcp --tcp-option 30 -m state --state NEW -j DROP
iptables -I OUTPUT -p tcp --tcp-option 30 -m state --state NEW -j DROP

before or after the line above? Or should I add them somewere else (dnscrypt configuration for example)?

 

[RMerlin]

Adding these two lines after the existing content should be fine.

 

[jph1589]

I was able to recreate the bandwidth hogging problem with my sons phone. So I used it to test this.

I connected with SSH and entered the two Iptables commands and then had him run the back to icloud. I didn't see any appreciable difference before and after the iptables commands were entered.

For now I have gone back the QOS bandwidth limiter for specific devices.

 

[RMerlin]

Might be worth inserting the rule in the FORWARD chain too, since your clients are connecting from the LAN.

 

[jph1589]

Might be worth inserting the rule in the FORWARD chain too, since your clients are connecting from the LAN.

I will give that a try this evening.

 

[jph1589]

I turned off the QOS limiter and put in the 3 iptables entries. Input, Output, and Forward. Then I ran the icloud backup from the iphone. After running about 10 minutes and taking all the upstream bandwidth the backup canceled saying that it terminated due to poor network conditions. I've never seen that message before. I will be interested to hear how this went for others.

 

[sfx2000]

I turned off the QOS limiter and put in the 3 iptables entries. Input, Output, and Forward. Then I ran the icloud backup from the iphone. After running about 10 minutes and taking all the upstream bandwidth the backup canceled saying that it terminated due to poor network conditions. I've never seen that message before. I will be interested to hear how this went for others.

That's interesting - put the QoS limiters back in, and keep the recommended iptables entries in place...

Really do appreciate the efforts here...

 

[jrmwvu04]

I set up a script with the rules suggested and I assume I have it correct, I see the following output:

admin@RT-AC68W:/tmp/home/root# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination        
DROP       tcp  --  anywhere             anywhere             tcp option=30 state NEW
...
DROP       all  --  anywhere             anywhere          

Chain FORWARD (policy DROP)
target     prot opt source               destination        
DROP       tcp  --  anywhere             anywhere             tcp option=30 state NEW
...
ACCEPT     all  --  anywhere             anywhere          

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination        
DROP       tcp  --  anywhere             anywhere             tcp option=30 state NEW

etc etc etc

Disabled QoS, rebooted. I tested Siri a few times, all appeared well. Both manual use and "hey Siri" voice activation. Then I started up a game of Rocket League and initiated a cloud backup on my phone. There's an appreciable change in how badly it crushes the game (was still borderline playable which is not usually the case), but not so much so that I'd want to give up QoS. At any rate, I'll probably leave it set up like this for the foreseeable future just to see what if anything happens.

 

[sfx2000]

I'm not asking for folks to disable/modify any QoS modifications...

please, if you have a good set there, don't change - just add the iptables entry as suggested, it's very specific..

I can appreciate the effort, but we're focusing on a single item - MPTCP and how things work if it's disabled...

Part of the problem with iOS devices is that there seems to be multiple parts - I'm trying to nail down one...

 

[jrmwvu04]

I'm not asking for folks to disable/modify any QoS modifications...

The only thing about that is that John's new QoS implementation completely handles the problem on its own so if it was enabled, I wouldn't know if your changes made any positive difference. But I do see where you're coming from. Either way, I'm going to keep your rules in place until there's a reason not to. One side note, I had an ongoing 2-3 week issue with wifi calling not activating properly that just resolved itself after making these changes. That could be entirely coincidence, though.

 

[sfx2000]

Here's the common ports that Apple uses - and with iOS -

tcp can be mptcp... which is why I proposed the ruleset...

By dropping the option for MPTCP, as we can't do anything with 80/TCP or 443/TCP without impacting other services...

FWIW - here's the ports that Apple/iCloud uses...

25/TCP - sending email for icloud

80/TCP - facetime, imessage, itunes, icloud backup
443/TCP - same as above with SSL - Siri used 443/tcp if it can

587/TCP - Authenticated SMTP
993/TCP - IMAP SSL - icloud mail

5323/TCP - Apple Push notifications

For Bonjour/mDNS...

5353/UDP - mDSNResponder/Bonjour/Avahi

 

[jrmwvu04]

Had an issue with a time machine backup failing. Tried several retries throughout the day, didn't work. Removed the rules and restarted the firewall and it worked right away. Perhaps coincidence, perhaps not.