Date: Wed, 18 May 2011 19:46:10 -0700 (PDT) From: JACK <jack.shang@huawei.com> To: freebsd-net@freebsd.org Subject: RE: RE: Is it a bug of RADIX ????? Message-ID: <78D2B330B6A30B4CB554FD2EC08D7434F36F04@szxeml508-mbx.china.huawei.com> In-Reply-To: <4DD3E713.3070008@ipfw.ru> References: <1305721909414-4406356.post@n5.nabble.com> <4DD3C17E.9070903@ipfw.ru> <4DD3E713.3070008@ipfw.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?78D2B330B6A30B4CB554FD2EC08D7434F36F04>