Hi,
2017-10-28 01:23:46 INFO btservice No internet connection available
Pi seems unable to connect to the internet. Have uninstalled iptables as fzinken suggested earlier?
Also could you please provide new logs with vpn disabled, as current ones are bit congested.
Thanks Tom.
OK. openvpn is disabled, iptables -F executed (w/a reboot in there somewhere) and here’s the link to the logs: http://paste.osmc.io/urokowifun.vhdl
Really appreciate the help. Hope this gets figured out soon. I’m still probing when I get the time.
Thx and cheers…
The log seems to suggest that you do have an Internet connection, though DNS doesn’t seem to be working.
A quick test of network connectivity is to run ping:
ping -c2 8.8.8.8
On the DNS side, please run:
cat /etc/resolv.conf
host -v google.comI sort of sensed it could be related to DNS, but don’t know nearly enuf to even ask the right questions 
Here are the results of the commands you suggested:
ping -c2 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss
(NOTE: did not hit cntrl-C to end the ping)
cat /etc/resolv.conf
# Generated by Connection Manager
nameserver <xxx.xxx.xxx.x>
(Note: the nameserver ipaddr returned is my router ipaddr. Is that correct? nameserver=DNS? My Win 10 sys, which works fine, uses DNS servers (2 of 'em) that are provided by my ISP, Comcast :frowning:
host -v google.com
Trying "google.com"
;; connection timed out; no servers could be reachedOh well, if was a good theory… 100% packet loss to an IP address isn’t good. Using the router for DNS is fine, as long as you’re not using openvpn.
If at all possible, please don’t doctor the output from commands. In this case it’s pointless since the router address is already in the log file but by doing so you might obscure some useful piece of information.
So back to the drawing board. Le’s see what we get from these commands:
route -n
ping -c5 127.0.0.1
ping -c5 192.168.101.1
I don’t know what router you’re using but if you can ping from the router to the Pi, give it a try.
Update: (171030.1)
Have been working with my other systems and have noticed a significant network improvement on my subnet. Seems things are back as they should be.
(171030.0)
My turn for a “D’oh!”…kind of. I was just about to provide results of your most recent suggested commands and I realized there was something I hadn’t checked. It should have been obvious because I’ve run into it before, but it’s been quite a while.
The RPI 3 has a static ipaddrs (as do some of my systems that need to be in a “certain” place). In a recent power outage, a DishNetwork DVR (which can only be DHCP’d), must have finished rebooting before the RPI 3 and grabbed its ipaddr, thus creating a collision issue for the RPI 
Once I changed the RPI 3 ipaddr, things started working again. I’ve only performed very preliminary testing, but it looks good.
I think we can call this solved.
Thx much for your and everyone’s help. Sorry to have wasted unnecessary time because of my dying brain cells 
Cheers…
That’s a good reminder that, if you use both DHCP and static IP addresses (as I do) you should always allocate the fixed addresses outside the range the DHCP allocates.
Derek
As I mentioned earlier about networks and me
Is that something that needs to be done at the router level? Thanks for the suggestion. I’ll have to go explore how best to do that.
Yes - it is a router feature, if the router is where the DHCP allocation takes place.
Some people have other arrangements, so I cannot be too specific about it.
I did have one router, about a year back, which was tricky to set this up (found the easiest way was to edit a text config file) - but ended up by ditching it as there were too many other problems.
Derek
Thx. I’ve been able to set up the router for different wi-fi nets, 1 for normal and 1 for guests. What I’m using is an ASUS RT-N10P with a Tomato OS which, I hope, makes it fairly flexible. Let’s see how badly I can mess things up some more I also set the router up so it limited the range of valid ipaddrs on the subnet, but will have to sort thru about how to set up a wall between DHCP and static.
Maybe it’s not so much that I’m networked challenged but rather network timid 
Appreciate the help and support!!
Cheers…
Well based on this picture it is fairly simple. In this picture the DHCP server just gives out addresses between 192.168.1.100 - 192.168.1.200 so you could use 192.168.1.2 - 192.168.1.99 for your static IPs.
https://learntomato.com/wp-content/uploads/router-setup-ip-dhcp.jpg
Thx. Your pic looks familiar. Just haven’t gotten into it yet, but it does look simpler than I thought ("Network-timid anxiety
And basically instead of Static IPs you also can use DHCP for that devices and define a fixed IP in the DHCP server for those devices
https://en.wikibooks.org/wiki/Tomato_Firmware/Menu_Reference#Static_DHCP
And when you want to step it up, put openwrt onto your router
https://wiki.openwrt.org/toh/asus/rt-n10plus
In spite of its shortcomings, such as being restricted to a Broadcom chipset, Tomato still rocks, IMO.
Oh, and what’s this I see on the OpenWRT page?
Note: The ASUS RT-N10P is a different hardware design, and this firmware does not run on it.
I was just about to ask which one was better and this reminded me of why I went with Tomato. It was better than openwrt simply because it worked
Thanks for the input, tho…Cheers…
Well I first was struggling to find proper manual for Tomato that was when I thought I mention openwrt.
Good spot