How to debug Push in one click on iOS

One of the interesting things about working in the Bay Area is that you can interact and exchange ideas with programmers from completely different engineering and cultural backgrounds. There are significant differences in language habits, educational environments, thinking patterns, and engineering experience. I have been in the Bay Area for more than half a year, and during this time I have a deep feeling that the programmers here place great emphasis on efficiency in doing things. When encountering a challenging project, the early design discussions and adjustments are very frequent in order to find the best path to reach the goal. When working on projects, each programmer has his own toolbox and small scripts to deal with various scenarios. The goal is to spend the least amount of time doing the most work, or to avoid overtime:)

Without further ado, this article shares with you a method I used to debug APN.

Scenario: Testing and finding that Push is no longer received

Every once in a while, the tester would find that the iPhone could not receive Push messages again. This was a common scenario at my previous company (it seems that many companies in the Bay Area did not test). After debugging, the reasons were different, but every time I had to stop the work at hand and go through the process: connect the phone with a data cable, check the uuid, start the virtual network card, run WireShark or tcpdump to capture packets, eliminate server-side problems, and check the phone settings. It took at least more than ten minutes to locate the problem, which was more than ten minutes wasted. After the above scenario happened several times, I wrote a simple tool to deal with it.

Question: How to improve efficiency?

I hope to simplify the process of network packet capture as much as possible. First, debug and locate whether the Apple server does not send Push, and finally complete the operation with one click. Use scripts to implement it step by step.

Step 1: After connecting to the test iPhone, automatically obtain the uuid

We can use the system profiler command in the terminal to obtain the USB device connected to the Mac:

 system_profiler SPUSBDataType

system_profiler is a command used to obtain the current system hardware and software configuration information. You can view detailed usage instructions through man system_profiler. The execution results of the above command are as follows:

You can clearly see the udid data (Serial Number) of the iPhone connected via USB. We can use sed to extract the target information:

 system_profiler SPUSBDataType | sed -n -E 's/Serial Number: (.+)/\1/1p'  

I only extracted the first match, since I usually only have one iOS device connected via USB.

The second step is to create a virtual network card to capture packets

We just need to pass the device udid extracted above as a parameter to the command to create the network card:

 system_profiler SPUSBDataType | sed -n -E 's/Serial Number: (.+)/\1/1p' | xargs rvictl -s

After executing the above command, you should see the following output:

 Starting device 198a630825ee39496411dc3e323039f2947fa16f [SUCCEEDED] with interface rvi0

The third step is to start tcpdump to monitor the virtual network card

Similarly, we only need to wait until the rvictl command is executed and then start tcpdump. From the output of step 2, we know that the id of the virtual network card is rvi0, so we modify the command as follows:

 system_profiler SPUSBDataType | sed -n -E 's/Serial Number: (.+)/\1/1p' | xargs rvictl -s | sudo tcpdump -i rvi0

*** You will need to enter the administrator password when running sudo tcpdump. If everything is normal, you will see the following output:

 tcpdump: WARNING: rvi0: That device doesn't support promiscuous mode
 (BIOCPROMISC: Operation not supported on socket)
 tcpdump: verbose output suppressed, use -v or -vv for   full protocol decode
 listening on rvi0, link-type PKTAP (Apple DLT_PKTAP), capture size 262144 bytes

Step 4: Adjust parameters

Although we have started the packet capture process, our goal is to debug push, so we are only interested in the network packets coming from APN. Next, we need to add a packet filter to tcpdump and set some simple parameters.

Here we need to have some knowledge about iOS APN. According to my analysis of the APN data channel, before iOS 9, Apple had a dedicated long connection channel to push applications, and the port number was fixed at 5223. Starting from iOS 9, Apple began to use HTTP 2.0 and created a comprehensive HTTP 2.0 long connection channel. This comprehensive channel should be used for more than just Push, so when capturing packets, you will see more packets than the previous 5223 channel. The current situation is: Apple uses two channels at the same time in the new version of the system, so APN sometimes goes through 5223 and sometimes goes through HTTP 2.0, and the strategy is unclear.

After a simple analysis, the goal is clear, we only need to restrict the port. HTTP 2.0 will undoubtedly use HTTPS, and the port is 443, so our *** command is adjusted as follows:

 system_profiler SPUSBDataType | sed -n -E 's/Serial Number: (.+)/\1/1p' | xargs rvictl -s | sudo tcpdump -i rvi0 src port 5223 or https

Step 5: Quick Start

We can't type the long list of commands above every time. For convenience, we can add an alias to the command and edit .bash_profile:

 vim ~/.bash_profile

Add command alias:

 alias apn= "system_profiler SPUSBDataType | sed -n -E 's/Serial Number: (.+)/\1/1p' | xargs rvictl -s | sudo tcpdump -i rvi0 src port 5223 or https"  

Enable Configuration

 source ~/.bash_profile

Step 6: Acceptance of results

Next time, when you test the problem of Push not being received, after plugging in the USB, I only need to:

1. Press F2 to start Terminal (a shortcut key set by BetterTouchTool on my Mac)
2. Enter apn and press Enter

Bingo, next you can have some coffee and look at the bag quietly.

Summarize

The above script just combines some small tools to save time and energy. There are many similar examples in the development process. There are always some tools or ways to improve our development efficiency. If you think more, you will gain something. You can also think more about how to use tools to improve productivity in your daily work.

Since I don’t have to work overtime at FB, I suddenly have more free time, so I plan to update more articles this year. The focus of the article will be on sharing ideas and experiences, mainly short and easy to digest. The purpose of this article is to share the idea of ​​using tools to improve efficiency and save time.