additional ifupdown problems

David Henderson dhenderson at digital-pipe.com
Thu Sep 22 13:26:28 UTC 2016


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.
>


More information about the busybox mailing list