Wapp

 Wapp is a framework for writing web applications in TCL.

static

This adds the ability to serve static content using fcopy without reading the entire file into memory first. This might undermine some of the deliberate security of wapp, but some care was taken. Feedback regarding security welcome.

thread

Refactor file delivery to allow the file content to be deivered by a new thread. One for each file. This makes the service about 30% faster when displaying a page full of large jpegs.

routes

Boiler plate generator for unpacking route path values and wapp-params into local variables in a page handler.

From lego12239/wapp

This is a fork of original wapp from D. Richard Hipp with some changes:

• support of PUT, PATCH, DELETE http methods;
• fix cookies parsing(make parsing more rfc6265 compliant, but be more liberal to cookie value, allowing any chars except dquote in a quoted value and any char except semicolon in a nonquoted value);
• throw error on bad cookie value set;
• -server option accepts a listen address in plan9 format: tcp!ADDR!PORT or tcp!ADDR!0 or tcp!ADDR or ADDR. If PORT isn't specified or 0, then the first not used port is selected. If ADDR is 0.0.0.0, then listen on wildcard address;
• fix request target parsing(make parsing more rfc3986 compliant);
• fix request header name-value parsing(make parsing more rfc7230 compliant);

For documentation look https://wapp.tcl.tk/home/doc/trunk/README.md .

from https://github.com/lego12239/wapp

mac上的全局代理程序OBTun2Socks

This project is a stab at packaging BadVPN's tun2socks into a CocoaPod.

tun2socks forwards TCP and UDP traffic to a SOCKS server - esp. Tor.

This is based off the work of Potatso and Jigsaw's Outline Client.

Example

To run the example project, clone the repo, and run pod install from the Example directory first. However, it is empty and just a target to test successful build.

Installation

OBTun2Socks is available through CocoaPods. To install it, simply add the following line to your Podfile:

pod 'OBTun2Socks'

from https://github.com/tladesignz/OBTun2Socks

陈破空：路线斗争，习下, 李上？李克强据有党内合法性

 近期，在中共党内，作为一、二把手的总书记习近平和总理李克强，路线斗争公开化，从防疫、经济、到外交等各领域，双方各说各话、各行其是。习李二人、以及他们各自代表的党内不同势力之间，分歧和矛盾日显，从路线斗争到权力斗争，都日趋激烈，已然成为公开的秘密。

首要的一条，习近平强调不惜一切代价搞“动态清零”，李克强主张以超常手段挽救经济。李克强召集的十万人大会（5月25日），成为一个摊牌的信号。会上，李克强列举中国经济的种种危机，亮出拯救手段，而对所谓病毒清零，则只字不提；但会后，由习家军把持的党媒党报，低调或压缩报道这次大会和李克强讲话，并在社交媒体上跟踪删除李克强讲话全文，显示习派对李克强讲话的恐惧。

此时此刻，有关习近平连任受阻、习下李上的消息，风传海内外。然而，习近平和习家军不甘心失败，或是顾面子，仍时不时在他们暂时掌控的宣传口搞小动作，发出似是而非的信息；而网上的少数挺习者，因不谙中共政治结构，仍相信习近平大权在握、盲目认定他连任已是铁板钉钉。

习家军通过他们操控的党媒，发表文章，以历史上毛泽东与张国焘和王明斗争为例，反对“另立中央”，等于承认遭李克强和反习派逼宫。然而，盘点中共党史，除了对张国焘和王明两役，毛泽东获取最高权力，过程漫长，乃是由下而上、由外而内、由边沿向中心夺权。实质是下级向上级夺权、地方向中央夺权。

毛泽东割据江西，只是一支地方武装，当时的中共中央设在上海，先后由陈独秀、周恩来等人领导。即便1935年的遵义会议，也没有确立毛泽东的最高领导权，而是重新确立了周恩来的最高领导权，只是让毛泽东参与军事上的谋划。所谓毛泽东的最高领导权，是在到了延安时期，才逐渐确立，至中共七大正式成型（1945年）。

由下而上、由外而内、由边沿向中心的权力斗争，也完全符合邓小平与华国锋的权力斗争模式。彼时，华国锋身兼中共中央主席、军委主席、国务院总理三职，而邓小平仅为副主席、副总理，但经过党内运作、逐渐争取到高层多数人支持，邓小平硬是以下级身份，夺取了最高领导人华国锋的权力（1981年）。

如何解释毛泽东和邓小平的夺权过程？中共党史有一个说法，曰：正确路线战胜错误路线。对于毛泽东早期，中共定义，他与陈独秀、李立三、王明、甚至周恩来等领导人作斗争，用讲究战略战术的正确路线战胜了“左倾冒险主义”和“右倾投降主义”的错误路线；对于邓小平，中共定义，他与华国锋为首的保守派和教条主义作斗争，用改革开放的正确路线战胜了“两个凡是”的错误路线。

从毛泽东和邓小平两例来看今日中共，没有谁是铁打不动的最高领导人，只有正确路线和错误路线的较量。由路线斗争的胜负而决出权力斗争的胜负。况且，今天的习近平，犯下天条：违背时代且违反党章，大搞个人崇拜，复辟个人独裁，妄图跨越两届任期，满足长期执政、乃至终身执政的权欲野心，引起党内外普遍不满、海内外普遍反感。而习近平在威信和实权两方面都远不及毛邓，堪称胆大妄为、肆意僭越和不知敬畏。

习近平以极左路线、极端独裁和极端封城手段，先后砸毁香港、砸毁上海，搞垮中国经济，搞乱中国社会。此时此刻，中共内部，惊鸿一片，路线之争必然浮出水面。

按照党内定性，李克强坚持改革开放、市场经济和国际合作，就是正确路线的代表人；习近平倒行逆施，大开历史倒车，经济上搞国进民退、外交上搞闭关锁国、政治上图谋复辟毛时代或文革旧制，就是错误路线的代表人。由此可见，且不说改革开放以来党内形成对任期制的共识，即便从中共的历史逻辑出发，李克强与习近平斗争，甚至取而代之，习下李上，都据有其党内的合法性与合理性。

Mini-Router

A mini-router supporting basic ARP protocol, IP forwarding, ICMP echo / reply, and RIP routing.

Build

Install project dependencies.

sudo apt install -y cmake libpcap-dev libjson-c-dev bird iperf3 wireshark

Build the project.

mkdir -p build && cd build
cmake .. -DCMAKE_BUILD_TYPE=Release
make -j

Run Router

Create a network topology using ip namespace.

# R1 <--------------> R2 <--------------> R3 <--------------> R4 <--------------> R5
#    r1r2        r2r1    r2r3        r3r2     r3r4       r4r3    r4r5        r5r4
#   10.0.1.9  10.0.1.1  10.0.2.9  10.0.2.1  10.0.3.1  10.0.3.9  10.0.4.1  10.0.4.9

cd ../script/
sudo bash router.sh

Run & test router.

# Start router in R3
sudo ip netns exec R3 ../build/bin/router ../conf/router/r3.json
# Ping router
sudo ip netns exec R2 ping 10.0.2.1 -c 4
sudo ip netns exec R4 ping 10.0.3.1 -c 4
# Test Host Unreachable
sudo ip netns exec R2 ip r add 10.0.233.1/32 via 10.0.2.1
sudo ip netns exec R2 ping 10.0.233.1 -c 4
# Start BIRD (a standard RIP router) in R2 & R4
sudo bash run_r2.sh
sudo bash run_r4.sh
# Ping R1 <-> R5
sudo ip netns exec R1 ping 10.0.4.9 -c 4
sudo ip netns exec R5 ping 10.0.1.9 -c 4
# Test TTL Exceeded
sudo ip netns exec R1 ping 10.0.4.9 -c 4 -t 2

Run speed test with iperf3.

# Start server
sudo ip netns exec R5 iperf3 -s
# Start client
sudo ip netns exec R1 iperf3 -c 10.0.4.9 -O 5 -P 10     # TCP multi-client
sudo ip netns exec R1 iperf3 -c 10.0.4.9 -O 5 -u -l 16 -b 1G    # UDP small packets

Run Switch

Create a network topology

# P12 <-----+ veth12
#    veth   |
#  10.0.1.2 |       veth-brd1
#           +---> BRD1 <--------> R
#           |               veth1
#           |             10.0.1.1
# P13 <-----+ veth13
#    veth
#  10.0.1.3

sudo bash switch.sh

Run switch.

sudo ip netns exec BRD1 ../build/bin/switch ../conf/switch/s.json

Make some tests.

# connectivity test
sudo ip netns exec P12 ping 10.0.1.3 -c 4
sudo ip netns exec P12 ping 10.0.1.1 -c 4
sudo ip netns exec R ping 10.0.1.3 -c 4
# speed test
sudo ip netns exec R iperf3 -s
sudo ip netns exec P12 iperf3 -c 10.0.1.1 -O 5 -P 10

Run Switch & Router

Create a network topology

# P12 <-----+ veth12                             veth22 +-----> P22
#    veth   |                                           |   veth
#  10.0.1.2 |       veth-brd1           veth-brd2       | 10.0.2.2
#           +---> BRD1 <--------> R <--------> BRD2 <---+
#           |               veth1   veth2               |
#           |            10.0.1.1   10.0.2.1            |
# P13 <-----+ veth13                             veth23 +-----> P23
#    veth                                                   veth
#  10.0.1.3                                               10.0.2.3

sudo bash complex.sh

Run router & switch.

# Run switch on 10.0.1.0/24 (bridge P12 & P13)
sudo ip netns exec BRD1 ../build/bin/switch ../conf/complex/s1.json
sudo ip netns exec P12 ping 10.0.1.3 -c 4
# Run switch on 10.0.2.0/24 (bridge P22 & P23)
sudo ip netns exec BRD2 ../build/bin/switch ../conf/complex/s2.json
sudo ip netns exec P23 ping 10.0.2.2 -c 4
# Run router on R
sudo ip netns exec R ../build/bin/router ../conf/complex/r.json
sudo ip netns exec P12 ping 10.0.2.3 -c 4
sudo ip netns exec P22 ping 10.0.1.2 -c 4
sudo ip netns exec P13 ping 10.0.2.1 -c 4   # ping router

from https://github.com/li-plus/mini-router

一个时代结束了：北京“去习近平化”悄悄开始了，习近平或将成“第二个华国锋”

 

敲锣打鼓吧，习猪头这个瘟神倒行逆施，终于要滚蛋了。但愿成真。

related post: https://briteming.blogspot.com/2022/05/blog-post_102.html ,  里面说：

“当前的危机导致中共内部乱成一团，改革开放的红利没了，中共垮了，权贵们的富贵也没了，甚至身家性命难保，所以党内元老和反对势力出面，横加干涉，要让“一尊”改弦易辙，否则不惜把他拉下马。权威比肩毛邓的习近平，这才肯让步。”

linux桌面系统上的全局代理程序Turnout

Transparent and HTTP proxy with smart routing solution. Automatic selection between direct route and SOCKS proxies, without the need to maintain any list.

Let's suppose for some reason your ISP is incapable to grant you reliable access to some specific websites. In such case, many of us ended up with a dual-connection plan.

A main connection provided by the ISP as is, is complemented by a second connection circumventing the problem of the first. The second route is usually metered, and accessible via a SOCKS5 interface.

Turnout is aimed to give users smooth browsing experience while minimizing the traffic ($$) incurred on the metered connection, by doing smart routing in the background.

User ------ Router ---(ISP)---- Route 1 (default unreliable route)
               |
               -----(SOCKS5)--- Route 2 (metered reliable route)

Conventional routing plans

• Geographic IP list

  Route domestic traffic via route 1 and foreign traffic via route 2.

  ✔ Simple and easy to maintain

  ❌ High traffic on route 2 (expensive)

  ❌ Unnecessary and inefficient on non-blocked sites

• Domain list (e.g. g**list)

  Keep a long list containing every site that needs special care.

  ✔ Save traffic as compared to geographic plan

  ❌ Need maintenance to keep the list up to date

  ❌ Impossible to cover every site

  ❌ There is no "one size fits all"

Smart routing

• COW

  Only use secondary routes if the site is blocked on the main route.

  ✔ Save traffic to minimum

  ✔ No need to keep any list

  ❌ Need learning at startup

  ❌ No transparent proxy (not supposed to be used on routers)

• Turnout

  Smart routing like COW but more efficient and works great on routers.

  ✔ Save traffic to minimum

  ✔ No list is needed

  ✔ No learning curve

  ✔ Work as both an HTTP proxy (all platforms) and a transparent proxy (Linux only)

  ✔ Slow download detection

  ✔ Sniff hostnames for better speed via SOCKS routes

  ✔ Live with bogus DNS results

  ✔ Support multiple SOCKS servers with customizable fail-over solution

  ❌ No UDP, no DNS and tunneling tools integrated (routing only)

Technical highlights

• Smart selection of routes

  For TLS connections, Turnout attempts connections via the main route and all priority-1 SOCKS servers simultaneously. If none of them works then priority-2 servers are tried. The fastest server that sends back a valid first byte will be chosen.

  For other protocols, attempts are made one at a time according to priority settings (main route, priority-1, priority-2...), because sending the same content via multiple routes may lead to errors.

• Destination-based server switch

  By default, Turnout saves the route choice for a new destination (by full hostname, or IP if hostname is not available) and makes sure that following connections use the same server. The route choice is reset if two consecutive attempts has failed or there has been no connection to the given destination for at least 30 seconds.

  This feature can help alleviating the problem of IP switching with some websites. Use -fastswitch option if you want to disable it.

• Fail-over design

  Turnout does not monitor the status of the SOCKS servers like clash. All servers are attempted according to the mechanism described above and the failure of one or two servers should not lead to downtime of the service. However, it's inefficient to entirely rely on this fail-over design by specifying a large number of servers, especially of the same priority, which can be CPU-intensive.

  You are recommended to put in place your own monitoring in parallel to Turnout. For example, you can specify 3 servers for Turnout and periodically monitor them based on some rules. If any one of them is deemed down, replace it with another one serving the same port so that Turnout does not need to restart.

Basic usage

Note: Turnout is supposed to be deployed on local network. It is not safe or optimized to use it in a remote environment, such as a VPS.

• Transparent proxy (Linux only)

  Both TPROXY (use -t option) and REDIRECT modes are supported. You need to redirect the traffic to Turnout using iptables.

  REDIRECT mode is an old feature available on nearly all devices and also easy to configure. It supports IPv6 since kernel 3.7. TPROXY mode is a bit faster than REDIRECT but TPROXY kernel module may be missing on some old systems. On standard kernels, TPROXY is available since 2.6.28 and supports IPv6 since 2.6.37.

  This example starts a transparent proxy at port 2222 and sets 127.0.0.1:1080 as upstream SOCKS5 proxy. Connections with download speed less than 100 kB/s will be added to slow list and routed via route 2 from the next connection. Incoming LAN traffic from interface br0 to non-local addresses is redirected to the proxy.

  # Start Turnout in the background
  turnout -b 0.0.0.0:2222 -s 127.0.0.1:1080 -t -slow 100 &
  
  # Option 1: Set up REDIRECT for all outgoing traffic (CPU-intensive)
  iptables -t nat -A PREROUTING -i br0 ! -d 192.168.0.0/16 -p tcp -j REDIRECT --to-ports 2222
  
  # Option 2: Set up REDIRECT for international traffic only (recommended if TPROXY is not available, ipset support and a domestic CIDR list are needed)
  iptables -t nat -A PREROUTING -i br0 ! -d 192.168.0.0/16 -p tcp -m set ! --match-set domestic dst -j REDIRECT --to-ports 2222
  
  # Option 3: Set up TPROXY for international traffic only (recommended, ipset support and a domestic CIDR list are needed)
  iptables -t mangle -N DIVERT
  iptables -t mangle -A DIVERT -j MARK --set-mark 1
  iptables -t mangle -A DIVERT -j ACCEPT
  ## This line matches established connections
  iptables -t mangle -A PREROUTING -m socket --transparent -j DIVERT
  ## These lines match new and related connections
  iptables -t mangle -A PREROUTING -i br0 ! -d 192.168.0.0/16 -m state --state NEW -p tcp -m set ! --match-set domestic dst -j CONNMARK --set-mark 1
  iptables -t mangle -A PREROUTING -i br0 -m connmark --mark 1 -p tcp -j TPROXY --on-port 2222 --tproxy-mark 1
  ## Rule for redirecting to local
  ip rule add fwmark 1 table 100
  ip route add local 0.0.0.0/0 dev lo table 100

  Multiple SOCKS servers can be configured to provide fail-over function. 3 priority grades can be set and lower grade servers are only used if higher grade servers fail. In this example, 192.168.1.1:1080 is set as main server (with priority 1) and 192.168.2.1:1080 and 192.168.2.1:1081 are priority-2 servers. Once 192.168.1.1:1080 fails, these two servers will be tried at the same time and the faster one will convey the traffic. You can set priorities according to the prices of the servers, for example.

  turnout -b 0.0.0.0:2222 -s 192.168.1.1:1080 -s2 192.168.2.1:1080,192.168.2.1:1081 -t

• HTTP proxy

  This command starts an HTTP proxy at local port 8080 and sets 127.0.0.1:1080 as upstream SOCKS5 proxy. Connections with download speed less than 100 kB/s will be added to slow list and routed via route 2 from the next connection.

  HTTP proxy and transparent proxy can be enabled at the same time.

  turnout -h 127.0.0.1:8080 -s 127.0.0.1:1080 -slow 100

• IP and host lists

  Turnout is supposed to be doing routing automatically without the help of any list. But it still supports these lists for the use by advanced users. Please refer to the sample lists to learn about the format.

Known issues

• Linux open files limit

  The default open files limit on Linux is 1024. You can check it by running ulimit -n.

  By the proxy nature Turnout uses a large number of connections and is hence very likely to reach the limit. You are strongly advised to increase that number. For example this command sets limit to 10000 and starts Turnout if successful.

  ulimit -n 10000 && turnout -b 0.0.0.0:2222 -s 127.0.0.1:1080 -t

• Unexpected closure of TLS connections

  In some circumstances, the server (or some intermediary) may cut the connection before it should close. Due to TLS connections' encrypted nature, Turnout may not be able to tell if the closure is normal and thus cannot identify the blockage.

• DNS

  Turnout is written with the assumption that DNS results can be bogus. Generally speaking, if a bogus result leads to nowhere, Turnout can detect it and use route 2 automatically. However, there are some circumstances that Turnout might need your help, such as in a plain text HTTP hijack. In case that Turnout is unable to tell there's a hijack, you might need to add a rule for that IP.

  If you have set up a reliable nameserver as system resolver, you are very welcome to use it but you also need to make sure it is optimized for CDNs in the main route. Please use -dnsok option to assert the results are genuine so that Turnout can skip some unnecessary checks.

• Hostname sniffing

  In transparent proxy mode, for any traffic sent over route 2, Turnout tries to sniff hostnames from the first packet and send them instead of IPs to SOCKS proxies to allow name resolution on the remote side, so that the speed is not affected by the local DNS result.

  HTTP and TLS connections are supported but TLS with ESNI is not because the hostname is encrypted. Cloudflare supports ESNI since 2018 but among major browsers only Firefox supports it (disabled by default). You are recommended to not use ESNI with Turnout.

• Unreliable ISP

  Turnout is not supposed to be using with highly unreliable ISPs. If your ISP can't provide at least acceptable quality in international or cross-ISP connections (for instance packets are heavily throttled or randomly dropped), your better choice is an IP/CIDR based routing plan. Because in that case any benefit from automatic routing will be erased by the poor network condition.

from  https://github.com/domosekai/turnout

text-convert，在线文字转换器。简体／繁体转为火星文

线上预览地址：

https://zhanyuzhang.github.io/text-convert/

from https://github.com/zhanyuzhang/text-convert