Documentation > Known Issues

• Kernel panic with certain kernels
  • Symptom: Kernel panic
  • Description: The problem appears if you run arand with a kernel higher than 2.4.18-3 (the default RedHat 7.3 kernel). arand will start and will operate fine. It will receive hello messages from other mobile nodes and successfully set up routes to those nodes. arand also successfully sends its hello messages and they are received at other nodes. The problem occurs when you either: (1) attempt to make a network connection from the node running arand or (2) send a packet from another mobile node to the machine running a kernel with version higher than 2.4.18-3. When you do either of these, the machine will immediately freeze. If you are running in X windows, you wont see any error messages. If you are running from the console, you will see kernel panic messages and its associated output
  • Workaround: None yet. I still don't know what is causing this although I suspect it to be something in the route_check module. Run kernel 2.4.18-3 for now.Update: I have installed kernel 2.4.18-19.7.x and arand seems to work fine.
  • Status of various kernels:
    1. 2.4.18-3 (stock Redhat 7.3 kernel) works
    2. 2.4.18-10 crashes
    3. 2.4.18-17.7.x crashes
    4. 2.4.18-19.7.x works
  
  
  
• Packets sent from interface that is "down"
  • Symptom: Packets sent from an interface that isn't up.
  • Description: Under some circumstances, packets will appear to come from an interface that is not up when arand is running. This is best illustrated with an example: suppose you are running arand on a laptop with a built-in ethernet port, eth0, and a 802.11b card, eth1. Suppose you have both interfaces up, and then bring eth0 down and run arand on eth1. Then, in another window, try to ping a host. The packet will appear to come from the IP address that eth0 was configured for, even though it is down. This happens to me on RedHat 7.3. I'm not sure whether it happens on other configurations.
  • Workaround: Configure the non-essential interface to not come up on boot and then reboot the machine. If this "other" interface is never up, you wont see the wierd behavior described above.