Network Link Conditioner to control Wi-Fi

Question

I just finished installing and testing Network Link Conditioner that comes with Mac OS X Lion and Xcode4.1. It works great locally on the Mac, i.e. when I use the Internet connection that Network Link Condition is limiting directly.
However, when I create a Wi-Fi network on the Mac and share with it the Mac's Internet connection, Network Link Conditioner blocks Internet access to the Wi-Fi network completely. When Network Link Conditioner is turned off, the phones that are connected to the Wi-Fi network are able to browse the Web without issues. But when I turn Network Link Conditioner back on, the phones lose Internet connectivity.
Does this mean NLC cannot be used to test actual iOS devices and is only useful when testing using the Simulator? Or is there a workaround for this?
Thank you.

Answer 1

I think the problem is caused by packets entering the firewall multiple times, inappropriately.  This normally might be corrected via some MAC layer 2 filtering rules in ipfw, but those features are not present within ipfw as it appears in Mac OS X.
Note that Mac OS X Lion uses natpmpd for NAT in Internet Sharing, while Mac OS X Snow Leopard uses natd.  These NAT solutions operate with different technical consequences, some of which affect the firewall rules used by Network Link Conditioner.
In the interim, I've found an acceptable, if not ideal solution.  Instead of allowing Network Link Conditioner to create ipfw rules that modify every packet on every interface, modify the rules to only trap inbound packets traversing from the bridged interface to the LAN interface, and vice versa for outbound packets.  After all, if you're testing simulated network conditions on attached WiFi devices, you only need to degrade network conditions for those devices, and you don't need (or probably want) your Mac's internal Internet connection to be affected.
I've created a script that can be executed to automatically fix the appropriate ipfw rules in Mac OS X Lion.  It needs to be executed as root every time you select a new profile in Network Link Conditioner.  Or, run it once in polling mode ( '-p' ), and it will run in the background and detect and fix Network Link Conditioner firewall rules automatically.  It needs to be run as root because ipfw can only inspect and modify rules from an account with root privileges.
The script is located here: https://gist.github.com/1870945
If you want to perform the same logic manually, simply look for rules in the following format using 'ipfw list':
00100 pipe 40269 ip from any to any in
00200 pipe 40270 ip from any to any out
Replace them with rules in the following format, assuming that en0 is your LAN connection and en1 is your bridged WiFi connection:
00100 pipe 40269 ip from any to any xmit en1 recv en0 in
00200 pipe 40270 ip from any to any recv en1 xmit en0 out
To perform the above modifications, issue the following commands:
ipfw delete 100 200
ipfw add 100 pipe 40269 ip from any to any xmit en1 recv en0 in
ipfw add 200 pipe 40270 ip from any to any recv en1 xmit en0 out
You might need to reset your host and/or client WiFi connections before the modified rules work properly, as the firewall maintains packet state that sometimes directs packets according to previous firewall rules.
Note that in order for ipfw to allow rules to be created that span interfaces, you might have to modify the 'scopedroute' property to be disabled.  Unfortunately, Mac OS X Lion has made this property read-only, and you can no longer modify the property by performing the following command, which works in Snow Leopard:
sudo sysctl -w net.inet.ip.scopedroute=0
If you find yourself needing to fix this problem in order for Network Link Conditioner to work with bridged connections in Mac OS X Lion, read the following link for a solution on how to modify 'scopedroute':
http://pastebin.com/NzAARKVG
Also note that after having implemented all of the above, sometimes the connection seems to freeze for several seconds at a time, after which it resumes normally.  You can disable/reenable WiFi on the client to correct the situation immediately, or just wait it out.  It's an unfortunate side-effect of not having all the necessary tools to direct packets properly in Mac OS X Lion.