Hello Roy, Sorry it took some time, I have concluded these are the only issues left for supporting a system without TCP/IP in kernel. Tested with rc6. 1. It will be nice if lo interface will accept config_lo="null" and will not try to assign IP address if null configuration is requested, same as any other interface. 2. ip route flush table cache dev XXX issues a warning that cannot open /proc/sys/net/.... maybe redirect to null (it returns success anyway). 3. /lib/rc/net/bridge.sh uses ifconfig in order to set promisc. From my tests this is not needed for bridging... Anyway, ifconfig does not work without TCP/IP... if iproute2 module is used, then ip link set $int promisc $state should be used in bridge as well. 4. ifplugd configuration does not work correctly, when this configuration is selected (modules="plug"), when interface is started I get: WARNING: net.eth0 not under our control, aborting This comes out of src/runscript.c, I don't exactly know what happens, I guess that if configuration is null then interface is started, and the condition of inactive does not apply. 5. OT: It is difficult to debug the background networking scripts... As the --debug only apply to current instance... Please consider adding IN_DEBUG environment variable or something similar so that debug will be inherited. Also the binary part of baselayout does not consider the --debug. Thanks!
Created attachment 134899 [details, diff] bridge-utils-1.2-noip.patch A patch to allow bridge-utils to work in TCP/IP-less system. robbat2: Upstream merged this.
Created attachment 134901 [details, diff] ifplugd-0.28-noip.patch A patch to allow bridge-utils to work in TCP/IP-less system. uberlord: I sent to upstream, got no response, maybe you can help.
(In reply to comment #0) > 1. It will be nice if lo interface will accept config_lo="null" and will not > try to assign IP address if null configuration is requested, same as any other > interface. Don't put net.lo in a runlevel then and we won't do anything with it. > 5. OT: It is difficult to debug the background networking scripts... As the > --debug only apply to current instance... Please consider adding IN_DEBUG > environment variable or something similar so that debug will be inherited. Also > the binary part of baselayout does not consider the --debug. IN_BACKGROUND=true /etc/init.d/net.eth0 --debug start
> Don't put net.lo in a runlevel then and we won't do anything with it. This is what I did. But then I need to have several softlevel in order to determine when to include it and when not. An easier and more consistent solution would be to support "null" configuration. > 5. OT: It is difficult to debug the background networking scripts... As the IN_BACKGROUND=true /etc/init.d/net.eth0 --debug start Tried this... :) But I could not reproduce the issue by hand, I even commented out the ifplugd action and tried again... I don't understand why the message (4) appear.
Created attachment 134915 [details, diff] null lo patch Well, it's no hardship to do this. Does this work for you?
Could you attach a directory layout of /proc/net and /proc/sys/net from your ipless kernel? Thanks
> Does this work for you? Partially. The routes should also be ignored I ${config} is not available at the route point, but if I copy it, I can do: [ "${config}" != "null" ] && routes="..."
Created attachment 134919 [details] find /proc/net and /proc/sys/net
Created attachment 134923 [details, diff] ipless.patch OK, this should deal with most of what you want changed in baselayout.
does disabling that stuff make any sense ? iow, why are you running iproute/ifplugd/whatever in the first place on a system that lacks IP ? simply sending things to >/dev/null is lame and can cover up real problems
(In reply to comment #10) > does disabling that stuff make any sense ? iow, why are you running > iproute/ifplugd/whatever in the first place on a system that lacks IP ? bridge uses iproute2/ifconfig to put the slave interface into promiscous mode. This is required if the slave interface has an ip address. > simply sending things to >/dev/null is lame and can cover up real problems I couldn't see anything in /proc to indicate if iconfig/iproute2 stands a chance of working or not. If the exact error message was given instead of "cannot open /proc/sys/net/...." then maybe we could do something else.
(In reply to comment #11) > bridge uses iproute2/ifconfig to put the slave interface into promiscous mode. > This is required if the slave interface has an ip address. What is slave interface? Do you mean the eth0 for example that is part of the bridge? If so, maybe turning promisc should be optional. > > simply sending things to >/dev/null is lame and can cover up real problems > > I couldn't see anything in /proc to indicate if iconfig/iproute2 stands a > chance of working or not. If the exact error message was given instead of > "cannot open > /proc/sys/net/...." then maybe we could do something else. > ip link set eth0 promisc on Works... it uses ioctl to do this. Why didn't you use this if iproute2 is available?
I still get: WARNING: net.eth0 not under our control, aborting For ifplugd. Why do I want ifplugd to work? When interface is up it is nice to do some stuff using baselayout and not hack a new ifplugd configuration. This is strange, as if I comment out ifplugd.action and do: /etc/init.d/net.eth0 start IN_BACKGROUND=true /etc/init.d/net.eth0 start All works great!
Created attachment 134954 [details, diff] ipless.patch OK, we just /dev/null the flushing of the cache now and use iproute2 if available, falling back to ifconfig. The ifplugd issue is probably related to bug #196029 and futher commentry on that issue should move there or elsewhere. I'll test your ifplugd patch for the AF_LOCAL thingy when I find some working cat5.
the route flushing only makes sense if /proc/net/route exists, so use that instead of /dev/null and then put a comment to indicate "this check is in case user has disabled IP support in their kernel and they are trying to use bridging (which tails into iproute)"
It does not work properly. The IFACE value is modified... I did not expect this either, but I checked this out... --- #!/bin/sh test1() { echo "B001 ${A}" } A="value1" echo "A001 ${A}" test1 A="value2" test1 echo "A002 ${A}" --- Outputs: --- A001 value1 B001 value1 B001 value2 A002 value2 --- While I expect: --- A001 value1 B001 value1 B001 value2 A002 value1 --- I checked with bash and busybox... So I must miss something. Shouldn't internal function behaves as external commands?
(In reply to comment #14) > The ifplugd issue is probably related to bug #196029 and futher commentry on > that issue should move there or elsewhere. OK. But I don't understand how it is related. But thanks!
Created attachment 134970 [details, diff] ipless.patch ok, this should be good to go now.
Created attachment 134972 [details, diff] ipless.patch erm, maybe this is
Thanks! A simple question... Won't it be cleaner to pass the interface as an argument?
In this instance yes, but most of the time it's not needed as we normally work on the interface in question.
-[ -e /proc/net/route ] && ip route flush table cache dev "${IFACE}" +[ -e /proc/net/route ] && ip route flush table cache dev "${IFACE}" || true And we are there! Thank you so much!
umm, no ... that does not have the behavior we want if [ -e /proc/net/route ] ; then ip route flush table cache dev "${IFACE}" fi
also, the comment in iproute2_post_start() is incorrect ... it isnt a TCP issue, it's an IP issue
(In reply to comment #23) > umm, no ... that does not have the behavior we want > > if [ -e /proc/net/route ] ; then > ip route flush table cache dev "${IFACE}" > fi > This will return false if no /proc/net/route, while is should return true. How about: ! [ -e /proc/net/route ] || ip route flush table cache dev "${IFACE}"
no it wont and that's the point ... yours forces ignoring the exit status while mine properly returns the correct status test it if you think otherwise: if false ; then true ; fi ; echo $? <- ok if true ; then true ; fi ; echo $? <- ok if true ; then false ; fi ; echo $? <- ok false && true || true ; echo $? <- ok true && true || true ; echo $? <- ok true && false || true ; echo $? <- bad
OK. Sorry.
(In reply to comment #23) > umm, no ... that does not have the behavior we want > > if [ -e /proc/net/route ] ; then > ip route flush table cache dev "${IFACE}" > fi > Thanks Dad!
(In reply to comment #2) > Created an attachment (id=134901) [edit] > ifplugd-0.28-noip.patch > > A patch to allow bridge-utils to work in TCP/IP-less system. > > uberlord: I sent to upstream, got no response, maybe you can help. Works ok, added to -r9. upstream is kinda dead i think.
ifplugd merged! :)
robbat2: Can you please add bridge-utils patch (attachment#134899 [details, diff]). This is the last issue, as ifplugd is setup and openrc fixes the baselayout stuff. Thanks!
OK. I've opened bug#204744 for bridge-utils fixups. Thanks for your help!
