net.lo has a feature if the user provides a preup function in conf.d/net it gets called before the interface 'starts' from the the net.lo init script: # We up the iface twice if we have a preup to ensure it's up if # available in preup and afterwards incase the user inadvertently # brings it down if [ "$(command -v preup)" = "preup" ]; then _up 2>/dev/null ebegin "Running preup" eindent preup || return 1 eoutdent fi According to my interpretation of the word preup it really should be executed 'pre up' and not in between 'up' and 'up' again. this also cause troubles with interfaces which need to be configured before they are up. a socketcan interface for example, which in the end is a simple net interface needs to be configured (with iproute2) before bringing it up. Reproducible: Always Steps to Reproduce: 1. provide a preup function Actual Results: interface is already 'up' in preup Expected Results: interface is not up yet as name suggests My suggestion is to remove the '_up' call before calling preup and document it accordingly so users know, if they need an interface which is already up in the preup function, they need to up it manually. as explained above this is really useful for certain situations where the interface has to be down in the preup function and as also more what the name preup suggests...
Created attachment 291631 [details, diff] don't call _up before preup
Hi Roy, I tend to agree with this bug (e.g. we shouldn't _up the interface before we call preup). But, can you tell me why the scripts were set up to do this? If I make the change I do not want to break anything. If it is just as a convenience for the user, I would like to remove the first _up like this patch suggests. What are your thoughts? William
From memory it was because some users expected it to be "up" even before preup. It shouldn't break anything other than these users preup functions. Also, some kernel drivers default their interface to being up so this just brought parity to the ones that weren't. Let me play devils advocate - if you're bring the interface up anyway why does the current behaviour hurt? Or rather what technical issue are you trying to resolve?
(In reply to comment #3) > Let me play devils advocate - if you're bring the interface up anyway why does > the current behaviour hurt? Or rather what technical issue are you trying to > resolve? linux-can interfaces (aka socketcan) need certain options to be set before they are up. from kernel/Documentation/networking/can.txt: A CAN network device is started or stopped as usual with the command "ifconfig canX up/down" or "ip link set canX up/down". Be aware that you *must* define proper bit-timing parameters for real CAN devices before you can start it to avoid error-prone default settings: $ ip link set canX up type can bitrate 125000 furthermore, if I remember correctly, I wasn't able to change this settings once the interface was up. maybe other interfaces have similar restrictions so not to up the interface would definitely be a good idea...
i'm fine with adding a net config option so users can explicitly disable this. i think things like CAN sockets are the exception to the rule rather than the norm.
commit 9a01f685 implements this as controllable now. The default stays the same. up_before_preup_IFVAR=no