The Xposed Framework is a neat Android program that enables user-made modules to change the behaviour of the lower-level Android OS. It does this by modifying /system/bin/app_process to add some hooks into it.

The issue is that when flashing a new ROM, the modified app_process is reverted back to the original version, disabling the Xposed Framework until it's restored.

The solution to this is a script that will automatically back up the existing app_process before a flash, then restore it after the flash completes.

The 90-xposed.sh script does exactly that. To enable it, download it to the Android device, move it to /system/addon.d/90-xposed.sh, and give it executable permissions.

This can be done on the device with a few different programs, but it's much easier to do from a computer with adb.

Download the script and push it to the SD card of the Android device with

1

adb push 90-xposed.sh /sdcard/

Once the file is on the device, log into it (using adb shell) and run the following commands:

1
2
3

su  # Get root permissions
cp /sdcard/90-xposed.sh /system/addon.d/  # Copy the file to the correct folder
chmod 755 /system/addon.d/90-xposed.sh  # Make the file executable

After logging out of the device, the Xposed framework will stay installed and active even after flashing a new ROM. Note that this should only really be used in situations where the ROM isn't changing too much (like flashing a new nightly ROM).

In situations where app_process would actually be changed by the flash, this script could cause issues as it would restore an incorrect version of the file. If this happens, delete app_process and app_process.orig in the /system/bin/ directory, then reflash. The script won't interfere, allowing the flash to update app_process to the correct version. After rebooting, install the Xposed Framework again.

Preamble

This article will focus on setting strict speed limits on misbehaving devices on your network. This can be a housemate incessantly torrenting, your kid downloading movies on iTunes, or anyone else clogging up your network with their overzealous bandwidth gobbling.

If you're looking for help with the QOS (quality of service) settings that come baked into most router firmwares, this article is not for you.

This article assumes you have a router running OpenWRT, DD-WRT, Tomato, or any other firmware that uses tc to manipulate traffic control settings.

Procedure

First, you'll need to get shell access to the router. With most custom router firmwares, this is as easy as selecting a radio button. Other firmwares might give you the ability to enter commands via a web interface. Whatever works.

Once you have shell access, follow the steps below. Note that bits of the commands you might want to change are included in brackets.

1. Using ifconfig, find the interface to apply the limits to. You'll want to use either the internal or external default gateway (the interfaces all the packets go though). Keep in mind which interface you use as the filtering rules will be reversed.

   • Internal gateway: to src = uploading, to dst = downloading
   • External gateway: to src = downloading, to dst = uploading

2. Remove all existing rules on the interface (interface = br0)

   1	tc qdisc del dev br0 root

3. Set up the connection (Ex: connection speed = 20mbit)

   1	tc qdisc add dev br0 root handle 1: cbq avpkt 1000 bandwidth 20mbit

4. Add the limiting rule (Ex: speed limit = 10mbit)

   1	tc class add dev br0 parent 1: classid 1:1 cbq rate 10mbit allot 1500 prio 5 bounded isolated

5. Filtering - Add the users to apply to rule to

   • By src IP (Ex: IP = 192.168.1.100)

     1	tc filter add dev br0 parent 1: protocol ip prio 16 u32 match ip src 192.168.1.100 flowid 1:1

   • By dst IP (Ex: IP = 192.168.1.100)

     1	tc filter add dev br0 parent 1: protocol ip prio 16 u32 match ip dst 192.168.1.100 flowid 1:1

   • By src MAC (Ex: MAC = M0-M1-M2-M3-M4-M5)

     1	tc filter add dev br0 parent 1: protocol ip prio 5 u32 match u16 0x0800 0xFFFF at -2 match u16 0xM4M5 0xFFFF at -4 match u32 0xM0M1M2M3 0xFFFFFFFF at -8 flowid 1:1

   • By dst MAC (Ex: MAC = M0-M1-M2-M3-M4-M5)

     1	tc filter add dev br0 parent 1: protocol ip prio 5 u32 match u16 0x0800 0xFFFF at -2 match u32 0xM2M3M4M5 0xFFFFFFFF at -12 match u16 0xM0M1 0xFFFF at -14 flowid 1:1

Sources

• http://lartc.org/lartc.html
• http://www.docum.org/faq/cache/62.html

GitHub currently doesn't provide a way to convert an issue to a pull request in their interface. However, the capability exists in their Pull Request API.

To call the API using a simple curl command, run the command:

1
2
3
4

curl --user "[github username]" \
     --request POST \
     --data '{"issue": "[issue num]", "head": "[branch to merge from]", "base": "[branch to merge into]"}' \
     https://api.github.com/repos/[user]/[repo]/pulls

For example, to make user1 change issue 13 into a pull request to merge branch test_branch into master in the testing_repo repository belonging to user2, the command would be:

1
2
3
4

curl --user 'user1' \
     --request POST \
     --data '{"issue": "13", "head": "test_branch", "base": "master"}' \
     https://api.github.com/repos/user2/testing_repo/pulls

To specify a fork of a repository to merge from, put the username followed by a semicolon in front of the branch name like so: "username:branch_name"

After running the command, you will be prompted for your GitHub password. Enter it and curl should output the JSON response from the API. Make sure to check this response for errors!