[systemd-devel] systemd-networkd DHCP server & DNS
For several years now, I've been enjoying the fact that the systemd-networkd DHCP server seems to do the right thing, but a question has arisen, and I'm getting results that I can't explain. Basically, the embedded system we've assembled has a WAN interface and one or more client interfaces, and the client devices get a local IP address and are then routed/NATted out the WAN interface -- real simple stuff. The WAN interface usually gets its IP address by DHCP, and when the client device gets its address from our DHCP server, the DNS received from the WAN is included in the DHCP lease for the client. Sometimes this isn't happening, however; sniffing the DHCP request/ack exchange on the client system, I see no DNS address at all, even though the lease packets from the WAN do indeed have DNS address(es) in them. The only possible cause I've found is that when this has happened, the WAN's default gateway isn't able to go anywhere -- but I can see no mechanism that would communicate this situation to our device. Picture: Internet | Corp GW | 10.1.10.1/24 | | 10.1.10.230/24 Lab Router | 192.168.11.1/24 | | 192.168.11.123/24 Embedded Device | 192.168.247.1/24 | | 192.168.247.101/24 Client Device Everything here has a DHCP client on the top side and a DHCP server on the bottom side except for Corp GW and Client Device. There's a DHCP server somewhere on the corporate LAN, but that's out of my scope. In its DHCP server role, Lab Router always includes "192.168.11.1" as DHCP option 6 (DNS) in its DHCP ACK packets. Sometimes Embedded Device emits that in its DCHP ACK packets, and sometimes it doesn't. As I said above, if the cable on Lab Router's 10.1.10 interface is disconnected, that's when it seems to happen -- but not always. For what it's worth, our DHCPServer section of the .network file looks like this: [DHCPServer] EmitRouter=yes EmitDNS=yes EmitNTP=yes PoolOffset=100 PoolSize=50 DefaultLeaseTimeSec=20 MaxLeaseTimeSec=20 (Yes, I know that a 20-second lease time seems insane. I won't try to explain it here.) Thanks in advance for any insight. -- Bruce A. Johnson Chantilly, Virginia, USA OpenPGP key ID: 296D1CD6F2B84CAB https://keys.openpgp.org/ OpenPGP_signature Description: OpenPGP digital signature
Re: [systemd-devel] Mobile broadband modems support in systemd-networkd
I wasn't clear what I meant about processing of the .network file. With Ethernet or Wi-Fi (using iwd), when the link comes up, systemd-networkd does the Right Thing and starts network services on the interface, running a DHCP client or setting up static address(es), routes, etc., as specified in the .network file. When ModemManager establishes the connection with the 3G carrier, systemd-networkd seems to be unaware of the event, and I have to poke it with "systemd restart systemd-networkd" or "networkctl reload" before it tries to use the information in the .network file for the interface. It seems to me like that ought to happen automatically. I suspect that ModemManager needs to be changed to inform systemd-networkd. So far, it's not looking like there's an effort to integrate ModemManager (or something similar) with systemd-networkd, which is kind of a shame. If I come up with anything useful toward making that happen, I'll offer a pull request, but at the moment I'm looking at cobbling something together with Python. Bruce A. Johnson | Firmware Engineer Blue Ridge Networks, Inc. 14120 Parke Long Court Suite 103 | Chantilly, VA 20151 Main: 1.800.722.1168 | Direct: 703-633-7332 http://www.blueridgenetworks.com OpenPGP key ID: 296D1CD6F2B84CAB https://keys.openpgp.org/ On 23/08/2021 16:11, Manuel Wagesreither wrote: I took a closer look at what's going on with systemd-networkd, and I found whether I use ModemManager or mbim-cli to connect to the mobile network, the .network file will be processed, but _only after I restart systemd-networkd_. I'm not 100% sure this applies to all the applications in the systemd ecosystem (like systemd-networkd), but systemd is reloading .unit, .service, .mount and all the other files there are only after a `systemctl daemon-reload`. That's the intended behaviour. Just wanted to mention this. Can't comment on anything else, though, as I have no clue either. But I'm interested in this topic and am silently monitoring this thread. OpenPGP_signature Description: OpenPGP digital signature
Re: [systemd-devel] Mobile broadband modems support in systemd-networkd
Mantas' and Ulrich's responses gave me insights to dig more. Neither the mbim-cli nor ModemManager sets the IP address on the interface, and some kind of agent needs to do that. When I start the connection using ModemManager, I am able to retrieve addresses that mmcli displays like the below. If I manually assign the IPv4 address to the interface and set up the route, I'm able to send traffic to and from other nodes. I haven't yet looked into how ModemManager communicates this info to NetworkManager or how things like a change of address are handled. As I see it, these addresses aren't really static, because the IPv6 addresses are different from one mobile session to the next. IPv4 configuration | method: static | address: 6.147.139.XXX | prefix: 30 | gateway: 6.147.139.YYY | dns: 10.177.0.34, 10.177.0.210 | mtu: 1500 IPv6 configuration | method: static | address: 2607:fb90:648f:2648:a5b3:8146:95aa:2955 | prefix: 64 | gateway: 2607:fb90:648f:2648:68d8:1c67:a27:b968 | dns: fd00:976a::9, fd00:976a::10 | mtu: 1500 I took a closer look at what's going on with systemd-networkd, and I found whether I use ModemManager or mbim-cli to connect to the mobile network, the .network file will be processed, but _only after I restart systemd-networkd_. When it is processed, the only address the interface gets is an IPv6 address, and it doesn't match the one in the ModemManager message above. I'm guessing that T-Mobile isn't providing DHCP for IPv4, and probably with good reason. [root@url-000db95362a6:~]# ip addr show wwan0 6: wwan0: mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 link/ether 52:95:20:b7:93:0f brd ff:ff:ff:ff:ff:ff inet6 2607:fb90:648f:2648:5095:20ff:feb7:930f/64 scope global mngtmpaddr noprefixroute valid_lft forever preferred_lft forever inet6 fe80::5095:20ff:feb7:930f/64 scope link valid_lft forever preferred_lft forever [root@url-000db95362a6:~]# ip -6 route ::1 dev lo proto kernel metric 256 pref medium 2607:fb90:648f:2648::/64 dev wwan0 proto ra metric 1024 pref medium fe80::/64 dev wwan0 proto kernel metric 256 pref medium ff00::/8 dev wwan0 metric 256 pref medium default via fe80::68d8:1c67:a27:b968 dev wwan0 proto ra metric 1024 expires 65524sec mtu 1500 pref medium At this point, I have a usable IP(v6) connection managed by systemd-networkd, but I can't see any indication that I'm getting DNS information. This could be that the only DNS tools I know of on my box are nslookup from Busybox and the gethostbyname() call in Python. Both are returning ESRCH. My .network file for the interface looks like this: [Match] Name=wwan0 [Network] Description=WAN connection on wwan0 DHCP=yes IPv6AcceptRA=true [DHCP] UseDNS=yes UseNTP=no SendHostname=no RouteMetric=0 [IPv6AcceptRA] UseDNS=true Is there something more that I need to add to get DNS addresses via the IPv6 router solicitation/advertisement mechanism, or does it appear that T-Mobile isn't providing DNS addresses except via the klunky method exposed by ModemManager? Bruce A. Johnson | Firmware Engineer Blue Ridge Networks, Inc. 14120 Parke Long Court Suite 103 | Chantilly, VA 20151 Main: 1.800.722.1168 | Direct: 703-633-7332 http://www.blueridgenetworks.com OpenPGP key ID: 296D1CD6F2B84CABhttps://keys.openpgp.org/ On 20/08/2021 03:15, Ulrich Windl wrote: Isn't the trick that the WIFI driver or kernel doe most of the magic required to make WIFI work, while a modem driver typically does not know much about the modem, i.e. a cellular modem requires some "special treatment". Dumb question: Does it work without systemd (i.e..: Do yoiu hgave some code that does all that handling)? On 20/08/2021 05:51, Mantas Mikulėnas wrote: Wouldn't e.g. `mbimcli` configure IP on its own? OpenPGP_signature Description: OpenPGP digital signature
[systemd-devel] Mobile broadband modems support in systemd-networkd
I am trying to integrate an MBIM cellular modem (Sierra Wireless MC7455) into my project, and while there seem to be plenty of people doing the same thing, all of the references seem to point to using ModemManager to set up the connection and NetworkManager to manage the IP config (address, gateway, and DNS). I'd like to avoid having to add NetworkManager to my build, since I've been getting along nicely with systemd-networkd for my Ethernet and Wi-Fi interfaces (using iwd to manage the Wi-Fi connection). Is there any work afoot to get systemd-networkd to set up the IP address info in concert with ModemManager, or do I have to force NetworkManager to play nicely with systemd-networkd? -- Bruce A. Johnson | Firmware Engineer Blue Ridge Networks, Inc. 14120 Parke Long Court Suite 103 | Chantilly, VA 20151 Main: 1.800.722.1168 | Direct: 703-633-7332 http://www.blueridgenetworks.com OpenPGP key ID: 296D1CD6F2B84CAB https://keys.openpgp.org/ OpenPGP_signature Description: OpenPGP digital signature
Re: [systemd-devel] "Correct" way to obtain DHCP lease info?
On 22/04/2021 16:14, Bruce A. Johnson wrote: I'm still trying to get an explanation of why having a valid DHCP address is not in itself good enough. Correction: I'm still trying to get an explanation from my requirements person :facepalm: Bruce A. Johnson | Firmware Engineer Blue Ridge Networks, Inc. 14120 Parke Long Court Suite 103 | Chantilly, VA 20151 Main: 1.800.722.1168 | Direct: 703-633-7332 http://www.blueridgenetworks.com OpenPGP key ID: 296D1CD6F2B84CAB https://keys.openpgp.org/ OpenPGP_signature Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] "Correct" way to obtain DHCP lease info?
I'm still trying to get an explanation of why having a valid DHCP address is not in itself good enough. The only reason I've been able to see is that after the lease is issued, and before the time comes to refresh the lease, there could be a communication failure somewhere between the switch the DHCP client is on and the home office where the DHCP server is. One would assume that application failures would be a reasonable clue Regardless, it seems to me that it's not unreasonable for an application outside of systemd-networkd to be able to obtain the DHCP lease information. Am I off base here? Bruce A. Johnson | Firmware Engineer Blue Ridge Networks, Inc. 14120 Parke Long Court Suite 103 | Chantilly, VA 20151 Main: 1.800.722.1168 | Direct: 703-633-7332 http://www.blueridgenetworks.com OpenPGP key ID: 296D1CD6F2B84CAB https://keys.openpgp.org/ On 22/04/2021 12:00, Mantas Mikulėnas wrote: On Thu, Apr 22, 2021 at 6:17 PM Bruce A. Johnson <mailto:bjohn...@blueridgenetworks.com>> wrote: Silvio, thanks for the suggestion. I'm not concerned with keeping the lease forever; the system actually experiences a topology change as it's switched from one network to another, and I can catch that from the DBus events that occur. The problem we're trying to solve is to contact some address that we're sure exists on the network, without knowing anything about that network. The default gateway was an obvious choice, but someone wants to cover the case of there being a private LAN with no gateway. The only other choice I could see is the DHCP server that issues the lease. Hmm, don't you also have the case of there being a private LAN with no gateway and no DHCP? Or possibly the case of a DHCP relay. And since you don't know anything about the network, you also don't know whether the address will respond to your communication attempts (other than ARP) -- it might be pingable but it might be not. I'm curious about what brought this problem into existence in the first place. Why *is* it necessary to contact a random address within the network? (If it's to check that the physical interface is working, then just the fact that you somehow acquired a lease would be enough. no?) -- Mantas Mikulėnas OpenPGP_signature Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] "Correct" way to obtain DHCP lease info?
Silvio, thanks for the suggestion. I'm not concerned with keeping the lease forever; the system actually experiences a topology change as it's switched from one network to another, and I can catch that from the DBus events that occur. The problem we're trying to solve is to contact some address that we're sure exists on the network, without knowing anything about that network. The default gateway was an obvious choice, but someone wants to cover the case of there being a private LAN with no gateway. The only other choice I could see is the DHCP server that issues the lease. As my thinking has evolved, I really want to get at more DHCP lease information when it comes in, like a private DHCP option code that conveys something about the environment. I came across a comment somewhere that said the only way is to set the systemd-networkd client to use debug log level and read from the journal, but isn't there a more direct way, like with the Dbus signals that tell subscribers about network interface status? Bruce A. Johnson | Firmware Engineer Blue Ridge Networks, Inc. 14120 Parke Long Court Suite 103 | Chantilly, VA 20151 Main: 1.800.722.1168 | Direct: 703-633-7332 http://www.blueridgenetworks.com OpenPGP key ID: 296D1CD6F2B84CAB https://keys.openpgp.org/ On 21/04/2021 15:34, Silvio Knizek wrote: Am Mittwoch, dem 21.04.2021 um 14:24 -0400 schrieb Bruce A. Johnson: Is there a correct way to obtain information about the DHCP lease received by systemd-networkd's DHCP client functionality? It was easy enough to find SERVER_ADDRESS in /var/run/systemd/netif/leases/4, but there is a big fat warning stamped at the top of the file: # This is private data. Do not parse. I'd like to be able to make a widget that can tell me which DHCP server issued my lease, how much more time I have, etc., mainly because I want to be able to ping something that is known to be on the network. I'm dealing with a lazy sysadmin who doesn't want to put a gateway on this private network, I haven't found a solution using the CLI tools. Thanks in advance. Hi Bruce, IMHO "having a lease" is not a good metric to determine if you can access something. I would suggest something along this line: --- /etc/systemd/system/internal-network-accessable.target [Unit] Description=Internal System Accessable --- --- /etc/systemd/system/check-if-internal-system-is-accessable.service [Unit] Description=Check if internal system can be reached [Service] ExecStart=/usr/local/bin/check-if-internal-system-is-accessable.sh Restart=always [Install] WantedBy=multi-user.target --- --- /usr/local/bin/check-if-internal-system-is-accessable.sh #!/usr/bin/bash while :; do if wget -q --spider $INTERNAL_RESOURCE; then systemctl start internal-network-accessable.target else systemctl stop internal-network-accessable.target fi sleep 600 done --- Than you can check just the status of the .target. You may need to tweak the lifeness probe, YMMV. Also in sd-networkd you can configure a .network to never loose its lease, see man:systemd.network → KeepConfiguration= HTH Silvio ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel OpenPGP_signature Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] "Correct" way to obtain DHCP lease info?
Is there a correct way to obtain information about the DHCP lease received by systemd-networkd's DHCP client functionality? It was easy enough to find SERVER_ADDRESS in /var/run/systemd/netif/leases/4, but there is a big fat warning stamped at the top of the file: # This is private data. Do not parse. I'd like to be able to make a widget that can tell me which DHCP server issued my lease, how much more time I have, etc., mainly because I want to be able to ping something that is known to be on the network. I'm dealing with a lazy sysadmin who doesn't want to put a gateway on this private network, I haven't found a solution using the CLI tools. Thanks in advance. -- Bruce A. Johnson | Firmware Engineer Blue Ridge Networks, Inc. 14120 Parke Long Court Suite 103 | Chantilly, VA 20151 Main: 1.800.722.1168 | Direct: 703-633-7332 http://www.blueridgenetworks.com OpenPGP key ID: 296D1CD6F2B84CAB https://keys.openpgp.org/ OpenPGP_signature Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-networkd vs. iwd
What are the state of things and the plan for the future with respect to iwd and systemd-networkd? A couple of years ago, I put together a satisfactory solution for my project in OpenEmbedded/Yocto using systemd-networkd to manage the IP connections and wpa_supplicant to manage the underlying Wi-Fi connection. Now it seems that Yocto has dropped wpa_supplicant in favor of iwd, and the iwd folks seem to want it to manage DHCP and routing in addition to the basic Level 2 connectivity. It also seems like systemd-networkd can still do the stuff it was doing before and that I can just use iwd to manage the Level 2. Am I going to write myself into another dead end if I keep using systemd-networkd for the network management and only use iwd for Level 2? Thanks! -- Bruce A. Johnson Herndon, Virginia USA ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] vt220 default for serial console still relevant?
Reading this discussion about VT220, I'm wondering why that was the choice and not VT100 (which was also monochrome). And I'm straining my memory to recall what it was that we had back then that made the VT100 seem so slick and futuristic. Bruce A. Johnson | Firmware Engineer Blue Ridge Networks, Inc. 14120 Parke Long Court Suite 103 | Chantilly, VA 20151 Main: 1.800.722.1168 | Direct: 703-633-7332 http://www.blueridgenetworks.com On 13/07/2020 17:08, Barry wrote: > > >> On 11 Jul 2020, at 20:31, Daan De Meyer wrote: >> >> >> > TERM=linux means Linux console, but that's just too much, as it not >> > only implies a multitude of ESC sequences specific to the Linux >> > console, but also indicates that certain ioctls might work. In our own >> > code we also bind certain behaviour to TERM=linux, as indicator if we >> > are on the Linux console. >> > >> > I am not aware of any widely-supported TERM value that would be a >> > reasonable subset of all currently used terminals and does color. >> >> I did some more research and it turns out VT220 does support colors. >> My terminal emulator (Konsole) just doesn't seem to support it. I >> installed xterm (which explicitly advertises support for VT220 escape >> codes) and got colored output as expected. I guess this means it's >> up to Konsole to support more of VT220 if I want this to work >> seamlessly (or I switch terminals to xterm). >> > > No vt220 does not support colour. I used to work on one and it is > monochrome hardware. > Xterm and konsole support extensions beyond vt220 that add in the > colour support. > > Barry > >> Thanks for the extra info and context. >> >> Daan >> >> On Sat, 11 Jul 2020 at 20:04, Lennart Poettering >> mailto:lenn...@poettering.net>> wrote: >> >> On Sa, 11.07.20 17:51, Daan De Meyer (daan.j.deme...@gmail.com >> <mailto:daan.j.deme...@gmail.com>) wrote: >> >> > Hi, >> > >> > I was playing around with mkosi's qemu support, more >> specifically adding >> > the -nographic option to have the virtual machine output in my >> terminal >> > instead of a separate window. After figuring out that I had to add >> > console=ttyS0 to mkosi's kernel command line, I got the output >> from the vm >> > in my terminal as expected. However, because systemd defaults >> to TERM=vt220 >> > for serial consoles, the output is not colorized. I searched >> around a bit >> > and found that this is done for compatibility reasons. Will >> there ever be a >> > point where we can switch the default to something that >> supports colors >> > (like TERM=linux)? >> >> TERM=linux means Linux console, but that's just too much, as it not >> only implies a multitude of ESC sequences specific to the Linux >> console, but also indicates that certain ioctls might work. In >> our own >> code we also bind certain behaviour to TERM=linux, as indicator if we >> are on the Linux console. >> >> I am not aware of any widely-supported TERM value that would be a >> reasonable subset of all currently used terminals and does color. >> >> > I managed to get around the problem by overriding >> serial-getty@ttyS0 and >> > setting Environment=TERM=linux explicitly but it's a bit of a >> pain and has >> > to be added to every rootfs that wants to support colored >> output on its >> > serial console. >> >> Unfortunately we can't guess the right terminal, we cannot propagate >> TERM=xterm or TERM=linux depending if you invoke qemu on an xterm or >> from a Linux console, hence the best thing we can do is stick to a >> reasonably powerful subset that is likely going to exist everywhere, >> and that's vt220 right now, as noone had a better suggestion so >> far... >> >> Lennart >> >> -- >> Lennart Poettering, Berlin >> >> ___ >> systemd-devel mailing list >> systemd-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/systemd-devel > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] ReadWriteDirectories directive in service file?
On 11/06/2020 15:39, Uoti Urpala wrote: . . . >> ReadWriteDirectories=/run/rl-web/tmp > I believe the cause of the error is that the directory /run/rl-web/tmp > does not exist when trying to create the namespace. You can only mount > paths that already exist. Why do you have this line anyway? /run is > writable by default, and I don't see anything which would restrict > that. ProtectSystem level "true" does not affect /run. I was specifying /run/rl-web/tmp as being a read-write directory because I needed the user account that the web service was being run under to have write access to the tmp directory. By default, it was being set up as owned by root. But anyway, I've fixed the pre-exec script to take care of everything, and it seems to work. Thanks for your response. I sure would like to know what happened to the ReadWriteDirectories directive, but that's something I'll have to look up another day. Bruce A. Johnson Herndon, Virginia USA On 11/06/2020 15:39, Uoti Urpala wrote: > On Thu, 2020-06-11 at 11:39 -0400, Bruce A. Johnson wrote: >> I'm trying to figure out how to resolve these errors that are preventing >> one of my services from running, and I'm kind of at a loss. Systemd is >> stumbling over a read-write directory that needs to be created for the >> service. >> >>> Jun 04 09:44:03 url-000db95361f2 systemd[3819]: rl-web.service: Failed >>> to set up mount namespacing: /run/systemd/unit-root/run/rl-web/tmp: No >>> such file or directory >> I cannot find the /ReadWriteDirectory/ directive I used in my original >> service file in the current systemd documentation. I tried replacing it >> with /ReadWritePaths/ and threw in /ProtectSystem=True/. (The original >> service file is below.) >> ReadWriteDirectories=/run/rl-web/tmp > > I believe the cause of the error is that the directory /run/rl-web/tmp > does not exist when trying to create the namespace. You can only mount > paths that already exist. Why do you have this line anyway? /run is > writable by default, and I don't see anything which would restrict > that. ProtectSystem level "true" does not affect /run. > > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] ReadWriteDirectories directive in service file?
I'm trying to figure out how to resolve these errors that are preventing one of my services from running, and I'm kind of at a loss. Systemd is stumbling over a read-write directory that needs to be created for the service. > Jun 04 09:44:03 url-000db95361f2 systemd[3819]: rl-web.service: Failed > to set up mount namespacing: /run/systemd/unit-root/run/rl-web/tmp: No > such file or directory > Jun 04 09:44:03 url-000db95361f2 systemd[3819]: rl-web.service: Failed > at step NAMESPACE spawning /bin/sh: No such file or directory Under systemd 234, the service worked, but my team is now trying to get together a newer OpenEmbedded build based on OE's dunfell branch, and systemd is now 244 (244.3+). It is quite possible that we have got a few things wrong, but it's a case of the nearsighted leading the blind. I cannot find the /ReadWriteDirectory/ directive I used in my original service file in the current systemd documentation. I tried replacing it with /ReadWritePaths/ and threw in /ProtectSystem=True/. (The original service file is below.) Namespaces support is turned on in the kernel config. The file /bin/sh mentioned in the log message is a symbolic link to /bin/busybox.nosuid, which exists and has mode 0755. The busybox version is 1.31.1. The RuntimeDirectory is being created, and the pre-exec start script is populating the directory with the rest of the files as expected. Can anyone give me a suggestion of what else I need to check? Thanks! -- Bruce A. Johnson Herndon, Virginia USA Original service file: [Unit] Description=RL Web Service After=rl-manager.service Requires=rl-manager.service PartOf=rl-manager.service [Service] EnvironmentFile=/var/run/rl-config/env EnvironmentFile=/ubg/rl_manager_platform.env Type=simple RuntimeDirectory=rl-web ReadWriteDirectories=/run/rl-web/tmp ExecStartPre=/bin/sh /usr/sbin/rl_web_setup start ExecStart=/usr/bin/stdbuf -o 0 -e 0 /usr/bin/python -m rl.webapp -d /run/rl-web SyslogIdentifier=rl-web ExecStartPost=/bin/sh /usr/sbin/rl_web_setup stop Restart=on-failure [Install] WantedBy=multi-user.target ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] No error even a Required= service does not exist
Joerg, I'm not anything near an expert, but perhaps you could try "PartOf=..." in the Unit section for the dependent service. I'll be interested in hearing others' opinion of this idea. But, really, a missing service file shouldn't get out the door. Bruce A. Johnson Chantilly, VA On 25/11/2019 08.07, Jörg Weinhardt wrote: > Hi, > > the behavior of systemd is not quite clear to me: > I have a service which requires another service to be started and running, > so I use a Requires= dependency to the required service. > But if the required service does not exist at all, there is no error message > from systemd. > e.g. > > Requires=xyz.service > > produces no complaint and starts the service even if there is no xyz.service > Is this the normal behavior or can I configure systemd to throw an error in > this case? > > If I write > "Requires=xyz" > > there will be a message: Failed to add dependency on xyz, ignoring: Invalid > argument > Does that error mean that "xyz" is not a valid unit name? > > Thank you, > Joerg > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Disabling IPv6 under systemd-networkd?
Is there a directive I can put into a .network or .link file to disable IPv6 for certain interfaces? I'm trying to prevent the multicast listener broadcast that goes out when an interface first connects. Thanks! -- Bruce A. Johnson | Firmware Engineer Blue Ridge Networks, Inc. 14120 Parke Long Court Suite 103 | Chantilly, VA 20151 Main: 1.800.722.1168 | Direct: 703-633-7332 http://www.blueridgenetworks.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Static IP address on wandering Wi-Fi client
I'm not so sure about handing the IP configuration to the service that is managing the link level. What then do we do with Ethernet? Do we build an iwd equivalent to set up the routes, etc. for the Ethernet connections? What I like about what I've seen with systemd-networkd and wpa_supplicant so far is that I can manage one set of systemd-networkd configuration files to determine which interface (eth0 or wlan0) gets priority, and whether or not to use the link's DNS and time services. It all "just works" for me. I understand that iwd is going to be more straightforward and better than wpa_supplicant, but systemd-networkd has also been straightforward and easy for me to work with. I'd like iwd to "just work", too. I'm no deep thinker on the subject of networking, but here you have my two cents' worth. Bruce A. Johnson | Firmware Engineer Blue Ridge Networks, Inc. 14120 Parke Long Court Suite 103 | Chantilly, VA 20151 Main: 1.800.722.1168 | Direct: 703-633-7332 http://www.blueridgenetworks.com On 17/06/2019 10.28, Marcel Holtmann wrote: > actually this is the wrong approach. You are not getting the full state > information back from the netlink interface. You need to talk to a proper > WiFi daemon like iwd that has a full understanding of the WiFi state. > > And frankly IP configuration needs to move into the network technology > daemons like iwd for example. Doing that at the level of networkd or > NetworkManager is not working out long term. Each technology has a lot of > interlinking between the IP configuration and its network technology. There > needs to be a split between configuring the network interface and setting up > routing and other relationships. The pure IP configuration has to be done by > iwd (and soon it will be). ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Static IP address on wandering Wi-Fi client
Is there any way to tell systemd-networkd to use one .network file or another depending on which SSID the Wi-Fi interface is connected to? I've been working for a while on a router-like project that has a WAN interface which normally gets its IP address by DHCP but can be configured to use a static IP address. We've been using systemd-networkd. We recently decided to add a Wi-Fi interface as an option to the Ethernet interface, and it was easy enough to set up wpa_supplicant to handle connecting the lower layer, after which systemd-networkd uses the .network file to bring up IP, either using DHCP or a static IP address. The next issue that came up in my thinking was that a static IP address might be needed with one Wi-Fi service set, but a different static IP or DHCP service might be in play on a different service set. I don't see any way to tell systemd-networkd to use one set of parameters for one SSID but a different set for another SSID. Does this capability exist, or do I have to roll my own? (I see that NetworkManager can do this, but I really don't want to drag NetworkManager into the picture if I can avoid it.) Thanks! -- Bruce A. Johnson | Firmware Engineer Blue Ridge Networks, Inc. 14120 Parke Long Court Suite 103 | Chantilly, VA 20151 Main: 1.800.722.1168 | Direct: 703-633-7332 http://www.blueridgenetworks.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Can't connect to WiFi when the wired and the wireless interfaces are bonded
I didn't see your in-line comments at first. I'm not part of the systemd development team (I'm just a "consumer", trying to give back), so I don't feel comfortable advising you to open a ticket, but I would at this point if I were you. I'll add a few more comments in-line below. Good luck! Bruce A. Johnson Herndon, Virginia On 2018-05-16 12:34, Doron Behar wrote: > Currently I'm not residing at home were I use both interfaces to connect > to the same network, so I can't test this setup right now. In the > following experiments results following your suggestions, I didn't > connect any Ethernet cable. > >> Mantas seems to be correct that I was giving you a bum steer about >> putting the DHCP=Yes into 25-wireless.network. I haven't used bonding >> before, either. So please consider advice from someone who actually >> knows what he/she's doing in preference to anything I suggest. >> >> Have a look at how systemd obtains the IP address on the [presumably >> working] wired connection. >> >> # journalctl -b | grep DHCP >> May 16 15:32:47 rl-000db948364a systemd-networkd[382]: en01: DHCPv4 address >> 192.168.3.200/24 via 192.168.3.1 > When I connect to the WiFi network only after boot, the command you used > above doesn't produce any output. If there is nothing from systemd-networkd about the IP address assignment and you having a working IP environment, it sounds like you're getting the IP address outside the systemd framework. That would probably preclude it from working with the active-backup configuration under systemd. I'm not sure whether wpa-supplicant does anything about getting an IP address, not having been there yet myself. > >> My Ethernet interface is called /en01/. I would expect your log to say >> it's /bond0/. Given that wireless interfaces look a lot like Ethernet >> interfaces, I don't see that you've done anything wrong, and maybe if >> you run dhcpd manually on bond0 for diagnostic purposes, you'll see a >> better result in your test. The other thing would be to ping the default >> gateway (192.168.43.1 in your log), in case ICMP to the outside world is >> blocked. (The router might also block ICMP pings, though. It depends on >> the paranoia level of the network administrator.) If you've just brought >> up dhcpd, it's still running, and the IP layer is down already, that >> suggests to me that systemd-networkd has gotten in the way. > Well first of all, running `dhcpcd bond0` when I connect to the WiFi network > only after > boot gives me this: > > dhcp6_listen: Address already in use > DUID 00:01:00:01:22:58:f0:ec:34:13:e8:35:48:e6 > bond0: IAID c4:ca:ef:aa > bond0: soliciting an IPv6 router > bond0: soliciting a DHCP lease > bond0: no IPv6 Routers available > > And it's stuck there for a really long time.. > > As for `ping`ing `192.168.43.1`, I get this output: > > connect: Network is unreachable > > My network infrastructure at the moment is a WiFi hotspot of my Android The gateway address would depend on the wireless network you're using, so if you were working from home WiFi before and are now working from a WiFi hotspot, there are reasonable odds the gateway address would be different. To find your gateway address without reading the log output from dhcpd, run /ip route/ and pick up the address on the default line: $ ip route default via 10.100.1.1 dev en01 proto static metric 100 10.100.1.0/24 dev en01 proto kernel scope link src 10.100.1.64 metric 100 In this example, the default gateway is 10.100.1.1, so if I were checking basic IP connectivity, I'd ping that address. (Although, honestly, if you have a default route, your IP is working and you're good to go.) > device. > >> With wired interfaces, I swap the cable around all the time and >> systemd-networkd properly picks up the new IP configuration from DHCP. >> Maybe try a setup without the bond interface and see whether you can get >> IP working over wireless. I would expect systemd-networkd to gracefully >> handle DHCP configuration when you go out of range of the transmitter >> and return, or if you move to another SSID that's set up in >> wpa-supplicant. If that works, it suggests an issue with interface bonding. > As for moving away and returning to the range of a WiFi networks, it > should be noted that it works great without having a bonding > configuration - when using just a dumb `wireless.network` with: > > [Match] > Name=wlp2s0 > > [Network] > DHCP=yes > >> Another thing you might do is set up .network files for the interfaces >> that inc
Re: [systemd-devel] Can't connect to WiFi when the wired and the wireless interfaces are bonded
Mantas seems to be correct that I was giving you a bum steer about putting the DHCP=Yes into 25-wireless.network. I haven't used bonding before, either. So please consider advice from someone who actually knows what he/she's doing in preference to anything I suggest. Have a look at how systemd obtains the IP address on the [presumably working] wired connection. # journalctl -b | grep DHCP May 16 15:32:47 rl-000db948364a systemd-networkd[382]: en01: DHCPv4 address 192.168.3.200/24 via 192.168.3.1 My Ethernet interface is called /en01/. I would expect your log to say it's /bond0/. Given that wireless interfaces look a lot like Ethernet interfaces, I don't see that you've done anything wrong, and maybe if you run dhcpd manually on bond0 for diagnostic purposes, you'll see a better result in your test. The other thing would be to ping the default gateway (192.168.43.1 in your log), in case ICMP to the outside world is blocked. (The router might also block ICMP pings, though. It depends on the paranoia level of the network administrator.) If you've just brought up dhcpd, it's still running, and the IP layer is down already, that suggests to me that systemd-networkd has gotten in the way. With wired interfaces, I swap the cable around all the time and systemd-networkd properly picks up the new IP configuration from DHCP. Maybe try a setup without the bond interface and see whether you can get IP working over wireless. I would expect systemd-networkd to gracefully handle DHCP configuration when you go out of range of the transmitter and return, or if you move to another SSID that's set up in wpa-supplicant. If that works, it suggests an issue with interface bonding. Another thing you might do is set up .network files for the interfaces that include a route metric of 0 for the wired (preferred) interface and 1 for the wireless: [Match] Name=en02 [Network] Description=WAN connection on en02 DHCP=yes [DHCP] RouteMetric=1 I'm using those successfully in my set-up, but the two interfaces are separate subnets. Still, I would expect it to work were they on the same subnet. I hope this helps, and I'm looking forward to learning more from what you find out and what others suggest. Bruce A. Johnson Herndon, Virginia On 2018-05-16 07:10, Doron Behar wrote: > I agree. This is what I understood from the manual pages. I've even > tried to run `dhcpcd wlp2s0` manually after I've connected to the WiFi > network and it didn't help either. Here is `dhcpcd`'s output: > > DUID 00:01:00:01:22:58:f0:ec:34:13:e8:35:48:e6 > wlp2s0: IAID c4:ca:ef:aa > wlp2s0: adding address fe80::bf80:8309:6514:f4ff > wlp2s0: soliciting a DHCP lease > wlp2s0: soliciting an IPv6 router > wlp2s0: offered 192.168.43.146 from 192.168.43.1 > wlp2s0: probing address 192.168.43.146/24 > wlp2s0: leased 192.168.43.146 for 3600 seconds > wlp2s0: adding route to 192.168.43.0/24 > wlp2s0: adding default route via 192.168.43.1 > forked to background, child pid 1142 > > It does seem to be working yet I'm not really connected to the internet, > `ping 8.8.8.8` doesn't work. > > On Wed, May 16, 2018 at 09:14:01AM +0300, Mantas Mikulėnas wrote: . . . >> I believe the individual bonded interfaces don't *need* to speak IP >> at all; >> only the 'main' bond itself does. >> >> -- >> Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Can't connect to WiFi when the wired and the wireless interfaces are bonded
Doron, I don't see any mention of DHCP in your wireless network definition, so I'm dubious that your system has made any attempt at getting an IP address on wlp2s0. Try adding /DHCP=yes/ to the /[Network]/ section of 25-wireless.network. I haven't done a wireless setup with systemd yet, nor have I tried the active-backup configuration you're working with, so I may be completely wrong. Please let me know whether or not it works. Thanks! Bruce A. Johnson Herndon, Virginia On 2018-05-15 04:27, Doron Behar wrote: > I've bonded my wireless and wired network interfaces with > systemd-networkd using an active-backup mode. > > These are the configuration files I have: > > /etc/systemd/network/10-bond0.netdev > > [NetDev] > Name=bond0 > Kind=bond > > [Bond] > Mode=active-backup > > > > /etc/systemd/network/20-wired.network > [Match] > Name=enp0s25 > > [Network] > Bond=bond0 > > > > /etc/systemd/network/25-wireless.network > > [Match] > Name=wlp2s0 > > [Network] > Bond=bond0 > > > > /etc/systemd/network/35-tethering.network > > [Match] > Name=enp0s20u* > > [Network] > Bond=bond0 > > > > /etc/systemd/network/40-bond0.network > > [Match] > Name=bond0 > > [Network] > DHCP=yes > > > > I've noticed that if I boot without any internet connection, WiFi or > Ethernet, and I connect to a WiFi network (only after the boot), > `wpa_supplicant` reports I'm connected to the WiFi network but I'm not > connected to the internet. > > Here is the output of `networkctl status`: > > ●State: degraded >Address: fe80::a05d:c4ff:feca:efaa on bond0 > > And `networkctl list`: > > IDX LINK TYPE OPERATIONAL SETUP > 1 lo loopback carrier unmanaged > 2 bond0bond degradedconfiguring > 3 enp0s25 ether no-carrier configuring > 4 wlp2s0 wlan carrier configuring > > 4 links listed. > > And the output of `ip addr`: > > 1: lo: 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: bond0: mtu 1500 qdisc > noqueue state UP group default qlen 1000 > link/ether a2:5d:c4:ca:ef:aa brd ff:ff:ff:ff:ff:ff > inet6 fe80::a05d:c4ff:feca:efaa/64 scope link > valid_lft forever preferred_lft forever > 3: enp0s25: mtu 1500 qdisc > fq_codel master bond0 state DOWN group default qlen 1000 > link/ether a2:5d:c4:ca:ef:aa brd ff:ff:ff:ff:ff:ff > 4: wlp2s0: mtu 1500 qdisc mq > master bond0 state UP group default qlen 1000 > link/ether a2:5d:c4:ca:ef:aa brd ff:ff:ff:ff:ff:ff > > Is this how it is supposed to behave? Is `systemd-networkd` supposed to be > used only for servers without roaming internet connections that change > after boot? > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Trouble with speed/mode in .link files - RESOLVED/PATCH
My problem seems to be a bug in ethtool-util.c's set_slinksettings().
The base parameters were not being copied into the ethtool_link_settings
request, so they were all zero and ioctl didn't like that. I've pasted
the patch below. Please let me know if there is anything else I need to
do to get this to the right person.
Thanks!
--
Bruce A Johnson
Chantilly, Virginia
diff --git a/src/udev/net/ethtool-util.c b/src/udev/net/ethtool-util.c
index 201fc23..a16ea07 100644
--- a/src/udev/net/ethtool-util.c
+++ b/src/udev/net/ethtool-util.c
@@ -436,15 +436,16 @@ static int set_slinksettings(int *fd, struct ifreq *ifr,
const struct ethtool_li
struct {
struct ethtool_link_settings req;
__u32 link_mode_data[3 *
ETHTOOL_LINK_MODE_MASK_MAX_KERNEL_NU32];
-} ecmd = {
-.req.cmd = ETHTOOL_SLINKSETTINGS,
-};
+} ecmd;
unsigned int offset;
int r;
if (u->base.cmd != ETHTOOL_GLINKSETTINGS ||
u->base.link_mode_masks_nwords <= 0)
return -EINVAL;
+memset(&ecmd, sizeof(ecmd), 0);
+memcpy(&ecmd.req, &u->base, sizeof(ecmd.req));
+ecmd.req.cmd = ETHTOOL_SLINKSETTINGS;
offset = 0;
memcpy(&ecmd.link_mode_data[offset], u->link_modes.supported, 4 *
ecmd.req.link_mode_masks_nwords);
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Trouble with speed/mode in .link files
I've been trying for a few days to figure out how to set Ethernet speed
and mode using a .link file, and I can't figure out what I'm doing
wrong. I've got a renamed interface ("eth2" -> "en01"), and ethtool
allows me to change it with no problem, but I get "Invalid argument"
messages from link_config, and the device ends up with the speed of the
connected switch and half-duplex.
Here's my config file:
> # cat /etc/systemd/network/80-en01.link
> [Match]
> MACAddress=00:0d:b9:48:36:4a
>
> [Link]
> AutoNegotiation=no
> Duplex=full
> BitsPerSecond=10M
>
Running udevadm to test the config gives me this:
> # udevadm test-builtin net_setup_link /sys/class/net/en01
> calling: test-builtin
> === trie on-disk ===
> tool version: 234
> file size: 8715156 bytes
> header size 80 bytes
> strings 1900828 bytes
> nodes 6814248 bytes
> Found container virtualization none.
> timestamp of '/etc/systemd/network' changed
> timestamp of '/run/systemd/network' changed
> ID_NET_DRIVER=igb
> link_config: Cannot set device settings for en01 : Invalid argument
> Could not set speed or duplex of en01 to 10 Mbps (full): Invalid argument
> ID_NET_LINK_FILE=/etc/systemd/network/80-en01.link
I'm running systemd version 234, built from source using OpenEmbedded.
--
Bruce A. Johnson
Chantilly, Virginia
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
