Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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 an attachment (id=134899) [details]
bridge-utils-1.2-noip.patch

A patch to allow bridge-utils to work in TCP/IP-less system.

robbat2: Upstream merged this.

Created an attachment (id=134901) [details]
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 an attachment (id=134915) [details]
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 an attachment (id=134919) [details]
find /proc/net and /proc/sys/net

Created an attachment (id=134923) [details]
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 an attachment (id=134954) [details]
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 an attachment (id=134970) [details]
ipless.patch

ok, this should be good to go now.

Created an attachment (id=134972) [details]
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] [details]
> 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]).
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!