Here's some more useful info... So if there are contents in the
/etc/network/interfaces file (at least static IP info), everything
works as designed (ifup/down and /var/run/ifstate) via the 'ifup -a'
during bootup.  Although if eth0 is ifdown'ed and has a virtual config
eth0:1, when you down eth0, the virtual adapter goes down too.  Not
sure if this is a bug or if eth0:1 piggy backs on eth0 making it
necessary.  However, if eth0 gets brought back online, the eth0:1
still remains down even though it is listed in /var/run/ifstate.

If no /etc/network/interfaces file is present during boot, currently
the boot script executes the following for wired NIC's:

NETDEVICES="$(awk -F: '/eth.:|tr.:/{print $1}' /proc/net/dev 2>>$LOG_BOOT)"
   ifconfig $DEVICE 2>>$LOG_BOOT | grep -q "inet addr"
   if [ "$?" != 0 ]; then
      ifup -v $DEVICE >>$LOG_BOOT 2>&1   # tried with and without this

      trap 2 3 11
      if [ $DEBUG -eq 1 ]; then
         /sbin/udhcpc -b -i $DEVICE -x hostname:$(/bin/hostname) -p
/var/run/udhcpc.${DEVICE}.pid 2>&1 | tee -a $LOG_BOOT
         /sbin/udhcpc -b -i $DEVICE -x hostname:$(/bin/hostname) -p
/var/run/udhcpc.$ >/dev/null
      trap "" 2 3 11
      sleep 1


On 9/22/16, David Henderson <> wrote:
> So to add more confusion to the mix, I've been able to successfully
> add 'virtual' adapter (e.g. eth0:1) configuration with everything
> working correctly - both 'ifup' and the modification of the
> /var/run/ifstate file!  Also, the test script in if-up.d ran
> flawlessly.  I do still get an error on 'ifdown' though:
> # sudo ifdown -v eth0:1
> run-parts /etc/network/if-down.d
> ip addr flush dev eth0:1
> ip link set eth0:1 down
> ip: SIOCSIFFLAGS: Cannot assign requested address
> The adapter does indeed go down, but is failing to complete the job
> successfully.  Attempts with 'eth0' is still having the same
> problems...
> Dave
> On 9/22/16, David Henderson <> wrote:
>> Hey Martin, it does not appear that a /proc/config.gz is present.  I
>> guess that option wasn't added in the kernel config itself.  What was
>> the option to check btw?
>> I also checked the full dmesg output, but it doesn't appear that
>> anything was in that log.
>> Let me ask this question.  I have to run 'ifup' using sudo - which has
>> a direct entry in /etc/sudoers.  I would assume this is true, but the
>> commands that are run using 'ifup' are also run as the elevated
>> account and do not require a specific entry in the /etc/sudoers
>> account for 'ip' as well right?
>> Thanks,
>> Dave
>> On 9/22/16, Martin Townsend <> wrote:
>>> Don't suppose there's a /proc/config.gz file on your board? this would
>>> be the kernel configuration but the kernel would have to be built with
>>> this feature enabled.
>>> zcat /proc/config.gz would give you the configuration.
>>> Can't remember if I've already asked but is there anything useful in
>>> dmesg?
>>> -Martin.
>>> On Thu, Sep 22, 2016 at 2:26 PM, David Henderson
>>> <> wrote:
>>>> Thanks for your continued efforts Martin!  I can try the full blown
>>>> iproute2 later today and let you know.  Not sure about the kernel
>>>> config as I'm working with a fork of TC linux - they maintain that
>>>> portion.  And I don't think it's a firewall issue because the routing
>>>> does get setup during boot, it's just that the ifstate file doesn't
>>>> get written to for some reason (and I don't think firewalls will
>>>> prevent writing to local files :).
>>>> Thanks,
>>>> Dave
>>>> On 9/21/16, Martin Townsend <> wrote:
>>>>> Hi Dave,
>>>>> On Wed, Sep 21, 2016 at 4:51 PM, David Henderson
>>>>> <> wrote:
>>>>>> On 9/21/16, Martin Townsend <> wrote:
>>>>>>> Hi Dave,
>>>>>>> On Wed, Sep 21, 2016 at 3:41 PM, David Henderson
>>>>>>> <> wrote:
>>>>>>>> Hey Martin,
>>>>>>>> On 9/21/16, Martin Townsend <> wrote:
>>>>>>>>> Hi Dave,
>>>>>>>>> On Wed, Sep 21, 2016 at 2:06 PM, David Henderson
>>>>>>>>> <> wrote:
>>>>>>>>>> Good morning everyone!  I'll add each question with the answer
>>>>>>>>>> below:
>>>>>>>>>> Q: maybe because something in if-pre-up.d fails?
>>>>>>>>>> A: there is only that one test script in if-up.d, no others so
>>>>>>>>>> nothing
>>>>>>>>>> there to fail.  And judging by the output from 'ifup', it doesn't
>>>>>>>>>> even
>>>>>>>>>> appear that the parsing of the if-up.d directory is happening,
>>>>>>>>>> only
>>>>>>>>>> if-pre-up.d.
>>>>>>>>> You misread the question, maybe something in if-pre-up.d fails
>>>>>>>>> which
>>>>>>>>> means it doesn't even attempt if-up.d, I don't know the
>>>>>>>>> implementation
>>>>>>>>> that well so I don't know if this would happen.
>>>>>>>> I think you misread the answer :)  There are no files in any of the
>>>>>>>> if-*.d directories except the if-up.d directory, and there is only
>>>>>>>> that one test script that was shown in another thread (which only
>>>>>>>> uses
>>>>>>>> one 'echo' call and one 'env' call).  There is nothing in any of
>>>>>>>> these
>>>>>>>> directories to fail.
>>>>>>>>>> Q: maybe something is overwriting it (do you have inotfiy-watch)?
>>>>>>>>>> A: I do not have inotify-watch running.  Unless something in BB
>>>>>>>>>> is
>>>>>>>>>> happening I have nothing else regarding networking running (e.g.
>>>>>>>>>> ifplugd, pppd, openvpn, etc).
>>>>>>>>> inotify-watch is a utility that you could run to determine if the
>>>>>>>>> file
>>>>>>>>> is being overwritten but maybe hard to use during boot anyway.
>>>>>>>> Got it!  No I don't have that running.  However, as specified,
>>>>>>>> unless
>>>>>>>> there is something in BB that also interacts with that file, there
>>>>>>>> is
>>>>>>>> no other services running that would even care about the
>>>>>>>> /var/run/ifstate file.  Only 'ifup -a' is called during bootup that
>>>>>>>> is
>>>>>>>> regarding networking.  The only other software that is installed
>>>>>>>> that
>>>>>>>> interacts with networking is the wpa suite, but afaik, it doesn't
>>>>>>>> bother with that file.  Also, wpa currently isn't even being
>>>>>>>> executed
>>>>>>>> because interaction has been with the wired side.  Would the
>>>>>>>> absence
>>>>>>>> of a physical connection cause any issues?  It doesn't seem to
>>>>>>>> bother
>>>>>>>> whether the network adapter is configured or not in the software
>>>>>>>> (using a static IP address as shown below).
>>>>>>>>>> Q: permissions?
>>>>>>>>>> A: file has been adjusted during the boot process (before 'ifup
>>>>>>>>>> -a'
>>>>>>>>>> is
>>>>>>>>>> called) to become: root:staff 664.  Additionally I have tried
>>>>>>>>>> changing
>>>>>>>>>> to my own user account with the 'staff' group and 777 - no
>>>>>>>>>> difference.
>>>>>>>>> I had a quick look through the code and as ifup is failing it is
>>>>>>>>> not
>>>>>>>>> writing out the new interface to ifstate so you need to find out
>>>>>>>>> why
>>>>>>>>> ifup is not working.
>>>>>>>>> As a test you could move all scripts out of if-pre-up.d and see if
>>>>>>>>> your test script gets called this will confirm whether something
>>>>>>>>> in
>>>>>>>>> if-pre-up.d is the problem.  If so move them back in one at a time
>>>>>>>>> until it breaks again.  Otherwise I'm out of ideas I'm afraid.
>>>>>>>> Again, there are no other scripts in any of those directories to
>>>>>>>> fail
>>>>>>>> and the one that is in there isn't even getting processed based on
>>>>>>>> the
>>>>>>>> 'ifup' output - it's in 'if-up.d', not 'if-pre-up.d'.
>>>>>>>>>> Q: Out of interest what is your /etc/network/interfaces file if
>>>>>>>>>> it
>>>>>>>>>> can
>>>>>>>>>> be shared?
>>>>>>>>>> A: Shown below:
>>>>>>>>>> auto eth0
>>>>>>>>>> iface eth0 inet static
>>>>>>>>>> address
>>>>>>>>>> netmask
>>>>>>>>>> gateway
>>>>>>>>>> dns-nameservers
>>>>>>>>>> dns-search whatever.local
>>>>>>>>> Looks pretty good to me.
>>>>>>>>>> Thanks,
>>>>>>>>>> Dave
>>>>>>>>>> On 9/20/16, Martin Townsend <> wrote:
>>>>>>>>>>> Hi Dave,
>>>>>>>>>>> On Tue, Sep 20, 2016 at 4:40 PM, David Henderson
>>>>>>>>>>> <> wrote:
>>>>>>>>>>>> That's what my research has yielded as well, however, it
>>>>>>>>>>>> doesn't
>>>>>>>>>>>> appear that /var/run/ifstate is getting written to.  I check
>>>>>>>>>>>> the
>>>>>>>>>>>> ownership/permissions of the file:
>>>>>>>>>>>> root:root 644
>>>>>>>>>>>> I since changed it to mimic yours and attempted an 'ifup' again
>>>>>>>>>>>> -
>>>>>>>>>>>> no
>>>>>>>>>>>> luck, same message.  I then tried adding the 'eth0=eth0' to the
>>>>>>>>>>>> file
>>>>>>>>>>>> and calling 'ifdown eth0' which worked like a charm.  So it
>>>>>>>>>>>> appears
>>>>>>>>>>>> that the problem lies with 'ifup'?  Also, the 'ifstate' file is
>>>>>>>>>>>> dynamically being created during the boot cycle (most likely by
>>>>>>>>>>>> the
>>>>>>>>>>>> 'ifup -a' call during boot), so I'm assuming the file ownership
>>>>>>>>>>>> and
>>>>>>>>>>>> permissions are getting set there.
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Dave
>>>>>>>>>>>> On 9/20/16, Martin Townsend <> wrote:
>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>> On Tue, Sep 20, 2016 at 4:03 PM, David Henderson
>>>>>>>>>>>>> <> wrote:
>>>>>>>>>>>>>> Good morning everyone!  During the boot of the OS, an 'ifup
>>>>>>>>>>>>>> -a'
>>>>>>>>>>>>>> is
>>>>>>>>>>>>>> called to bring all the configured adapters online via the
>>>>>>>>>>>>>> /etc/network/interfaces file.  Once the device is up and
>>>>>>>>>>>>>> running,
>>>>>>>>>>>>>> I
>>>>>>>>>>>>>> can see the proper configurations via an 'ifconfig' call.
>>>>>>>>>>>>>> However,
>>>>>>>>>>>>>> when I issue an 'ifdown eth0' call, I get the following
>>>>>>>>>>>>>> error:
>>>>>>>>>>>>>> ifdown: interface eth0 not configured
>>>>>>>>>>>>>> Checking with the 'ifconfig' confirms that no action was
>>>>>>>>>>>>>> taken
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>> that the adapter is still up and running.  Running an 'ifdown
>>>>>>>>>>>>>> -f
>>>>>>>>>>>>>> eth0'
>>>>>>>>>>>>>> achieves the desired goals, but why do I need to force this?
>>>>>>>>>>>>>> Checking
>>>>>>>>>>>>>> the /var/run/ifstate file shows that it is 0 bytes at all
>>>>>>>>>>>>>> times
>>>>>>>>>>>>>> (e.g.
>>>>>>>>>>>>>> right after a reboot, after tinkering with ifup/down, etc).
>>>>>>>>>>>>>> Also,
>>>>>>>>>>>>>> once the configuration is removed and an 'ifup -v eth0' is
>>>>>>>>>>>>>> called,
>>>>>>>>>>>>>> here's what I get:
>>>>>>>>>>>>>> run-parts /etc/network/if-pre-up.d
>>>>>>>>>>>>>> ip addr add dev eth0 label eth0
>>>>>>>>>>>>>> ip link setup eth0 up
>>>>>>>>>>>>>> ip route add default via dev eth0
>>>>>>>>>>>>>> ip: RTNETLINK answers: File exists
>>>>>>>>>>>>>> I've tried calling a "ip addr flush dev eth0" to see if that
>>>>>>>>>>>>>> would
>>>>>>>>>>>>>> resolve the problem, but didn't work.  Also keep in mind that
>>>>>>>>>>>>>> I
>>>>>>>>>>>>>> can
>>>>>>>>>>>>>> not run an 'strace' since the machine I'm working on (or more
>>>>>>>>>>>>>> precisely developing on) does NOT have a current Internet
>>>>>>>>>>>>>> connection.
>>>>>>>>>>>>>> As a side note to one of my other posts, it doesn't appear
>>>>>>>>>>>>>> that
>>>>>>>>>>>>>> any
>>>>>>>>>>>>>> other if-*.d directories are getting processed (which would
>>>>>>>>>>>>>> explain
>>>>>>>>>>>>>> why my test script isn't being called).  Is this due to the
>>>>>>>>>>>>>> error
>>>>>>>>>>>>>> preventing further processing, or are the other directories
>>>>>>>>>>>>>> getting
>>>>>>>>>>>>>> skipped for some other reason?
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> Dave
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> busybox mailing list
>>>>>>>>>>>>> I'm sure that /var/run/ifstate must contain the name of the
>>>>>>>>>>>>> currently
>>>>>>>>>>>>> configured network interfaces otherwise ifdown will not work
>>>>>>>>>>>>> so
>>>>>>>>>>>>> I
>>>>>>>>>>>>> would start there.   On my system /var/run is in tmpfs and is
>>>>>>>>>>>>> a
>>>>>>>>>>>>> link
>>>>>>>>>>>>> to /run as should have 777 permissions.
>>>>>>>>>>>>>  df -h /var/run
>>>>>>>>>>>>> Filesystem      Size  Used Avail Use% Mounted on
>>>>>>>>>>>>> tmpfs           503M  8.5M  495M   2% /run
>>>>>>>>>>>>> ls -al /var/run
>>>>>>>>>>>>> lrwxrwxrwx 1 root root 6 Sep 19 17:28 /var/run -> ../run
>>>>>>>>>>>>> Is there anything in dmesg about ifstate?  can you write to
>>>>>>>>>>>>> ifstate
>>>>>>>>>>>>> echo "eth0=eth0" > /var/run/ifstate
>>>>>>>>>>>>> if so does ifdown now work?
>>>>>>>>>>>>> -Martin
>>>>>>>>>>> Hmm.  So ifup/down is not writing to the ifstate file like it
>>>>>>>>>>> should,
>>>>>>>>>>> maybe because something in if-pre-up.d fails? or maybe something
>>>>>>>>>>> is
>>>>>>>>>>> overwriting it (do you have inotfiy-watch) ? Permissions? Out of
>>>>>>>>>>> interest what is your /etc/network/interfaces file if it can be
>>>>>>>>>>> shared? errors in here can give " ip: RTNETLINK answers: File
>>>>>>>>>>> exists"
>>>>>>>>>>> - Martin.
>>>>>>> hmm, I'm out of ideas I'm afraid.
>>>>>>> I tried with no cable on my setup and it works fine
>>>>>>> ifup -v eth0
>>>>>>> run-parts /etc/network/if-pre-up.d
>>>>>>> ip addr add dev eth0 label eth0
>>>>>>> ip link set eth0 up
>>>>>>> ip route add default via dev eth0
>>>>>>> run-parts /etc/network/if-up.d
>>>>>>> and down works fine to.
>>>>>>> So looking at this the reason that if-up.d is not getting called is
>>>>>>> because the ip route add default command failing on your setup.  I
>>>>>>> tried running your ip commands from ifup manually on my setup and it
>>>>>>> failed on ip link setup as this must have changed to ip link set.
>>>>>>> But
>>>>>>> if correct this it all works fine.  What version of iproute2 are you
>>>>>>> using?
>>>>>>> I get the following:
>>>>>>> ip -V
>>>>>>> ip utility, iproute2-ss160111
>>>>>>> - Martin.
>>>>>> So I ended up removing everything with routing via 'ip route delete
>>>>>> ...' so that the table was completely empty.  I then ran the
>>>>>> following:
>>>>>> ip route
>>>>>> dev lo
>>>>>> ifup -v eth0
>>>>>> run-parts /etc/network/if-pre-up.d
>>>>>> ip addr add dev eth0 label eth0
>>>>>> ip: RTNETLINK answers: File exists
>>>>>> ip link set eth0 up
>>>>>> ip route add default via dev eth0
>>>>>> ip: RTNETLINK answers: Network is unreachable
>>>>>> ip route
>>>>>> dev lo
>>>>>> So it appears that anytime the 'ip' command is called, I get an
>>>>>> error.
>>>>>> I'm not sure what file it is referring to, but it is also important
>>>>>> to
>>>>>> note that nothing is getting added to the routing table.  Does BB
>>>>>> write to a file with the 'ip' command?  Here is the version I'm
>>>>>> using:
>>>>>> ip -V
>>>>>> BusyBox v1.24.1 (2016-09-16 11:08:49 UTC) multi-call binary.
>>>>>> Sorry about the 'ip link setup', it was a typo - remember the dev
>>>>>> computer doesn't have a network connection so I have to transpose...
>>>>>> Thanks,
>>>>>> Dave
>>>>> All I can suggest is trying the full blown ip from iproute2 to see if
>>>>> this fixes things I'm afraid.  Maybe the kernel configuration?
>>>>> Firewall?
>>>>> - Martin.
busybox mailing list

Reply via email to