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

Reply via email to