So your dig commands for the security.ubuntu.com site are showing a totally correct response and exactly the same from both your Ubuntu machine and from IPFire. It is showing no problem with accessing the website by DNS.
Hi Adolph,
All looks good, except from any of the x86_64 and 9 Ubuntu based SBC’s when update attempted.
No trouble at all with Fedora 34 x84_64 or 3 openSUSE x86_64 boxes.
There is something that’s causing the problem when trying to update from the LAN while there is no problem on Wifi which bypasses the IPfire box.
I notice an identical problem being worked on by you in another post.
I am now on the MiniPC which has Core154 installed.
Everything works! It’s some gremlin in Core 160.
root@sdrbox1:~# aptitude update
Hit Bytemark - Mirror impish InRelease
Hit Bytemark - Mirror impish-updates InRelease
Hit Bytemark - Mirror impish-security InRelease
Hit Bytemark - Mirror impish-backports InRelease
Get: 1 Index of /ubuntu impish-security InRelease [103 kB]
Get: 2 Index of /ubuntu impish-security/main i386 Packages [20.7 kB]
Get: 3 Index of /ubuntu impish-security/main amd64 Packages [81.0 kB]
Get: 4 Index of /ubuntu impish-security/main Translation-en [20.5 kB]
Get: 5 Index of /ubuntu impish-security/main amd64 DEP-11 Metadata [4,680 B]
Get: 6 Index of /ubuntu impish-security/universe i386 Packages [11.5 kB]
Get: 7 Index of /ubuntu impish-security/universe amd64 Packages [15.3 kB]
Get: 8 Index of /ubuntu impish-security/universe Translation-en [8,204 B]
Get: 9 Index of /ubuntu impish-security/multiverse i386 Packages [1,080 B]
Get: 10 Index of /ubuntu impish-security/multiverse amd64 Packages [1,088 B]
Get: 11 Index of /ubuntu impish-security/multiverse Translation-en [324 B]
Get: 12 Index of /ubuntu impish-security/restricted i386 Packages [12.9 kB]
Get: 13 Index of /ubuntu impish-security/restricted amd64 Packages [73.8 kB]
Get: 14 Index of /ubuntu impish-security/restricted Translation-en [10.4 kB]
Fetched 365 kB in 2s (185 kB/s)
Current status: 1 (+1) upgradable, 66324 (+217) new.
root@sdrbox1:~# aptitude full-upgrade
The following packages will be upgraded:
linux-libc-dev
1 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 1,287 kB of archives. After unpacking 8,192 B will be used.
Do you want to continue? [Y/n/?]
Get: 1 Index of /ubuntu impish-security/main amd64 linux-libc-dev amd64 5.13.0-21.21 [1,287 kB]
Fetched 1,287 kB in 1s (1,402 kB/s)
(Reading database … 322418 files and directories currently installed.)
Preparing to unpack …/linux-libc-dev_5.13.0-21.21_amd64.deb …
Unpacking linux-libc-dev:amd64 (5.13.0-21.21) over (5.13.0-20.20) …
Setting up linux-libc-dev:amd64 (5.13.0-21.21) …
Current status: 0 (-1) upgradable.
root@sdrbox1:~#
Still absolutely fine on Core 154 on the MiniPC. I’ll probably swap back to the PC and try Core 161 Beta later in the week.
root@sdrbox1:~# aptitude update
Hit Bytemark - Mirror impish InRelease
Hit Bytemark - Mirror impish-updates InRelease
Hit Bytemark - Mirror impish-security InRelease
Hit Bytemark - Mirror impish-backports InRelease
Hit Index of /ubuntu impish-security InRelease
root@sdrbox1:~# aptitude full-upgrade
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
I am now on core-163 and still experiencing problems. The problem originally seen on Core-160.
If I disable the LAN connection on any PC/SBC and connect to my cable modem via Wifi there is no problem.
PC → IPfire → Cable Modem → (PROBLEM)
PC → Cable Modem via WiFi (AOK).
root@sdrbox1:~# nslookup www.arduino.cc
Server: 127.0.0.53
Address: 127.0.0.53#53
On the IpFire box (No Wifi) – nslookup www.arduino.cc or dig www.arduino.cc return – Connection timed out: no server could be reached.
This is with DNS set to UDP, TLS or TCP.
Looking back over this thread I have found that sdrbox1 is a pc running Ubuntu
I believe that the testing of the dig commands is being done from a lan pc with IPFire either in place or out of loop.
Looking back over the thread it seems to be more related to problems in having apt-get to work properly. @sboyce should confirm if that is still the problem being experienced.
If yes then this could be related to a bug that Ubuntu and Debian have (or have had, I don’t know if it has been fixed in later releases) where if an ipv6 communication occurs from the dns system then Ubuntu will only try to update via ipv6 even if an ipv4 address is provided.
See thread https://community.ipfire.org/t/dns-returning-ipv6-addresses-can-cause-breakage/5595
I ran a test with Ubuntu 20.04.3 which is an LTS release and had no problems with running apt-get update or upgrade. From the thread it looks @sboyce is on Ubuntu Impish which is 21.10, an interim release.
Later on I will test out installing Ubuntu Impish on a vm and see if I have a similar problem or not. I will also test it with aptitude update which is what was used by @sboyce but as far as I am aware aptitude just is a higher level operation of apt-get so the same final program is run.
So I have installed Ubuntu Impish (21.10) on a vm on my vm network which has a vm IPFire running Core Update 163.
I stopped the install doing any package or security updates.
I the successfully installed aptitude and ran it. It highlighted 53 upgradable packages and these were then successfully updated with no issues making connections to the Ubuntu repository.
I did an Ubuntu Server install with no additional packages specified when the list of additional packages was shown.
@sboyce have you modified the config of aptitude or apt-get. So far I have been unable to duplicate the issue you are seeing.
Nothing has been modified on any of the numerous boxes I have. It all happened since I upgraded to Core160 as well as the current MiniPC with Core160 upgraded to Core163.
They are all on the same Gigabit switch getting DHCP addresses from the IPFire box.
The raspios and Ubuntu PC and SBC’s all show the same problem, the openSUSE boxes all cannot resolve ardiono.cc.
openSUSE Tumbleweed x86_64
slipstream:~ # dig www.arduino.cc
; <<>> DiG 9.16.25 <<>> www.arduino.cc
;; global options: +cmd
;; connection timed out; no servers could be reached
slipstream:~ #
However, no problem with the Fedora 35 x86_64 box.
[root@Fedora ~]# dig www.arduino.cc
slipstream:~ # ip r
default via 192.168.10.103 dev enp3s0 proto dhcp metric 100
default via 192.168.0.1 dev wlp9s0f3u4u1 proto dhcp metric 600
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.0.0/24 dev wlp9s0f3u4u1 proto kernel scope link src 192.168.0.11 metric 600
192.168.10.0/24 dev enp3s0 proto kernel scope link src 192.168.10.224 metric 100
192.168.100.0/24 dev virbr1 proto kernel scope link src 192.168.100.1 linkdown
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
slipstream:~ #
[root@Fedora ~]# ip r
default via 192.168.10.103 dev eno1 proto dhcp metric 100
default via 192.168.0.1 dev wlp2s0 proto dhcp metric 600
192.168.0.0/24 dev wlp2s0 proto kernel scope link src 192.168.0.13 metric 600
192.168.10.0/24 dev eno1 proto kernel scope link src 192.168.10.220 metric 100
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
[root@Fedora ~]#
The fact that you have the problem also with OpenSUSE rules out any issue with the apt-get bug because OpenSUSE uses YaST.
Can you confirm if you only have a problem with certain websites like the Ubuntu Package Update servers and www.arduino.cc but other websites can be accessed with no problems on those affected OS’s or are they unable to access any websites?
running an OpenSuSE machine behind IPFire as well, I just tried to reproduce the issue with www.arduino.cc (while I did not experience notable DNS issues on that operating system combination before).
Did not work tough…
$ dig soa www.arduino.cc
; <<>> DiG 9.16.6 <<>> soa www.arduino.cc
;; global options: +cmd
;; connection timed out; no servers could be reached
… but for a different reason:
[root@maverick ~]# grep ".cc TLD" /var/log/suricata/fast.log
02/21/2022-23:15:43.594855 [Drop] [**] [1:2027758:5] ET DNS Query for .cc TLD [**] [Classification: Potentially Bad Traffic] [Priority: 2] {UDP} x:37883 -> x:53
02/21/2022-23:15:48.588608 [Drop] [**] [1:2027758:5] ET DNS Query for .cc TLD [**] [Classification: Potentially Bad Traffic] [Priority: 2] {UDP} x:37883 -> x:53
02/21/2022-23:15:53.590232 [Drop] [**] [1:2027758:5] ET DNS Query for .cc TLD [**] [Classification: Potentially Bad Traffic] [Priority: 2] {UDP} x:37883 -> x:53
While this might be a bit off-topic, I think it makes sense to double-check the IPS configuration, to avoid it to drop DNS queries (in addition to the actual bug we are trying to track down here). Just thought I’d mention that…
No problem with any other website.
Fedora 35 does something smart, if both LAN and Wifi are up, it gets to www.arduino.cc via Wifi, fails the same as every other box if Wifi is down.
From IPfire
[root@ipfire ~]# ping www.arduino.cc
ping: www.arduino.cc: Name or service not known
[root@ipfire ~]#
