Re: additional ifupdown problems
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 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 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
>> 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 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 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
> 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 wrote:
>>> Hi Dave,
>>>
>>> On Wed, Sep 21, 2016 at 4:51 PM, David Henderson
>>> wrote:
On 9/21/16, Martin Townsend wrote:
> Hi Dave,
>
> On Wed, Sep 21, 2016 at 3:41 PM, David Henderson
> wrote:
>> Hey Martin,
>>
>> On 9/21/16, Martin Townsend wrote:
>>> Hi Dave,
>>>
>>> On Wed, Sep 21, 2016 at 2:06 PM, David Henderson
>>> 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 directo
Re: additional ifupdown problems
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 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 > 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 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 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 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 wrote: >> Hi Dave, >> >> On Wed, Sep 21, 2016 at 4:51 PM, David Henderson >> wrote: >>> On 9/21/16, Martin Townsend wrote: Hi Dave, On Wed, Sep 21, 2016 at 3:41 PM, David Henderson wrote: > Hey Martin, > > On 9/21/16, Martin Townsend wrote: >> Hi Dave, >> >> On Wed, Sep 21, 2016 at 2:06 PM, David Henderson >> 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 B
Re: additional ifupdown problems
Here's some more useful info... So if there are contents in the
/etc/network/interfaces file (at least static IP info), everything
works as designed (ifup/down and /var/run/ifstate) via the 'ifup -a'
during bootup. Although if eth0 is ifdown'ed and has a virtual config
eth0:1, when you down eth0, the virtual adapter goes down too. Not
sure if this is a bug or if eth0:1 piggy backs on eth0 making it
necessary. However, if eth0 gets brought back online, the eth0:1
still remains down even though it is listed in /var/run/ifstate.
If no /etc/network/interfaces file is present during boot, currently
the boot script executes the following for wired NIC's:
NETDEVICES="$(awk -F: '/eth.:|tr.:/{print $1}' /proc/net/dev 2>>$LOG_BOOT)"
for DEVICE in $NETDEVICES; do
ifconfig $DEVICE 2>>$LOG_BOOT | grep -q "inet addr"
if [ "$?" != 0 ]; then
ifup -v $DEVICE >>$LOG_BOOT 2>&1 # tried with and without this
trap 2 3 11
if [ $DEBUG -eq 1 ]; then
/sbin/udhcpc -b -i $DEVICE -x hostname:$(/bin/hostname) -p
/var/run/udhcpc.${DEVICE}.pid 2>&1 | tee -a $LOG_BOOT
>>/var/log/udhcpc.${DEVICE}.log
else
/sbin/udhcpc -b -i $DEVICE -x hostname:$(/bin/hostname) -p
/var/run/udhcpc.$DEVICE.pid >/dev/null
2>>/var/log/udhcpc.${DEVICE}.log
fi
trap "" 2 3 11
sleep 1
fi
done
Thanks,
Dave
On 9/22/16, David Henderson 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 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 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
>>> 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 wrote:
> Hi Dave,
>
> On Wed, Sep 21, 2016 at 4:51 PM, David Henderson
> wrote:
>> On 9/21/16, Martin Townsend wrote:
>>> Hi Dave,
>>>
>>> On Wed, Sep 21, 2016 at 3:41 PM, David Henderson
>>> wrote:
Hey Martin,
On 9/21/16, Martin Townsend wrote:
> Hi Dave,
>
> On Wed, Sep 21, 2016 at 2:06 PM, David Henderson
> 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
Re: additional ifupdown problems
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 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 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 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 >>> 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 wrote: > Hi Dave, > > On Wed, Sep 21, 2016 at 4:51 PM, David Henderson > wrote: >> On 9/21/16, Martin Townsend wrote: >>> Hi Dave, >>> >>> On Wed, Sep 21, 2016 at 3:41 PM, David Henderson >>> wrote: Hey Martin, On 9/21/16, Martin Townsend wrote: > Hi Dave, > > On Wed, Sep 21, 2016 at 2:06 PM, David Henderson > 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 oth
Re: additional ifupdown problems
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 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 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 >> 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 wrote: Hi Dave, On Wed, Sep 21, 2016 at 4:51 PM, David Henderson wrote: > On 9/21/16, Martin Townsend wrote: >> Hi Dave, >> >> On Wed, Sep 21, 2016 at 3:41 PM, David Henderson >> wrote: >>> Hey Martin, >>> >>> On 9/21/16, Martin Townsend wrote: Hi Dave, On Wed, Sep 21, 2016 at 2:06 PM, David Henderson 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: pe
Re: additional ifupdown problems
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 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 > 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 wrote: >>> Hi Dave, >>> >>> On Wed, Sep 21, 2016 at 4:51 PM, David Henderson >>> wrote: On 9/21/16, Martin Townsend wrote: > Hi Dave, > > On Wed, Sep 21, 2016 at 3:41 PM, David Henderson > wrote: >> Hey Martin, >> >> On 9/21/16, Martin Townsend wrote: >>> Hi Dave, >>> >>> On Wed, Sep 21, 2016 at 2:06 PM, David Henderson >>> 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
Re: additional ifupdown problems
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 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 wrote: >> Hi Dave, >> >> On Wed, Sep 21, 2016 at 4:51 PM, David Henderson >> wrote: >>> On 9/21/16, Martin Townsend wrote: Hi Dave, On Wed, Sep 21, 2016 at 3:41 PM, David Henderson wrote: > Hey Martin, > > On 9/21/16, Martin Townsend wrote: >> Hi Dave, >> >> On Wed, Sep 21, 2016 at 2:06 PM, David Henderson >> 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 wrote: Hi Dave, On Tue, Sep 20, 2016 at 4:40 PM, David Henderson wrote: >>>
Re: additional ifupdown problems
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 wrote: > Hi Dave, > > On Wed, Sep 21, 2016 at 4:51 PM, David Henderson > wrote: >> On 9/21/16, Martin Townsend wrote: >>> Hi Dave, >>> >>> On Wed, Sep 21, 2016 at 3:41 PM, David Henderson >>> wrote: Hey Martin, On 9/21/16, Martin Townsend wrote: > Hi Dave, > > On Wed, Sep 21, 2016 at 2:06 PM, David Henderson > 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 wrote: >>> Hi Dave, >>> >>> On Tue, Sep 20, 2016 at 4:40 PM, David Henderson >>> 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
Re: additional ifupdown problems
Hi Dave, On Wed, Sep 21, 2016 at 4:51 PM, David Henderson wrote: > On 9/21/16, Martin Townsend wrote: >> Hi Dave, >> >> On Wed, Sep 21, 2016 at 3:41 PM, David Henderson >> wrote: >>> Hey Martin, >>> >>> On 9/21/16, Martin Townsend wrote: Hi Dave, On Wed, Sep 21, 2016 at 2:06 PM, David Henderson 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 wrote: >> Hi Dave, >> >> On Tue, Sep 20, 2016 at 4:40 PM, David Henderson >> 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 wrote: Hi David, On Tue, Sep 20, 2016 at 4:03 PM, David Henderson 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 t
Re: additional ifupdown problems
On 9/21/16, Martin Townsend wrote: > Hi Dave, > > On Wed, Sep 21, 2016 at 3:41 PM, David Henderson > wrote: >> Hey Martin, >> >> On 9/21/16, Martin Townsend wrote: >>> Hi Dave, >>> >>> On Wed, Sep 21, 2016 at 2:06 PM, David Henderson >>> 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 wrote: > Hi Dave, > > On Tue, Sep 20, 2016 at 4:40 PM, David Henderson > 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 wrote: >>> Hi David, >>> >>> On Tue, Sep 20, 2016 at 4:03 PM, David Henderson >>> 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: >>>
Re: additional ifupdown problems
Hey Martin, On 9/21/16, Martin Townsend wrote: > Hi Dave, > > On Wed, Sep 21, 2016 at 2:06 PM, David Henderson > 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 wrote: >>> Hi Dave, >>> >>> On Tue, Sep 20, 2016 at 4:40 PM, David Henderson >>> 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 wrote: > Hi David, > > On Tue, Sep 20, 2016 at 4:03 PM, David Henderson > 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 byte
Re: additional ifupdown problems
Hi Dave, On Wed, Sep 21, 2016 at 2:06 PM, David Henderson 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. > > 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. > > 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. > 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 wrote: >> Hi Dave, >> >> On Tue, Sep 20, 2016 at 4:40 PM, David Henderson >> 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 wrote: Hi David, On Tue, Sep 20, 2016 at 4:03 PM, David Henderson 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 n
Re: additional ifupdown problems
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. 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). 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. 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 Thanks, Dave On 9/20/16, Martin Townsend wrote: > Hi Dave, > > On Tue, Sep 20, 2016 at 4:40 PM, David Henderson > 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 wrote: >>> Hi David, >>> >>> On Tue, Sep 20, 2016 at 4:03 PM, David Henderson >>> 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. > ___ busybox mailing list busybox@busybox.net http://lists.bus
Re: additional ifupdown problems
Hi Dave, On Tue, Sep 20, 2016 at 4:40 PM, David Henderson 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 wrote: >> Hi David, >> >> On Tue, Sep 20, 2016 at 4:03 PM, David Henderson >> 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. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: additional ifupdown problems
Additionally, I have tried to remove the /var/run/ifstate file before running 'ifup' - same failed result. What exact file is the following line referring to? ip: RTNETLINK answers: File exists Thanks, Dave On 9/20/16, David Henderson wrote: > Aside from ownership/permissions, can anyone think of why 'ifup' does > not write to this file? Regression on BB code perhaps? Can any > confirm theirs actuallys writes to this file? > > Thanks, > Dave > > > On 9/20/16, David Henderson 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 wrote: >>> Hi David, >>> >>> On Tue, Sep 20, 2016 at 4:03 PM, David Henderson >>> 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 >>> >> > ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: additional ifupdown problems
Aside from ownership/permissions, can anyone think of why 'ifup' does not write to this file? Regression on BB code perhaps? Can any confirm theirs actuallys writes to this file? Thanks, Dave On 9/20/16, David Henderson 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 wrote: >> Hi David, >> >> On Tue, Sep 20, 2016 at 4:03 PM, David Henderson >> 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 >> > ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: additional ifupdown problems
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 wrote: > Hi David, > > On Tue, Sep 20, 2016 at 4:03 PM, David Henderson > 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 > ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
