I just started using a pi2 v1.1. It's old, I know. I'd buy and use a 4, but can't get my hands on one.
I loaded the pi2 with a fresh raspbian (bullseye) lite using the imager. I updated everything with an apt get.
When I ping, I get strange behavior, depending on the site I ping. Ping doesn't work for big sites like yahoo, Google, or Microsoft. For example,
$ ping www.yahoo.com
PING www.yahoo.com(media-router-fp73.prod.media.vip.bf1.yahoo.com (2001:4998:124:1507::f000)) 56 data bytes
^C
--- www.yahoo.com ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 57ms
Google and Microsoft have similar behavior where the ping doesn't go to an IP address but rather another domain. However, ping does work as expected for other sites, e.g.
$ ping www.longform.org
PING longform.org (165.227.71.159) 56(84) bytes of data.
64 bytes from 165.227.71.159 (165.227.71.159): icmp_seq=1 ttl=43 time=39.8 ms
64 bytes from 165.227.71.159 (165.227.71.159): icmp_seq=2 ttl=43 time=39.3 ms
64 bytes from 165.227.71.159 (165.227.71.159): icmp_seq=3 ttl=43 time=39.0 ms
^C
--- longform.org ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 5ms
rtt min/avg/max/mdev = 38.996/39.364/39.821/0.342 ms
When I ping using my laptop, I get the expected behavior for yahoo.com, google.com, etc. For example:
$ ping www.yahoo.com
PING new-fp-shed.wg1.b.yahoo.com (74.6.231.21): 56 data bytes
64 bytes from 74.6.231.21: icmp_seq=0 ttl=48 time=57.075 ms
The output of resolv.conf is
domain home
nameserver 192.168.1.1
nameserver 2607:f428:ffff:ffff::2
nameserver 2607:f428:ffff:ffff::1
I've tried the following on the pi:
--changed the /etc/dhcpcd.conf to explicitly include Cloudfare DNS. The resolv.confis now
domain home
nameserver 8.8.4.4
nameserver 8.8.8.8
nameserver 2607:f428:ffff:ffff::2
nameserver 2607:f428:ffff:ffff::1
No dice.
--installed the legacy buster lite. No dice. Also changed resolv.conf on the buster lite. Still no dice.
Any help would be greatly appreciated!
EDIT 1) dig appears to give the correct information:
$ dig www.yahoo.com
; <<>> DiG 9.11.5-P4-5.1+deb10u8-Raspbian <<>> www.yahoo.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58321
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.yahoo.com. IN A
;; ANSWER SECTION:
www.yahoo.com. 31 IN CNAME new-fp-shed.wg1.b.yahoo.com.
new-fp-shed.wg1.b.yahoo.com. 31 IN A 74.6.231.21
new-fp-shed.wg1.b.yahoo.com. 31 IN A 74.6.143.26
new-fp-shed.wg1.b.yahoo.com. 31 IN A 74.6.231.20
new-fp-shed.wg1.b.yahoo.com. 31 IN A 74.6.143.25
;; Query time: 24 msec
;; SERVER: 8.8.4.4#53(8.8.4.4)
;; WHEN: Tue Dec 27 15:11:24 GMT 2022
;; MSG SIZE rcvd: 138
And, just to confirm, ping still doesn't work properly:
$ ping www.yahoo.com
PING www.yahoo.com(media-router-fp74.prod.media.vip.ne1.yahoo.com (2001:4998:44:3507::8001)) 56 data bytes
^C
--- www.yahoo.com ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 118ms
$ ping 74.6.231.21
PING 74.6.231.21 (74.6.231.21) 56(84) bytes of data.
64 bytes from 74.6.231.21: icmp_seq=1 ttl=48 time=60.2 ms
EDIT 2) Going to the full raspbian (bullseye) "Raspberry Pi OS with desktop" gives no change in behavior
EDIT 3) Using systemd-networkd installed by following https://raspberrypi.stackexchange.com/a/108593/151115 led to a very, very slow, but ultimately successful ping for www.longform.org and the same behavior as before for www.yahoo.com
EDIT 4) altering resolv.conf to only Cloudflare or Google still led to weird non-IP addresses being used for yahoo.com, etc.
EDIT 5) using the 2015-01-31 raspian OS resolves the issue. I don't know what it is about this distro that makes the problem go away. I'd really rather not use such old an old OS (for security reasons). Any ideas would be much appreciated!
EDIT 6) as requested by @Milliways, the result of ip a is
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether b8:27:eb:f2:57:12 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.243/24 brd 192.168.1.255 scope global dynamic noprefixroute eth0
valid_lft 258451sec preferred_lft 226051sec
3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500
link/none
inet 10.130.173.1/24 scope global tun0
valid_lft forever preferred_lft forever
4: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
link/none
inet 10.255.128.1/24 scope global wg0
valid_lft forever preferred_lft forever
and the result of ip r is
default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.243 metric 202
10.130.173.0/24 dev tun0 proto kernel scope link src 10.130.173.1
10.255.128.0/24 dev wg0 proto kernel scope link src 10.255.128.1
192.168.1.0/24 dev eth0 proto dhcp scope link src 192.168.1.243 metric 202
The above is with my fully updated bullseye setup with IPv6 disabled as described in my comment below @Milliway's answer. Current output of resolv.conf is
domain home
nameserver 192.168.1.1
