additional ifupdown problems

Martin Townsend mtownsend1973 at gmail.com
Wed Sep 21 16:04:06 UTC 2016


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.


More information about the busybox mailing list