Kpw-5.3.3 with BBB installed, at a public, non-AT&T (free) WiFi hotspot.
Some of the blocked ranges are not being hit.
This is expected behavior. bbb-13038 has both USA and UK cloud access ranges blocked.
The end-user experience could be a bit better - might have a go at using the REJECT (code) target rather than DROP.
At least then the foolish lab126 software might at least give up in less than 5 minutes or so.
Non-Amazon DNS is not being used. Need to fix that.
ICMP filter is allowing routing messages. Need to fix that.
For development purposes, adding some pcap format logging to what is being dropped (or rejected) might give a better idea of what the device is attempting to do.
There seems to be a "limit counter" in the system, which only allows a limited number of non-Amazon Wifi connections to fail trying to "call home" - and then it forces you to select a different network.
What is quite possible the "limit counter" is being displayed on the 711 page.
Need to find and fix that if possible.
Also, a bit of "mangle" table diddling of packet fields may be in order - further research required on that subject.
In particular, diddling the SECMARK and CONNSECMARK fields a bit (no pun intended).
Chatty Kathy with the gag on:
Code:
core2quad ~ $ ssh kpw "PATH=$PATH ; iptables -vnL OUTPUT"
Chain OUTPUT (policy ACCEPT 959 packets, 70802 bytes)
pkts bytes target prot opt in out source destination
506 109K ACCEPT all -- * lo 0.0.0.0/0 127.0.0.1
747 123K DROP all -- * * 0.0.0.0/0 23.20.0.0/14
0 0 DROP all -- * * 0.0.0.0/0 54.240.0.0/12
0 0 DROP all -- * * 0.0.0.0/0 54.240.128.0/18
0 0 DROP all -- * * 0.0.0.0/0 64.208.0.0/16
0 0 DROP all -- * * 0.0.0.0/0 64.209.0.0/17
66 4008 DROP all -- * * 0.0.0.0/0 72.21.192.0/19
48 2880 DROP all -- * * 0.0.0.0/0 176.32.96.0/21
0 0 DROP all -- * * 0.0.0.0/0 178.236.0.0/21
28 1808 DROP all -- * * 0.0.0.0/0 205.251.192.0/18
24 1440 DROP all -- * * 0.0.0.0/0 207.171.160.0/19