Anybody know about hacked routers?

kwikbreaks

spannerzone wrote: »

Powering off the router every night might end up with poor ADSL speeds as the exchange might see this regular disconnection as a line fault / poor performance and will possibly drop the speeds lower and lower in an automated attempt to improve reliability of the connection.

How many times is this hoary old chestnut going to arise? Do you honestly believe that the software designers of the line management software just plain forgot that some people turn their kit off overnight.

wongataa

kwikbreaks wrote: »

How many times is this hoary old chestnut going to arise? Do you honestly believe that the software designers of the line management software just plain forgot that some people turn their kit off overnight.

I have personally seen connection speeds rise when a router was left on all the time instead of being switched of at night. It can happen.

grumpycrab

Fightsback wrote: »

The TP-Link TD-W8960N is way past support cut off depending on the hardware version (v1-v7) and has known vulnerabilities, I wouldn't waste any more time on it.

I'm assuming it's probably a V1 or V2.

V2. As soon as I saw it I thought -put a new router in ASAP- which I did. It would have been interesting to find the culprit (most seem to think the data was sucked through wifi but even then it must have been hacked somehow -the password had been changed recently and was the highest available on that box. WPA-PSK).

spannerzone

kwikbreaks wrote: »

How many times is this hoary old chestnut going to arise? Do you honestly believe that the software designers of the line management software just plain forgot that some people turn their kit off overnight.

Well it certainly has happened to users, it may well be a lot more speeded up in recovery of speeds these days.

As for what i believe software designers might forget, I have no idea but can make a guess or two based on some absolute dog poop software I've used over the last couple of decades, you must have used WinME and Win Vista right?

Cycrow

Even if the software developes knew about it, doesn't mean they can make the software detect it.

afterall, to the software, theres no difference between a broken line and a router being switched off. In both cases they wont receive a signal back

ChiefGrasscutter

Cycrow wrote: »

afterall, to the software, theres no difference between a broken line and a router being switched off. In both cases they wont receive a signal back

Yes there is:
Routers are meant to issue a 'dying gasp' signal back to the exchange when they are deliberatly switched off by the user at the off button on the router which will be different to when the line is suddenly cut either by the mains failing/plug in wall being pulled out or by the connection to the exchange being severed.
How many correctly implement this of course in another case!

Poor performing and long lines may benefit from being switched off each night as the worse atmospheric electrical disturbances from the rise in the Heaviside layer in the atmosphere at night due to the solar wind will not be disturbing the router from the increased general noise level on the line. This may cause the router to 'hiicup' overnight and reduce the line speed
Other lines may benefit from being left on all the time as the length of time of undisturbed operation per day will be continuous rather than say 10 hours. This means for lines with low error counts on them any small disturbances/interference which might occur will be ignored as it forms a very small % of the overall unit connected uptime per sampling period. This will not be the case for those lines only 'up' a few hours per day.

kwikbreaks

Multiple disconnects over a short period or simply yanking the phone connection out can certainly lead to problems on lines with BT DLM. A proper router power down shouldn't. Even without the "dying gasp" a single power off at night and a power on in the morning is very easy to detect as not being a line fault condition.

DLM isn't perfect and many LLU providers simply don't have any and manually apply a higher default noise margin if there are problems reported.

I have never powered mine down but used to spend a fair time on a few different boards covering ADSL and have never seen an authenticated report of the DLM being cockeyed enough to decrease the sync purely because of overnight power downs.

spannerzone

kwikbreaks wrote: »

Multiple disconnects over a short period or simply yanking the phone connection out can certainly lead to problems on lines with BT DLM. A proper router power down shouldn't. Even without the "dying gasp" a single power off at night and a power on in the morning is very easy to detect as not being a line fault condition.

DLM isn't perfect and many LLU providers simply don't have any and manually apply a higher default noise margin if there are problems reported.

I have never powered mine down but used to spend a fair time on a few different boards covering ADSL and have never seen an authenticated report of the DLM being cockeyed enough to decrease the sync purely because of overnight power downs.

Well thanks for taking the time to write that, which was a bit more helpful than your earlier post

AndyPix

grumpycrab wrote: »

-the password had been changed recently and was the highest available on that box. WPA-PSK).

The WPA(2) password is completely irrelevant if you still have WPS enabled.
Cracking it is a trivial matter, it doesn't matter how complex it is, brute forcing the WPS pin (just the first 4 digits of it) will force the router to reveal the WPA key.

This is a known vulnerability in the WPS system.
If you absolutely must leave it turned on, then at least set a PIN attempt rate limit,
so for example no more than 4 pins can be tried in 1 minute, or the router will lock down WPS for the next 10 minutes for example.
This will greatly extend the time required to crack it - but cracking it is still possible

grumpycrab

Ok, since OP I put a different router in (another old TP LINK) but disabled wi-fi. Its been fine for 4 days. (finger pointing to compromised wifi). Put a new router in today. Enabled wifi. Will monitor it.

Re. the original router, I plugged it in for a few mins and turned all the logging I could find on. Lots of Kernel intrusions, possibly normal. Log extract below...

[FONT=&quot]Nov 30 13:49:25[/FONT]
[FONT=&quot]daemon[/FONT]
[FONT=&quot]err[/FONT]
[FONT=&quot]user: tr69c: Unable to retrieve attributes in scratch PAD[/FONT]
[FONT=&quot]Nov 30 13:49:25[/FONT]
[FONT=&quot]daemon[/FONT]
[FONT=&quot]err[/FONT]
[FONT=&quot]user: Stored Parameter Attribute data is corrupt or missing[/FONT]
[FONT=&quot]Nov 30 13:49:35[/FONT]
[FONT=&quot]user[/FONT]
[FONT=&quot]alert[/FONT]
[FONT=&quot]kernel: Intrusion -> IN=ppp_0_0_38_1 OUT= MAC= SRC=91.236.75.4 DST=80.175.82.89 LEN=40 TOS=0x00 PREC=0x00 TTL=244 ID=54321 PROTO=TCP SPT=45239 DPT=8080 WINDOW=65535 RES=0x00 SYN URGP=0[/FONT]
[FONT=&quot]Nov 30 13:50:17[/FONT]
[FONT=&quot]user[/FONT]
[FONT=&quot]notice[/FONT]
[FONT=&quot]igmp[814]: setsockopt- MRT_DEL_MFC[/FONT]
[FONT=&quot]Nov 30 13:50:17[/FONT]
[FONT=&quot]user[/FONT]
[FONT=&quot]debug[/FONT]
[FONT=&quot]igmp[913]: iptables -t filter -I FORWARD 1 -i ppp_0_0_38_1 -d 224.0.0.2 -j DROP 2>/dev/null[/FONT]
[FONT=&quot]Nov 30 13:50:17[/FONT]
[FONT=&quot]user[/FONT]
[FONT=&quot]debug[/FONT]
[FONT=&quot]igmp[915]: iptables -t filter -D FORWARD -i ppp_0_0_38_1 -d 224.0.0.2 -j ACCEPT 2>/dev/null[/FONT]
[FONT=&quot]Nov 30 13:50:17[/FONT]
[FONT=&quot]user[/FONT]
[FONT=&quot]notice[/FONT]
[FONT=&quot]igmp[814]: setsockopt- MRT_DEL_MFC[/FONT]
[FONT=&quot]Nov 30 13:50:17[/FONT]
[FONT=&quot]user[/FONT]
[FONT=&quot]notice[/FONT]
[FONT=&quot]igmp[814]: setsockopt- MRT_DEL_MFC[/FONT]
[FONT=&quot]Nov 30 13:50:17[/FONT]
[FONT=&quot]user[/FONT]
[FONT=&quot]debug[/FONT]
[FONT=&quot]igmp[917]: iptables -t filter -I FORWARD 1 -i ppp_0_0_38_1 -d 224.0.0.22 -j DROP 2>/dev/null[/FONT]
[FONT=&quot]Nov 30 13:50:17[/FONT]
[FONT=&quot]user[/FONT]
[FONT=&quot]debug[/FONT]
[FONT=&quot]igmp[919]: iptables -t filter -D FORWARD -i ppp_0_0_38_1 -d 224.0.0.22 -j ACCEPT 2>/dev/null[/FONT]
[FONT=&quot]Nov 30 13:50:17[/FONT]
[FONT=&quot]user[/FONT]
[FONT=&quot]notice[/FONT]
[FONT=&quot]igmp[814]: setsockopt- MRT_DEL_MFC[/FONT]
[FONT=&quot]Nov 30 13:50:41[/FONT]
[FONT=&quot]user[/FONT]
[FONT=&quot]alert[/FONT]
[FONT=&quot]kernel: Intrusion -> IN=ppp_0_0_38_1 OUT= MAC= SRC=37.58.75.46 DST=80.175.82.89 LEN=60 TOS=0x00 PREC=0x00 TTL=53 ID=2842 DF PROTO=TCP SPT=38841 DPT=80 WINDOW=14600 RES=0x00 SYN URGP=0[/FONT]
[FONT=&quot]Nov 30 13:51:12[/FONT]
[FONT=&quot]user[/FONT]
[FONT=&quot]alert[/FONT]
[FONT=&quot]kernel: Intrusion -> IN=ppp_0_0_38_1 OUT= MAC= SRC=66.240.192.138 DST=80.175.82.89 LEN=40 TOS=0x00 PREC=0x00 TTL=109 ID=30898 PROTO=TCP SPT=34680 DPT=8098 WINDOW=42616 RES=0x00 SYN URGP=0[/FONT]
[FONT=&quot]Nov 30 13:52:43[/FONT]
[FONT=&quot]user[/FONT]
[FONT=&quot]alert[/FONT]
[FONT=&quot]kernel: Intrusion -> IN=ppp_0_0_38_1 OUT= MAC= SRC=71.6.167.142 DST=80.175.82.89 LEN=40 TOS=0x00 PREC=0x00 TTL=109 ID=44352 PROTO=TCP SPT=16592 DPT=11211 WINDOW=60182 RES=0x00 SYN URGP=0[/FONT]
[FONT=&quot]Nov 30 13:53:00[/FONT]
[FONT=&quot]user[/FONT]
[FONT=&quot]alert[/FONT]
[FONT=&quot]kernel: Intrusion -> IN=ppp_0_0_38_1 OUT=ppp_0_0_38_1 SRC=60.168.68.32 DST=80.175.82.91 LEN=60 TOS=0x00 PREC=0x00 TTL=51 ID=59719 DF PROTO=TCP SPT=46151 DPT=23 WINDOW=5840 RES=0x00 SYN URGP=0[/FONT]
[FONT=&quot]Nov 30 13:53:03[/FONT]
[FONT=&quot]user[/FONT]
[FONT=&quot]alert[/FONT]
[FONT=&quot]kernel: Intrusion -> IN=ppp_0_0_38_1 OUT=ppp_0_0_38_1 SRC=60.168.68.32 DST=80.175.82.91 LEN=60 TOS=0x00 PREC=0x00 TTL=51 ID=59720 DF PROTO=TCP SPT=46151 DPT=23 WINDOW=5840 RES=0x00 SYN URGP=0[/FONT]
[FONT=&quot]Nov 30 13:53:09[/FONT]
[FONT=&quot]user[/FONT]
[FONT=&quot]alert[/FONT]
[FONT=&quot]kernel: Intrusion -> IN=ppp_0_0_38_1 OUT=ppp_0_0_38_1 SRC=60.168.68.32 DST=80.175.82.91 LEN=60 TOS=0x00 PREC=0x00 TTL=51 ID=59721 DF PROTO=TCP SPT=46151 DPT=23 WINDOW=5840 RES=0x00 SYN URGP=0[/FONT]

[FONT=&quot] [/FONT]