[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: additional ifupdown problems
From:       David Henderson <dhenderson () digital-pipe ! com>
Date:       2016-09-24 16:53:55
Message-ID: CAF-YAQwpg2fe8SSShFsJ7DTERcQ95UH90ZPZ9YADGRg-FNVGiw () mail ! gmail ! com
[Download RAW message or body]

So I've altered the boot script to now use:

NETDEVICES="$(awk -F: '/eth.:|tr.:/{print $1}' /proc/net/dev 2>>$LOG_BOOT)"
for DEVICE in $NETDEVICES; do
        ifconfig $DEVICE 2>>/var/log/${DEVICE}.log | grep -ve 'inet
addr:127.0.0.1' | grep -q "inet addr"
        if [ "$?" != 0 ]; then
                echo "auto $DEVICE" >> /etc/network/interfaces
                echo "iface $DEVICE inet dhcp" >> /etc/network/interfaces
                echo '' >> /etc/network/interfaces

                ifup -v $DEVICE 2>&1 | tee -a /var/log/${DEVICE}.log >>$LOG_BOOT

                sleep 1
        fi
done

The results are still the same - no writing to /var/run/ifstate.  Help
is appreciated!

Thanks,
Dave


On 9/23/16, David Henderson <dhenderson@digital-pipe.com> wrote:
> Good morning Martin.  I have actually be a part of that thread - still
> waiting for a reply from Denys on it actually.  I'll apply the patch
> at some point to resolve the ifdown issue, however, I'm still trying
> to figure out what is going on with bringing up the interfaces without
> an /etc/network/interfaces file.  How am I supposed to do this
> properly Denys?  You've been vocal about this, but aren't supplying
> additional info.
>
> Thanks for your help though Martin!
>
> Dave
>
>
> On 9/22/16, Martin Townsend <mtownsend1973@gmail.com> wrote:
>> Hi Dave,
>>
>> I think you will need my recent patch that I submitted to get ifdown
>> working, check the archived mailing list for about a week ago.  I was
>> getting the same problem with an aliased/virtual IP address.
>>
>> Very strange why this works though, rules out sudoer problems.  I'm
>> afraid this one has me stumped.
>>
>> - Martin.
>>
>> On Thu, Sep 22, 2016 at 7:53 PM, David Henderson
>> <dhenderson@digital-pipe.com> 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 <dhenderson@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@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@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@gmail.com> wrote:
>>>>>>> Hi Dave,
>>>>>>>
>>>>>>> On Wed, Sep 21, 2016 at 4:51 PM, David Henderson
>>>>>>> <dhenderson@digital-pipe.com> wrote:
>>>>>>>> On 9/21/16, Martin Townsend <mtownsend1973@gmail.com> wrote:
>>>>>>>>> Hi Dave,
>>>>>>>>>
>>>>>>>>> On Wed, Sep 21, 2016 at 3:41 PM, David Henderson
>>>>>>>>> <dhenderson@digital-pipe.com> wrote:
>>>>>>>>>> Hey Martin,
>>>>>>>>>>
>>>>>>>>>> On 9/21/16, Martin Townsend <mtownsend1973@gmail.com> wrote:
>>>>>>>>>>> Hi Dave,
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Sep 21, 2016 at 2:06 PM, David Henderson
>>>>>>>>>>> <dhenderson@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@gmail.com> wrote:
>>>>>>>>>>>>> Hi Dave,
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, Sep 20, 2016 at 4:40 PM, David Henderson
>>>>>>>>>>>>> <dhenderson@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@gmail.com> wrote:
>>>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Tue, Sep 20, 2016 at 4:03 PM, David Henderson
>>>>>>>>>>>>>>> <dhenderson@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@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.
>>>>>>>
>>>>>
>>>>
>>
>
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic