Can Someone Please Ping

[pidd]

Can someone please ping gggg for me and see if you get something like ....

Code: Select all

 ping gggg
PING gggg (92.XXX.XXX.16) 56(84) bytes of data.

(IP disguised)

EDIT: Now confirmed that router received an update which had a bug in dealing with tld domain names. However there are other issues as to why the Pi isn't using MDNS which is the problem that exposed the router bug.

[DarkElvenAngel]

Code: Select all

 
[~]# ping gggg
ping: gggg: Name or service not known
[~]#

There you go

[pidd]

Code: Select all

 
[~]# ping gggg
ping: gggg: Name or service not known
[~]#

There you go

Thank you, my ARP has broken and I was just checking that this was also part of the same problem. Its an unusual address it defaults to, I'm not sure if something hasn't been hacked.

[trejan]

Thank you, my ARP has broken and I was just checking that this was also part of the same problem. Its an unusual address it defaults to, I'm not sure if something hasn't been hacked.

DNS lookups aren't anything to do with ARP. Your DNS server probably has a wildcard record that is matching everything. It is somewhat suspicious though so you should check for malware and misconfiguration. If it is your ISP server then they're likely to be doing stupid wildcard redirections to "help" you find typoed sites i.e. they're serving ads.

Who owns that IP?

[DougieLawson]

Use dig gggg to trace the resolvers that turn gggg into 92.xxx.xxx.16, or dig -x 92.xxx.xxx.16 to do the reverse lookup.

Here's an example (I've redacted my local nameserver address) using an well-known address that does resolve. My domain (at Mythic Beasts does have a wildcard entry).

Code: Select all

dougie@apollo:~$ dig google.com

; <<>> DiG 9.11.5-P4-5.1+deb10u1-Raspbian <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42915
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: bf86ce324c90f5d778edf6ce5f12089ec42c2b221f3ad44f (good)
;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             261     IN      A       172.217.169.46

;; AUTHORITY SECTION:
.                       73464   IN      NS      g.root-servers.net.
.                       73464   IN      NS      d.root-servers.net.
.                       73464   IN      NS      h.root-servers.net.
.                       73464   IN      NS      f.root-servers.net.
.                       73464   IN      NS      c.root-servers.net.
.                       73464   IN      NS      m.root-servers.net.
.                       73464   IN      NS      i.root-servers.net.
.                       73464   IN      NS      b.root-servers.net.
.                       73464   IN      NS      l.root-servers.net.
.                       73464   IN      NS      a.root-servers.net.
.                       73464   IN      NS      e.root-servers.net.
.                       73464   IN      NS      j.root-servers.net.
.                       73464   IN      NS      k.root-servers.net.

;; Query time: 43 msec
;; SERVER: 2002:pppp:pppp:pppp:ba27:ebff:fe85:c936#53(2002:pppp:pppp:pppp:ba27:ebff:fe85:c936)
;; WHEN: Fri Jul 17 20:22:54 UTC 2020
;; MSG SIZE  rcvd: 294

dougie@apollo:~$

Code: Select all

dougie@apollo:~$ dig -x 172.217.169.46

; <<>> DiG 9.11.5-P4-5.1+deb10u1-Raspbian <<>> -x 172.217.169.46
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54068
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: beaf0f3f66c62f00e8b4943e5f1209091985145b47b89887 (good)
;; QUESTION SECTION:
;46.169.217.172.in-addr.arpa.   IN      PTR

;; ANSWER SECTION:
46.169.217.172.in-addr.arpa. 20985 IN   PTR     lhr48s08-in-f14.1e100.net.

;; AUTHORITY SECTION:
.                       73357   IN      NS      l.root-servers.net.
.                       73357   IN      NS      b.root-servers.net.
.                       73357   IN      NS      f.root-servers.net.
.                       73357   IN      NS      g.root-servers.net.
.                       73357   IN      NS      k.root-servers.net.
.                       73357   IN      NS      m.root-servers.net.
.                       73357   IN      NS      e.root-servers.net.
.                       73357   IN      NS      d.root-servers.net.
.                       73357   IN      NS      h.root-servers.net.
.                       73357   IN      NS      i.root-servers.net.
.                       73357   IN      NS      j.root-servers.net.
.                       73357   IN      NS      a.root-servers.net.
.                       73357   IN      NS      c.root-servers.net.

;; Query time: 41 msec
;; SERVER: 2002:pppp:pppp:pppp:ba27:ebff:fe85:c936#53(2002:pppp:pppp:pppp:ba27:ebff:fe85:c936)
;; WHEN: Fri Jul 17 20:24:41 UTC 2020
;; MSG SIZE  rcvd: 331

dougie@apollo:~$

[DarkElvenAngel]

That's an interesting thought I have pi-hole on my network but would you get that response if it's blocked?

I checked the logs I didn't see anything was blocked.

[pidd]

Use dig gggg to trace the resolvers that turn gggg into 92.xxx.xxx.16, or dig -x 92.xxx.xxx.16 to do the reverse lookup.

Thanks Dougie, much appreciated.

Its my router that is serving it up, it does it with any domain you enter that doesn't have a decimal point. Unfortunately that includes all the names of my Pis.

The address appears to belong to a Serbian outfit.

I'm pretty sure the router received an update the other day, whether that came from my ISP or some hacker I am yet to find out.

All three Pis are on a static address assigned at the router, I have avahi disabled in a failed attempt to block multi-cast stuff that I don't want to talk to my Pis.

I think its just poor software update from Sagemon/talktalk but obviously its a worry as to what exactly is going on. I lost my names off my Pis about two days ago..

[DougieLawson]

https://community.talktalk.co.uk/t5/Fib ... -p/2300940

I'd start with a factory reset of your router (then re-enter credentials). Then update firmware with a known good version downloaded from talktalk.co.uk. If TalkTalk allow you to change your ADSl/VDSL2 password then change it. Then read all the other posts in that forum about the 5364.

[trejan]

Its my router that is serving it up, it does it with any domain you enter that doesn't have a decimal point. Unfortunately that includes all the names of my Pis.

Did you set a domain in the Pi or router config that doesn't belong to you? e.g. if you had set microsoft.com as your domain then it would automatically append microsoft.com to any queries that aren't fully qualified with a domain already.

Look in /etc/resolv.conf for any lines that start with search or domain.

[pidd]

Its my router that is serving it up, it does it with any domain you enter that doesn't have a decimal point. Unfortunately that includes all the names of my Pis.

Did you set a domain in the Pi or router config that doesn't belong to you? e.g. if you had set microsoft.com as your domain then it would automatically append microsoft.com to any queries that aren't fully qualified with a domain already.

Look in /etc/resolv.conf for any lines that start with search or domain.

resolv.conf is clean, thanks.

[pidd]

https://community.talktalk.co.uk/t5/Fib ... -p/2300940

I'd start with a factory reset of your router (then re-enter credentials). Then update firmware with a known good version downloaded from talktalk.co.uk. If TalkTalk allow you to change your ADSl/VDSL2 password then change it. Then read all the other posts in that forum about the 5364.

I'm never happy with these backdoors into routers but on the other hand some of the updates are worth while. One thing that talktalk do that I'm not happy with is keep records of all my connected devices and how well they are performing - I'm not sure I signed up to that one!

talktalk don't release the firmware for users to manually install and I can't trust a random download that claims to be correct.

I can ask them to re-install their firmware remotely., they don't even state what the current firmware version is because if they do the forum gets overloaded with "I want the latest firmware" while the roll out is still going on.

Router's log files have been completely messed up for a long time, they are in a random date order and don't seem to delete some of the old logs when the buffer is full. So they are no help to me and I'm pretty sure many records are wrongly date-stamped anyway (there are Raspberry url records in there dated before I had a Pi or joined the forum).

I'm about to have a whinge to talktalk, though I haven't rebooted the router yet - it has to go off for at least 20 mins to make sure open-reach doesn't lower the speed.

[pidd]

https://community.talktalk.co.uk/t5/Fib ... -p/2300940

I'd start with a factory reset of your router (then re-enter credentials). Then update firmware with a known good version downloaded from talktalk.co.uk. If TalkTalk allow you to change your ADSl/VDSL2 password then change it. Then read all the other posts in that forum about the 5364.

Arrrrrgh!!!!

Did a few more checks after rebooting the router .....

Its only the Pis that exhibit this behaviour, not my PC nor my phone. But they can't find my Pis by name either only by IP.

I'm lost, wireshark time.

[trejan]

What is the full IP address anyway?

[pidd]

What is the full IP address anyway?

Just in case it is an innocent bystander and so a bot can't pick it up.

The missing bits are 244 .132

[trejan]

Uh. That IP is a dynamically assigned IP that is owned by a Serbian cable ISP. There shouldn't be any legitimate reason for it to be present on your network. There is something very strange going on with your Pi installs.

What is the output of "host -v gggg"?

[pidd]

Mmmmm, wireshark tells me why the PC doesn't exhibit the same behaviour

Pi4 ping gggg
Pi4 asks router DNS for gggg.lan
router says no
Pi4 then asks router DNS for gggg
router returns the rogue serbian IP

Pi4 ping gggg.gg
Pi4 asks router's DNS
router says no

Pi4 ping bbc.co.uk
Pi4 asks router's DNS
router returns correct IP

PC ping gggg
PC asks MDNS for gggg.local
nobody replies
PC then asks MDNS for gggg
nobody replies

PC ping gggg.gg
PC asks router's DNS
router says no

PC ping bbc.co.uk
PC asks router's DNS
router returns correct IP

I've not bothered duplicating the A and AAAA attempts

So is my Pi asking the wrong question, should it not ask a DNS server for anything not containing a decimal point are they reserved for MDNS? I'll re-enable avahi in case that has an impact.

One thing that is the back of my mind, a couple of nights ago I was reading something about ARP poisoning/spoofing etc and the was a suggestion about a command including the words "no arp" or something similar. I was thinking of trying it but I don't think I did and I can't find it in my bash history - its just a remarkable coincidence of timing perhaps.

[pidd]

Uh. That IP is a dynamically assigned IP that is owned by a Serbian cable ISP. There shouldn't be any legitimate reason for it to be present on your network. There is something very strange going on with your Pi installs.

What is the output of "host -v gggg"?

192.168.1.222 is my router

Code: Select all

$ host -v gggg
Trying "gggg.lan"
Trying "gggg"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65011
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;gggg.				IN	A

;; ANSWER SECTION:
gggg.			0	IN	A	92.XXX.XXX.16

Received 38 bytes from 192.168.1.222#53 in 13 ms
Trying "gggg"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60671
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;gggg.				IN	AAAA

Received 22 bytes from 192.168.1.222#53 in 5 ms
Trying "gggg"
Host gggg not found: 3(NXDOMAIN)
Received 97 bytes from 192.168.1.222#53 in 8 ms

[pidd]

The Pi4 DNS requests were exactly the same with avahi running.

I should have mention its the A record the router gives the rogue serbian IP, the AAAA response occurs after that with no IP and no rejection

[bls]

This all smells like yet another reason why I dislike using my router for DNS and DHCP. Two critical services to in making the network work, and they are enclosed in a (figurative) black box. Better if you're using dd-wrt, but I still don't like these critical services being enclosed, often with no easy programmatic way to get the databases out in a usable format (for migrating to a new router...or better yet, a Pi).

[ejolson]

Can someone please ping gggg for me and see if you get something like ....

Code: Select all

 ping gggg
PING gggg (92.XXX.XXX.16) 56(84) bytes of data.

(IP disguised)

Do you have a domain line in your resolv.conf file? If you put one in, does the problem go away?

[pidd]

Do you have a domain line in your resolv.conf file? If you put one in, does the problem go away?

Now that is interesting, it picked up something that's gone wrong due to actions I have taken so what I thought was a bit of a success is probably not so.

I re-enabled avahi last night and initially it made no difference but a while later pinging gggg correctly reported not available, I need to undo some firewall settings on the other (server) Pi4 to fully enable multicast (even though I want multicast eradicated).

Also last night I put the router back to factory settings before re-configuring it, I isolated from some of the network because I knew its IP would be reset to 192.168.1.1 (its normally 192.168.1.222) colliding with another router. Unfortunately I left the Pi's connect to the (normally 222) router and they picked up 192.168.1.1 nameserver, when I reconnected to the rest of the local network they have retained that that IP using the other router.

So currently I have the following but hopefully a few resets should put that back to 192.168.1.222

Code: Select all

cat /etc/resolv.conf
# Generated by resolvconf
domain lan
nameserver 192.168.1.1

Until I get that sorted I won't know if re-enabling avahi helped or not. Before resetting the router the resolv.conf was correct.

Absolutely regardless of what the Pis are doing the DNS resolver in the router should not be giving me this fixed serbian IP. I have put a whinge on the talktalk forum.

[DougieLawson]

Is there a name server running on port 53 on your RPi?

Use sudo netstat -tlnpu | grep 53

Code: Select all

root@apollo:~# netstat -tlnpu | grep 53
tcp        0      0 10.8.0.1:53             0.0.0.0:*               LISTEN      591/named
tcp        0      0 192.168.3.14:53         0.0.0.0:*               LISTEN      591/named
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      591/named
tcp        0      0 127.0.0.1:953           0.0.0.0:*               LISTEN      591/named
tcp6       0      0 :::53                   :::*                    LISTEN      591/named
tcp6       0      0 ::1:953                 :::*                    LISTEN      591/named
udp        0      0 10.8.0.1:53             0.0.0.0:*                           591/named
udp        0      0 192.168.3.14:53         0.0.0.0:*                           591/named
udp        0      0 127.0.0.1:53            0.0.0.0:*                           591/named

I'm running plain old bind9 (because I can). Note that it listens on both TCP:53 & UDP:53 (and in my case UDP6:53 because I've got IPv6 properly configured).

[pidd]

Is there a name server running on port 53 on your RPi?

Use sudo netstat -tlnpu | grep 53

I've just got my desktop Pi4 back on the right router with avahi running so have a load of MDNS port 5353 but no port 53

Code: Select all

$ sudo netstat -tlnpu | grep 53
udp        0      0 224.0.0.251:5353        0.0.0.0:*                           1371/chromium-brows 
udp        0      0 224.0.0.251:5353        0.0.0.0:*                           1319/libpepflashpla 
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           347/avahi-daemon: r 
udp6       0      0 :::5353                 :::*                                347/avahi-daemon: r 

The server Pi4 gives nothing but I still have port 5353 blocked on that one so I don't think avahi is happy - desperately trying to remember how to use ufw to unblock that port ..... just remembered the line number trick.

[trejan]

It doesn't sound like there is anything wrong with your Pi. It is the router itself that is acting very strange.

Until I get that sorted I won't know if re-enabling avahi helped or not. Before resetting the router the resolv.conf was correct.

Avahi will have no effect on resolv.conf. You still had your Pi connected to the network which meant they picked up the new DNS address from DHCP.

Did you restart the router before you did the factory reset? If you hadn't then the restart as part of the factory reset is likely to be what has fixed the problem for you.

[pidd]

It doesn't sound like there is anything wrong with your Pi. It is the router itself that is acting very strange.

Until I get that sorted I won't know if re-enabling avahi helped or not. Before resetting the router the resolv.conf was correct.

Avahi will have no effect on resolv.conf. You still had your Pi connected to the network which meant they picked up the new DNS address from DHCP.

Did you restart the router before you did the factory reset? If you hadn't then the restart as part of the factory reset is likely to be what has fixed the problem for you.

Yes, I tried a reboot of the router before the factory reset but the problem persists.

I agree it appears to be the router's problem but now I have both the Pi4's back to correct ips, nameservers, avahi running etc I am trying to figure out why my PC chooses MDNS for names without decimal points whereas the Pis go for DNS. If the Pi's did an MDNS request then I'd be able to address them by name again.

Why are names without decimal points are treated differently to names with, if they should be treated differently then the Pi's aren't behaving properly, if they shouldn't be treated differently then the the PC is not behaving properly.