alias p='ping'
alias pp='ping -s 1024'
alias p4='ping'
alias pp4='ping -s 1024'
alias p6='ping6'
alias pp6='ping6 -s 1024'
alias t='traceroute'
alias tt='traceroute -n'
alias n='nslookup'
Guide
p pings using default stack pp pings using 1kB data p4 forces IPv4 (pp4 1kB data) p6 forces IPv6 (pp6 1kB data) t makes a traceroute (you can use first parameter -4 or -6 to force stack) tt makes a traceroute without resolving names (-4, -6) n resolves a name to IP address
I've had this problem for almost a year. When using WiFi with CyanogenMod 11 (Android KitKat 4.4.4), the phone lost connection to WiFi and no data came through even though it looked connected (the phone didn't use mobile data, because it was still connected to "faster" WiFi). Some apps drained the battery even more waiting for data and keeping the phone more awake (mostly waiting for position acquisition using Google geolocation).
The problem was caused by WiFi router configuration where I use latest OpenWRT. The damned WMM mode (some special kind of QoS for multimedia) was causing this, and after I turned it off, there were no more lock-ups. From what I've read, there is a bug in Android sources that causes this and nobody bothered to fix it so far.
To be able to play LAN games over OpenVPN tunnel, please follow OpenVPN manual and create your unique certificates, one for server and one for players.
Also create one additional certificate using openvpn --genkey --secret tls-auth.key for handshakes.
On the server machine you also have to open the port in public IP / redirect the port to your internal PC.
The situation is as follows: a minimum of two players both have Windows, at least one has to have public IP/open port (42222). All other clients connect to him and they make a fast and secure virtual LAN network for games. None of them uses the chosen IP range for local network, in this example 10.5.5.0/24.
tls-client
port 42222
proto udp
dev tap
tun-ipv6
nobind
resolv-retry infinite
tls-auth tls-auth.key 1
ca lan-ca.crt
cert lan-client.crt
key lan-client.key
tls-version-min 1.2
cipher AES-256-CBC
auth SHA256
tls-cipher TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256:TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256:TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256
remote-cert-eku "TLS Web Server Authentication"
pull dhcp-options
mute 10
comp-lzo
verb 1
Change 111.111.111.111 to match your server's IP. The predefined routes will take care of priorities and in most games the players should see each other and the server.
Just one more thing - you need to make sure the virtual device is given the highest priority (even above LAN or WiFi). You can do so by renaming your OpenVPN TAP network adapter to "OpenVPN" and running these commands from command line:
Code:
netsh int ipv4 set interface OpenVPN metric=2
netsh int ipv6 set interface OpenVPN metric=2
I recommend creating gameserver on the server machine to minimize latency. And the very last thing would be to add the network range to trusted networks in your firewall (once and for good).
Posted by: Ashus - 16.12.2014 09:11 - Forum: Other
- No Replies
Copy sh script using ES File Explorer (with root) to folder /system/addon.d . Set up rights to be 770 (rwxrwx---).
Re-flash firmware (upgrade).
Tested on CyanogenMod 11 (Android 4.4.4 KitKat) od NovaFusion (20141214).
Nahrát sh skript pomocí ES File Exploreru (s rootem) do /system/addon.d . Nastavte práva na 770 (rwxrwx---).
Flashnout znovu firmware (aktualizovat).
Testováno na CyanogenModu 11 (Android 4.4.4 KitKat) od NovaFusion (20141214).
Posted by: Ashus - 11.6.2014 02:42 - Forum: Other
- No Replies
V přiloženém ZIPu jsou dva reg soubory pro modifikaci registru Windows. Jeden nastavuje prioritu IPv4, druhý zpátky na IPv6, tedy pokud máte dualstack spojení internetu, můžete si zvolit, které spojení se má používat prioritně. Po aplikování je nutný restart systému.
V případě tunelování IPv6 nebo pokud potřebujete používat VPN spojení, které je nakonfigurováno čistě v IPv4 k sítím, které jsou zároveň dostupné i přes IPv6 se to může hodit.
Posted by: Ashus - 18.3.2014 07:14 - Forum: Other
- No Replies
If you have tried to forward UDP packets of UPNP (dynamic NAT port forwarding) to another network (you may have NAT further away from you), you need a little workaround for miniupnpd server to accept addresses that are not bound to any interface. The message in debug reads following: miniupnpd[3605]: get_lan_for_peer(): 192.168.5.25:1900 not found !
Let's say we have main router A, that NATs traffic of clients at A and router B. Router A also shapes traffic, so we can't use NAT on B natively and just forward everything to A. We need to forward UPNP and nat-PMP requests from clients of B to the router A. Clients of A have IP range 192.168.1.0/24, clients of B 192.168.5.0/24. The router A has IP 192.168.1.1 and 192.168.2.1 on p2p link with B. Router B has IPs 192.168.5.1 and 192.168.2.2 on p2p link with A.
Getting NAT-PMP to work is really easy, only one line is required in the firewall of B:
To route multicast traffic, you need to use smcroute on B. Configuration must be done per-IP:
[code]function smcroute_ip {
smcroute -a "$2" "$1" 239.255.255.250 wlan0
}
smcroute -a wlan0 192.168.2.1 239.255.255.250 eth0
![[Image: IHjhiN3S2-lEMF3-ObPsRshFlys2Johu7IRyYRRc...00-e365-rw]](https://lh6.googleusercontent.com/IHjhiN3S2-lEMF3-ObPsRshFlys2Johu7IRyYRRcCtkfwv8saJhJfO9Cb49C-BBdlmeS6bt-XQ=s640-h400-e365-rw)