I am thinking the USB virtual wired ethernet might not be tied in to systemd
, which would mean USB virtual wired won’t care about whether systemd
networking is enabled or not. Do you use the USB virtual wired ethernet which provides the 192.168.55.1
IP address?
CAN is likely similar in that it depends on a driver and hardware without using systemd
for init.
Basically you need to know what interfaces are managed by systemd
to know if stopping something on systemd
(which is what “networking.service
” is…a systemd
service) will stop that communications. Each of those non-systemd services would have its own configuration. In the case of CAN it is likely device tree plus some config file (I don’t know for sure, I have never tried to configure CAN…device tree is for hardware setup and driver arguments, but other config would be a file somewhere, probably in “/etc
”). For the USB virtual wired ethernet, the configuration is in:
/opt/nvidia/l4t-usb-device-mode
Within that /opt
device mode directory there are in fact some systemd
compatible scripts, but I suspect that they are not tied directly to networking.service
. To demonstrate, run this command:
systemctl list-units | grep 'l4t'
You should find the bridge which is used by the virtual USB ethernet, but the actual virtual ethernet would be “nv-l4t-usb-device-mode.service
”. One could then cd
to “/etc/systemd
”, and run this command:
find . -name '*l4t*'
…which would point out this local config (I’m looking at an old TX2 install, so this might differ from your Nano):
./system/multi-user.target.wants/nv-l4t-usb-device-mode.service
./system/nv-l4t-usb-device-mode.service
It seems that hitting text mode multi-user.target
enables the USB wired ethernet. One could rearrange those files in “/etc/systemd/system
” and tie USB wired to networking.service
instead of being tied to “mutli-user.target
”. There is a good reason why this was not actually done: The purpose of the virtual wired ethernet is for flashing a system which may not have networking…add to this that device mode enables more than just the virtual wired ethernet, it also enables a block device example, and that block device is needed even when networking is not enabled. Combine this with the fact that the USB virtual wired ethernet is for working on a system with no “standard” ethernet networking. I suppose the real “best and politcaly correct” way to modify this would be to keep all non-networking services in the existing “nv-l4t-usb-device-mode.service
”, but to separate out the virtual wired ethernet into its own service, and combine this with the wants/needs of “networking.service
”.
I don’t know which service CAN is tied to (if any…perhaps it isn’t managed at all by systemd
), but this would be a similar story where it might (or could be) tied to networking.service
, but is not currently tied to it.