So the IP with the highest usage is likely the seller and the rest is consumers getting auto updates from a poorly implemented script.
1 Like
I also thought about some device sold by a local shop in Bilbao; but the number of devices seems too big for a local shop, and a local shop would rarely have the resources for a mass-update.
But you mentioned "commuting", and that made me think about another possibility: perhaps those devices are being distributed internally by a company, among their offices or among their teleworking employees...
1 Like
I can haz live like diz?? pllleeeeeeeeezzz!!!!11 
(inspired by http://ip-api.com/docs/statistics; that's where I got the geoip info from)
Not 100% serious, but asking: Why not?-)
Not 100% joking, therefore asking: can somebody script this?
pllleeeeeeeeezzz!!!!11
1 Like
When we first started investigating this, one of questions I had asked was: "Why this image?" In particular these requests are for the factory image and NOT the sysupgrade image. Why would that be over so many nodes?
1 Like
IMHO the answer is something on the line that the downloaded image is not actually used for anything, but the download action is just used to measure connectivity and/or bandwidth. (As most downloads are not even completed, the downloaded file will be unusable in any case.)
Many questions, many speculations, very little answers that bring us forward.
I think we have reached a point now where we have exhausted the information contained in the server logs (except if @eduperez is able to distill some new information out of the logs over the weekend).
I checked where we could complain about this issue, and it boils down to basically 6 adresses (the numbers are the current download counts 06...18.-JAN-2019):
If somebody is able to investigate this deeper, then it's the ISPs, since they know who is behind their IPs and how to contact them.
@thess How do you think about this?
Its very strange . im from bilbao but euskaltel doesnt provide that router . i can check it if you can send some information on euskaltel network.
I worked on the files during the weekend, and came to more speculations... at the end of the day, all we have are addresses, times, clients, sizes, etc; I could not get to any conclusion about who or why is doing all these access.
I'm pretty sure this has to be related to something like guifi.net, since I don't know about any ISP giving that router nor using OpenWRT. This stuff is used by geek guys behind ISPs router, there are many tutorials about it, see:
https://tombatossals.github.io/instalar-openwrt/
and many more.
Well, I refined the search looking for "site:guifi.net wr1043nd-v1-squashfs-factory.bin"
I got just one result "http://listas.valencia.guifi.net/pipermail/usuarios/2013-February/001641.html" where the subject can be translated as "OpenWRT install tutorial with OpenVPN client on TP-Link router" It should be noted that message is dated back to 2013 and by going back on that thread i found a non-working (404) link to dropbox.
So I can only guess this is a matter of somebody IT-iliterate doing something really wrong, and I would suggest getting in contact with guifi.net people, not because I think they are the bad guys but instead because they have mailing lists, etc, and they could perhaps issue a warning.
However, ban of spanish IP-addresses could be even faster, and I don't think it could harm anybody.
guifi does not fit to the observed hotspots.
Compare https://guifi.net/ca/node/17718/view/map and the pictures in my posting above which are showing the hotspots of the 1043nd issue.
- guifi has concentrations in two locations (shown in blue in below picture): Eastcoast and west of Bilbao.
- the 1043nd issue has concentration around Bilbao (shown in red), a bit in Madrid, but not so much at the eastcost (Barcelona etc.) as one would expect from the guifi-map.
- Logrono has a significant amount of downloads (same range as Barcelona), but is practically non-existent on the guifi-map.
1 Like
Thank you anyways for your efforts!
1 Like
Thanks for your suggestions! I ended up at http://ip-api.com/.
Free, nice and easy, selectable output, 150 requests/min (quite high compared to other services which allow only 1000 / day).
As a next step and temporary remedy to help reduce excessive bandwidth waste, I have a proposal.
By using simple rewrite rules, all references to the specific image file will be re-directed to a small static page with a message and a link to the requested target file. The substitute link can be used to fetch the actual staged image file. By doing the redirection in this manner, it will not interfere with build system uploads and sha256sums. The file name will be slightly different but I think that can be handled by a rename or manual sha256 check by whoever is fetching it. No signatures will be invalidated.
I intend to relay this information to the dev mailing lists and will not put it in effect for a couple of days - waiting for feedback, etc. The static page will probably be something like:
Requested file has been relocated due to excessive download requests by automated processes.
The file you requested can be obtained here: <link-to tl-wr1043nd-v1>
We are sorry for any inconvenience caused by this issue.
While this change is in effect we should continue to pursue the source of the anomalous download requests..
3 Likes
Should you feel that you've reached this page in error.... please email xxx@yyy.zzz with a brief description of your use case, country and $ offer 
The effects of
- blocking a single IP (the one with the by far highest download volume) -> leads to 403
- renaming the 1043nd v1 image to 1043nd V1 -> leads to 404
=> The user behind the blocked IP (403) hasn't noticed anything or at least not changed anything during the past 2 weeks that he is being banned.
Hi again,
I didn't mean this is a usual practice, because I know for sure it is not. So the pattern does not need to follow map.
Good luck and best wishes
maybe i'm wrong, but what if the clients try to load something else and are only redirected to this file since 30.09.2018 ?
apart from that, i don't see a problem with the proposed solution, after all it's a factory image and snapshots, nothing one would consider critical for any kind of use case.
The effects of the redirect are quite impressive:
- Download size dropped to practically zero
- Download count increased (today 27.01. is still young, so not that much counts so far)
The redirects also have an effect on the timing of the download requests:
(right-click on the picture -> show picture)
green: low counts before, higher counts after the redirect
red: peak at 22sec before, peak at 18sec after redirect
yellow: high peaks at 33sec before, lower peak at 30sec after redirect
A bit clearer view via histograms of download counts vs. seconds for 24./26.01.2019
2 Likes
Time for an update, now that the redirect is in effect since some days.
1043nd download count per day
- redirect implemented 25.01.2019
- counts at significantly higher level for 3 days
- today significant drop (todays is not yet over, but anyways...)
1043nd download count per hour
(for details: right-click on the picture -> show picture)
What are we seeing here?
- yellow blocks: 3h intervall; react to the redirect with increased download count
- blue blocks: 3h intervall (except 0700), 1h shifted to the yellow ones; react to he redirect, similar to yellow ones; look almost like a weak echo of the yellow blocks -> see 2100 + 2200
- green blocks: do not react to redirect (until today 20:00)
- since today 1200 significant drop on the yellow, blue + green blocks
20:00 / 21:00 comparison
Let's take a closer look at 2000 (unimpressed by redirect) + 2100 (reacting to redirect)
- wget and uclient-fetch have the same pattern
- 20:00 is completely unimpressed by the redirect - until today
- 21:00 reacts to the redirect with increased download count - until today
- download counts for both 2000 + 2100 drop from previously 1300 / 600 to practically zero today
- note the weekly pattern at 2100: 14 / 21 / 28.01. are Mondays -> increased download count by factor of 2
Should this mass-downloading be over? Maybe.... maybe not...
Take a look at the current download stats:
Suspiciously high download count for the 18.06.1 image.... what do you think?
Yes! We have a reaction!
1043nd 18.06.1 factory download count
and guess where the downloads are coming from... right: Spain!
Where from in Spain? Exactly the cities we already know:
When? Today 11:15 CET
The image that is being downloaded has changed from snapshot to 18.06.1 today at 11:15.
This is centrally managed behaviour. The question is: Who and why (and does he also work on weekends)?
@thess Time for the next redirect?
1 Like