<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<tt>Hi Lorela,<br>
<br>
I have checked the lab you have sent me and, unfortunately, I do
not have any ready suggestions to solve this problem. For future
reference, here is the lab topology, as I could reconstruct it
(all IP addresses are 192.168/24):<br>
<br>
<br>
external network<br>
A --------+---------<br>
|<br>
| eth0<br>
</tt><tt> +--+--+<br>
| OLT |<br>
</tt><tt> +--+--+<br>
| eth1<br>
| .1.1<br>
B --+---------+---------+--<br>
| .1.11 .1.12 |<br>
| eth0 eth0 |<br>
+--+--+ </tt><tt>+--+--+<br>
</tt><tt> | GW1 | | GW2 |<br>
</tt><tt> +--+--+ </tt><tt>+--+--+<br>
</tt><tt>
</tt><tt> | eth1 eth1 |<br>
| .100.1 .100.2|<br>
C --+-------------------+--<br>
| .100.11 .100.12 |<br>
| eth0 eth0 |<br>
</tt><tt> +--+--+ </tt><tt>+--+--+<br>
</tt><tt> | PC1 | | PC2 |<br>
</tt><tt> +--+--+ </tt><tt>+--+--+<br>
</tt>
<tt>
<br>
</tt><tt>The reference implementation of aodvd (</tt>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a href="http://sourceforge.net/projects/aodvuu/">http://sourceforge.net/projects/aodvuu/</a><tt>)
is executed on all machines but OLT, and is enabled on the
interfaces that are attached to collision domain C. GW1 and GW2
run it in "Internet gateway" mode.<br>
<br>
I confirm the crash, which actually triggers the following kernel
messages (this is from pc2, immediately after a ping to a
destination that is beyond the gateways):<br>
<br>
<blockquote type="cite">EIP: 0023:[<082aea93>] CPU: 0 Not
tainted ESP: 002b:192dbb3c EFLAGS: 00010202<br>
Not tainted<br>
EAX: 00000000 EBX: 192dbbb4 ECX: 00000000 EDX: 00000004<br>
ESI: 80000000 EDI: 19885a80 EBP: 08273470 DS: 002b ES: 002b<br>
083b7b38: [<0826e4b9>] ip_local_deliver_finish+0x99/0x210<br>
083b7b48: [<0826e420>] ip_local_deliver_finish+0x0/0x210<br>
083b7b54: [<0826e021>] ip_rcv_finish+0x151/0x2e0<br>
083b7b78: [<0826ded0>] ip_rcv_finish+0x0/0x2e0<br>
083b7b90: [<0821cef9>] netif_receive_skb+0x269/0x390<br>
083b7bc8: [<08067aa2>] segv_handler+0x52/0xd0<br>
083b7bd8: [<082aea93>] nf_nat_out+0x23/0x110<br>
083b7bf4: [<0821bb0d>] net_rx_action+0x2d/0x170<br>
083b7c00: [<0808445c>] uml_net_interrupt+0x3c/0x70<br>
083b7c08: [<080a1931>] _local_bh_enable+0x21/0xa0<br>
083b7c1c: [<080a1a48>] __do_softirq+0x98/0xb0<br>
083b7c40: [<0808c454>] os_waiting_for_events+0x24/0xb0<br>
083b7c50: [<0806995e>] free_irqs+0x5e/0xd0<br>
083b7c70: [<0808dbe5>] sig_handler_common+0x55/0xa0<br>
083b7c94: [<08273470>] ip_finish_output+0x0/0x2b0<br>
083b7cb0: [<082aea93>] nf_nat_out+0x23/0x110<br>
083b7ce8: [<0808dd82>] sig_handler+0x22/0x40<br>
083b7cf0: [<0808dfed>] handle_signal+0x5d/0xa0<br>
083b7d0c: [<08273470>] ip_finish_output+0x0/0x2b0<br>
083b7d10: [<08090517>] hard_handler+0x17/0x20<br>
083b7d3c: [<08273470>] ip_finish_output+0x0/0x2b0<br>
083b7d5c: [<082aea93>] nf_nat_out+0x23/0x110<br>
<br>
Kernel panic - not syncing: Kernel mode fault at addr 0x0, ip
0x82aea93<br>
<br>
EIP: 0023:[<40100d6c>] CPU: 0 Not tainted ESP:
002b:ff54642c EFLAGS: 00000246<br>
Not tainted<br>
EAX: ffffffda EBX: 00000010 ECX: ff546430 EDX: ff546444<br>
ESI: 00000040 EDI: 08050440 EBP: ff546458 DS: 002b ES: 002b<br>
083b7ad8: [<080b6684>] notifier_call_chain+0x34/0x70<br>
083b7afc: [<082fae7a>] panic+0x71/0xff<br>
083b7b18: [<08067944>] segv+0x234/0x340<br>
083b7b24: [<082aea93>] nf_nat_out+0x23/0x110<br>
083b7b38: [<0826e4b9>] ip_local_deliver_finish+0x99/0x210<br>
083b7b48: [<0826e420>] ip_local_deliver_finish+0x0/0x210<br>
083b7b54: [<0826e021>] ip_rcv_finish+0x151/0x2e0<br>
083b7b78: [<0826ded0>] ip_rcv_finish+0x0/0x2e0<br>
083b7b90: [<0821cef9>] netif_receive_skb+0x269/0x390<br>
083b7bc8: [<08067aa2>] segv_handler+0x52/0xd0<br>
083b7bd8: [<082aea93>] nf_nat_out+0x23/0x110<br>
083b7bf4: [<0821bb0d>] net_rx_action+0x2d/0x170<br>
083b7c00: [<0808445c>] uml_net_interrupt+0x3c/0x70<br>
083b7c08: [<080a1931>] _local_bh_enable+0x21/0xa0<br>
083b7c1c: [<080a1a48>] __do_softirq+0x98/0xb0<br>
083b7c40: [<0808c454>] os_waiting_for_events+0x24/0xb0<br>
083b7c50: [<0806995e>] free_irqs+0x5e/0xd0<br>
083b7c70: [<0808dbe5>] sig_handler_common+0x55/0xa0<br>
083b7c94: [<08273470>] ip_finish_output+0x0/0x2b0<br>
083b7cb0: [<082aea93>] nf_nat_out+0x23/0x110<br>
083b7ce8: [<0808dd82>] sig_handler+0x22/0x40<br>
083b7cf0: [<0808dfed>] handle_signal+0x5d/0xa0<br>
083b7d0c: [<08273470>] ip_finish_output+0x0/0x2b0<br>
083b7d10: [<08090517>] hard_handler+0x17/0x20<br>
083b7d3c: [<08273470>] ip_finish_output+0x0/0x2b0<br>
083b7d5c: [<082aea93>] nf_nat_out+0x23/0x110<br>
</blockquote>
<br>
On the other hand, these are the last lines of output of aodvd:<br>
<br>
<blockquote type="cite">09:34:22.656 nl_kaodv_callback: Got
ROUTE_REQ: 8.8.8.8 from kernel<br>
09:34:22.656 rreq_create: Assembled RREQ 8.8.8.8<br>
09:34:22.656 log_pkt_fields: rreq->flags: rreq->hopcount=0
rreq->rreq_id=0<br>
09:34:22.656 log_pkt_fields: rreq->dest_addr:8.8.8.8
rreq->dest_seqno=0<br>
09:34:22.656 log_pkt_fields: rreq->orig_addr:192.168.100.12
rreq->orig_seqno=2<br>
09:34:22.656 aodv_socket_send: AODV msg to 255.255.255.255 ttl=2
size=24<br>
09:34:22.656 rreq_route_discovery: Seeking 8.8.8.8 ttl=2<br>
09:34:22.661 aodv_socket_process_packet: Received RREP<br>
09:34:22.661 rrep_process: from 192.168.100.2 about
192.168.100.12->192.168.100.2<br>
09:34:22.662 log_pkt_fields: rrep->flags: rrep->hcnt=0<br>
09:34:22.662 log_pkt_fields: rrep->dest_addr:192.168.100.2
rrep->dest_seqno=10<br>
09:34:22.662 log_pkt_fields: rrep->orig_addr:192.168.100.12
rrep->lifetime=3000<br>
09:34:22.662 rrep_process: RREP_INET_DEST_EXT: <8.8.8.8><br>
09:34:22.662 rt_table_insert: Inserting 8.8.8.8 (bucket 8) next
hop 192.168.100.2<br>
09:34:22.662 nl_send_add_route_msg: ADD/UPDATE:
8.8.8.8:192.168.100.2 ifindex=3<br>
09:34:22.663 rt_table_insert: New timer for 8.8.8.8, life=3000<br>
09:34:22.663 aodv_socket_process_packet: Received RREP<br>
09:34:22.663 rrep_process: from 192.168.100.1 about
192.168.100.12->192.168.100.1<br>
09:34:22.663 log_pkt_fields: rrep->flags: rrep->hcnt=0<br>
09:34:22.663 log_pkt_fields: rrep->dest_addr:192.168.100.1
rrep->dest_seqno=10<br>
09:34:22.664 log_pkt_fields: rrep->orig_addr:192.168.100.12
rrep->lifetime=3000<br>
09:34:22.664 rrep_process: RREP_INET_DEST_EXT: <8.8.8.8><br>
09:34:22.664 rt_table_update: rt->next_hop=192.168.100.2,
new_next_hop=192.168.100.1<br>
09:34:22.664 nl_send_add_route_msg: ADD/UPDATE:
8.8.8.8:192.168.100.1 ifindex=3<br>
09:34:22.664 rrep_process: INET Response, but no update 8.8.8.8<br>
09:34:23.668 rt_table_update: rt->next_hop=192.168.100.1,
new_next_hop=192.168.100.2<br>
09:34:23.668 nl_send_add_route_msg: ADD/UPDATE:
8.8.8.8:192.168.100.2 ifindex=3<br>
09:34:23.669 nl_rt_callback: NLMSG_ERROR, error=-17 type=24<br>
</blockquote>
<br>
So, apparently there is an error with some callback function that
(I am really guessing now) might be invoked after updating the
routing table. It is not unlikely that this could be fatal to
aodvd, up to the point that the kaodv kernel module causes a
panic. And, of course, the origin of this may not be easy to find.<br>
I am not an expert of AODV but the "gateway mode" seems to
envision the setup of a tunnel between the source node and the
gateway itself (see, for example, <a
href="https://github.com/erimatnor/aodv-uu/blob/master/README#L216">https://github.com/erimatnor/aodv-uu/blob/master/README#L216</a>):
this is probably achieved by the kernel module and is accomplished
while handling the RREQ which appears in the aodvd log above. So,
I cannot exclude the possibility that the failure of this process
is due to a bug in the kernel module or just an incompatibility
with the Netkit kernel.<br>
<br>
Sorry, but I don't have any better answers at this time.<br>
<br>
Regards,<br>
Massimo<br>
<br>
</tt>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<tt><br>
<br>
<br>
<br>
On 29/03/2013 15:53, Lorela Cano wrote:</tt>
<blockquote
cite="mid:BF9190064CF0764AA0E233D2C059BF3D1C882178@AMXPRD0610MB354.eurprd06.prod.outlook.com"
type="cite">
<pre wrap=""><tt>Hello,
I apologise for not being very specific. Aodv seems to work fine inside a single wireless network. ( sends hello messages and populates the routing table). However, it has a feature named Internet gateway ( ex. aodvd -i eth0 -d -w, where -w makes the node a gateway to connect to an external network/address outside the range of wireless network). The problem is that when we run it with this extra option it crashes the virtual machines. Is there any other way to reach an external node (statically connected to one of the wireless nodes) without this option?
Thank you.
Lorela
________________________________________
From: <a class="moz-txt-link-abbreviated" href="mailto:netkit.users-bounces@list.dia.uniroma3.it">netkit.users-bounces@list.dia.uniroma3.it</a> [<a class="moz-txt-link-abbreviated" href="mailto:netkit.users-bounces@list.dia.uniroma3.it">netkit.users-bounces@list.dia.uniroma3.it</a>] on behalf of <a class="moz-txt-link-abbreviated" href="mailto:netkit.users-request@list.dia.uniroma3.it">netkit.users-request@list.dia.uniroma3.it</a> [<a class="moz-txt-link-abbreviated" href="mailto:netkit.users-request@list.dia.uniroma3.it">netkit.users-request@list.dia.uniroma3.it</a>]
Sent: Thursday, March 28, 2013 12:00 PM
To: <a class="moz-txt-link-abbreviated" href="mailto:netkit.users@list.dia.uniroma3.it">netkit.users@list.dia.uniroma3.it</a>
Subject: Netkit.users Digest, Vol 64, Issue 4
Send Netkit.users mailing list submissions to
<a class="moz-txt-link-abbreviated" href="mailto:netkit.users@list.dia.uniroma3.it">netkit.users@list.dia.uniroma3.it</a>
To subscribe or unsubscribe via the World Wide Web, visit
<a class="moz-txt-link-freetext" href="http://list.dia.uniroma3.it/mailman/listinfo/netkit.users">http://list.dia.uniroma3.it/mailman/listinfo/netkit.users</a>
or, via email, send a message with subject or body 'help' to
<a class="moz-txt-link-abbreviated" href="mailto:netkit.users-request@list.dia.uniroma3.it">netkit.users-request@list.dia.uniroma3.it</a>
You can reach the person managing the list at
<a class="moz-txt-link-abbreviated" href="mailto:netkit.users-owner@list.dia.uniroma3.it">netkit.users-owner@list.dia.uniroma3.it</a>
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Netkit.users digest..."
Today's Topics:
1. Re: Aodv (Massimo Rimondini)
----------------------------------------------------------------------
Message: 1
Date: Thu, 28 Mar 2013 10:19:26 +0100
From: Massimo Rimondini <a class="moz-txt-link-rfc2396E" href="mailto:rimondin@dia.uniroma3.it"><rimondin@dia.uniroma3.it></a>
To: <a class="moz-txt-link-abbreviated" href="mailto:netkit.users@list.dia.uniroma3.it">netkit.users@list.dia.uniroma3.it</a>
Subject: Re: [Netkit.users] Aodv
Message-ID: <a class="moz-txt-link-rfc2396E" href="mailto:51540B1E.3010508@dia.uniroma3.it"><51540B1E.3010508@dia.uniroma3.it></a>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
sorry for the late reply, but I was waiting to check whether someone else could more specifically address your problem.
Have you checked the routing tables of virtual machines to verify that routing entries are properly injected in the forwarding table?
What do you mean by "the virtual machine disappears"?
Regards,
Massimo
On 03/24/2013 10:19 PM, Lorela Cano wrote:
</tt></pre>
<blockquote type="cite">
<pre wrap=""><tt>Hello!
My group-mates and I are working on a project based on Netkit. Here's a little description of it:
It consists of two end/user nodes and 2 gateways that compose a wireless network with aodv as routing protocol and a static part that connects the two gateways with an OLT. We managed so far to make aodv work on the wireless part. However when we ping an address from outside the wireless network it appears to be unreachable.
We tried the -w option of aodv to make the gateways Internet gateways ( as specified in aodv-uu 0.9.6), but the moment the pinging process starts, the virtual machine dissapears ( say from user1 to ping the static interface of the gateway2).
We'd be grateful if you could suggest something.
Kind regards.
_______________________________________________
Netkit.users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Netkit.users@list.dia.uniroma3.it">Netkit.users@list.dia.uniroma3.it</a>
<a class="moz-txt-link-freetext" href="http://list.dia.uniroma3.it/mailman/listinfo/netkit.users">http://list.dia.uniroma3.it/mailman/listinfo/netkit.users</a>
</tt></pre>
</blockquote>
<pre wrap=""><tt>-------------- next part --------------
An HTML attachment was scrubbed...
URL: <a class="moz-txt-link-rfc2396E" href="http://list.dia.uniroma3.it/pipermail/netkit.users/attachments/20130328/a33503b6/attachment-0001.html"><http://list.dia.uniroma3.it/pipermail/netkit.users/attachments/20130328/a33503b6/attachment-0001.html></a>
------------------------------
_______________________________________________
Netkit.users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Netkit.users@list.dia.uniroma3.it">Netkit.users@list.dia.uniroma3.it</a>
<a class="moz-txt-link-freetext" href="http://list.dia.uniroma3.it/mailman/listinfo/netkit.users">http://list.dia.uniroma3.it/mailman/listinfo/netkit.users</a>
End of Netkit.users Digest, Vol 64, Issue 4
*******************************************
_______________________________________________
Netkit.users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Netkit.users@list.dia.uniroma3.it">Netkit.users@list.dia.uniroma3.it</a>
<a class="moz-txt-link-freetext" href="http://list.dia.uniroma3.it/mailman/listinfo/netkit.users">http://list.dia.uniroma3.it/mailman/listinfo/netkit.users</a>
</tt></pre>
</blockquote>
</body>
</html>