A way to fix DD-WRT can not run on some Linksys EA2700 router

I have a Linksys EA2700 router, the original firmware functional very limited, I like to use this router as a wireless repeater and a giga switch for the computers near by it. So of course, DD-WRT is the best choice. The problem is, although I am a long time DD-WRT user, no matter how I try to flash DD-WRT firmware, testing any different version, I could not have it run on my ea2700, after several reboots, it return to the original classic firmware.

I wired the serial port pints out, try to figure out what was happening. Update firmware from classic firmware web ui, during booting, log show something like this:

List of all partitions:
1f00        512 mtdblock0 (driver?)
1f01       1536 mtdblock1 (driver?)
1f02      18432 mtdblock2 (driver?)
1f03    4175864 mtdblock3 (driver?)
1f04      18432 mtdblock4 (driver?)
1f05      16524 mtdblock5 (driver?)
1f06      25600 mtdblock6 (driver?)
No filesystem could mount root, tried:  squashfs ntfs fuseblk
Kernel panic – not syncing: VFS: Unable to mount root fs on unknown-block(31,5)

and something like that:

nand_read_bbt: Bad block at 0x00c84000

I mean, it seem that NAND had some bad block, that could not be read during booting, using web UI to update, it said it is succeeded, but I doubt it. Then I try to update firmware using CFE way and tftp, before tftp upload finish, CFE report that

 I/O error
*** command status = -4

This error could be repeated. So I think the part of NAND is damaged. The problem is, I could upload linksys classic firmware success every time!

The original firmware size is 13M while ddwrt is 17M. So I figure out a way to modify DD-WRT firmware, remove some unnecessary ‘big’ modules and resources, repack the firmware @ 12M. Upload by tftp, it works for me!

cat /proc/partitions

major minor  #blocks  name
  31        0      30720 mtdblock0
  31        1      31744 mtdblock1
  31        2        512 mtdblock2
  31        3       1536 mtdblock3
  31        4      30720 mtdblock4
  31        5      29518 mtdblock5
cat /proc/mtd
dev:    size   erasesize  name
mtd0: 01e00000 00004000   namelinux;
mtd1: 01f00000 00004000   nameddwrt;
mtd2: 00080000 00004000   namecfeot;
mtd3: 00180000 00004000   namenvram;
mtd4: 01e00000 00004000   namenandimage
mtd5: 01cd3800 00004000   namerootfsage

I know that mtd table looks strange, but most function works as expected.

Here is the way of how to modify DD-WRT firmware. Hope this could help

Posted in tech | Tagged , , , , | 1 Comment

How to Unpack/MOD/Repack A DD-WRT trx Firmware

DD-WRT firmware is packed as ‘.trx’. The purpose of document is to to show you how to MOD a DD-WRT package, without recompile it from source. All the tool need is a virtual-boxed ubuntu, DD-WRT svn source code, a hex editor, HxD .

A MOD firmware may brick your device, so make sure you know what you are doing by googling enough before apply changes to the router. Doing this on your own risk.

There is one obvious way to modify the package is, to download and modify source code/script, recompile from source code, repack firmware. But it seems to me that DD-WRT maintainers are not very please sharing their build system, the best resource is could found is Compiling DD-WRT. It was a miserable process for me, I don’t know which module need to be built for EA2700 and endless error shows up, when trying to read/modify configuration, guessing, building. I spent a whole weekend keep failing, not even able to run through the configuration. So I gave up this way.

I also found a tool Firmware Mod Kit, but seems that it is out of maintenance, at least not for me.

During the building attemptsssssssssssssss, I acknowledge that for EA2700, the main build script is src/router/Makefile.brcm3x, I was thinking that there must be packing process in this script, so if I want to unpack, I shall be able to find some clues of how the package generated. Here is some piece of code from Makefile.brcm3x:

gzip -c9 mipsel-uclibc/lzma_vmlinus > mipsel-uclibc/lzma_vmlinuz
../../opt/tools/trx -m 32000000 -o $(ARCH)-uclibc/dd-wrt.v24-K3-nandboot.trx $(ARCH)-uclibc/lzma_vmlinuz  -a 1024 $(ARCH)-uclibc/rootfs.squashfs

According to TRX Header, from openwrt,

  0                   1                   2                   3   
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
 |                     magic number ('HDR0')                     |
 |                  length (header size + data)                  |
 |                       32-bit CRC value                        |
 |           TRX flags           |          TRX version          |
 |                      Partition offset[0]                      |
 |                      Partition offset[1]                      |
 |                      Partition offset[2]                      |
  • offset[0] = lzma-loader
  • offset[1] = Linux-Kernel
  • offset[2] = rootfs

It seems that the trx is packing two files, lzma_vmlinuz and rootfs.squashfs. I also verify this by reading source code of trx.c. lzma_vmlinuz should be a gzipped Linux kernel and rootfs.squashfs should be the read-only rootfs, and that is my interest.

Open a prebuilt firmware, using Hxd, we can see the trx header very clear:


trx header

The first part, vmlinuz is at offset: 0x0000001c, the second part, rootfs, should be located at offset:0x0012c800, little endian.

If we just extract rootfs, we could ignore the first part, but as we need to repack firmware after modification, flash to router, without rebuilding from source, we need a standalone lzma_vmlinuz. As we can see in the previous script, lzma_vmlinuz is gzip compressed, so need to have some knowledge of gzip format.

 2.3. Member format

      Each member has the following structure:

         |ID1|ID2|CM |FLG|     MTIME     |XFL|OS | (more-->)

      (if FLG.FEXTRA set)

         | XLEN  |...XLEN bytes of "extra field"...| (more-->)

      (if FLG.FNAME set)

         |...original file name, zero-terminated...| (more-->)

      (if FLG.FCOMMENT set)

         |...file comment, zero-terminated...| (more-->)

      (if FLG.FHCRC set)

         | CRC16 |

         |...compressed blocks...| (more-->)

           0   1   2   3   4   5   6   7
         |     CRC32     |     ISIZE     |

gzip header

Gzip header is very clear, original file name is lzma_vmlinus, the problem is we don’t know where it ends. So we move to position: 0x0012c800, the second file, where rootfs starts:

rootfs head

lzma_vmlinuz ends here

0x0012c800 is where rootfs begun. trx tool padding some zeros to the to the end of each part, according to -a 1024 option. We could not tell exactly where vmlinus ends, but we can guess. According to RFC1952, gzip end with 32bits CRC32 and 32bits ISIZE, the original file size, so the last 4 bytes has meaning. 0x12cd48bc, is too big for a file size, while 0x000012cd is too small, but 0x0012cd40=1,232,200 sounds reasonable. So we copy from offset 0x1c to 0x12c739, open a new tab from HxD, save to a new file, name it ‘vmlinuz‘, using 7zip on windows or gzip on linux to decompress it, check if the guess is correct. In this way, we had lzma_vmlinuz exacted and verified. We don’t really need to decompress lzma_vmlinuz, ’cause we do not actually modify it.

From 0x0012c800, to the end of file, save as another file ‘rootfs.squashfs‘, we could consider it as rootfs, but how to exact and  apply a MOD? Here is another piece from Makefile.brcm3x:

$(LINUXDIR)/scripts/squashfs/mksquashfs-lzma $(ARCH)-uclibc/target $(ARCH)-uclibc/rootfs.squashfs -noappend -root-owned -le

It is said, rootfs.squashfs is a, LZMA compressed, SQUASHFS file system. So how to exact rootfs? I don’t do much reading of SQUASHFS file system spec, I found the source code of mk/unsquashfs-lzma. OK, just build this tool on Ubuntu by typing ‘make‘, you get both tools of mksquashfs-lzma and unsquashfs-lzma. That is way much easier than building DD-WRT. Now we have tools of packing and unpacking squashfs image.

./unsquashfs-lzma rootfs.squashfs

The result is a directory (default name ‘rootfs.squashfs‘, I don’t remember, see help) tree of run-time read-only Linux rootfs:

rootfs tree

I was so exciting about what I saw. The original unpack size is more than 49M. Now we could start a MOD. As my purpose is to reduce size of the whole package, I located big files and relate resources, which I assure unnecessary, remove them from directory tree. You could also add new tool, modify init script, modify services, make symbol link, whatever you needed, I think.

After modification, the last step is to repack it. Things are straightforward:

# packing rootfs.squashfs image
sudo ./mksquashfs-lzma rootfs.squashfs -noappend -root-owned -le
#packing firmware. if you do have trx tool, just build it yourself
sudo ./trx -m 32000000 -o new.trx vmlinuz  -a 1024 rootfs.squashfs

Then you can try upload new firmware using Web GUI, or serial recovery, if you already have serial pin out. The web page including all necessary resource to flashing DD-WRT to router by serial port, but  maybe out of date, I actually using :

flash -noheader : flash1.trx

to flash Linksys ea2700 router. Flashing firmware, especially a MOD version, using CFE, maybe dangerous, but as my understand, as long as CFE is not damage, Linksys router always has a backup ‘known good’ firmware on the other partition, which will automatically recover to active partition, if active partition boots failed for several times, that is why peoples reported that sometimes their Linksys router return back to original factory firmware during flash DD-WRT.


I share a Dropbox folder here, including some tools (I built on Ubuntu 16.04 LTS) and a MOD firmware for Linksys EA2700. I did not list what I remove, but you can always unpack ‘dd-wrt-30949-ea2700.MOD.trx’, then compare rootfs directory tree to the original version download from ftp.dd-wrt.com.

Posted in tech | Tagged , , , , , , | 1 Comment

Share:Wireless protocols showdown: Why not Wi-Fi?

Original link: https://blog.silvair.com/2015/10/01/wireless-protocols-showdown-3/


As promised, with this episode we’ll start reviewing each of the leading connectivity solutions one by one, sharing the lessons we’ve learned while exploring their capabilities and limitations. And what else could we start with but Wi-Fi, arguably the most globally recognized wireless networking technology. According to the Wi-Fi Alliance, the standard carries roughly a half of all Internet traffic for billions of users worldwide. It’s most commonly used to provide computers, smartphones and tablets with a quick a reliable Internet access, but it can theoretically connect any two devices to enable the exchange of data between them. Widely used in private homes, offices and public spaces around the entire globe, Wi-Fi might seem to be perfectly positioned to take the early IoT market by storm. And while the dust is far from settling in the IoT communication standards war, this powerful technology is clearly nowhere near the top of the list of today’s hottest connectivity solutions for the Internet of Things. So what went wrong? Let us break it down for you.

The Wi-Fi technology is based on the family of wireless networking standards IEEE 802.11x. They define only the first two layers of the OSI reference model – the physical layer and the data link layer (a quick introduction to the 7 layers of the OSI model can be found in our previous blogpost). As far as the network and transport layers are concerned, Wi-Fi typically relies on other standard protocols, such as UDP or TCP (for transport) and IPv4 or IPv6 (for networking). Let’s see what this arrangement looks like on a simplified version of the OSI model:

WiFi on OSI

Note the empty space at the application layer, as we’ll get back to it later.

Wi-Fi is a powerful and reliable wireless connectivity solution that the technology industry has successfully relied on over many years.  802.11 has emerged as a global communication standard because it offered numerous excellent features, and was continually developed and improved by the Institute of Electrical and Electronics Engineers (IEEE). As a result of these efforts, multiple “flavors” of 802.11 were developed over time, with 802.11n being the most commonly used in today’s homes and offices. A Wi-Fi network has a star topology, which means that all its nodes connect directly to the central hub, e.g. a wireless router. With this arrangement, devices can be added and removed from the network without disrupting its entire structure and flow of data. Designed for the rapid exchange of high data volumes over reasonable distances, Wi-Fi does that job just perfectly. Basic parameters, such as range or data transfer rate, vary between different 802.11 standards, but a typical wireless router is usually enough to provide a decent network coverage for a standard apartment. In larger buildings, more access points or signal extenders can be deployed to increase coverage. As for the throughput, some versions of the 802.11 standard have the limit of 11 or 54 Mb/s, but the commonly used 802.11n is capable of transmitting hundreds of megabit per second, and 802.11ac is even faster. These numbers certainly look impressive, as the throughput of other wireless connectivity solutions for the IoT is expressed in kb/s rather than Mb/s. On top of that, one of Wi-Fi’s major strengths is the ubiquity of 802.11 infrastructure across the globe. The fact that it is commonly integrated into new laptops, smartphones and tablets is also extremely relevant from the perspective of IoT applications.

The features mentioned above is what made Wi-Fi the default technology for enabling wireless Internet access in our lives. It can easily transport high-definition video streams and its throughput limits are usually way higher than the needs of an average user. But the IoT is a completely different thing that the good ol’ Internet. Wi-Fi’s impressive data transfer rate is overkill for typical smart home/office applications, where instead of data-heavy content, devices broadcast simple commands (e.g. on/off), state-change signals or only tiny bits of information (e.g. sensor data). And while such overcapacity is not a big problem by itself, there is a cost for this enormous throughput. Being a high-bandwidth communication standard, Wi-Fi is also extremely power-intensive. This is a big problem in the resource-challenged IoT world, where multiple devices are supposed to operate without any wires. In the case of several other connectivity solutions, coin batteries can keep simple wireless devices running for years. But building a battery-powered Wi-Fi device that could last even one year with decent responsiveness is virtually impossible. The power-hungriness is obviously not a big deal if a particular device is connected to a power lead or wall outlet, but for all those applications where battery-powered operation is a must (e.g. sensors in remote places), Wi-Fi is just not capable of delivering a reasonable performance.

Further limitations arise from the topology of a Wi-Fi network. Reliance upon a central gateway to handle all the traffic has one major drawback – once a hub fails, individual nodes of the network cannot communicate with each other, essentially making the entire network inoperable. Of course you don’t expect your hub to go down all that often, but each such incident could end up being extremely irritating if all your light bulbs, door locks and garage doors belong to a single smart network.

As already mentioned, Wi-Fi can be found in every new smartphone or laptop on the market. Out of all the communication protocols aspiring to connect the IoT, only Wi-Fi and Bluetooth have this advantage of being natively integrated into our phones, making them ultimate controllers for our smart environments. However, in the case of Wi-Fi this potential cannot be fully realized. Even though a smartphone and a Wi-Fi device use the same language to communicate, this communication is not direct as it always goes through the network’s central access point. This is why Wi-Fi devices cannot use proximity sensing features that have become a trademark of the Bluetooth technology.

Given that virtually every potential customer has a Wi-Fi enabled phone, one could assume that setting up a Wi-Fi network of smart devices would be a piece of cake. It is a bit complicated, though. Before a smart device can be added to a Wi-Fi network, it has to know the password for this network. This is easy when you want to connect a laptop or a smartphone, but gets tricky when your device has no keyboard and no screen. It might seem that a smartphone could do the job, after all it also speaks Wi-Fi so why not use it to tell the device what the password is? This certainly can be done – but first the device has to be networked with the phone, which brings us back to where we started from. Manufacturers use various methods to make this setup process as easy and intuitive as possible, yet each of them introduces additional complexity and has certain drawbacks. The setup process is one of the biggest problems of the Wi-Fi technology in smart home environment where a flawless user experience is top priority. To address this challenge, some of the vendors have gone so far as to add microUSB ports to their smart devices solely for configuration purposes. While this effectively solves the setup issues, we are not convinced that light switches with USB ports is where we want to get with the IoT.

In the first episode of our series, we kept emphasizing that interoperability tops the list of challenges which need to be addressed for the IoT to realize its full potential. So what Wi-Fi offers in this regard? Not that much, unfortunately. As we already mentioned, Wi-Fi does not define the application layer, which means that machine-to-machine communication is basically impossible unless companies manufacturing two particular devices work in close cooperation to precisely define how they can communicate. Wi-Fi is often mistakenly considered interoperable, since we use it all the time to successfully enter into all kinds of interactions with each other. But all these interactions can happen only because there are humans on both ends of the communication process. Setting up a Skype conversation is what can be described as adding an ad-hoc application layer to the Wi-Fi based communication. Humans can do it by choosing the right tools and coordinating the entire process by themselves. “Things” can’t handle that, and for this reason Wi-Fi is a standard which by itself does not ensure any interoperability in the world of connected devices.

Finally, there is the price factor that always needs to be taken into consideration by manufacturers. Wi-Fi modules are relatively pricey, and although differences have decreased recently, they still remain between 50% to 100% more expensive than some of the competing radio modules used in connected devices. This is not something that can be easily ignored when drawing up mass production plans.

Now it must be emphasized that some of the disadvantages mentioned above apply to the vast majority of the leading communication technologies, just to mention the hub-based topology or the complicated setup process. But what really disqualifies Wi-Fi as the ultimate connectivity solution for the IoT is its power-hungriness. Despite numerous impressive features, it just cannot efficiently support wireless devices, such as sensors or controllers, which are an important part of what the IoT is expected to become.

There are certain scenarios where Wi-Fi can still get the job done really well. If you are a manufacturer of a device which needs a reliable connection with the cloud rather than with a dense network of other smart devices, and your product needs to be connected to a power lead or wall outlet anyway, and you manage to find a way to overcome setup challenges to make this process intuitive and user-friendly, and you don’t care all that much about the price of a radio module, then Wi-Fi becomes a totally reasonable solution for you. Otherwise, you should think twice. Wi-Fi is an excellent technology for performing data-heavy activities, such as streaming video content, and it is likely to cover this small fraction of the IoT space where such processes are required. But when it comes to smartening our homes and offices, there are simply more suitable solutions out there, the ones that were designed specifically to address the needs of the IoT. Next time we’ll take a look at one of them, so stay tuned.

Posted in tech | Tagged , , , , | Leave a comment


original is here


马基亚维里是意大利佛罗伦萨人,在佛罗伦萨城市共和国担任过国务秘书和外交官,后来佛罗伦萨的共和制被推翻了,美第奇家族执掌了权力,马基亚维里丢 了官,还一度被关进了监狱。他为了得到新统治者的青睐,东山再起,写了一本为统治者美第奇家族出谋划策的书,这就是著名的《君主论》。






但是也有人认为马基亚维里是清醒和真实的,他站在君主的立场上所说的实话恰恰反映了或者说揭露了专制制度邪恶的本质,在专制制度下,统治者必然要作 恶,马基亚维里要君主服从这“必然性的命令”,这个必然性对于人们认清专制本质有着积极的意义。恩格斯把马基亚维里称作文艺复兴的巨人,大概也是从这个角 度考虑的。





最高权力的执掌者也是凡人,没有孙悟空的本领,没有刀枪不入的神功,他的个人力量是极其有限的。他可以下令杀人,但也可能被杀。如果没有民意支持, 仅仅靠暴力手段进行统治,那掌握暴力的人就是他的最大的危险所在。古罗马帝国的皇帝害怕军队政变,把罗马军团都布置在帝国的边疆区,首都罗马只留忠诚的近 卫军保护皇帝,但后来恰恰是近卫军成了废立皇帝的决定性力量,一些皇帝就是被近卫军杀死的。中国的帝王死于非命的也大都是身边的权臣、宦官或兄弟所为,被 造反民众所杀的是极少数。


权力从来都不缺争夺者,专制权力更是如此,多少人为了夺权你死我活地拼杀,儿子可能杀父亲,母亲可能杀儿子,亲兄弟也互相残杀,更不用说没有骨肉关 系的政敌了。在统治者失去民意的情况下,他的政敌一定会利用这一点替天行道为民除害。所以,统治者一旦失去民意,就离覆灭不远了,起义、造反、政变、暗 杀、逼宫、废黜等大戏在等着他。中外历史上这种例子太多了,举不胜举。




在欧洲,在基督教没有获得统治地位之前,天意的权威没有确立起来,那时候罗马帝国的皇帝被杀被废的比例非常高。当基督教统治欧洲后,皇帝与国王由教 皇承认并加冕,由于大多数民众是教徒,如此使得君权神授被认可,天意代表了民意。中世纪君主的人身安全要比罗马帝国的皇帝强了许多。即使如此,君主们也不 敢掉以轻心,必须依靠谎言巩固统治。15世纪德国人古登堡的印刷术给欧洲带来了出版便利,所有国家的君主无一例外地限制言论自由和出版自由,他们尽管有天 意支撑,还是害怕谎言被揭穿,执政地位被动摇。












Posted in personal | Leave a comment

EPSON R270更换打印头 故障处理











Posted in personal, tech | Tagged , , , , , , , | Leave a comment

How to setup a personal proxy server inside the GFW

How the cross the fucking wall? VPN might be the best choose in the old time. But things are always changing. VPN provider banned by China gov one by one, or under attack, they are not that stable and available as before. They make themselves the targets, they are host spots on the internet like stars in the deep sky easy to trail and to make business  they have to let anyone to know the services they providing. Passive-security is never enough in the tough and dirty fight with China gov.

I have been use TOR for a while long time ago, it is never stable as expect and today it is useless at all against China Great Firewall.

I am using FreeGate for years, I have to say it is a loyalty company. Seem that it has strong enough technical background, always survived from GFW, both side upgraded from time to time, and FG is the winner in the end, for now . Another optional tool is Psiphon3, I been using this tools for the recent years, as a backup of FG. It is working well most time, not as stable but faster than FG, and Psiphon has a good free Android client, set the mobile phone free for Internet.

OK, my focus on this document is not the history, but practice of setup a personal proxy server step by step. Why we need a personal server? A personal server is private, low profile, catch less attention. It is not open to the Internet, just a secret gate for home. That will  keep you  head down, which make it much impossible to get notice by GFW. Surely you can share your server with trusted friends, but not always a good idea. And maybe the most importance is that  your  person proxy sever is available all over the China mainland, as I known, there is not way to break through the Wall in some parts of China, like Tibet, Xinjiang, I think they are unconditionally banned, not by GFW rule, and that is reasonable, there is no rule there, I mean normal rule. Also you could set up a personal cloud base on this infrastructure, with more security add-ins.

To set up a server, there are several parts of works:

1, choose the ladder: As I mentioned above, I choose FreeGate and Psiphon 3, one for major, one for back up. FG provide only HTTP proxy, local port is 8580 by default, Psiphon provide both HTTP and SOCK proxy, port could be setup by your self. You can’t setup the tool to run @ Windows startup.

2, A laptop running Windows 10. most Windows is fine, but sooner or latter it will upgrade to win 10 anyway, so why not switch to 10 by yourself. An importance software is proxy server, it will bind all local network interface and provide proxy function on those interface. A good proxy server is key choose. I choose FreeProxy. It is free though a little old, out of maintenance , not working very well on win10, but I really can’t found a better replacement. FreeProxy actually running in services mode, to configure FreeProxy, you need run the console as administrator, or you may not connect to the services. You need to add several proxy entries, enable them and done. For example, for FreeGate configuration:freeproxy congfigure.png

figure : example proxy entry setting

The last part need to modify the computer is to make it auto logon, that will make freegate  or Psiphon running automatically, may has some security problem here but as I said, it is a  private server, should not contain sensitive information or you have to using a really server level Os like Linux.

3.From now on, you can access to ladder anywhere in you local network, just setup any client software ‘s proxy server, pointing to the computer IP  @ port 9090.  But how to make the server accessible all over the mainland? Here are some sub steps:

  1. you need a router, which support NAT configuration. In China mainland, broadband provider give you  a free router, almost can’t be configured by user, they are managed  remotely by ISP. so you need a router, if it could support DDWRT, that would be much better. Anyway, the requirement is: supporting NAT. Setup NAT entry, mapping outer access to 9090 (as example  show) to you computer local IP port  9090, so that if you try to access 9090 port from outside network, the request will be redirect to computer running the services, port 9090, which is listened by FreeProxy entry “freegate” as the picture above shown. When I have to use ISP provided router, for some reason, it don’t support NAT setting, but at least it supports UPNP, I had wrote a small program which will setup Nat using UPNP, that is the best solution I could figure out before I bought Cisco EA2700. If you need, I could provide help, UPNP is not very stable, but it works in most time.
  2. Now you are on the run, but you external IP is a dynamic (each ISP PPP dialing will acquire a new one), will be changed for some reason like reboot the router, how could you know your current external IP when you are not at home? There  is not easy  way, the best solution is to setup DDNS service. That will bind a domain name to your IP, like a real DNS. You can google for dynamic IP provider, here I choose www.dtdns.com, it announces for free for good and most importantly, it is not banned by China. DTDNS has a web dash to setup domain name/IP mapping, also it provides a spec of how to update IP programmable.
  3. You should be able to cross the WALL from anywhere, if you correctly setup you client ‘s proxy setting. I had make a little program, running on server computer, it will be ran every 30 minutes(through Windows task scheduler), checking current external IP, if the IP has been changed, it would fire a request to http://www.dtdns.com, update the domain with new IP, so that if Ican’t visit my personal server, all I have to do is to sit tight and wait for no more than 40 minutes(some extra minutes needed for DNS cache flesh), and  it will back on line. Actually, DDWRT also has such services, but it is buggy for DTDNS, and to modify that will lead to a hard work to recompile the whole DDWRT, so I choose to make the one myself, just running on Windows, not the router.

4. Everything is set now, for the server side. The last part is about how the make the good use of  what we has built. There are two major clients, browser on PC and mobile device. For PC, I use Firefox, with Aut0Pr0xy extension, the extension subscribes GFW banned list automatically apply proxy setting to those site, quite a smart transparency tool. For Android user, I suggest install an app “ProxyDroid”, excellent proxy management tool, you could setup different proxy set, each on has its own rule. The rule includes, when will the proxy activated, on mobile network or WiFi environment or just all time; how to apply proxy setting, global mode or white-list mode: apps you chose will not apply to proxy, others, include Android system, would be proxied. that is very useful for me. For Apple user, kiss my ass.

Here is what I want to say about this topic today. I wrote this document not just for meno, also I think it as a contribution to the great works of “breaking the Wall down”. It is absolutely an degeneration of building such a technical barrier between China and the rest of the world, and the wall is higher everyday. People inside the wall, getting ignorant day by day, I call these people, the walking dead. Today in China major city, flesh air, green mountain or pure blue sky are so precious, people begin to forget what the real world looks like, feel like, after years of haze, they took what they experience as the real world, losing imagination and the hope for beautiful things, they don’t even has voice, they are the silent generation. Only when you open an outward window, smell flesh freedom air, see the beauty and ugly u self, you can’t wake up.

If anything unclear follow the instructions, please let me know, I have been using this ‘solution’ for years so I may missing some critical steps or leave some parts unclarify. Thanks.

Posted in personal, tech | Tagged | Leave a comment

赤脚医生之 扁挑体


day1, 感觉右侧扁挑体有所不适,仅仅略微不适而已,以经验来说这不是什么问题通常睡一觉就完全没问题, 不予处理

day2, 情况在变坏,以为是感冒或者伤寒导致,决定吃点泰诺试试看.虽然觉得自己没感冒,但是一周前在云南度假,昼夜温差较大,白天温度适宜,晚上通常穿的也比较少,可能是风寒引起的.有点低烧,38+.

day3, 不适感大大加重,已经开始分散我的注意力,无法正常上班,抽烟.不能抽烟是个很大的问题,不是烟瘾的问题,而是说明身体无法接受快感,霉运当头.晚上开始已经难以愉快的进食,睡前服用2次阿莫西林,放弃感冒的想法


day5, what a F night. 按经验来说,消炎药如果有效,应该能够立即缓解症状,显然这次又增加了不同的经验.经历了不能吃不能睡的两天,我发现自己还是很馋的.加上明显感觉到肾脏的负担,不敢再自己药自己了.为了治好馋虫,加之已经被颠覆的经验,只好乖乖的投医问药去了.诊断认为是化脓性扁挑体发炎,也就是重症扁挑体发炎.这次开回来头孢地尼分散片+搭配销售的中成药,去个中医院总得出点血,西药倒是医保基本包含,中药有自费部分,还好自费部分总共只占1/6,中药部分占了2/5或者是3/5记不清了.一天三次2片.医生说要3-5天才能有效,还叫我拼命喝水排毒.我的内心是崩溃的.头孢地尼分解片貌似欲水即溶,估计含服效果不错(抱怨一下,bing IME太没有生活经验了,什么组合词都打不出来,这大概就是MS和google的差距吧,虽然学习能力还行).中药就不提了,傻大黑粗,入胃即溶,释放出一股奇怪的气味.药名上来说是具有排毒作用,看不见摸不着,闻得到,我还是不评价了.

day6, another F night, 咽部的刺激以及无规律的大脑和左手小臂神经放射性刺痛让我这几天过足了隐,任何东西都都可以变得有情节,支离破碎但是就这么在我大脑里开始排练,我昏天黑地的被固定在观众席上味同嚼蜡,看着自己的无意识在爬行.早晨带着重生的心态从床上爬起,一不做二不休,强力止疼,上芬必得.虽然说明书没指出可以对付扁挑体的疼痛,但是神经放射性刺痛应该有效.这是个明智的选择,半个小时候神经性头痛开始慢慢消失,一个多小时以后,喉部的疼痛也基本上减轻到可以轻松应对的程度.剥离痛感仅剩触感,不用直接观察都可以准确的感到扁条体已经被侵蚀得像环形山了,口水流过都有明确的质感.今天阳光真美好,我透过雾霾认清你的本质.一大早7点多做了一大锅饭(难吃的要屎)和一大锅菜(难吃的要屎2),吃的好开心,蛤蛤.下午居然可以去打球,居然打的还算正常,除了感觉瞄来瞄去有点晃,我猜这是植物神经在长时间爬行之后改成直立行走,忽然有点不适应,需要重新校准.傍晚时分,芬必得12小时药力一过,各种症状劈头盖脸而来,爷已经不怕你了.开心的忍痛把上午的屎吃完,下一颗核弹要留到睡前两个小时,我已经看够了无意识流导演的烂片以及各种鬼才知道的哪里翻出来的线索,比大陆导演还差劲.今天检查创口,没有任何改善,可能还略有加重的嫌疑,好凶

day7, a silent night and morning, 芬必得果然是良心药.早起检查伤口,发现开始出现收缩的趋势,止疼药的药效明显已经消失,神经性头痛已经消失,喉部的疼痛变得可以忍受.开始乱吃东西,干家务,还修好了飞机,蛤蛤,爷回来了,可以飞了.





Posted in medical, personal | Tagged | Leave a comment