[hipl-users] Re: HIP mobility testings : Bug report
- From: Mika Kousa <mkousa@xxxxxxxxx>
- To: HIPL Users <hipl-users@xxxxxxxxxxxxx>
- Date: Wed, 10 Mar 2004 19:45:29 +0200 (EET)
On Wed, 10 Mar 2004, Simon Schuetz wrote:
-> Hi,
-> till yesterday I used statically defined IPs and routes. That why I had
-> to use the workaround below.
-> To avoid the workaround and just use ifconfig up/down, I switched to an
-> "dynamic" approach.
-> R is now running radvd for router advertising (IPv6 autconfiguration).
-> S and C therefore dynamically change there IPs and routes when the
-> interfaces come up (although in reality each interface always gets the
-> same IP as before, cause the advertised prefix does not change).
It's great that some one tests these scenarios, because at least I have
not tested this kind of a situation.
-> If I shut down both interfaces on C, and bring up one of them lateron, C
-> crashes within a few seconds.
-> In /var/log/messages there is some binary data, is this some core dump
-> that could help for debugging?
If you mean the so called Oops message when you say "binary data", this
happens and is normal when the kernel crashes and is still able to log the
Oops message. It tells where the kernel was when it crashed and some more
related information. See file linux/README for more info on the Oops
message.
With ksymoops program you might be able to trace what happened. When you
execute ksymoops check that the options it uses are right, or else the
results are wrong. If they do not correspond to values of your just
crashed kernel, change them with needed options (-k, -l, -o, -m etc.) to
ksymoops. When the ksymoops starts, copy and paste all of the crash
information and then press ctrl-d.
-> For the first, I will now use the approach with static IPs.
This might work better.
Anyway, as mentioned before in this mailing list, the mobility code is
highly unstable.
Other related posts:
