additional ifupdown problems

Thu Sep 22 18:53:16 UTC 2016

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 <dhenderson at digital-pipe.com> 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 <mtownsend1973 at gmail.com> 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
>> <dhenderson at digital-pipe.com> 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 <mtownsend1973 at gmail.com> wrote:
>>>> Hi Dave,
>>>>
>>>> On Wed, Sep 21, 2016 at 4:51 PM, David Henderson
>>>> <dhenderson at digital-pipe.com> wrote:
>>>>> On 9/21/16, Martin Townsend <mtownsend1973 at gmail.com> wrote:
>>>>>> Hi Dave,
>>>>>>
>>>>>> On Wed, Sep 21, 2016 at 3:41 PM, David Henderson
>>>>>> <dhenderson at digital-pipe.com> wrote:
>>>>>>> Hey Martin,
>>>>>>>
>>>>>>> On 9/21/16, Martin Townsend <mtownsend1973 at gmail.com> wrote:
>>>>>>>> Hi Dave,
>>>>>>>>
>>>>>>>> On Wed, Sep 21, 2016 at 2:06 PM, David Henderson
>>>>>>>> <dhenderson at digital-pipe.com> 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 192.168.0.23
>>>>>>>>> netmask 255.255.255.0
>>>>>>>>> gateway 192.168.0.1
>>>>>>>>> dns-nameservers 8.8.8.8 8.8.4.4
>>>>>>>>> dns-search whatever.local
>>>>>>>>>
>>>>>>>> Looks pretty good to me.
>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Dave
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 9/20/16, Martin Townsend <mtownsend1973 at gmail.com> wrote:
>>>>>>>>>> Hi Dave,
>>>>>>>>>>
>>>>>>>>>> On Tue, Sep 20, 2016 at 4:40 PM, David Henderson
>>>>>>>>>> <dhenderson at digital-pipe.com> 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 <mtownsend1973 at gmail.com> wrote:
>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Sep 20, 2016 at 4:03 PM, David Henderson
>>>>>>>>>>>> <dhenderson at digital-pipe.com> 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 192.168.0.25/22 dev eth0 label eth0
>>>>>>>>>>>>> ip link setup eth0 up
>>>>>>>>>>>>> ip route add default via 192.168.0.1 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
>>>>>>>>>>>>> busybox at busybox.net
>>>>>>>>>>>>> http://lists.busybox.net/mailman/listinfo/busybox
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 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 192.168.0.50/24 dev eth0 label eth0
>>>>>> ip link set eth0 up
>>>>>> ip route add default via 192.168.0.1 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
>>>>> 127.0.0.1 dev lo
>>>>>
>>>>> ifup -v eth0
>>>>> run-parts /etc/network/if-pre-up.d
>>>>> ip addr add 192.168.0.23/24 dev eth0 label eth0
>>>>> ip: RTNETLINK answers: File exists
>>>>> ip link set eth0 up
>>>>> ip route add default via 192.168.0.1 dev eth0
>>>>> ip: RTNETLINK answers: Network is unreachable
>>>>>
>>>>> ip route
>>>>> 127.0.0.1 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.
>>>>
>>
>