ZenLinux Blog

I returned to China during a three country East-Asia trip this Spring, and thought I’d share some more notes on being able to work remotely while in China. Some things worth sharing have changed since my last blog post on the topic in 2016.

One thing that’s interesting about the Great Firewall (GFW) is that China uses it for censorship of its mainland residents, but doesn’t do so for residents of Hong Kong, even though many of the same Chinese telecoms offer services there. I’ve heard that if you buy a prepaid sim card in Hong Kong, and use it in mainland China, your cell data service is not blocked by the GFW. So I was going to buy a prepaid Hong Kong sim before my trip until I learned that you can also buy sim cards from foreign providers that can work at 4G speeds in roaming mode in multiple countries. As I was traveling to Japan, Korea, and China, I started looking for a single sim solution that would work in all three countries.

What I found (and which worked flawlessly) was the AIS sim2fly prepaid sim card, which you can buy on Amazon. AIS is one of the biggest telecom companies in Thailand, and they claimed that these cards worked at full 4G speeds in roaming mode in several Asian countries, and that the service was not blocked by the GFW when used in China. They offer an 8-day prepaid sim with 6 GB of data (tethering supported), which was more than enough data for me. I ended up buying a few of these, so that after 8 days I simply popped in a new sim card and I was good to go for another 8 days. On top of that, using these sim cards was cheaper than if I were to have bought separate sim cards for Japan, Korea, and China. I’d highly recommend the AIS sim2fly prepaid sims for these kinds of trips.

As for the times I had to use a VPN over wifi, I did some more research and learned that Astrill is still a reliable provider. As of late, ExpressVPN seems to have become mostly unusable in China based on my research, though I didn’t try to use it personally during this trip. Anytime I had to use Astrill (which I typically used in their Wireguard mode), my speeds were extremely slow (1-2 Mbps) compared to what I’d get tethered to my smartphone AIS connection. Also my VPN would disconnect at random times – sometimes it would work reliably for a half-hour or more, and other times it would disconnect every few minutes. So my advice is if you don’t need to stream a lot of data, it would be far more convenient to rely entirely on smartphone tethering for your internet needs, assuming you’ve got good cell data coverage in the area you’ll be visiting. For any major city in China, this will be a non-issue.

An unrelated observation I had while in Beijing was that none of the locals used cash – everyone paid for things using WeChat Pay.
Unfortunately, you can’t link a foreign debit card to your WeChat Pay account – it only works with cards issued by Chinese banks.
So I was often the annoying foreigner who paid for things with cash. At one bakery, they even refused to break a 100 RMB note (worth around $14 USD) because they didn’t have enough change in their register. Being able to use WeChat pay unlocks a lot of other conveniences you can use in China, such as Didi (their equivalent of Lyft/Uber) rideshare payments, bike rentals, etc. So if you’re going to be in China for a long time (e.g, over a month), it may be worth the effort to open a Chinese bank account and keep a small amount of money in it for use with WeChat Pay.

Last month I visited Beijing, China and had to work remotely during my trip. At work we rely on a number of Google services, so I needed a reliable way to circumvent the Great Firewall of China (GFW). After doing a decent amount of research, I learned that just running a SOCKS proxy via SSH is likely to run into problems, so I used a couple of commercial VPNs, as well as a private Shadowsocks server I had set up on various ports of a Digital Ocean droplet. The idea being to have a couple of fall-back methods to tunnel through the GFW in case my primary one stopped working. I thought it might be useful to report on what worked well, and what was most challenging about this.

Given that I’m a Linux user and needed solutions that were Linux-friendly, I settled on two highly recommended commercial VPNs – ExpressVPN and Astrill. I also sprung for the added “VIP” add-on to Astrill that gives you access to a few additional VPN endpoints that presumably have lower utilization. In summary, Astrill was the clear winner, especially with the VIP add-on. Though no matter which VPN service I was using, there was a lot of fiddling that had to be done to test the latency of different proxy endpoints. There wasn’t one I could just set and forget.

Finding usable wifi in Beijing is another story, and proved to be a frustrating problem. My local resident friend told me that the Chinese tend to use the internet for recreation rather than getting work done, so the vast majority of folks packed in coffee shops are streaming video to watch movies or TV shows. My own observations backed this up, and it was easy to notice this, as a sizable proportion of these folks don’t bother to use headphones when watching their entertainment (grumble). So I found the only times I had really solid wifi speeds were when I found a coffee shop that was mostly empty, and probably half the time I gave up on the wifi and just tethered to my phone’s data connection. For most of my work I was running remote builds over SSH, and I found my phone’s data connection was laggy in a more consistent way than when I tried to use wifi in a busy cafe.

Regarding SIM cards in China, I have some tips to share as well. I ended up buying a prepaid China Unicom SIM with 2 GB of data from Amazon before I left for my trip, which was incredibly convenient. The way this works is you buy the SIM online, they send it to you, and you have to activate it over email with the seller. Once the SIM is activated, the 90-day lifetime of the SIM doesn’t start until you actually begin to use it, so you can complete the activation well before your trip and then pop the SIM card into your phone once you land in China. I have no complaints about dealing with the seller LvyCom on Amazon and would definitely recommend them.

So how was ExpressVPN? Decent and reliable, but not especially fast. I found it helped significantly to change the connection type from “auto” to “udp”, but Astrill’s Openweb connection type still beat it when it came to speeds. But to set expectations – generally the speeds were still slow. My friend had an 80 Mbit home internet connection which I tested without the VPN enabled, but once I enabled a VPN, the best I could get from it was around 3-5 Mbit. This was generally only good enough to watch YouTube videos at 480p. My friend was quite surprised when I told him I always watch YouTube at home at 1080p resolution with no hiccups or delays.

Shadowsocks turned out to be the least reliable method of tunneling out of China, sometimes working well and sometimes not working at all. Since it’s a lot of extra effort to set up a Shadowsocks server compared to just using a commercial VPN, I don’t think it’s necessary unless you want to have that extra peace of mind.

Overall I was able to get work done while in China, but it was regularly a frustrating experience to deal with the lack of bandwidth and annoying latency on SSH terminal sessions. Oh, and bring good headphones if you plan to try to work from coffee shops!

Photos from my recent trip to Beijing can be found here. For news about the GFW and VPNs, I recommend greatfire.org.

The following originally appeared on the Yocto Project’s blog:

The Yocto Project’s developers have been working hard to improve the usability of our software, especially its “out of the box” user experience. One area that has admittedly been a thorn in our side is when users need to access the internet via a network proxy server*. I thought I’d take a few moments to explain the situation, why we don’t have a “silver bullet” solution yet, and how to work around it.

If your personal or corporate network doesn’t require you to use a network proxy to access the Internet, consider yourself lucky. Proxies complicate network communications, requiring special protocols (such as SOCKS) to pass your development computer’s packets out to the Internet and back. And while the “do one thing and do it well” design philosophy of Linux/Unix programs has allowed these utilities to weather the test of time extremely well, there is no universally adopted method of modifying the networking behavior of these programs when it comes to using proxies. Here are but a few methods Linux programs can be made to use a proxy server:

• Some utilities check for a special environment variable (HTTP_PROXY, HTTPS_PROXY, FTP_PROXY, etc)
• Many desktop applications (e.g, GNOME apps) look for a proxy settings key in their global desktop registry
• Others (like Subversion, or Mozilla Firefox) have their own config files or internal configuration dialogs where you have to specify proxy settings
• Finally, some programs don’t contain any code for working with network proxies at all! In this case, you can sometimes get away with running the program under a separate, wrapper program which intercepts its network communications and automatically routes them through your proxy (tsocks is one of these wrapper programs)

I’m reminded of the saying: “Standards are like toothbrushes – everyone has one, but no one wants to use anyone else’s.” Truth be told, there is really no single solution to the proxy problem.

Another issue that poses problems for Yocto Project developers is that many of the proxy configurations for various tools (such as Subversion) are stored in the user’s own home directory. And modifying configuration files in your home directory is not something that will endear us to many users.

So what do you need to do to work with the Yocto Project behind a network proxy? Rather than filling this blog post with configuration tips, I’ll refer you to our wiki page, Working Behind a Network Proxy, where we make every effort to keep up to date with configuration tweaks needed for network proxy users.

If anyone can devise a way of reliably automating this process into a support script we could ship with the Yocto Project, we would be very open to including it. Just keep in mind that the script’s actions cannot clobber other config customizations a user may have, and would need to be fully reversible, to work for users who need to move in and out of proxied network environments.

* Note: a network proxy is different from a “firewall” – Yocto builds should work fine when run from behind a typical firewall router. Sometimes the terms “proxy” and “firewall” are used interchangeably, but they are quite different concepts.

I’m working with Debian Sarge (stable) on an embedded Linux device at work, and recently wasted a lot of time tracking down problems with DHCP. Specifically, the client was changing IP addresses intermittently during a DHCP lease renewal – not cool. So I put the device behind another Linux system running its own DHCP server, and found the following clue in the logs:


dhcpd: DHCPDISCOVER from 00:d0:c9:9e:ae:59 via eth1
dhcpd: ICMP Echo reply while lease 192.168.1.215 valid.
dhcpd: Abandoning IP address 192.168.1.215: pinged before offer
dhcpd: Wrote 0 deleted host decls to leases file.
dhcpd: Wrote 0 new dynamic host decls to leases file.
dhcpd: Wrote 9 leases to leases file.
dhcpd: DHCPDISCOVER from 00:d0:c9:9e:ae:59 via eth1
dhcpd: DHCPOFFER on 192.168.1.210 to 00:d0:c9:9e:ae:59 via eth1
dhcpd: DHCPREQUEST for 192.168.1.210 (192.168.1.1) from 00:d0:c9:9e:ae:59 via eth1
dhcpd: DHCPACK on 192.168.1.210 to 00:d0:c9:9e:ae:59 via eth1


Interesting… Some research (and help from the folks on the GNHLUG discussion list) uncovered that the client was sending a DHCPDISCOVER while still using the old address. When a DHCP lease is being renewed, the client is supposed to send a DHCPREQUEST, not DHCPDISCOVER.

So why on earth was it doing this in the first place? My only explanation is that the dhcp-client package that Debian Sarge comes with (v2) isn’t following the specification correctly. I have no idea how old that package is, but I do know that nearly all of the modern Linux distros I’ve used for years come with dhcp3-client. Fortunately, the Debian stable repositories include dhcp3-client – it’s just not the default client!

The lesson from all of this?: don’t assume that just because a package is in Debian’s default stable install you can take its correct operation for granted.