netdev - RE: IPv6 routing requests ignore NLM_F_CREATE and NLM_F

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <82C9FC7ED59434458AD4E09AFF2DE230B534F9@FIESEXC006.nsn-intra.net>
Date:	Tue, 18 Oct 2011 09:02:21 +0300
From:	"Vaittinen, Matti (EXT-Other - FI/Oulu)" 
	<matti.vaittinen.ext@....com>
To:	<netdev@...r.kernel.org>
Subject: RE: IPv6 routing requests ignore NLM_F_CREATE and NLM_F_REPLACE

 
Hi again.


	> -----Original Message-----
	> From: Vaittinen, Matti (EXT-Other - FI/Oulu) 
	> Sent: Monday, October 17, 2011 12:06 PM
	> To: 'netdev@...r.kernel.org'
	> Subject: IPv6 routing requests ignore NLM_F_CREATE and
NLM_F_REPLACE
	> 
	> 	Hi dee Ho!
	> 
	> I was enchancing an userspace application configuring IPv4
routes via netlink sockets to support 
	> IPv6 route configuration too. While doing this I noticed that
NLM_F_* flags seemed to have 
	> no handling at IPv6 side. For example replacing a route to
some destiantion, with route 
	> having different pref_src (or metric or gateway or...) can be
done by having NLM_F_REPLACE flag 
	> specified in netlink request and leaving out NLM_F_CREATE.
	> 
	> However with IPv6, if new route being requested has different
properties (like gateway or 
	> metric or..) the existing one will not be replaced. Instead a
new route will be created - even 
	> if NLM_F_CREATE was not specified in request.
	> 
	> That causes some inconvenience when a route is being changed.
Routes need to be queried, and 
	> matching route needs to be explisitly deleted by userspace
application. Also creating new route 
	> even without NLM_F_CREATE feels a bit strange to me.
	> 
	> I was wondering if this is a bug or wanted behaviour? I was
thinking of trying to write a patch 
	> to add support for replacing a route, but I feel I'm a bit
lost with the fib :) I guess the 
	> fib6_add_rt2node function could be changed to inspect the
NLM_F_ flags from nl_info pointer, 
	> and to perform replace instead of returning -EEXIST /
performing insertion. Also returning error 
	> when NLM_F_CREATE is not specified, and existing route is not
found could propably be implemented.
	> 
	> Anyways, before I spend more time trying to understand the
data structures in fib6, I would like 
	> to ask if the handling of NLM_F_* flags is dropped out in
purpose?

I do not intend pushing this topic but is this the correct list to ask
this? Is there something I could clarify regarding my question? If this
is not correct list, could someone please point me the right one.

	> 
	> 
	> Br. Matti Vaittinen
	> 
	> --
	> 
	> Theory:
	> Theoretical approach means that everything is well known, but
still nothing works.
	> Practice:
	> Practical approach means that everything works but no one
knows why.
	> 
	> Thank God we have theory and practice balanced here. Nothing
works, and no one knows why...
	> 
	> 

Regards. 
-Matti Vaittinen
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html