Is it a bug of RADIX ?????
JACK
jack.shang at huawei.com
Thu May 19 02:46:12 UTC 2011
THANKS FOR YOUR REPLY! :)
the version I used can be found here:
http://fxr.watson.org/fxr/source/net/radix.c?v=DFBSD
I'm not use the rt_maskedcopy, I 'build' the key by my rdx_build_rtentry.
Maybe there is some bug in my rdx_build_rtentry? but I can't find it!
<pre>
struct rtsockaddr {
u_char sa_len; /* total length */
// u_char sa_family; /* address family */
u_char sa_data[18 + 1]; /* actually longer; address value */
};
struct rtentry {
struct radix_node rt_nodes[2]; /* tree glue, and other values */
struct rtsockaddr key;
struct rtsockaddr msk;
int rt_index;
};
void rdx_build_rtentry (
struct rtentry *rt,
unsigned int uiVpnId,
unsigned int *puiKey,
int iKeyLen)
{
int k;
int dwLen;
dwLen = (iKeyLen / 32) + !!(iKeyLen & 31);
rt->key.sa_len = 1 + 2 + (iKeyLen / 8) + !!(iKeyLen & 7);
rt->msk.sa_len = rt->key.sa_len;
rt->key.sa_data[0] = (uiVpnId >> 8) & 0xFF;
rt->key.sa_data[1] = uiVpnId & 0xFF;
rt->msk.sa_data[0] = 0xFF;
rt->msk.sa_data[1] = 0xFF;
for (k = 0; k < dwLen; k++)
{
rt->key.sa_data[k * 4 + 2] = (puiKey[k] >> 24) & 0xFF;
rt->key.sa_data[k * 4 + 3] = (puiKey[k] >> 16) & 0xFF;
rt->key.sa_data[k * 4 + 4] = (puiKey[k] >> 8) & 0xFF;
rt->key.sa_data[k * 4 + 5] = puiKey[k] & 0xFF;
rt->msk.sa_data[k * 4 + 2] = 0xFF;
rt->msk.sa_data[k * 4 + 3] = 0xFF;
rt->msk.sa_data[k * 4 + 4] = 0xFF;
rt->msk.sa_data[k * 4 + 5] = 0xFF;
}
for (k = iKeyLen / 8 + 2 + !!(iKeyLen & 7);
// k < rt->key.sa_len;
k < sizeof(rt->key.sa_data);
k++)
{
rt->key.sa_data[k] = 0;
rt->msk.sa_data[k] = 0;
}
if (k = (iKeyLen & 0x7))
{
rt->key.sa_data[iKeyLen / 8 + 2] &= ((1 << k) - 1) << (8 - k);
rt->msk.sa_data[iKeyLen / 8 + 2] &= ((1 << k) - 1) << (8 - k);
}
if (1 && 0x36 == rt->key.sa_data[2]
&& 0x0a == rt->key.sa_data[3])
{
int i = 0;
printf ("\r\n%04X/%08X/%2d -> ", uiVpnId, puiKey[0], iKeyLen);
printf ("%02X ", rt->key.sa_len);
for (i = 0; i < rt->key.sa_len - 0; i++)
{
printf ("%02X ", (unsigned char)rt->key.sa_data[i]);
}
printf ("/ ");
printf ("%02X ", rt->key.sa_len);
for (i = 0; i < rt->msk.sa_len - 0; i++)
{
printf ("%02X ", (unsigned char)rt->msk.sa_data[i]);
}
}
}
int rdx_insert_key (
struct radix_node_head *rdx_hdr,
unsigned int uiVpnId,
unsigned int *puiKey,
int iKeyLen,
unsigned int index)
{
struct rtentry *rt;
R_Malloc(rt, struct rtentry *, sizeof(*rt));
bzero(rt, sizeof(*rt));
rdx_build_rtentry (rt, uiVpnId, puiKey, iKeyLen);
rt->rt_index = index;
if (NULL == rdx_hdr->rnh_addaddr((char*)&rt->key, (char*)&rt->msk, rdx_hdr, rt->rt_nodes))
{
return RDX_ALREADY_EXIST;
}
return RDX_OK;
}
int rdx_delete_key (
struct radix_node_head *rdx_hdr,
unsigned int uiVpnId,
unsigned int *puiKey,
int iKeyLen)
{
struct rtentry rt = {0};
struct rtentry *rt_hit;
rdx_build_rtentry (&rt, uiVpnId, puiKey, iKeyLen);
rt_hit = (struct rtentry *) rdx_hdr->rnh_deladdr((char*)&rt.key, (char*)&rt.msk, rdx_hdr);
if (NULL == rt_hit)
{
return RDX_NOT_EXIST;
}
Free (rt_hit);
return RDX_OK;
}
<b>rdx_hdr = NULL;
rn_inithead((void **)&rdx_hdr, 8); // I just want to skip the first byte of key</b>
</pre>
and the output of inserting and deleting was as below:
<pre>
Inserting ...
0000/360AD0A2/30 -> 07 00 00 36 0A D0 A0 00 / 07 FF FF FF FF FF FC 00
0000/360ADFEC/20 -> 06 00 00 36 0A D0 00 / 06 FF FF FF FF F0 00
0000/360AD082/30 -> 07 00 00 36 0A D0 80 00 / 07 FF FF FF FF FF FC 00
Dumping ...
07 00 00 36 0A D0 80 / 07 FF FF FF FF FF FC
07 00 00 36 0A D0 A0 / 07 FF FF FF FF FF FC
06 00 00 36 0A D0 / 06 FF FF FF FF F0
Deleting ...
0000/360AD0A2/30 -> 07 00 00 36 0A D0 A0 00 / 07 FF FF FF FF FF FC 00
0000/360ADFEC/20 -> 06 00 00 36 0A D0 00 / 06 FF FF FF FF F0 00 <<<<< fail here
0000/360AD082/30 -> 07 00 00 36 0A D0 80 00 / 07 FF FF FF FF FF FC 00
</pre>
/jack
JACKSHANG/62185
HUAWEI TECHNOLOGIES CO.,LTD.
Address: Huawei Industrial Base
Bantian Longgang
Shenzhen 518129, P.R.China
E-mail: JACK.SHANG at HUAWEI.COM
www.huawei.com
-------------------------------------------------------------------------------------------------------------------------------------
This e-mail and its attachments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!
发件人: Alexander V. Chernikov-2 [via FreeBSD] [mailto:ml-node+4406813-1462758870-209672 at n5.nabble.com]
发送时间: 2011年5月18日 23:37
收件人: Jack Shang(hongzhang)
主题: Re: 答复: Is it a bug of RADIX ?????
On 18.05.2011 19:15, Jack Shang(hongzhang) wrote:
> I do these by call the radix routine such as rn_addroute and rn_delete directly.
Okay. Can you provide FreeBSD version and a piece of code triggering
such a situation?
IMHO radix assumes destination address to have host bits cleared, code in
rtrequest1_fib does this via rt_maskedcopy().
Are you sure you need to pass
0x360AD0A2/30
0x360ADFEC/20
0x360AD082/30
instead of:
0x360AD0A0/30
0x360AD000/20
0x360AD080/30
?
> ________________________________________
> 发件人: Alexander V. Chernikov [[hidden email]]
> 发送时间: 2011年5月18日 20:54
> 到: Jack Shang(hongzhang)
> Cc: [hidden email]
> 主题: Re: Is it a bug of RADIX ?????
>
> On 18.05.2011 16:31, JACK wrote:
>> After inserting the following IPv4 routers:
>>
>> 0x360AD0A2/30
>> 0x360ADFEC/20
>> 0x360AD082/30
>>
>> I try to delete the above routes, when delete the second
>> route(0x360ADFEC/20), the operation fail.
> Can you specify exact commands you are issuing to add/remove routes?
> (or "route monitor" output if you are doing this from some dynamic
> routing software)
>
> The following order works for me (8.2-STABLE):
>
> 16:44 [0] bibi# route add -net 54.10.208.162/30 10.11.0.1
> add net 54.10.208.162: gateway 10.11.0.1
> 16:45 [0] bibi# route add -net 54.10.223.236/20 10.11.0.1
> add net 54.10.223.236: gateway 10.11.0.1
> 16:46 [0] bibi# route add -net 54.10.208.130/30 10.11.0.1
> add net 54.10.208.130: gateway 10.11.0.1
>
> 16:46 [0] bibi# netstat -rn -finet | grep 54
> 54.10.208.0/20 10.11.0.1 UGS 0 0 em0
> 54.10.208.128/30 10.11.0.1 UGS 0 0 em0
> 54.10.208.160/30 10.11.0.1 UGS 0 0 em0
> 16:46 [0] bibi# route delete 54.10.208.0/20
> delete net 54.10.208.0
> 16:48 [0] bibi# route delete 54.10.208.128/30
> delete net 54.10.208.128
> 16:49 [0] bibi# route delete 54.10.208.160/30
> delete net 54.10.208.160
> 16:49 [0] bibi# netstat -rn -finet | grep 54
> 16:49 [0] bibi#
>
>
>> struct radix_node * rn_delete (........)
>> {
>> ...
>> /*
>> * Delete our route from mask lists.
>> */
>> if (netmask != NULL) {
>> if ((x = rn_addmask(netmask, TRUE, head_off)) == NULL)
>> return (NULL);
>> netmask = x->rn_key;
>> while (tt->rn_mask != netmask)
>> if ((tt = tt->rn_dupedkey) == NULL)
>> return (NULL); // rn_delete return here!!!
>> }
>> ...
>> }
>>
>> but, if I delete as the following order, all routers was deleted
>> successfully:
>>
>> 0x360AD0A2/30
>> 0x360AD082/30
>> 0x360ADFEC/20
>>
>>
>> so, is it a bug of RADIX?
>>
>> /jack
>>
>>
>>
>>
>> --
>> View this message in context: http://freebsd.1045724.n5.nabble.com/Is-it-a-bug-of-RADIX-tp4406356p4406356.html
>> Sent from the freebsd-net mailing list archive at Nabble.com.
>> _______________________________________________
>> [hidden email] mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>> To unsubscribe, send any mail to "[hidden email]"
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[hidden email]"
________________________________________
If you reply to this email, your message will be added to the discussion below:
http://freebsd.1045724.n5.nabble.com/Is-it-a-bug-of-RADIX-tp4406356p4406813.html
To unsubscribe from Is it a bug of RADIX ?????, click here.
--
View this message in context: http://freebsd.1045724.n5.nabble.com/Is-it-a-bug-of-RADIX-tp4406356p4408573.html
Sent from the freebsd-net mailing list archive at Nabble.com.
More information about the freebsd-net
mailing list