On Tue, Feb 28, 2012 at 02:51:49AM +0000, Alexander V. Chernikov wrote:
On 27.02.2012 10:20, Ondrej Zajicek wrote:
On Fri, Feb 24, 2012 at 11:30:19PM +0400, Alexander V. Chernikov wrote:
Hello list!
There are several improvements that can be applied to OSPF:
1) At the moment TTL is not explicitly set in per-interface sockets, so multicast messages are sent with default OS ttl (which is 255 on *BSD). Hmm, you are right, default TTL for multicast seems to be 1 on Linux, so i missed that.
sk->flags = SKF_LADDR_RX; + sk->ttl = 1;
This will break vlinks (they use same sockets). As TTL for unicast can be different than TTL for multicast, the simplest fix would be to keep sk->ttl for unicast and add a ttl arg to sk_setup_multicast(). This will leave 255 TTL for unicast packets on NBMA ifaces, which is probably not a big issue.
Another possibility is to have a common independent socket for vlinks, but i am not sure whether vlinks need an iface-specific socket - have to be checked what are requirements for vlink sockets. This would be probably better for implementing TTL security later. Vlink sockets are not bound to interface since ospf_iface_new() are called with NULL interface address (ospf.c). ... Are you sure ospf_sk_open() is ever called by vlink code?
It is more complicated - vlink ifaces do not have their sockets, but when a vlink iface is activated, the socket is shared with 'proper' OSPF iface through which the vlink goes. See ospf_check_vlinks().
Maybe we can simply add some kind of:
+ if (s->ttl == -1) + s->ttl = 1;
You are right, this is probably enough. I will fix this.
3) Another problem with OSPF sockets is that they depend on device routes in routing tables and depend on kernel to choose proper source address (if there are more IPv4 prefixes on one iface.
In Linux, the multicast source address is specified in IP_MULTICAST_IF or IP_ADD_MEMBERSHIP, unicast source address is chosen based on dst. address.
I am not sure, but if i remember correctly, this does not work on (at least some) BSD.
Depending on device routes is not a big problem, but makes it a bit more fragile (and also a reason why we do not support _real_ unnumbered ptp ifaces). Sorry, can't get the idea (I'm mostly unaware about multicast API). What we're trying to accomplish?
The problem is not specific to multicast. There are two related but different issues: 1) send a packet through a specific iface, regardless of a state of the kernel routing table (device routes in the routing table in case of a packet to a neighbors). 2) choose a proper source address for that packet. I guess that both could be solved with SO_DONTROUTE, SO_BINDTOIFACE (Linux specific) and/or IP_PKTINFO socket options, but IP_PKTINFO does not work with raw sockets on some BSDs. For multicast sockets, a source address is specified in IP_ADD_MEMBERSHIP on Linux, but on BSD the address used in that option is AFAIK just used to specify an iface and does not affect a source address of sent packets. Unfortunately, this part of socket interface is not well documented and not really consistent between Linux and all BSDs. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."