dsldevice.lan? EDITED to add Q. about firewall error message

[#1]

When changing settings in my router yesterday via the web interface, and for the first time, I got a cookie prompt from dsldevice.lan, which I refused because I didn't know what/who it was. I thought perhaps it was my router, but wasn't sure because I have only ever had a cookie prompt from 192.168.1.254 when going into the web interface. A quick search and I think that it is indeed my router, but I wonder; Is there any reason why this dsldevice.lan should want to set a cookie now?
Beside this, I notice today that when I did a trace route the first entry always shows as this:
1    11 ms    99 ms    99 ms  dsldevice.lan [192.168.1.254]
Seems a bit long to me. Could there be something wrong with some setting to cause this 99ms delay?

[#2]

The cookie shouldn't be an issue, but what settings were you changing (and which browser) out of curiosity? The times are not uncommon for these Thomsons it seems, doesn't really mean that much.

[#3]

From the Thomson 585 setup guide:

Quote

Accessing the Thomson Gateway Web Interface Proceed as follows: 1  Open your web browser. 2  Browse to http://dsldevice.lan or to the IP address of your Thomson Gateway (by default: 192.168.1.254).

[#4]

Quote from: Anotherone

The cookie shouldn't be an issue, but what settings were you changing (and which browser) out of curiosity?

Hi Anotherone.
It's an issue for me because it's unusual behaviour. I'm naturally suspicious when anything out of the ordinary goes on with my computer. I don't get why, after what, three or four months of daily logging into my router, sometimes several times a day, and switching the same settings back and forth, it should suddenly decide that instead of cookies from 192.168.1.254 that one should be presented from dsldevice.lan when I've never had one from that (so named) before. Settings were usual ones for gaming that I change every day. Browser is FF. Well, at least I know it's the router now.

Quote from: Anotherone

The times are not uncommon for these Thomsons it seems, doesn't really mean that much.

Perhaps I am misunderstanding something here. Is not the 99ms representative of a ping time, as when one does ping at the prompt and get's ##ms back for the ping time of each packet? Um, I think I am misunderstanding. ...

Quote from: PeeGee

From the Thomson 585 setup guide:

Ah. Further confirmation it is the router. The guide for the TG582n doesn't mention 'dsldevice.lan', just the IP address (which I knew anyway - ironically from the 585 I once had, ha). Thanks for that, anyway.

[#5]

Well the 582n is certainly known as dsldevice.lan as well, though strangely I can't find anything in where it says that! The cookie still shouldn't be an issue but I don't disagree about the sudden strange behaviour which is why I asked what you were changing and which browser.
Any FF or other updates since you last changed those settings? I've never seen a cookie prompt for dsldevice.lan although I do have a session cookie for 192.168.1.254 but never had a prompt for it. Have you changed any FF settings? Most odd.
You aren't misunderstanding about the 99ms time but it's just the device response at that time, it doesn't add to the ping time of any external address you care to ping or do a traceroute on as I expect you've seen.

[#6]

Thanks for that. Yeah, it was confusing me a bit because my ping times were usual and I couldn't understand what was going on there. I did begin to wonder if it could account for the delays I have with speed test uploads starting/not completing.
As for updates, the only one I have done on my gaming OS is to update to FF19.0.0, but this cookie for dsldevice.lan came well after doing that and having been in the interface several times already. In fact, it came right in the middle when I was already logged in to the router and switching to one of the other pages (though I can't remember which it was). The settings I change are simply assigning the port settings for my game, game mode on and ping responder on. In between that I check/clear logs as there is always a delay before the router actually implements my settings (usually ca. 30 seconds), or I may gateway hop and check/clear logs again. Of course when I've finished with the game for the time being I unassign, game mode of, ping responder off and check/clear logs.

[#7]

Quote from: Razer

Perhaps I am misunderstanding something here. Is not the 99ms representative of a ping time, as when one does ping at the prompt and get's ##ms back for the ping time of each packet? Um, I think I am misunderstanding. ...

I believe all Thomson/Technicolour routers will provide a 99ms ping response regardless of the actual response time. The only real ping time you need to worry about are the ones at the end of the traceroute.
Though, I don't have any comments in relation to the other query you've got, sorry!
Regards,
Matt

[#8]

The strange thing is that you only see those times when you do a Traceroute. If you ping the device itself, they are <1ms .

[#9]

So it does. I never realised that.

[#10]

Can someone enlighten me about a particular kind of firewall error message? I have previously asked in another thread and got no answer.
What does this error mean exactly:

Quote

Error Mar 11 16:21:34 FIREWALL replay check (1 of 11): Protocol: ICMP Src ip: 216.240.146.139 Dst ip: 87.113.176.213 Type: Destination Unreachable Code: Port Unreacheable

The way I read this is that the 216 IP address (Evenbalance game server) has tried to ping or contact my computer and the firewall has blocked the attempt. Is that correct?
This is just one entry from a list of 17 of the same type in the space of half an hour or so.

[#11]

That type of ICMP packet - Destination Unreachable - has nothing to do with ping. It would be a perfectly legitimate reply to a UDP packet if there was no server type program waiting to receive UDP packets on that port.
I can only speculate that "replay check" has something to do with duplicate packets. No real idea what "(1 of 11)" means. It's got 11 entries in some table to check the packet against? 11 checks to do? 11 packets waiting in a queue to be checked?

[#12]

OK, so it's not ping. Thanks for that. At least I can forget about that aspect now. I don't understand this, however:

Quote from: ejs

It would be a perfectly legitimate reply to a UDP packet if there was no server type program waiting to receive UDP packets on that port.

Is that to say that as the 216 IP address sent something to me it is my computer or router which could not properly receive or deal with it because it has 'no server type program waiting to receive' the packet on the port?

Quote from: ejs

No real idea what "(1 of 11)" means.

I have assumed that it means 11 tries to send to me at that time. Each of the 17 entries logged at different times in the half hour period has varying amounts.
EDITED to add. I don't know why all these things have to be set up so bloody complicated. Why can't whoever is responsible for these things simply set it to say exactly what it is. i.e. Such and such sent you this, but we can't accept it because ... So do this to fix it. Instead they have to couch everything in gobbledegook and paint it with smoke and mirrors.

[#13]

Quote from: Razer

Is that to say that as the 216 IP address sent something to me it is my computer or router which could not properly receive or deal with it because it has 'no server type program waiting to receive' the packet on the port?

I am assuming that your computer sent something to the 216. IP, but the server on the 216 IP wasn't running, so the 216 IP sent the ICMP message back to you. That assumes the "Src ip" in the log message is referring to the source of the ICMP message.
But that doesn't explain why it triggered the firewall message. It would have to be something along the lines of: your computer sent a UDP packet, didn't get any response at all, sends another UDP packet ... but the 216 IP server did receive them all, and eventually gets around to sending an ICMP response for each one. The router firewall will be expecting responses to sent packets, but only within a certain time limit.

Quote from: Razer

EDITED to add. I don't know why all these things have to be set up so bloody complicated. Why can't whoever is responsible for these things simply set it to say exactly what it is. i.e. Such and such sent you this, but we can't accept it because ... So do this to fix it. Instead they have to couch everything in gobbledegook and paint it with smoke and mirrors.

The ICMP Destination Unreachable packet itself is pretty much "We couldn't accept this packet because 'reason XYZ', followed by the first few bytes of the packet it's a reply to".
The firewall log message is somewhat less helpful.

[#14]

These destination unreachable and similar messages appear to originate from IPs often in China, Russia, and similar that I imagine are rarely, if ever, servers UK users are likely to initiate communications with. My suspicion is that they are not what they seem but attempts to solicit responses from unprotected computers which hackers can then try to exploit.
Of course one could say we all have a virus on our computers that unbeknown to us is phoning home; or perhaps Windows is doing it (do the messages also appear when users run Macs and Linux computers?). But then why would the messages appear at times when the router is the only device that is switched on?

[#15]

Quote from: ejs

I am assuming that your computer sent something to the 216. IP, but the server on the 216 IP wasn't running, so the 216 IP sent the ICMP message back to you. That assumes the "Src ip" in the log message is referring to the source of the ICMP message.

OK, that makes absolute sense to me. Thanks for that. I just wish the message would make that clear instead of making it seem the other way.

Quote from: ejs

But that doesn't explain why it triggered the firewall message.

This is part of my confusion over the whole thing as I have ports forwarded and game mode running. I also can get them when the firewall is disabled in the interface, which really did my head in (I have since learned that apparently disabling the firewall in the interface doesn't actually disable it. Go figure - Thompson router with it's wonderful 'functioning'.

Quote from: ejs

The ICMP Destination Unreachable packet itself is pretty much "We couldn't accept this packet because 'reason XYZ', ...

For those who know that, yes. I was getting at 'for those who don't - plain English please'

Quote from: ejs

The firewall log message is somewhat less helpful.

Yes. Would be nice if it specified which port. I'd have a better idea as I know which ports I'm forwarding.
Spraxyt: What, you mean with a spoofed IP address? I have to say that most of the time these messages are logged in my router I am not getting connections in my game (to which the 216 IP address applies) - i.e. no connections with other players, controlled seemingly by the game servers, is occurring. In fact I always expect to see these kind of entries when there's nothing doing with the game and am only surprised when there aren't such entries. That's not to say they aren't spoofed responses sent from elsewhere, or even that something else isn't going on that just happens to interfere with my game. I do after all run with certain ports open and the ping responder on, so my modem is singing to the world.