You are not logged in.
Hello everyone! I got a problem with arch networking on a vps server.
The tl;dr: is from a timespan of 1 to 3 week every incoming connection is immediately closed.
Everything starts on 21-feb; I did a system upgrade (full list below the post); I rebooted and discovered that I can't get incoming connection.
The server reply to pings, but the nginx and sshd connection were dropped just after connecting (connection reset on clients). I update the vps every 2-3 weeks, and check the news before, and nothing about networking showed up.
I started digging on the problem, with the guys of the provider that patiently were trying stuff with me (slowly because this is a free-time vps, so I couldn't reply to their request during work-time).
I discovered that I can get incoming connection in the arch install medium (it's 2014-05 disc, opening nc -l -p 9999 -nv and connecting to it from my machine), but not on the arch system.
I did a backup of the data (the server can connect to external networks) and decided to start fresh again, so installed with:
mkfs.ext4 /dev/sda1
mount /dev/sda1
pacman -Sy pacman
pacman-db-upgrade
pacman-keys --refresh-keys
pacstrap /mnt base grub gnu-netcat
genfstab -p /mnt > /mnt/etc/fstab
arch-chroot /mnt
grub-mkconfig -o /boot/grub/grub.cfg
grub-install /dev/sdaI restarted the server and started the network as stated in this post (I got my share of networking issues on the first setup with systemd-networkd): https://bbs.archlinux.org/viewtopic.php?pid=1510472
ip addr add 1.2.3.4 dev ens3
ip link set dev ens3 up
ip route add 5.6.7.8/32 dev ens3
ip route add default via 5.6.7.8And then started again with netcat the tests and got a connection reset again.
Now I'm stuck, I can't get incoming connections working.
Any help is really appreciated at this point.
If anyone want to try I can share vnc credentials and all.
Upgrade package list:
archlinux-keyring (20160123-1 -> 20160215-1)
glibc (2.22-3 -> 2.22-4)
gcc-libs (5.3.0-3 -> 5.3.0-4)
gnutls (3.4.8-1 -> 3.4.9-1)
libcap (2.24-2 -> 2.25-1)
coreutils (8.24-1 -> 8.25-1)
ca-certificates-mozilla (3.21-1 -> 3.22-1)
aria2 (1.19.3-1 -> 1.20.0-1)
bind-tools (9.10.3.P3-1 -> 9.10.3.P3-3)
curl (7.47.0-1 -> 7.47.1-1)
gcc (5.3.0-3 -> 5.3.0-4)
git (2.7.0-1 -> 2.7.1-1)
grep (2.22-1 -> 2.23-1)
htop (1.0.3-3 -> 2.0.0-2)
http-parser (2.6.0-1 -> 2.6.1-1)
nss (3.21-1 -> 3.22-1)
jre8-openjdk-headless (8.u72-1 -> 8.u74-1)
libgcrypt (1.6.4-1 -> 1.6.5-1)
libsystemd (228-3 -> 229-2)
luajit (2.0.4-1 -> 2.0.4-2)
nano (2.5.1-1 -> 2.5.2-1)
nodejs (5.5.0-1 -> 5.6.0-1)
npm (3.6.0-1 -> 3.7.3-1)
pacman-mirrorlist (20160124-1 -> 20160208-2)
python-pyparsing (2.0.7-1 -> 2.1.0-1)
python-packaging (16.0-1 -> 16.2-1)
python-setuptools (1:19.7-1 -> 1:20.1.1-1)
strace (4.10-2 -> 4.11-1)
systemd (228-3 -> 229-2)
systemd-sysvcompat (228-3 -> 229-2)
tre (0.8.0-3 -> 0.8.0-4)
vim-runtime (7.4.1190-1 -> 7.4.1294-1)
vim (7.4.1190-1 -> 7.4.1294-1)Offline
I also have such a problem on my server. I noticed it yesterday, but I am not sure when it could have begun. Seafile will drop its connection to the server all the time, only showing a green light for a brief moment every now and then. Radicale and Taskwarrior server simply refuse to connect, unless restarted and immediately connecting, then they will work for the first few seconds after which the connection is dropped again. The website part for Seafile (using Nginx) displays the same behaviour; once restarted the page starts loading for a few second, and after that it refuses to connect to any page on the web server.
Connecting through SSH on the local network is working without any hiccups, though. This connection doesn't get dropped. Pinging Google dot com from the server is without any drops of connection also.
The only funny thing I've noticed is that after booting the machine (I've rebooted numerous times now), systemd jobs are stated as started "4 days ago" even though the machine just came online. Does this happen to you as well?
Maybe this has something to do with systemd 229-3? Not sure if any other package got upgraded recently which could have caused this.
Offline