Joined: 12 May 2018 Posts: 31 Location: Broomfield, Colorado USA
Posted: Fri Jan 04, 2019 17:20 Post subject: Re: Fixed the local IP lookup issue?
al_c wrote:
On numerous occasions, people have noticed that their local (private network) IP addresses were showing up as belonging to some other external organizations in the Active Connections table (Live Usage tab).
This started happening after I switched from storing individual addresses for the IP lookups to CIDR (Classless Inter-Domain Routing) ranges. That change was necessary because the size of the ip database (~100K entries) broke the look-up & sync functionality in the reports.
When you click an IP address in the Active Connections table, it triggers a JSON call which returns the entry in the database with the narrowest CIDR range that includes that IP. If there is no match, a new entry gets added (based upon a reverse Whois lookup and some other logic). For a reason that I don't fully understand yet, the way that I am resolving the CIDR ranges occasionally returns non-sensical values - e.g., an entry that covers all addresses between 192.0.0.0-192.255.255.255.
It occurred to me just recently (in a moment of `duh`) that I could/should manually add entries for the private network IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). AFAIK, that should now permanently fix this problem.
You might want to resync your entries by clicking the gear icon in the top right corner of the Active Connections table and then clicking `Sync IPs with usage-monitoring.com`
Let me know if I've missed anything
Al
Hey Al - I think this might have just broken, perhaps just this morning. My local network (192.168.x.x range) is suddenly saying it is in Denmark. I tried a re-sync but haven't tried anything else. NOT URGENT - just wanted to let you know.
Mike
Yamon (HTML: 3.4.5 / Script: 3.4.5) isn't working for me on the latest stable kong build using only ipv4. Yamon logs are filled with the following message:
Code:
00:02:24 2 checkChainEntries: YAMON34v4 returned only 0 entries?!? Resetting iptables rules
Yamon (HTML: 3.4.5 / Script: 3.4.5) isn't working for me on the latest stable kong build using only ipv4. Yamon logs are filled with the following message:
Code:
00:02:24 2 checkChainEntries: YAMON34v4 returned only 0 entries?!? Resetting iptables rules
I'm not seeing that line.
What router and version of DD-WRT are you using? _________________ Segment 1 XR700 10Gb LAN, 1Gb WAN ISP BS
Wired AP 1 Unifi Wifi 6 LR US 1Gb LAN
Wired AP 2 Unifi Wifi 6 LR US 1Gb LAN
Wired AP 3 Unifi Wifi 6 LR US 1Gb LAN
Syslog Services Asustor 7110T NAS 10GB
NetGear XS716T 10GB Switch
download1.dd-wrt.com/dd-wrtv2/downloads/betas/ (Brain Slayer)
YAMon https://usage-monitoring.com/index.php
I haven't pinpointed the root cause of it yet (because frankly I haven't had the time to fully investigate) but I can confirm this behavior as well. Simply restarting YAMon resolves it. At some point through the processes of DD-WRT and/yamon the yamon iptables gets mangled. It's seems to take 1 - 3 days to occur. At least on my setup. I also make liberal use of other services so that may be a contributing factor.
A quick and dirty work around I started using to avoid the problem was setting a cron job to restart YAMon at 3:45AM and I've never seen the problem when I did that.
I'll probably mod my local copy to do a restart when that message is seen in the logs. Now oddly enough, the last time I looked in the logs it looks like Al does try to reset the entries when the message occurs but it must be different from standard start up.
In case someone has more time than I do, here's how I plan to investigate.
1. Take a full list of iptables right after YAMon starts.
2. Monitor the log for the next occurrence of the error.
3. When it occurs, increase logging to maximum for one hour and try to review the logs to identify root cause.
4. Put some mechanism to reset the iptables similar to what a restart does.
Hey guys I got this installed last night and everything is working however the data seems to be reporting way too small. Any ideas? I'm using it with Firmware: DD-WRT v3.0-r36168 std (06/20/1.
Hey guys I got this installed last night and everything is working however the data seems to be reporting way too small. Any ideas? I'm using it with Firmware: DD-WRT v3.0-r36168 std (06/20/1.
Which router? Ethernet or Wifi?
Care to post up your config.file?
Mine currently lists 28 devices and 3.11 GB for the day.
Not much Netflix or Amazon today. _________________ Segment 1 XR700 10Gb LAN, 1Gb WAN ISP BS
Wired AP 1 Unifi Wifi 6 LR US 1Gb LAN
Wired AP 2 Unifi Wifi 6 LR US 1Gb LAN
Wired AP 3 Unifi Wifi 6 LR US 1Gb LAN
Syslog Services Asustor 7110T NAS 10GB
NetGear XS716T 10GB Switch
download1.dd-wrt.com/dd-wrtv2/downloads/betas/ (Brain Slayer)
YAMon https://usage-monitoring.com/index.php
Hey guys I got this installed last night and everything is working however the data seems to be reporting way too small. Any ideas? I'm using it with Firmware: DD-WRT v3.0-r36168 std (06/20/1.
Which router? Ethernet or Wifi?
Care to post up your config.file?
Mine currently lists 28 devices and 3.11 GB for the day.
Not much Netflix or Amazon today.
Don't see anything glaring at me though you may want to update your firmware build. _________________ Segment 1 XR700 10Gb LAN, 1Gb WAN ISP BS
Wired AP 1 Unifi Wifi 6 LR US 1Gb LAN
Wired AP 2 Unifi Wifi 6 LR US 1Gb LAN
Wired AP 3 Unifi Wifi 6 LR US 1Gb LAN
Syslog Services Asustor 7110T NAS 10GB
NetGear XS716T 10GB Switch
download1.dd-wrt.com/dd-wrtv2/downloads/betas/ (Brain Slayer)
YAMon https://usage-monitoring.com/index.php
Yeah I'm not sure what the deal is. Attached is a picture of the software currently. See how goofy the statistics are. I disabled SFE and universal plug-and-play and it still does this.
I really have no clue what I did but I upgraded my firmware and it made my USBs no longer function. So I downgraded back to the firmware I was using before and now all of a sudden Yamon is working. Totally weird!
I haven't pinpointed the root cause of it yet (because frankly I haven't had the time to fully investigate) but I can confirm this behavior as well. Simply restarting YAMon resolves it. At some point through the processes of DD-WRT and/yamon the yamon iptables gets mangled. It's seems to take 1 - 3 days to occur. At least on my setup. I also make liberal use of other services so that may be a contributing factor.
A quick and dirty work around I started using to avoid the problem was setting a cron job to restart YAMon at 3:45AM and I've never seen the problem when I did that.
I'll probably mod my local copy to do a restart when that message is seen in the logs. Now oddly enough, the last time I looked in the logs it looks like Al does try to reset the entries when the message occurs but it must be different from standard start up.
In case someone has more time than I do, here's how I plan to investigate.
1. Take a full list of iptables right after YAMon starts.
2. Monitor the log for the next occurrence of the error.
3. When it occurs, increase logging to maximum for one hour and try to review the logs to identify root cause.
4. Put some mechanism to reset the iptables similar to what a restart does.
clearly something horrible is going wrong. And of course, it is not happening on my machines.
Can someone send me logs (at loglevel=0 or -1) when the problem occurs?
I believe that the code is detecting a bad state in iptables but is not recovering gracefully from that. So, one, I have to change the recovery mechanism and two have to fix whatever is causing the bad state. But recovering is the higher priority, I think.
Yamon (HTML: 3.4.5 / Script: 3.4.5) isn't working for me on the latest stable kong build using only ipv4. Yamon logs are filled with the following message:
Code:
00:02:24 2 checkChainEntries: YAMON34v4 returned only 0 entries?!? Resetting iptables rules
Can you send me the log? Can you set loglevel=0 and wait until the problem happens again and then send that log too?
When starting yamon with startup.sh after telneting into the router, my terminal would always hang on exit. By adding these lines to yamon3.4.5.sh to detach from the terminal just before the main loop, exiting from the terminal now returns cleanly to the host from which the telnet was made. This assumes that yamon doesn't do terminal I/O once running in background.
Code:
$send2log ">>> Starting main loop" 1
# Detach from terminal
exec 0>&- # close stdin
exec 1>&- # close stdout
exec 2>&- # close stderr
.
