NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
sickbeard, readynas remote/leafnet, wombles
forever I have had errors from sickbeard regarding wombles index.
after some investigation, I discovered that nzb.isasecret.com I can ping from my pc, but the readynas's can not.
vs
looking at the nas routing table, leafnet is sending all 5.x.x.x traffic to the leafnet adapter.
since wombles is apparently hosted on a 5.x.x.x network, but not a leafnet network, it is failing because it is trying to route out the leaf adapter instead of the default route.
I would prefer to keep remote installed/enabled, but it obviously has the wrong subnet mask in the routing table.
looking up the 5.168 network shows
not sure why it doesn't belong to leafnet or netgear, but which calculates out to be a 5.168.0.0/15 network
so I fixed it with the below;
after some investigation, I discovered that nzb.isasecret.com I can ping from my pc, but the readynas's can not.
Z:\d>ping nzb.isasecret.com
Pinging nzb.isasecret.com [5.135.178.43] with 32 bytes of data:
Reply from 5.135.178.43: bytes=32 time=472ms TTL=113
Reply from 5.135.178.43: bytes=32 time=202ms TTL=113
Reply from 5.135.178.43: bytes=32 time=192ms TTL=113
Reply from 5.135.178.43: bytes=32 time=249ms TTL=113
Ping statistics for 5.135.178.43:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 192ms, Maximum = 472ms, Average = 278ms
vs
sauron:~# ping nzb.isasecret.com
PING nzb.isasecret.com (5.135.178.43) 56(84) bytes of data.
From 5.168.x.x icmp_seq=2 Destination Host Unreachable
looking at the nas routing table, leafnet is sending all 5.x.x.x traffic to the leafnet adapter.
sauron:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.168.0 * 255.255.255.0 U 0 0 0 eth0
5.0.0.0 * 255.0.0.0 U 0 0 0 LeafNets
default DD-WRT 0.0.0.0 UG 0 0 0 eth0
since wombles is apparently hosted on a 5.x.x.x network, but not a leafnet network, it is failing because it is trying to route out the leaf adapter instead of the default route.
I would prefer to keep remote installed/enabled, but it obviously has the wrong subnet mask in the routing table.
looking up the 5.168 network shows
inetnum: 5.168.0.0 - 5.169.255.255
netname: TIM-NET
descr: TIM
descr: Telecom Italia Mobile
descr: Service Provider
country: IT
not sure why it doesn't belong to leafnet or netgear, but which calculates out to be a 5.168.0.0/15 network
so I fixed it with the below;
route del -net 5.0.0.0 netmask 255.0.0.0
ip route add 5.168.0.0/15 dev LeafNets
6 Replies
Replies have been turned off for this discussion
- When Leaf first began operations, 5.x.x.x was reserved for "experimental use" by IANA so it was safe to use for the VPN address scheme.
When IPv4 addresses started becoming scarce, it was re-allocated, so it could be (and now is) used for internet addressing. Netgear needs to switch the leaf adapter to use a private address space. But they never have, even though the 5.x.x.x addresses were reallocated a few years ago. - I had wondered about that, makes sense. They definitely need to switch to a private network then, 5.x public ips are inaccessible from the nas unless you manually make the routing changes.
A /15 may not even be most correct subnet for leaf too. - I just ran into this myself. I was having this really strange networking issue last night where I could no longer access one of my (recently moved) remote servers from any of my ReadyNAS devices [destination network unreachable], however, all of my other devices could access it perfectly fine. After a couple hours of troubleshooting [disabling bonding, jumbo frames, rebooting, etc] I noticed that the ReadyNAS Remote service (specifically the LeafNetworks adpater) has a network ID & subnet mask of 5.169.x.y/255.0.0.0 that was sending traffic destined for my server through the Leaf adapter instead of the server (5.79.x.y)
I have disabled ReadyNAS remote as a temporary workaround, but it would be wise for Netgear to address the issue. - Wow, here we are in 2015 and this still is not fixed.
Thanks for the well documented solution/hack/workaround. - If it was a simple fix we would have fixed this ages go.
- IP6 and done.
:)
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
