PROBLEM: nd_tbl not a public symbol in net/ipv6/ndisc.c

PROBLEM: nd_tbl not a public symbol in net/ipv6/ndisc.c

[Christian Tschudin]

Our LUNAR project (underlay for wireless multihop networks)
stumbled over the same problem that at least two other projects
(infiniband, and mipv6) also experienced many months ago:

  The neighbor table 'nd_tbl' in net/ipv6/ndisc.c
  is not accessible from other modules.

  This prevents several 2.6.x kernel modules in networking
  from being deployed without kernel patching and recompilation.

Please find a patch below.

best, christian tschudin.

---

--- linux-2.6.10/net/ipv6/ipv6_syms.c   2004-12-24 22:35:23.000000000 +0100
+++ work/linux-2.6.10/net/ipv6/ipv6_syms.c      2005-01-30 23:44:42.743620264 +0100
@@ -41,3 +41,4 @@
 EXPORT_SYMBOL(rt6_lookup);
 EXPORT_SYMBOL(fl6_sock_lookup);
 EXPORT_SYMBOL(ipv6_push_nfrag_opts);
+EXPORT_SYMBOL(nd_tbl);

---
Christian Tschudin, University of Basel       http://cn.cs.unibas.ch/
Computer Science Dept, Bernoullistr. 16, CH - 4056 Basel, Switzerland

Re: PROBLEM: nd_tbl not a public symbol in net/ipv6/ndisc.c

[YOSHIFUJI Hideaki / 吉藤英明]

In article <Pine.OSF.4.58.0501310903220.211@igor.urz.unibas.ch> (at Mon, 31 Jan 2005 09:04:34 +0100 (MET)), Christian Tschudin <Christian.Tschudin@unibas.ch> says:

> Our LUNAR project (underlay for wireless multihop networks)
> stumbled over the same problem that at least two other projects
> (infiniband, and mipv6) also experienced many months ago:
> 
>   The neighbor table 'nd_tbl' in net/ipv6/ndisc.c
>   is not accessible from other modules.
:
> +EXPORT_SYMBOL(nd_tbl);

I disagree.
Basically, ndisc.c is the only user of that structure and
I cannot find why you really need this symbol.

--yoshfuji

Re: PROBLEM: nd_tbl not a public symbol in net/ipv6/ndisc.c

[Christian Tschudin]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 1499 bytes --]

On Mon, 31 Jan 2005, YOSHIFUJI Hideaki / [iso-2022-jp] µÈÆ£±ÑÌÀ wrote:

> In article <Pine.OSF.4.58.0501310903220.211@igor.urz.unibas.ch> (at Mon, 31 Jan 2005 09:04:34 +0100 (MET)), Christian Tschudin <Christian.Tschudin@unibas.ch> says:
>
> > Our LUNAR project (underlay for wireless multihop networks)
> > stumbled over the same problem that at least two other projects
> > (infiniband, and mipv6) also experienced many months ago:
> >
> >   The neighbor table 'nd_tbl' in net/ipv6/ndisc.c
> >   is not accessible from other modules.
> :
> > +EXPORT_SYMBOL(nd_tbl);
>
> I disagree.
> Basically, ndisc.c is the only user of that structure and
> I cannot find why you really need this symbol.

We have implemented an underlay network layer protocol.
This means that we present to the IP stack a subnet illusion
while doing wireless multihop forwarding underneath.
To this end we need to set and unset entries in the neighbor
table, because we are actively managing neighbors.

Now, if you know a technique how to invoke

  neigh_lookup(struct neigh_table *tbl, ...)
or
  neigh_lookup_errno(struct neigh_table *tbl, ...)

without having the reference to nd_tbl (i.e., getting at this
value by some indirect means), we would be happy use it.
Is there a way? Otherwise, we need a public nd_tbl symbol.

best, christian

---
Christian Tschudin, University of Basel       http://cn.cs.unibas.ch/
Computer Science Dept, Bernoullistr. 16, CH - 4056 Basel, Switzerland

Re: PROBLEM: nd_tbl not a public symbol in net/ipv6/ndisc.c

[YOSHIFUJI Hideaki / 吉藤英明]

In article <Pine.OSF.4.58.0501310922130.2054@igor.urz.unibas.ch> (at Mon, 31 Jan 2005 10:16:29 +0100 (MET)), Christian Tschudin <Christian.Tschudin@unibas.ch> says:

> We have implemented an underlay network layer protocol.
> This means that we present to the IP stack a subnet illusion
> while doing wireless multihop forwarding underneath.
> To this end we need to set and unset entries in the neighbor
> table, because we are actively managing neighbors.

Ok, but basically, we do not export it unless it is really used.
We may do if it is necessary when you merge it.

BTW, for your purpose, we may export
 ndisc_lookup()
or something instead of nd_tbl itself.

Anyway, I'd like to know the usage (code).

--yoshfuji

Re: PROBLEM: nd_tbl not a public symbol in net/ipv6/ndisc.c

[Christian Tschudin]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 1330 bytes --]

On Mon, 31 Jan 2005, YOSHIFUJI Hideaki / [iso-2022-jp] µÈÆ£±ÑÌÀ wrote:

> Ok, but basically, we do not export it unless it is really used.
> We may do if it is necessary when you merge it.
>
> BTW, for your purpose, we may export
>  ndisc_lookup()
> or something instead of nd_tbl itself.
>
> Anyway, I'd like to know the usage (code).

Your new ndisc_lookup() would need to distinguish the IP address types
(relating to different tables).

Here is roughly what we do:

---
int netbox_neigh_map(struct net_device *dev,
		     struct lunartarget_s *host,
		     char *eth)
{
	struct neighbour *neigh = 0;

	if (TARGET_IS_IPV4(host))
		neigh = neigh_lookup_errno(&arp_tbl, (struct in_addr*)&(host->addr.ipv4), dev);
	else if (TARGET_IS_IPV6(host))
		neigh = neigh_lookup_errno(&nd_tbl, &host->addr.ipv6, dev);

        if (!IS_ERR(neigh)) {
		neigh->parms->delay_probe_time = 0;
                NEIGH_UPDATE(neigh, eth, NUD_REACHABLE, 1, 0);
                neigh_release(neigh);
        }

	return 0;
}
---

Our other function netbox_neigh_unmap() is basically the same,
with the flag NUD_REACHABLE replaced by NUD_NONE.

best, christian

PS: full code (use guest/guest for username/password) at
    https://subversion.cs.unibas.ch/repos/lunar/trunk/lnx/knetbox.c

>
> --yoshfuji
>

Re: PROBLEM: nd_tbl not a public symbol in net/ipv6/ndisc.c

[Christian Tschudin]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 1796 bytes --]

three weeks ago we had a message exchang on nd_tbl not
being a public symbol; I had sent you some code for showing
the usage.

What do you think now?

best, christian.

---
Christian Tschudin, University of Basel       http://cn.cs.unibas.ch/
Computer Science Dept, Bernoullistr. 16, CH - 4056 Basel, Switzerland

On Mon, 31 Jan 2005, Christian Tschudin wrote:

> On Mon, 31 Jan 2005, YOSHIFUJI Hideaki / [iso-2022-jp] µÈÆ£±ÑÌÀ wrote:
>
> > Ok, but basically, we do not export it unless it is really used.
> > We may do if it is necessary when you merge it.
> >
> > BTW, for your purpose, we may export
> >  ndisc_lookup()
> > or something instead of nd_tbl itself.
> >
> > Anyway, I'd like to know the usage (code).
>
> Your new ndisc_lookup() would need to distinguish the IP address types
> (relating to different tables).
>
> Here is roughly what we do:
>
> ---
> int netbox_neigh_map(struct net_device *dev,
> 		     struct lunartarget_s *host,
> 		     char *eth)
> {
> 	struct neighbour *neigh = 0;
>
> 	if (TARGET_IS_IPV4(host))
> 		neigh = neigh_lookup_errno(&arp_tbl, (struct in_addr*)&(host->addr.ipv4), dev);
> 	else if (TARGET_IS_IPV6(host))
> 		neigh = neigh_lookup_errno(&nd_tbl, &host->addr.ipv6, dev);
>
>         if (!IS_ERR(neigh)) {
> 		neigh->parms->delay_probe_time = 0;
>                 NEIGH_UPDATE(neigh, eth, NUD_REACHABLE, 1, 0);
>                 neigh_release(neigh);
>         }
>
> 	return 0;
> }
> ---
>
> Our other function netbox_neigh_unmap() is basically the same,
> with the flag NUD_REACHABLE replaced by NUD_NONE.
>
> best, christian
>
> PS: full code (use guest/guest for username/password) at
>     https://subversion.cs.unibas.ch/repos/lunar/trunk/lnx/knetbox.c
>
> >
> > --yoshfuji
> >
>

Re: PROBLEM: nd_tbl not a public symbol in net/ipv6/ndisc.c

[YOSHIFUJI Hideaki / 吉藤英明]

In article <Pine.OSF.4.58.0502240942570.11226@igor.urz.unibas.ch> (at Thu, 24 Feb 2005 09:47:39 +0100 (MET)), Christian Tschudin <Christian.Tschudin@unibas.ch> says:

> three weeks ago we had a message exchang on nd_tbl not
> being a public symbol; I had sent you some code for showing
> the usage.
> 
> What do you think now?

I believe you can manage (map/unmap) neighbour entries via netlink.

--yoshfuji