[Netkit.users] Internet gateway for AODV
Massimo Rimondini
rimondin at dia.uniroma3.it
Tue Apr 2 11:48:15 CEST 2013
Hi Lorela,
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):
external network
A --------+---------
|
| eth0
+--+--+
| OLT |
+--+--+
| eth1
| .1.1
B --+---------+---------+--
| .1.11 .1.12 |
| eth0 eth0 |
+--+--+ +--+--+
| GW1 | | GW2 |
+--+--+ +--+--+
| eth1 eth1 |
| .100.1 .100.2|
C --+-------------------+--
| .100.11 .100.12 |
| eth0 eth0 |
+--+--+ +--+--+
| PC1 | | PC2 |
+--+--+ +--+--+
The reference implementation of aodvd ( http://sourceforge.net/projects/aodvuu/) 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.
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):
> EIP: 0023:[<082aea93>] CPU: 0 Not tainted ESP: 002b:192dbb3c EFLAGS: 00010202
> Not tainted
> EAX: 00000000 EBX: 192dbbb4 ECX: 00000000 EDX: 00000004
> ESI: 80000000 EDI: 19885a80 EBP: 08273470 DS: 002b ES: 002b
> 083b7b38: [<0826e4b9>] ip_local_deliver_finish+0x99/0x210
> 083b7b48: [<0826e420>] ip_local_deliver_finish+0x0/0x210
> 083b7b54: [<0826e021>] ip_rcv_finish+0x151/0x2e0
> 083b7b78: [<0826ded0>] ip_rcv_finish+0x0/0x2e0
> 083b7b90: [<0821cef9>] netif_receive_skb+0x269/0x390
> 083b7bc8: [<08067aa2>] segv_handler+0x52/0xd0
> 083b7bd8: [<082aea93>] nf_nat_out+0x23/0x110
> 083b7bf4: [<0821bb0d>] net_rx_action+0x2d/0x170
> 083b7c00: [<0808445c>] uml_net_interrupt+0x3c/0x70
> 083b7c08: [<080a1931>] _local_bh_enable+0x21/0xa0
> 083b7c1c: [<080a1a48>] __do_softirq+0x98/0xb0
> 083b7c40: [<0808c454>] os_waiting_for_events+0x24/0xb0
> 083b7c50: [<0806995e>] free_irqs+0x5e/0xd0
> 083b7c70: [<0808dbe5>] sig_handler_common+0x55/0xa0
> 083b7c94: [<08273470>] ip_finish_output+0x0/0x2b0
> 083b7cb0: [<082aea93>] nf_nat_out+0x23/0x110
> 083b7ce8: [<0808dd82>] sig_handler+0x22/0x40
> 083b7cf0: [<0808dfed>] handle_signal+0x5d/0xa0
> 083b7d0c: [<08273470>] ip_finish_output+0x0/0x2b0
> 083b7d10: [<08090517>] hard_handler+0x17/0x20
> 083b7d3c: [<08273470>] ip_finish_output+0x0/0x2b0
> 083b7d5c: [<082aea93>] nf_nat_out+0x23/0x110
>
> Kernel panic - not syncing: Kernel mode fault at addr 0x0, ip 0x82aea93
>
> EIP: 0023:[<40100d6c>] CPU: 0 Not tainted ESP: 002b:ff54642c EFLAGS: 00000246
> Not tainted
> EAX: ffffffda EBX: 00000010 ECX: ff546430 EDX: ff546444
> ESI: 00000040 EDI: 08050440 EBP: ff546458 DS: 002b ES: 002b
> 083b7ad8: [<080b6684>] notifier_call_chain+0x34/0x70
> 083b7afc: [<082fae7a>] panic+0x71/0xff
> 083b7b18: [<08067944>] segv+0x234/0x340
> 083b7b24: [<082aea93>] nf_nat_out+0x23/0x110
> 083b7b38: [<0826e4b9>] ip_local_deliver_finish+0x99/0x210
> 083b7b48: [<0826e420>] ip_local_deliver_finish+0x0/0x210
> 083b7b54: [<0826e021>] ip_rcv_finish+0x151/0x2e0
> 083b7b78: [<0826ded0>] ip_rcv_finish+0x0/0x2e0
> 083b7b90: [<0821cef9>] netif_receive_skb+0x269/0x390
> 083b7bc8: [<08067aa2>] segv_handler+0x52/0xd0
> 083b7bd8: [<082aea93>] nf_nat_out+0x23/0x110
> 083b7bf4: [<0821bb0d>] net_rx_action+0x2d/0x170
> 083b7c00: [<0808445c>] uml_net_interrupt+0x3c/0x70
> 083b7c08: [<080a1931>] _local_bh_enable+0x21/0xa0
> 083b7c1c: [<080a1a48>] __do_softirq+0x98/0xb0
> 083b7c40: [<0808c454>] os_waiting_for_events+0x24/0xb0
> 083b7c50: [<0806995e>] free_irqs+0x5e/0xd0
> 083b7c70: [<0808dbe5>] sig_handler_common+0x55/0xa0
> 083b7c94: [<08273470>] ip_finish_output+0x0/0x2b0
> 083b7cb0: [<082aea93>] nf_nat_out+0x23/0x110
> 083b7ce8: [<0808dd82>] sig_handler+0x22/0x40
> 083b7cf0: [<0808dfed>] handle_signal+0x5d/0xa0
> 083b7d0c: [<08273470>] ip_finish_output+0x0/0x2b0
> 083b7d10: [<08090517>] hard_handler+0x17/0x20
> 083b7d3c: [<08273470>] ip_finish_output+0x0/0x2b0
> 083b7d5c: [<082aea93>] nf_nat_out+0x23/0x110
On the other hand, these are the last lines of output of aodvd:
> 09:34:22.656 nl_kaodv_callback: Got ROUTE_REQ: 8.8.8.8 from kernel
> 09:34:22.656 rreq_create: Assembled RREQ 8.8.8.8
> 09:34:22.656 log_pkt_fields: rreq->flags: rreq->hopcount=0 rreq->rreq_id=0
> 09:34:22.656 log_pkt_fields: rreq->dest_addr:8.8.8.8 rreq->dest_seqno=0
> 09:34:22.656 log_pkt_fields: rreq->orig_addr:192.168.100.12 rreq->orig_seqno=2
> 09:34:22.656 aodv_socket_send: AODV msg to 255.255.255.255 ttl=2 size=24
> 09:34:22.656 rreq_route_discovery: Seeking 8.8.8.8 ttl=2
> 09:34:22.661 aodv_socket_process_packet: Received RREP
> 09:34:22.661 rrep_process: from 192.168.100.2 about 192.168.100.12->192.168.100.2
> 09:34:22.662 log_pkt_fields: rrep->flags: rrep->hcnt=0
> 09:34:22.662 log_pkt_fields: rrep->dest_addr:192.168.100.2 rrep->dest_seqno=10
> 09:34:22.662 log_pkt_fields: rrep->orig_addr:192.168.100.12 rrep->lifetime=3000
> 09:34:22.662 rrep_process: RREP_INET_DEST_EXT: <8.8.8.8>
> 09:34:22.662 rt_table_insert: Inserting 8.8.8.8 (bucket 8) next hop 192.168.100.2
> 09:34:22.662 nl_send_add_route_msg: ADD/UPDATE: 8.8.8.8:192.168.100.2 ifindex=3
> 09:34:22.663 rt_table_insert: New timer for 8.8.8.8, life=3000
> 09:34:22.663 aodv_socket_process_packet: Received RREP
> 09:34:22.663 rrep_process: from 192.168.100.1 about 192.168.100.12->192.168.100.1
> 09:34:22.663 log_pkt_fields: rrep->flags: rrep->hcnt=0
> 09:34:22.663 log_pkt_fields: rrep->dest_addr:192.168.100.1 rrep->dest_seqno=10
> 09:34:22.664 log_pkt_fields: rrep->orig_addr:192.168.100.12 rrep->lifetime=3000
> 09:34:22.664 rrep_process: RREP_INET_DEST_EXT: <8.8.8.8>
> 09:34:22.664 rt_table_update: rt->next_hop=192.168.100.2, new_next_hop=192.168.100.1
> 09:34:22.664 nl_send_add_route_msg: ADD/UPDATE: 8.8.8.8:192.168.100.1 ifindex=3
> 09:34:22.664 rrep_process: INET Response, but no update 8.8.8.8
> 09:34:23.668 rt_table_update: rt->next_hop=192.168.100.1, new_next_hop=192.168.100.2
> 09:34:23.668 nl_send_add_route_msg: ADD/UPDATE: 8.8.8.8:192.168.100.2 ifindex=3
> 09:34:23.669 nl_rt_callback: NLMSG_ERROR, error=-17 type=24
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.
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, https://github.com/erimatnor/aodv-uu/blob/master/README#L216): 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.
Sorry, but I don't have any better answers at this time.
Regards,
Massimo
On 29/03/2013 15:53, Lorela Cano wrote:
> 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: netkit.users-bounces a list.dia.uniroma3.it [netkit.users-bounces a list.dia.uniroma3.it] on behalf of netkit.users-request a list.dia.uniroma3.it [netkit.users-request a list.dia.uniroma3.it]
> Sent: Thursday, March 28, 2013 12:00 PM
> To: netkit.users a list.dia.uniroma3.it
> Subject: Netkit.users Digest, Vol 64, Issue 4
>
> Send Netkit.users mailing list submissions to
> netkit.users a list.dia.uniroma3.it
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://list.dia.uniroma3.it/mailman/listinfo/netkit.users
> or, via email, send a message with subject or body 'help' to
> netkit.users-request a list.dia.uniroma3.it
>
> You can reach the person managing the list at
> netkit.users-owner a list.dia.uniroma3.it
>
> 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 <rimondin a dia.uniroma3.it>
> To: netkit.users a list.dia.uniroma3.it
> Subject: Re: [Netkit.users] Aodv
> Message-ID: <51540B1E.3010508 a dia.uniroma3.it>
> 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:
>> 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
>> Netkit.users a list.dia.uniroma3.it
>> http://list.dia.uniroma3.it/mailman/listinfo/netkit.users
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://list.dia.uniroma3.it/pipermail/netkit.users/attachments/20130328/a33503b6/attachment-0001.html>
>
> ------------------------------
>
> _______________________________________________
> Netkit.users mailing list
> Netkit.users a list.dia.uniroma3.it
> http://list.dia.uniroma3.it/mailman/listinfo/netkit.users
>
>
> End of Netkit.users Digest, Vol 64, Issue 4
> *******************************************
>
>
> _______________________________________________
> Netkit.users mailing list
> Netkit.users a list.dia.uniroma3.it
> http://list.dia.uniroma3.it/mailman/listinfo/netkit.users
>
-------------- parte successiva --------------
Un allegato HTML ? stato rimosso...
URL: <http://list.dia.uniroma3.it/pipermail/netkit.users/attachments/20130402/7e17245c/attachment-0001.html>
More information about the Netkit.users
mailing list