djurny

Hi there, Then I would advise to try to: bridge NIC1 and NIC2, then configure the resulting bridge interface br0 to 192.168.100.101/24 configure 'device 1' to 192.168.100.102/24 or some other IP address that does not overlap/conflict with any other device on the 192.168.100.0/24 network. This setup should present "one interface" to the 192.168.100.0/24 network, pulling 'device 1' into the network as it were. I'm not sure if you have to enable ip forwarding in case you create a bridge, my experience with bridge (both networking and card wise) is limited. Groetjes, Btw, there has to be a reason why PC1 and the gateway/router in the red box are not able to be changed 😉 Perhaps the people that set it up that way were actively trying to prevent fanning out into different additional networks. (I know many employers do not allow this on their office network for example, for very good reasons...)

Not to forget this: What is your endgoal here? You just want to ping 'device 1' from PC1 ? Or you want to connect to 'device 1' from PC1 using some protocol? Gr,

Hi there, You could try to change 10.10.10.0/24 to 192.168.100.0 but this can cause IP overlap if you do not have control over the 192.168.100.0/24 network. If NIC1 and NIC2 are part of the same network, you will have to make sure that all traffic to the default gateway will exit via NIC1, `ip route` should show the device it will use. I do not have any experience with setting up bridge networks, perhaps someone else can help with that - using bridge containing both NIC1 and NIC2 might be the easiest way, but you will have to fix/work the IP address overlap it will create. (link: https://www.baeldung.com/linux/bridging-network-interfaces) Hope that helps, Groetjes,

Hi there, In this setup with these networks you specified, it is really PC1 - or the gateway/router in the red box that need to know where to send packets to for 10.10.10.0/24. This is usually done by a static route on the gateway/router, or by adding a hop in the routing on PC1. If neither know where packets for 10.10.10.0/24 need to go to, they will be forwarded to the default route of firstly PC1 (which is the gateway) and on the gateway/router's default route. If you can change neither, you will need to think about more exotic solutions, like setting up an ssh tunnel from PC1 and using rocky linux as a jumphost. Or, as you also imply, perhaps bridging 192.168.100.0/24 with 10.10.10.0/24, which (i think) will chaning 10.10.10.0/24 to a subnet of 192.168.100.0/24. What are your options/abilities in PC1 here? What can you change and what not? Do you have administrator rights for example? Can you run/install cygwin or any windows flavor of ssh for example? What is the WAN side of the gateway/router? The internets or some other network? What can also work is to put 'device 1' in that network, if all you need is to ping it. Groetjes,

Hi there, To make it more clear: On PC1: [As administrator] Add a route/hop via 'rocky linux' for packets destined for 10.10.10.0/24 https://www.howtogeek.com/22/adding-a-tcpip-route-to-the-windows-routing-table/ route ADD 10.10.10.0 MASK 255.255.255.0 192.168.100.101 On 'rocky linux' Raspberry Pi: Enable IPv4 forwarding: sudo sysctl -w net.ipv4.ip_forward=1 Add masquerading for NIC2 (10.10.10.1): sudo iptables -t nat -A POSTROUTING -j MASQUERADE -o enp4s0 Or use the firewall-cmd thing, which you posted: sudo firewall-cmd --zone=public --add-masquerade Then try to ping 'device 1' from PC1 once more. The traceroute should show nexthop to be 'rocky linux' for any IP address in the range 10.10.10.0/24 if you configured the route/hop on PC1 correctly. Groetjes,

Hi there, Ah so PC1 is windows based? You need to set the route to 'rocky linux' on that box. Some googling shows you can add a route on windows: https://www.howtogeek.com/22/adding-a-tcpip-route-to-the-windows-routing-table/. I do not have any Windows PCs around to test this out though. Is your goal to only ping 'device 1' ? I presume that you have other things in mind that just pinging 'device 1' ? Another route you can try is to connect from PC1 to a specific port on 'rocky linux' and then have that port traffic forwarded/NATed to 'device 1'. Have not done that myself ever, but let's see. Groetjes,

Hi there, Not sure about the syntax of `firewall-cmd`, but you should only masquerade on the NIC connected to the 10.10.10.0/24 network, as masquerading does have some performance impact to/from that NIC. Seems you need to check which `zones` are defined and create a `zone` to only cover NIC2 on 'rocky linux'. For the `route` command, you can use the "new" `ip route` way: # type on PC1 sudo ip route add 10.10.10.0/24 via 192.168.100.101 This will tell PC1 to throw packets that are destined to reach the 10.10.10.0/24 network towards 'rocky linux''s NIC1. No, masquerading is done on the destination address of the IP packet, it will not change any source/destination port number. Masquerade here uses NAT, port is not translated. Groetjes,

Hi there, Ah that diagram changes things a little. You would need to add a route to PC1, so that it knows to send packets for device 1 via 'rocky linux'. sudo route add -net 10.10.10.0/24 gateway 192.168.100.101 That will make sure packets with destination 10.10.10.0/24 will be sent to 'rocky linux'. Then on 'rocky linux' the forwarding should handle forwarding those packages from NIC1 to NIC2. You will have NIC2 masquerade outgoing packets as 10.10.10.1 instead of the real source address 192.168.100.102, so 'device 1' will respond to 10.10.10.1 instead of 192.168.100.102 - as 'device 1' has no default route. Then on 'device 1', packets will arrive from "masqueraded" NIC2 10.10.10.1 and it should respond accordingly. Then on 'rocky linux' responses from 'device 1' will be received on NIC2, conntrack will know where the packet originally came from and send stuff back to 'PC1' This should work, but this is a little messy 🙂 Do ping back here! Groetjes,

Hi there, The `net.ipv4.ip_forward=1` will make the packets coming in on NIC1 be routed/sent to NIC2 due to the destination fitting in the network, but the device on NIC2 will not know how to send return packets to 192.168.100.*/24 as it does not have any fitting directly connected networks. Usually you could use default gateway/route to point them back to the Pi, but you said you cannot configure that. Try the following on the Pi: sudo iptables -t nat -A POSTROUTING -j MASQUERADE -o enp4s0 That should enable NAT on NIC2, which will masquerade any packet sent from NIC2 with "source address" 10.10.10.*/24 which it does know how to talk to. Btw, can you confirm the following was indeed the output of `ip route`: 10.10.10.10/24 dev enp4s0 proto kernel scope link src 10.10.10.2 metric 100 One would expect 10.10.10.0/24 as network instead of 10.10.10.10/24. Groetjes,

Hi there, Not sure if your question is complete, are both NIC1 and NIC2 in the same PC1 ? (NIC being network interface controller/card.) If NIC1 and NIC2 are both in the same computing node, the routes should be there already, if the configuration is plain and not something funky. Can you share the output of `ip a s` and `ip route` ? Also, do you have any firewall enabled? Gr,

Hi @Ed van den Enden, Looks like the on-chip RTC is used for initial time-setting by the kernel in your case. It also seems that the overlay to enable i2c is now loaded correctly! I can help with two options, you can choose which one you want to use: Option 1: Use the `rtc-sync` script with the cronjob and systemd modification. Option 2: Use the user-overlay that will move the I2C "external" RTC to the first slot, naming it `rtc0`. The on-chip RTC will move to the second slot, `rtc1`. Option 1 will need more modifications in your configuration, but will work nonetheless. You can find the script attached here: Put the rtc-sync script in /usr/local/sbin/. Change onwership/permissions: sudo chown root:staff /usr/local/sbin/rtc-sync sudo chmod 0775 /usr/local/sbin/rtc-sync Create the cronjob /etc/cron.d/rtc-sync as follows: #min hr mon day dow run-as command 30 * * * * root /usr/local/sbin/rtc-sync -Ad update Modify ntp service unit file by adding the following to the end of the file (/lib/systemd/system/ntpsec.service OR /lib/systemd/system/ntp.service depending on which ntp package you have installed): # Added to sync wallclock to an external RTC [Service] ExecStartPre=-/usr/local/sbin/rtc-sync -A -d start ExecStopPost=-/usr/local/sbin/rtc-sync -A -d stop Option 2 will require adding the user-overlay file and changing only your armbianEnv.txt. I can only give you the user-overlay i used that works for the orangepi zero, but as this uses the same CPU as your board, it should work. if it does not work, you will always have option 1 as fallback. You can find the user-overlay (rtc1-soc.dts) and the instruction on how to compile and add this to armbianEnv.txt in this topic here: The user-overlay is also included down here: In addition to the user-overlay, you will also need to disable the `fake-hwclock` service, as that tries to emulate a real RTC by reloading the last known wallclock from a file that was created when the system was shutdown/rebooted. Instructions for this also in the same linked topic. Pick your option and try it out. If it all works well, for option 2 you will find that the i2c RTC is named rtc0, for option 1 you will see i2c RTC is still rtc1, but the rtc-sync script, cronjob and systemd modification will use the i2c RTC to set the wallclock (after it's set improperly by rtc0). Feel free to check back in if it still does not work. Groetjes,

I see. The logs show that you have setup armbianEnv.txt to boot from a filesystem that the later logs show is an EXT4 filesystem, located on the first partition of first namespace of the first found NVMe device. The logs do not show any blockdevice for mmc1 (which appears to be the driver linked to the SD card). No logging usually means that there is no device detected. Do note that things will indeed not be simple if you change your setup after gathering diagnostics logs. People are willing to help, but correct diagnostics information is needed for people to actually help you. Grt,

Hi @AaronNGray, Did you check if there is indeed an SD card inserted? If so, try to remove it then re-insert it while the system has booted. Also, seems that you have an NVMe storage device attached, on which the OS was installed - not the SD card as you mentioned? As @laibsch mentioned, the eMMC is detected and available as /dev/mmcblk0, but seems that SD card is not seen (if it was inserted). Grt,

Hi @coroner21, Can you share some pics of the Helios4 you have? Thanks, Groetjes,

Hi Loeriver, Where is the other end of your USB serial dongle connected to? Can you check there if the dongle had disappeard from the USB bus and re-appeared around the same time? In my "professional" life we have had workstations mysteriously reboot whenever we would power cycle the device hosting the USB to serial device. Even though you say it's not related, if this is still mysterious, best to check under each stone... Groetjes,