As I’m currently in the airport, waiting for a flight back to the UAE, I thought I’d share this small snippet of transparency vs secrecy.

As most China users will know, there is no official agency that “blocks” websites. In fact, most of the time, the government states that sites are not blocked, despite fairly obvious proof to the contrary.

China typically asserts that “connection resets” to sites like Facebook and Youtube are just network issues, despite those network issues solely appearing at the ip addresses associated with the government firewalls at the gateway routers to overseas.

Here in the UAE (Dubai), the government still blocks, but at least they’re upfront about it:
See below for an example of a blocked site

Why is this important?

Transparency is a big problem for western entities doing business in China. As with the recent Google PR stunt/debacle, most companies have no real mechanism for dealing with arbitrary judgements for / against things that affect their business.

A clear and transparent mechanism for dealing with why sites are blocked, coupled with a delisting mechanism would be a good place to start. It would also help to defuse the detractors against censorship – although most countries censor, China is one of the usual scapegoats picked on.

Maybe if China implemented a what (was blocked) / why (it was blocked) / how (to get unblocked) system, detractors would have less to complain about.

Lawrence.

Although most of my friends are using 3G/s now, I do get the odd 2G phone to play with.

Today I had another crack at enabling MMS on a 2G. For some reason not much documentation, and too much misinformation out there on the net.

Guaranteed working instructions for China Mobile users below:

Install 3.1.2
Jailbreak with usual steps.
Add cydia.ifoneguide.nl in Cydia / Sources
Wait a bazillion years for cydia to timeout with the various blocked in China repositories.
Click Search
Download Activate 2G MMS
Reboot

Normally we’d be done, however the MMS settings won’t let us save a diffferent MMS and GPRS name, so we need to install a specific IPCC (iPhone Carrier Setting file) for China Telecom.
As China Telecom is (at time of writing) not an official iPhone supplier, they don’t have an IPCC file, so we need to roll our own.

Here’s one I found earlier – ChinaMobileCarrierSettingsWithMMS.zip

Download that, unzip, and throw on the desktop.

We’ll need to tell iTunes that its ok to use the IPCC file first, so close iTunes.
Now head off to terminal (or a DOS window for those on Windows), then paste this in.

Mac users:
defaults write com.apple.iTunes carrier-testing -bool TRUE

Windows users:
(32 bit)
“C:\Program Files\iTunes\iTunes.exe” /setPrefInt carrier-testing 1

(64 bit)
“C:\Program Files (x86)\iTunes\iTunes.exe” /setPrefInt carrier-testing 1

Done?

Ok, now open iTunes again, connect the phone if its not connected, and..

Mac Users:

Press + hold down Alt(option), and Click “Update”

Windows Users:

Press + hold down shift, then Click “Update”

iTunes will prompt you for a file.
Choose the IPCC file you downloaded.

Sync the phone.

Finally… shut the phone off again.

Once you power up again, you should be able to send/ receive MMS!

If its not working for you, check that the settings are in there –

Settings / General / Network / Cellular Data Network

(anything not listed below should be empty)

Cellular Data
APN -> cmnet

MMS
APN -> cmwap
MMSC -> http://mmsc.monternet.com
MMS Proxy -> 10.0.0.172
MMS Max Message Size -> 300172

Tested, and working on 2 x 2g iPhones!

New rules are now in place that restrict applications for Chinese domain names (anything ending in .cn)

CNNIC issued new guidelines for registrars and hosting companies on January 6th / 2010.

Roughly translated, these state:

CNNIC (China’s Internet Domain Government Agency) wishes promote the standard and healthy application of .CN domain names.
CNNIC aims to coordinate with China’s review mechanism for domain name registration information and further crack down on registration of domain names with false information.

What this means in non-government-speak is that from now onward new .com.cn and .cn domains cannot be registered unless you are an officially licensed entity within China.
Existing domains can be renewed for the meantime though (pending verification of details/validity).

This has been in process since mid December, as individual registrations were the first to get blocked

Chinese domain name supervision organization China Internet Network Information Center announced that starting from 21:00 on December 14, 2009, it closed domain name registrations for individual users who are not purchasing domains on behalf of companies or organizations. Prior to this sudden announcement, China’s central television station criticized domain name registration service providers and agencies for false, inaccurate or incomplete information in the registration process.

More here on that here – http://www.chinatechnews.com/2009/12/21/11239-chinese-measures-will-regulate-website-domain-name-registrations

Entities wishing to register domain names for others will need an ICP许可证 (ICP Xu Ke Zheng).
The ICP许可证 is a commercial licence, which is different from an ICP备案 (ICP Bei An).
We will also be subject to new requirements for new domain registrations (China loves paperwork!)

The Notification about further enhancement of auditing domain name registration information

In order to further enhance the authenticity, accuracy, and integrality of the domain name registration information, now notify as following:

1. Domain name applicants need to submit the formal paper based application material when making the online application to the registrar. The application material includes the original application form with business seal, company business license (photocopy), and registrant ID (photocopy).

2. Registrar should carefully review the application material. When application is deemed qualified, registrar need to submit the application material via fax or E-mail to CNNIC, and withhold the original application material.

3. From the day of the submission of online application, if CNNIC does not receive the formal paper based application material within 5 days or the application material auditing is not qualified, the domain name to be applied will be deleted.

4. The above regulations will be executed since 9:00AM (Beijing Time), Dec 14th, 2009.

If you have any question, free to contact us at 86-10-58813000 or email to service@cnnic.cn.

Existing ICP Registrations
In addition to these new rules, all existing domain registrations are being scrutinized carefully, and all details are being verified.
As we have been quite proactive in ensuring that all clients have ICP licensing, and keeping our upstream ISP / contacts at Shanghai Telecom advised of anything information they require ahead of time, we expect that this will cause minimal disruption to our services.
If we do need to verify additional information from clients, please be prompt in forwarding them to us if we do request them, to avoid issues.

New ICP Registrations
Due to the above checks, new ICP registrations (which are required for any domain hosted in China) are taking substantially longer than the normal 2-3 days. We are currently seeing delays of up to 2 months for new license applications from the MII (Ministry of Information). We deal with the licensing bureau’s on a daily basis, and are notified quickly in case of issues, but the current checking requirements are just making everything take rather longer than is usual. We ask clients to be patient while their ICP registration is in progress. We are aware that it is not an ideal situation to have to wait for a few weeks, but we are dependent on the government issuing body, who are very very backlogged with work right now. License applications that are currently in process can be checked by clients at the government website here – http://www.miibeian.gov.cn/chaxun/ggcx.jsp.

Computer Solutions client ICP Registration site is here – http://icp.computersolutions.cn/. New clients can register a user account on our ICP site, and submit an application form from our site.

Noticed that our incoming TLS connection queue was a little high – running at 60 concurrent connections for an hour or so.

A check of the queue revealed that all the connections were coming from a single IP – and were tying up the queue, making it a denial of service attack. This one ip address was connecting and reconnecting multiple times, hogging up all the connections.
Read more »

Although I’m loathe to call ourselves a corporation – we’re not!, we do try to do the odd bit of good for the community, whether locally, or regionally.

Last year saw our first donation to the Library Project. The Library Project is a worthy cause, and donates books and libraries to under financed schools and orphanages in the developing world.

Computer Solutions donated funds for a Library, which ended up going to Chen Jia Gou Elementary school in Shaanxi province.

Link to our donated library here – http://www.library-project.org/libraries/chen_jia_gou_elementary_school.html

We also donate support to a more local cause – LifeLine Shanghai.

Computer Solutions has been providing complementary IT, and Web Services for a number of years now for Lifeline. Last year, after a few months of persuasion they finally agreed to let us redesign their existing volunteer created website too.

Our design team took note of LifeLine’s requirements, and came up with something more visually appealing, with a clearer layout and site structure. Visit their site here – http://www.lifelineshanghai.com

Lastly, we also support a cause which donates items and books for schools up in Qinghai. We’ve previously donated computers, funds, and other items to help out. More info about that here: http://www.tonyphotoshop.com/forum/index.php?topic=4.0. Do your part too, and help out, donations of clothes and other items are very welcome!

Lastly, if you are a charity organization in Shanghai, or China, and would like us to assist you in some way, please contact us. We’re more than happy to donate our services to worthy causes.

One of my friends brought round a notebook for me to Hackintosh yesterday. Unlike the usual god no… kind of options I get given, this is actually a nice machine.
This one is almost as Mac friendly as my current Nano sized Hackintosh (aka Loz’s Hackbook Nano)

I present the next best thing in Mini Mac’s (until the will it? won’t it? Mac Tablet comes out!) – The Samsung N310

The Samsung is a generic Atom based Netbook with the following hardware:

CPU Intel Atom N270, 1600 Mhz
Chipset Intel 82945GSE Graphics Controller
Graphics Card Intel GMA 950
Audio Realtek ALC272
Wifi Atheros AR5007EG Wireless
Ethernet Marvell Yukon 88E8040 PCI-E Fast Ethernet
Bluetooth Adapter USB Based Generic
Webcam USB Based Namuga 1.3M

Installation is remarkably easy.
You’ll need the following things – an External USB DVD drive, and Snow Leopard.

Download the latest NetbookInstaller ISO from here – http://osx.mechdrew.com/downloads/
Burn to CD. Connect your USB drive to the N310, and boot off of the newly burned CD.

Follow the instructions to swap with your Snow Leopard DVD at the appropriate time, and boot into the installer.
Install as normal (in my case, I just wiped the existing partitions, set the boot type to GUID instead of MBR in Partition, Options, and did a full install)
Once the OS reboots, boot from the NetbookInstaller ISO again, but this time choose the HDD (as we still need to install a valid bootsector for the OS to run)

The OS should boot up ok, fill in the relevant bits and pieces, and get to the desktop screen.
Open up NetBookMaker from the CD, navigate to the Tools folder and open NetbookInstaller:

I did this using 0.8.3RC4, but newer versions should be similar.
Click Continue for the Unrecognized Hardware Prompt.

Choose the correct disk in the Volume Dropdown, and
Check Install Chameleon 2 RC3
Check Install General Extensions
Check Generate a System Specific DSDT.AML file.
Uncheck everything else.

Click Install.

It should trundle away for a few minutes, then recommend you reboot.

Remove the NetbookInstaller DVD, and make sure that you can reboot ok from the Hard Drive

Right now you should have working Webcam, Video, Bluetooth, and Trackpad will support 2 finger scroll (go to System / Preferences/ Trackpad to configure)

We’re still missing Wifi, Audio, and you’ll notice that sleep doesn’t quite work yet.
To install those, we’ll need to download some extra Kext’s, and replace the wifi card.

Wifi – the original card is a crap atheros. I couldn’t be buggered looking for drivers, and immediately swapped it out for a Dell1390 Broadcom card. Cheap, and the same as real Macbooks, so no driver issues.
The N310 is reasonably easy to disassemble, just remove all the plastic plugs underneath (including the larger feet ones), and remove the screws. Gently remove the case bottom, and replace the wifi card.
If you use the Dell1390 you won’t need to install any drivers, they’re built in, yay!

For the remaining drivers, see below:
Audio – As I’m a nice person, I’ve uploaded the working driver here – http://www.kexts.com/view/182-alc272_%28snow_leopard%29.html
Sleep – Go to http://www.superhai.com/darwin.html, and download the 2 Snow Leopard kexts (VoodooBattery.kext, VoodooPowerMini.kext).

Download those to the desktop, unzip the kexts.
Copy to /Extras/GeneralExtensions, then rebuild the Extension cache.

You can do that manually or use a tool. NetbookInstaller nicely places a program called UpdateExtra into the /Extra folder which can rebuild the Extension cache for you.

Thats pretty much it!

If you are having problems with the laptop waking from sleep:
I’ve uploaded a DSDT.aml for the n310 here – DSDT.aml. you’ll need to rename it so that the .N310 is removed, and copy into the root folder over the existing DSDT.aml that NetBookMaker may or may not have created. I’d appreciate comments as to whether this works for you or not.

Iain in the comments thread was nice enough to email his working sleep DSDT.aml file, can some people try both and see if either work for them? Also check the BIOS settings as per Iain’s comment: Enabled EDB. Disabled Legacy USB Support. Enabled USB S3 Wake-Up

Download his DSDT.aml here. To use, rename file to DSDT.aml, and copy to /Extra, then reboot.

Note: If you do mess around with DSDT.aml files, please have a working recovery method available that you can access the hard drive with (eg an OSX Install DVD + Boot132 CD). Apple’s install DVD can also be used for recovery.

If you find that you can’t boot after installing the DSDT.aml, boot from the Boot132 CD or USB, then boot into to the OSX install DVD. Go to terminal in the installer, and delete the offending file, then reboot.

Now you should have a fully working Samsung N310 running OSX Snow Leopard!

I haven’t bothered messing around with the brightness or volume stuff, but the volume on/off keyboard functions work, as do the trackpad on/off.

Good luck with yours!

Useful links:
http://www.kexts.com – kexts (drivers) for OSX
http://www.superhai.com/darwin.html – Power related drivers for OSX
http://osx.mechdrew.com/ – MechDrew from MyDellMini’s site on Hackintosh Installs
http://cid-8b65993ef55cf014.skydrive.live.com/browse.aspx/.Public/OSx86/Snow%20Leopard – some Czech site hosted on live.com full of goodies/ kexts

Apple used to have info about where phones came from on their website, but for some reason have now deleted that info.
Below is a list of verified unlocked part numbers.

Hong Kong

MB489ZP/A 8gb blk
MB496ZP/A 16gb blk
MB500ZP/A 16gb white
Read more »

Seems that when it rains, it pours.

The gods were not content to give us only one issue today from an external provider, but two!

At approximately 7pm the network that includes our mail server was on got hit by a massive denial of service attack.
The nice people at Shanghai Telecom decided that they would simply shut off routing for the entire subnet as their optimal solution.

We have a nice graph of that happening here:

Note the sudden precipitous drop in network traffic starting at approximately 7pm, which lasted until approximately 8pm.

We also have images of the DoS attack [although not completely, as our network was null routed (shut off) for the brunt of the attack]

You can see the sudden increase in incoming traffic in this image below (which occurred before they killed the network completely).
The green line which indicates incoming packets suddenly goes sky high before the network people shut off the network.

Some of the other servers also got hit by this – notable our web servers, although they didn’t cut those off thankfully.
See below for a view of that traffic.

As the old curse goes – may you live in interesting times.
Some days are more interesting than others!

Early Monday morning it was bought to our attention that some clients could not receive mail, and others were having difficultly reaching their subdomains.

Investigation of the issue showed that the affected clients were missing DNS records.

Our DNS services are provided by a 3rd party – ServerBeach.
ServerBeach recently got bought out by a larger company Peer1.

The geniuses at Peer1 have managed to lose all our DNS info for over 400 of our domains during a migration from ServerBeach to Peer1 provided services, and now a substantial number of our clients have missing or incomplete DNS records.

They are aware of the issue, and are working on it.

We received an email notice about this this morning (after 7 or 8 hours of their DNS being offline)

Dear ServerBeach Customer,

At approximately 11:30am CST today we encountered an issue with our DNS services being imported into the new ServerBeach portal. This may be causing an interruption for certain domains that are hosted on the GeoDNS servers.

We are currently working diligently to correct this issue and will provide an update when DNS services are fully functional.

All of us at ServerBeach sincerely regret the inconveniences associated with this incident, and will fully stand behind our Service Level Agreement. We apologize for this disruption and thank you for your continued patronage and understanding.

If you have any questions regarding this issue, please open an online ticket athttps://my.serverbeach.com/ or contact our support team at 1-800-741-9939.

Regards,

Brian Daffern
Director of Support

We have raised a number of tickets with ServerBeach / Peer1 regarding this, and hope for a speedy resolution to the matter.

As an interim measure I’ve added forwarding records for domains affected, so that mail received on the webservers that host affected domains know to forward mail to the correct mail server.

ServerBeach is updating a forum post regarding this issue here:
http://forums.serverbeach.com/showthread.php?t=7919
(Note that in the second post they incorrectly say it has been resolved. It has not been resolved yet)

If ServerBeach / Peer1 cannot resolve this by this evening, we may have to look at changing to a different DNS provider.
This is a last resort measure though, as DNS server changes take 1-2 days to propagate throughout the internet.

Apologies for any inconvenience, and we hope you can bear with us while we resolve the situation.

If you have any questions, please address them to our support email: support at computersolutions.cn

Setting up OpenVPN was a real PIA for a number of reasons DNS, crap documentation, and general issues with vpn clients.

My working notes are below:

Install OPENVPN from tar.gz or apt-get install…
Generate key’s etc (tons of other tutorials on that)

Prelim info
My vpn server has a static ip address, in the 66.xx range. Our local client machines use a 192.x range (typically).
I setup a tun address for 10.1.0.1 for the server.

As we don’t want to have routing issues, I set openvpn to use the 10.x range for any vpn connections.
(Essentially all clients connected to the openvpn ip will get a 10.1.0.x address).

I also force clients to use our DNS server (more on that later), as China does some DNS lookup interceptions which break stuff if you are using a tunnel. I also don’t use openvpn on the standard port 1194, as I was seeing mysterious tcp resets when using the common vpn ports. Amazing how that happens in China. Lastly, I’ve put in on port 8080 for our users, as this seems to work without issue.

To do all that, I created an openvpn.conf file with the following:

port 8080
#proto tcp
#dev tun
proto udp
dev tap
ca keys/ca.crt
cert keys/server.crt
key keys/server.key
dh keys/dh1024.pem
server 10.1.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
keepalive 10 120
comp-lzo
user nobody
group users
persist-key
persist-tun
status /var/log/openvpn-status.log
verb 3
client-to-client
push "redirect-gateway"
push "dhcp-option DNS 10.1.0.1"
link-mtu 1456
mssfix 1412
cipher AES-256-CBC

(You can read the standard install stuff for your own key generation)

Next we need to tell our server to route stuff appropriately for vpn traffic

echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -A INPUT -p udp --dport 8080 -j ACCEPT
iptables -A INPUT -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT
iptables -A INPUT -i tap+ -j ACCEPT
iptables -A FORWARD -i tap+ -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.1.0.0/24 -o eth0 -j MASQUERADE

(You’ll need to change the 10.1.0.0 to your actual vpn user subnet if you change in the openvpn.conf)

OpenVPN should start, and be connectable.

My client config looks approximately something like this:

client
dev tap
proto udp
remote mysupersekritvpnserver.com 8080
comp-lzo
verb 3
mute 20
nobind
persist-key
persist-tun
cipher AES-256-CBC
ca ca.crt
cert my.crt
key my.key

my.crt, my.key, ca.crt should be copied / generated from the server, and copied over to the client machine.
mysupersekritvpnserver.com should be changed to your server name.
We use Mac’s mostly, so we use tunnelblick, copy that config in, check the “Set NameServer” box in Details.

You should be able to connect now and ping remotely with that.
Next, we need to setup DNS

For the longest time I couldn’t get this working, despite me reading and re-reading the doc’s.

We use dnscache for dns lookups on our servers. DNS Cache allegedly allows lookups from other ip addresses by sticking whats allowed into /etc/dnscache/root/ip

This wasn’t working at all.

Eventually I twigged that dnscache binds to one ip address, and ignores the others, which is why local lookups worked, but tunnel started ones didn’t.

Took me a while to see that though. Was only when I did an nmap 10.1.0.1 and saw port 53 was closed, that I realised, despite the misleading fscking documentation which says “just add the ip address for the computers allowed to connect” to the dnscachefolder/root/ip, you really need to bind it to all the ports you will want lookups to work for.

Which is not clearly mentioned in any documentation I saw on the net.

I ended up making another dnscache specifically for our tun address on 10.1.0.1, and telling it to allow queries from the actual server ip 66.x, and from 10.x, *then* it started working.

Hours of fun and joy.

Worth it though, I can now connect to bookface and toobyou, yay!