[OLSR-users] Problems to transmit two hops away...

[(spam-protected)]

Hello again,


The result of cat /proc/sys/net/ipv4/ip_forward is "1" (on 192.168.11.2)...
and the result of cat /proc/sys/net/ipv4/conf/<INT NAME>/send_redirects on
the same computer is "0"....

And I am very sure that the olsrd is running on 192.168.11.2...

Do you have any other idea?...

I just want to add that I found something extrange about the routes
created by OLSRD... I found this by comparing the routes displayed using
the Linux-GUI and the output of the command "route" at the node
192.168.11.3. This node has two neighbors one hop away... 192.168.11.2 and
192.168.11.4. The Linux-GUI says that to reach 192.168.11.2 the weight is
"1" and the Gateway is "0.0.0.0". The "route" command says that the Metric
is "1" and the Gateway is "*". I think that this info is correct...

However, to reach 192.168.11.4, the Linux-GUI says that the weight is "0"
and the Gateway is "192.168.11.4" (I think this is wrong). On the other
hand, he "route" command says that the Metric is "1" and the Gateway is
"*" . So, is it wrong or it has something to do with the "MPRs"?

Thanks in advance...

Pedro


> Hi,
>
>
> what is the result of:
> cat /proc/sys/net/ipv4/ip_forward
> ?
>
> If this file contains 0 then IP forwarding is not enabled. Do a:
> echo "1" > /proc/sys/net/ipv4/ip_forward
>
> It also seems as ICMP redirects are not disabeled on the 192.168.11.2
> node. This can be disabled by setting:
> echo "0" > /proc/sys/net/ipv4/conf/<INT NAME>/send_redirects
> where <INT NAME> is the label of the interface(eg. eth0). Olsrd should
> set thieese proc entries itself, so something must have happened here...
> you are sure olsrd is running on 192.168.11.2?
>
> - Andreas
>
>
> (spam-protected) wrote:
>> Hi there...
>>
>> I set up a testbed with four computers using OLSRD and it was working
>> properly... but now (after two weeks of not using it) I cannot do a ping
>> to reach a computer located more than one hop away...
>>
>> I though that the the forwarding node could have the FORWARDING
>> attribute
>> blocked, but I checked the IPTables and it is not like that... the
>> output
>> of "iptables --list" at the forwarding computer is:
>>
>>
>> Chain INPUT (policy ACCEPT)
>> target     prot opt source               destination
>> DROP       all  --  192.168.11.4         anywhere
>> ACCEPT     udp  --  anywhere             anywhere            udp dpt:698
>>
>> Chain FORWARD (policy ACCEPT)
>> target     prot opt source               destination
>> ACCEPT     all  --  anywhere             anywhere
>>
>> Chain OUTPUT (policy ACCEPT)
>> target     prot opt source               destination
>> ACCEPT     all  --  anywhere             anywhere
>>
>>
>> I am trying to PING from 192.168.11.3 to 192.168.11.1 passing by
>> 192.168.11.2, but I get the following output..
>>
>> PING 192.168.11.1 (192.168.11.1) 56(84) bytes of data.
>>>From 192.168.11.2: icmp_seq=0 Redirect Host(New nexthop: 192.168.11.1)
>>>From 192.168.11.2: icmp_seq=1 Redirect Host(New nexthop: 192.168.11.1)
>>>From 192.168.11.2: icmp_seq=2 Redirect Host(New nexthop: 192.168.11.1)
>>>From 192.168.11.2: icmp_seq=3 Redirect Host(New nexthop: 192.168.11.1)
>>>From 192.168.11.2: icmp_seq=4 Redirect Host(New nexthop: 192.168.11.1)
>>
>>
>> The routing table of the transmitter computer (192.168.11.3) is:
>>
>>
>> Kernel IP routing table
>> Destination     Gateway         Genmask         Flags Metric Ref    Use
>> Iface
>> 192.168.11.2    *               255.255.255.255 UH    1      0        0
>> eth1
>> 192.168.11.1    192.168.11.2    255.255.255.255 UGH   2      0        0
>> eth1
>> 192.168.1.0     *               255.255.255.0   U     0      0        0
>> eth0
>> 192.168.11.0    *               255.255.255.0   U     0      0        0
>> eth1
>> 169.254.0.0     *               255.255.0.0     U     0      0        0
>> eth0
>> 127.0.0.0       *               255.0.0.0       U     0      0        0
>> lo
>> default         192.168.1.1     0.0.0.0         UG    0      0        0
>> eth0
>>
>>
>> I have tried every idea that has came to my mind but I cannot make it
>> work... Any idea anybody?
>>
>>
>> Thanks in advance
>>
>>
>>
>> _______________________________________________
>> olsr-users mailing list
>> (spam-protected)
>> https://www.olsr.org/mailman/listinfo/olsr-users
>
> --
> Andreas Tønnesen
> http://www.olsr.org
>