You are not logged in.
** This has been solved, the issue was not having configuration files set up for systemd-networkd **
Fresh install. I think this is DNS related.
After the installation of the base system, I installed iwd as a network daemon.
Pinging google.com over wi-fi works fine and it loads in the browser too, however, when trying to ping 8.8.8.8, I get the following error message:
Network is unreachable
Pinging duckduckgo.com or any other website (besides facebook, youtube, archlinux.org and a few others) gives me:
Name or service not known.
Web browsers refuse to load those sites too.
Interestingly enough, I'm able to resolve any website via
$ getent hosts anywebsite.org
However entering the IP to browser doesn't load the site, with Firefox stating Unable to connect.
I'm even able to install any software with pacman with only occasional
Could not resolve host
error message on some mirrors.
After doing some research, I created a symlink with:
ln -sf /run/sytemd/resolve/stub-resolv.conf /etc/resolv.conf
Similar situation to the one described above was the case with the live USB too.
My hosts file:
127.0.0.1 localhost
::1 localhost
127.0.1.1 archsystem.localdomain archsystem
resolv.conf:
# Generated by resolvconf
domain home
nameserver 192.168.0.1
nameserver 2001:730:3ef2::10
nameserver 2001:730:3ef2::11
Changing the first nameserver entry to 8.8.8.8 didn't help.
stub-resolv.conf
nameserver 127.0.0.53
search home
*comments omitted
My systemd-resolved is up and running.
Note: Before I realized this might be DNS related, I tried to reduce the MTU to something like 1400 bytes, however this helped not.
Last edited by patresko (2018-12-12 04:31:39)
Offline
If you cannot ping 8.8.8.8 or reach other domains by IP, this is not a DNS issue. The limited IP resolution probably happens out of the cache.
Post the outputs of
ip a; ip r
and a complete journal from one boot, please.
Offline
ip a:
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
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp3s0f1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 9c:5c:8e:33:af:82 brd ff:ff:ff:ff:ff:ff
3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 10:02:b5:99:6b:dc brd ff:ff:ff:ff:ff:ff
inet6 2a02:ab04:2c6:cd00:1202:b5ff:fe99:6bdc/64 scope global dynamic mngtmpaddr
valid_lft 1128756sec preferred_lft 523956sec
inet6 fe80::1202:b5ff:fe99:6bdc/64 scope link
valid_lft forever preferred_lft forever
ip r gave no output.
journalctl -b:
https://ptpb.pw/3FUU
Last edited by patresko (2018-12-06 07:30:39)
Offline
You've no route and no IPv4 address, wild guess:
systemctl list-unit-files --state=enabled
?
Offline
Here you go, sire.
UNIT FILE STATE
autovt@.service enabled
dbus-org.freedesktop.network1.service enabled
dbus-org.freedesktop.resolve1.service enabled
getty@.service enabled
iwd.service enabled
systemd-networkd-wait-online.service enabled
systemd-networkd.service enabled
systemd-resolved.service enabled
systemd-networkd.socket enabled
remote-fs.target enabled
10 unit files listed.
Offline
Nope.
What do your /etc/systemd/network/* configs look like?
Offline
iwd.service enabled
.....
systemd-networkd.service enabled
Maybe a conflict between iwd & systemd-networkd ?
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Afaiu the systemd-network wiki page you actually *have* to be running either the iwd or the wpa_supplicant service, ie. it won't establish the carrier itself?
Offline
Most of my network knowledge comes from the OSI 7 layer model which was designed when wired connections were normal and wifi non-existant.
I used wifi / wpa2 through frontends like netcfg , windows network management, router webinterfaces and never looked deeper into them.
I checked things and realise now iwd/wpa_supplicant function on layer 1 + layer 2 and don't have a counterpart in wired connections.
systemd-networkd operates on layer 3 and above and needs other stuff to establish layer 1 & 2 connectivity.
iwd & wpa_supplicant are implementations that play a role in provide that connectivity.
TL;DR :
a conflict between iwd & systemd-networkd is impossible by definition.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
@Lone_Wolf:
Thank you for your input.
@seth:
My /etc/systemd/network seems to be empty.
Have I missed something on wiki?
Offline
iwd will only provide you with access to the AP, ie. it establishes the "cable", so to speak.
You'll still have to configure the interface (or let it configure by dhcp) and in case you want to use systemd-networkd for that job, tell it to do so.
https://wiki.archlinux.org/index.php/Sy … ss_adapter
Offline
Thank you so much, this has solved the issue.
Now the question is, why certain bigger sites worked and minor/local didn't.
Offline
Afaiu only "getent hosts anywebsite.org" worked (and apparently only for a limited set of webpages)?
That's only an internal response from the resolver, ie. lilkely resolved's cache.
Offline