On 5/29/2011 3:33 AM, David Woodhouse wrote:
> On Sat, 2011-05-28 at 22:27 -0500, Matthew Kitchin (public/usenet)
> wrote:
>> I tried to compile a package for Openwrt last time, and it didn't go
>> very well. I spent a great deal of time, and made little progress. I
>> believe that is why I'm running a patched version.
> I don't think your current problem is related to the fact that you're
> running v2.25.
>
>>>> After about 3 days, I lose all connectivity between the devices on my
>>>> 192.168.1.x subnet. The devices can still get to the internet, still get
>>>> to the remote vpn subnets, but cannot see each other.
>>> How are the machines connected to one another? And if they can still
>>> happily see everything but each other, wtf is your 'ping 10.85.0.1'
>>> doing?
>>>
>> All the machines at my house are connected by wifi to the Openwrt box.
>> Openwrt has the vpn connection to remote office. All home machines are
>> on the 192.168.1.X subnet. 10.85.0.1 is a router IP at my corporate
>> office I ping to check if the VPN connection is up or not.
> OK, but you said that when the problem happens, they can still get to
> the remote VPN subnets. So this 'ping 10.85.0.1' check would still be
> *working*, and thus fail to detect the problem?
Correct. They can still get to 10.85.0.1. That check was only put in
there to detect when the VPN connection goes down. I believe my VPN
server is set to disconnect at 12 hours. I have not put in anything
automated to try and fix this local lan problem
> Or did I misunderstand, and your 'reconnect script' isn't actually
> solving the problem with the 192.168.1.x hosts on the wireless not being
> able to talk to each other? Except that when it *happens* to trigger
> because the VPN goes down, that somehow solves the (unrelated?) wlan
> issue?
Correct. It is not solving this problem. When the problem has occurred,
if I simply kill the openconnect process, the local connection between
the devices on the 192.168.1.x subnet is resolved. Perhaps this problem
is happening more often than I thought, and it is being resolved every
time the script runs to reconnect the VPN connection.
> It sounds like this is an OpenWRT routing problem. If hosts on your
> *wireless* cannot see each other, that really shouldn't be anything to
> do with openconnect. If restarting openconnect 'fixes' it then that
> really makes me suspect the routing setup, because that's all that
> openwer will really change. So I'll need to see those routing tables in
> all three cases.
>
I don't disagree at all. I thought I would start here because stopping
openconnect seemed to resolve the problem. Here is routing info right
now when all is well.
Openwrt:
root at OpenWrt:~# route -e
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt
Iface
10.85.0.10 10.70.6.134 255.255.255.255 UGH 0 0 0
tun0
10.85.0.11 10.70.6.134 255.255.255.255 UGH 0 0 0
tun0
216.248.9.102 c-68-63-248-1.h 255.255.255.255 UGH 0 0 0
eth1
10.70.6.0 10.70.6.134 255.255.255.0 UG 0 0 0
tun0
192.168.1.0 * 255.255.255.0 U 0 0 0
br-lan
68.63.248.0 * 255.255.248.0 U 0 0 0
eth1
172.27.0.0 10.70.6.134 255.255.0.0 UG 0 0 0
tun0
10.85.0.0 10.70.6.134 255.255.0.0 UG 0 0 0
tun0
10.92.0.0 10.70.6.134 255.255.0.0 UG 0 0 0
tun0
default c-68-63-248-1.h 0.0.0.0 UG 0 0 0
eth1
Windows machine on wifi:
C:\Users\Matthew Kitchin>route print
===========================================================================
Interface List
10...00 1e 58 3f a4 95 ......D-Link DWA-556 Xtreme N PCIe Desktop Adapter
9...00 1e 0b a1 f9 0b ......Intel(R) 82566DM-2 Gigabit Network Connection
1...........................Software Loopback Interface 1
15...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
25...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
13...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.221 25
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
192.168.1.0 255.255.255.0 On-link 192.168.1.221 281
192.168.1.221 255.255.255.255 On-link 192.168.1.221 281
192.168.1.255 255.255.255.255 On-link 192.168.1.221 281
224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 192.168.1.221 281
255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
255.255.255.255 255.255.255.255 On-link 192.168.1.221 281
===========================================================================
Persistent Routes:
None
IPv6 Route Table
===========================================================================
Active Routes:
If Metric Network Destination Gateway
13 58 ::/0 On-link
1 306 ::1/128 On-link
13 58 2001::/32 On-link
13 306 2001:0:4137:9e76:30be:3346:bbc0:62a/128
On-link
10 281 fe80::/64 On-link
13 306 fe80::/64 On-link
13 306 fe80::30be:3346:bbc0:62a/128
On-link
10 281 fe80::7830:bd1c:38ae:22fc/128
On-link
1 306 ff00::/8 On-link
13 306 ff00::/8 On-link
10 281 ff00::/8 On-link
===========================================================================
Persistent Routes:
None
C:\Users\Matthew Kitchin>
