[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#646961: #646961 (was: D-I changes needed for xterm transition)



On 20.11.2011 17:31, Robert Millan wrote:

> Cool.  Btw, there's also #646961 (with patch available).

Yeah I looked at it today too, but have some.. issues with it.
For which I installed kFreeBSD system in kvm again.


The proposed change:

-		/sbin/route add default gw $i dev $interface metric $metric
+		if [ ${uname} = "GNU/kFreeBSD" ] ; then
+		    /lib/freebsd/route add -net 0.0.0.0 $i dev $interface metric $metric
+		else
+		    /sbin/route add default gw $i dev $interface metric $metric
+		fi

the only difference here is the usage of "gw" keyword on
the linux side -- linux route understands -net 0.0.0.0 just
fine and the same way as "default".  And the usage such as

  route add <...> gw 192.168.88.1

on freebsd completes on my host successfully, because there's
a host named "gw" and it places wonderful route with
_netmask_ 192.168.88.1 to the same IP address.  Which does
not exactly work ;)

So maybe freebsd route can recognize and skip this "gw"
keyword between source and destination?

This way, there will be no need to distinguish between
linux and freebsd routes anymore.

Or alternatively, maybe it is better to teach linux route
to not require this "gw" (it gives syntax error if "gw" is
not used).


The other change:

-	    while /sbin/route del default gw 0.0.0.0 dev $interface; do :; done
+	    if [ ${uname} = "GNU/kFreeBSD" ] ; then
+		/lib/freebsd/route -q flush
+	    else
+		while /sbin/route del default gw 0.0.0.0 dev $interface; do :; done
+	    fi

appears to be not required, the loop (with command line corrections)
works on freeBSD too.  But I'm not sure this change is right in the
first place: isn't `route flush' flushes _all_ routes, not only the
default one?


So basically, we only need to sort out this "gw" thing (maybe with
the mentioned /sbin/route wrapper, maybe with source-level changes),
and - provided we use /lib/freebsd/ version - modify $PATH in the
script, instead of resorting to somewhat-ugly uname comparisons.

What do you think about this?

Thanks,

/mjt



Reply to: