quick update - i've reproduced the problem on x86 and sparc and tested
that Roland's suggested fix works for both /sbin/sh and /usr/bin/ksh93
(used static IP configuration with an /etc/defaultrouter file, changed
#!/sbin/sh
to #!/usr/bin/ksh93). also tested that dhcp is okay too (the codepath
in question isn't reached for dhcp, but thought it'd be good to ensure
that there's no other ksh93 issues elsewhere). as was discussed, the
differing
behaviour around the "set" builtin in ksh93 is the cause, resulting in
the default
routes added earlier in boot (via net-physical) being removed by
net-routing-setup,
(the intended behaviour is that only the default route added via
BOOTPARAMS should
be removed, and only then if that route is not present in
/etc/defaultrouter). thanks!
alan
Roland Mainz wrote On 05/03/07 18:22,:
James Carlson wrote:
Roland Mainz writes:
- set -- `/usr/sbin/route -n add default \
+ x=`/usr/sbin/route -n add default \
-gateway $router`
- [ $? -ne 0 -a "x$5" = "x$route_IP:" ] \
+ res=$?
+ set -- $x
+ [ ${res} -ne 0 -a "x$5" = "x$route_IP:" ] \
&& do_delete=no
I think that still leaves us with some mysteries, such as why the
original poster's system "works."
Chris: ping!
Does he have junk in his
/etc/defaultrouter file that we just didn't previously detect?
Did something get broken in /usr/sbin/route such that it doesn't
return error codes properly?
The only thing my patch "fixes" is the return value propagation of the
"route" command. On my B61 VMware machine it returns a non-zero value
which the Bourne shell "set" command seems to "pass through" in some
weired cases and that is what the script seems to expect. The patch
above moves the call to "route" into a seperate line (storing the
resulting output in "x"), explicitly fetches the return value and stores
it in "res" and then calls "set" with the value of "x".
----
Bye,
Roland
_______________________________________________
networking-discuss mailing list
[email protected]
