Re: [mpls-linux-devel] Problem with netlink use by MPLS

[James R. L. <jl...@mi...>]

Good job finding the root cause. I will gladly accept a patch that fixes th=
is.
When implementing you patch you may want to look at the some of the
discussions on netdev about netlink handling other address families.  I'm
not sure if code was submitted for this, but if so it would be in the
2.6.11+ time frame.

Let me know if I can answer any questions.

On Tue, Apr 19, 2005 at 11:38:59AM +0200, Vincent Untz wrote:
> Hi,
>=20
> I reported a crash in this thread:
> http://sourceforge.net/mailarchive/forum.php?thread_id=3D7071062&forum_id=
=3D5051
>=20
> After some debugging, we think we found the problem. Here's what's
> happening:
>=20
>  * tcpdump/ethereal/etc. call getifaddrs() to get the the list of
>    interfaces
>  * in glibc >=3D 2.3.3, getifaddrs() uses netlink to find the
>    informations. It opens a netlink socket with the NETLINK_ROUTE family
>    and send RTM_GETLINK and RTM_GETADDR requests for every protocol
>    (AF_UNSPEC)
>  * MPLS uses the NETLINK_ROUTE family and overrides the RTM_* types with
>    its own types. For example, RTM_GETADDR is overrided by
>    MPLS_RTM_GETILM.
>  * when the kernel receives the RTM_GETADDR requests for every protocol,
>    it uses the rtnelink_links[] table to find the table for each
>    protocol that determines what function is called. For MPLS, this
>    table is mpls_rtnetlink_table. Thus, when a RTM_GETADDR request for
>    every protocol is sent, the MPLS_RTM_GETILM callback is called and
>    returns some data.
>  * as this data is not expected (it's not a link and it's not an
>    adresse), the libc abort().
>=20
> There are two problems here :
>  * MPLS overrides the meaning of RTM_* when it shouldn't. I don't think
>    this is easily fixable since the number of RTM_* types is limited and
>    there is not enough space left for MPLS.
>  * MPLS uses NETLINK_ROUTE. It should really use a new netlink family,
>    for example NETLINK_MPLS. I don't think this will be hard to do. It
>    probably involves copying some code from net/core/rtnetlink.c in
>    net/mpls/mpls_netlink.c
>=20
> We'll try to make a patch to add NETLINK_MPLS.
>=20
> Vincent
>=20
> --=20
> Les gens heureux ne sont pas press??s.



--=20
James R. Leu
jl...@mi...