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 <dhender...@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 <dhender...@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 <mtownsend1...@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 >>> <dhender...@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 <mtownsend1...@gmail.com> wrote: >>>>> Hi Dave, >>>>> >>>>> On Wed, Sep 21, 2016 at 4:51 PM, David Henderson >>>>> <dhender...@digital-pipe.com> wrote: >>>>>> On 9/21/16, Martin Townsend <mtownsend1...@gmail.com> wrote: >>>>>>> Hi Dave, >>>>>>> >>>>>>> On Wed, Sep 21, 2016 at 3:41 PM, David Henderson >>>>>>> <dhender...@digital-pipe.com> wrote: >>>>>>>> Hey Martin, >>>>>>>> >>>>>>>> On 9/21/16, Martin Townsend <mtownsend1...@gmail.com> wrote: >>>>>>>>> Hi Dave, >>>>>>>>> >>>>>>>>> On Wed, Sep 21, 2016 at 2:06 PM, David Henderson >>>>>>>>> <dhender...@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 <mtownsend1...@gmail.com> wrote: >>>>>>>>>>> Hi Dave, >>>>>>>>>>> >>>>>>>>>>> On Tue, Sep 20, 2016 at 4:40 PM, David Henderson >>>>>>>>>>> <dhender...@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 <mtownsend1...@gmail.com> wrote: >>>>>>>>>>>>> Hi David, >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, Sep 20, 2016 at 4:03 PM, David Henderson >>>>>>>>>>>>> <dhender...@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
