08:56 <cruxbot> [xorg.git/3.6]: libinput: update to 1.19.2

09:25 <cruxbot> [opt.git/3.6]: lvm2: update to 2.03.14

09:25 <cruxbot> [core.git/3.6]: gdbm: update to 1.22

09:25 <cruxbot> [core.git/3.6]: libdevmapper: update to 1.02.181

13:04 <stenur> i am pissed by that china survei dingsbums given the etat of the NSA

13:04 <stenur> budget. yawn

13:55 <SiFuh> :-)

13:58 <stenur> ach the older i get. keep on rockin' in the free world, let's read some trump on twitter. https://www.zeit.de/kaenguru-comics/2021-01/folge-37

15:43 <cruxbot> [contrib.git/3.6]: grafana: 8.2.1 -> 8.2.2

15:43 <cruxbot> [contrib.git/3.6]: lxc: 4.0.10 -> 4.0.11

15:43 <cruxbot> [contrib.git/3.6]: media-session: initial commit, version 0.4.0

15:43 <cruxbot> [contrib.git/3.6]: mpd: 0.23 -> 0.23.1

15:43 <cruxbot> [contrib.git/3.6]: notmuch: 0.33.2 -> 0.34

15:43 <cruxbot> [contrib.git/3.6]: [notify] pipewire: 0.3.38 -> 0.3.39; breaking changes inside! look at README.md before updating this port

15:43 <cruxbot> [contrib.git/3.6]: python3-numpy: 1.21.2 -> 1.21.3

15:43 <cruxbot> [contrib.git/3.6]: seatd: corrected changed meson flag to build internal seatd server

16:35 <Guest-69> almost whole day has gone in debugging and i haven't succeeded so i came to ask if anyone has an idea. i also contacted the server owner but he said everything is ok on his side. there are 2 bare metal machines - M1 and M2. both machines have 2 network ports used. port 1 is for WAN, and port 2 is for LAN in a different VLAN. both machines can

16:35 <Guest-69> access WAN through network port 1. i've assigned 10.0.20.0/24 for the LAN network, M1 having 10.0.20.1/eth1 and M2 having 10.0.20.2/eno2. now this is the thing, pinging from M1 to M2 works, however M2 is receiving this traffic on wrong network port, it is coming on the network port that should be used for WAN. looking at ARP on M1 it is visible

16:35 <Guest-69> that the MAC address of M2 is incorrect (10.0.20.2 dev eth1 lladdr 2c:44:fd:7c:80:70 REACHABLE), it should be MAC :71 which corresponds to network port 2, but shows network port 1 MAC :70. it is also visible on M2 with tcpdump that traffic is coming on network port 1. on M2 i can also see the following; "10.0.20.1 dev eno2 FAILED ...... 10.0.20.1

16:35 <Guest-69> dev eno1 lladdr 2c:44:fd:93:f2:f1 STALE ..... xx.xx.xx.1 dev eno1 lladdr 3c:e5:a6:3b:23:57 REACHABLE". it seems that connection was tried over the correct network port 2 (eno2) but failed. i tried flushing arp multiple times. also tried switching IPs for port1/port2 on M2, then LAN works but WAN doesn't. the IP route on M2 is set to 'default via

16:35 <Guest-69> x.x.x.1 dev eth0' which is for WAN. i have been reading about setting up multiple default routes with policy routing, however haven't succeeded yet. last thing. as everything mentioned but if i change only a single thing on M2 attach the LAN IP to WAN interface, in that case M1<->M2 ping works both sides but M1 receives it on port2/LAN, and M2

16:35 <Guest-69> sending it on port1/WAN. does anyone have an idea how would i debug this further? i am fairly new to routing.

16:42 <Guest-69> M1 is running slackware 14.2 since 2014 and hasn't been touched since, M2 is the machine i was setting up the other day running CRUX 3.6.1 kernel 5.14.14. about the last thing where M1 from LAN port can communicate with M2 on WAN port, i find this odd. I do not know how he connected the cables, that's why I tried switching IPs on M2. anyone thinks

16:42 <Guest-69> setting up multiple routing tables should be the right way to go into this, or has a better idea? :/

16:51 <Guest-69> the last odd thing, if he set network ports on both machines into same vlan, how can M2 from WAN port communicate with M1 with LAN port. :/

16:53 <Guest-69> M1 | port1 WAN | port2 LAN ... M2 | port1 WAN | port2 LAN ... I was told M1|port2 and M2|port2 are in same VLAN, how can then M1|port2 communicate with M2|__PORT1__

17:07 <Guest-69> hopefully it's not a cable jungle over there :-D

17:23 <cruxbot> [opt.git/3.6]: rust: 1.55.0 -> 1.56.0

17:37 <cruxbot> [compat-32.git/3.6]: mesa-32: fixed footprint and removed option thats not supported on x86

19:32 <Guest-69> probably a cable jungle. :/

21:08 <SiFuh> Too early in the morning to get my head around that. Probably would have been better in a dpaste or something :-P