From: Christian Tschudin <hidden> Date: 2005-01-31 08:04:34
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.
---
In article [off-list ref] (at Mon, 31 Jan 2005 09:04:34 +0100 (MET)), Christian Tschudin [off-list ref] 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
From: Christian Tschudin <hidden> Date: 2005-01-31 09:16:29
On Mon, 31 Jan 2005, YOSHIFUJI Hideaki / [iso-2022-jp] µÈÆ£±ÑÌÀ wrote:
In article [off-list ref] (at Mon, 31 Jan 2005 09:04:34 +0100 (MET)), Christian Tschudin [off-list ref] says:
quoted
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.
:
quoted
+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
In article [off-list ref] (at Mon, 31 Jan 2005 10:16:29 +0100 (MET)), Christian Tschudin [off-list ref] 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
From: Christian Tschudin <hidden> Date: 2005-01-31 10:30:52
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
From: Christian Tschudin <hidden> Date: 2005-02-24 08:47:39
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:
quoted
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