В письме от 9 ноября 2013 07:42:06 Вы написали:
Hi,
I applied this code manually:
+ if ((v1.type == T_IP) && (v2.type == T_PREFIX_SET)) { + v1.val.px.len = MAX_PREFIX_LENGTH; + return trie_match_fprefix(v2.val.ti, &v1.val.px); + }
To filter.c
However maybe the patch failed because I don't have the following:
if (v2.type != T_SET) return CMP_ERROR;
Maybe the patch that was sent was within a different branch than the main 1.3.11 that's available for download?
Oh sorry, John, I patch really was made on top of current upstream tree, not 1.3.11. In attachment udpated patch version applied on top of 1.3.11 stable tree. Sorry for that. And yes, really according to documentation we could match only on set with elements of same tyme. On the other hand, an ip type may be easily represented as prefix with length of max AFI prefix length (32 - IPv4, 128 - IPv6, so I see no problem using this conversion of ip to prefix type. Moreover on IPv4 BIRD build there is implicit conversion of ip type to quad as on IPv4 they basically represent value with same format. Thanks for your note. -- SP5474-RIPE Sergey Popovich
Hi, Confirmed that the code I applied in the last patch is working fine. Also confirmed that the latest patch supplied works successfully with: patch -p1 < bird-1.3.11-match-T_IP-against-T_PREFIX_SET-v2.patch in top level directory of bird-1.3.11 source, and also confirmed that the function you suggested is working fine. Thank you very much! -JJ On Mon, Nov 11, 2013 at 3:08 AM, Sergey Popovich <popovich_sergei@mail.ru>wrote:
В письме от 9 ноября 2013 07:42:06 Вы написали:
Hi,
I applied this code manually:
+ if ((v1.type == T_IP) && (v2.type == T_PREFIX_SET)) { + v1.val.px.len = MAX_PREFIX_LENGTH; + return trie_match_fprefix(v2.val.ti, &v1.val.px); + }
To filter.c
However maybe the patch failed because I don't have the following:
if (v2.type != T_SET) return CMP_ERROR;
Maybe the patch that was sent was within a different branch than the main 1.3.11 that's available for download?
Oh sorry, John, I patch really was made on top of current upstream tree, not 1.3.11. In attachment udpated patch version applied on top of 1.3.11 stable tree.
Sorry for that.
And yes, really according to documentation we could match only on set with elements of same tyme. On the other hand, an ip type may be easily represented as prefix with length of max AFI prefix length (32 - IPv4, 128 - IPv6, so I see no problem using this conversion of ip to prefix type.
Moreover on IPv4 BIRD build there is implicit conversion of ip type to quad as on IPv4 they basically represent value with same format.
Thanks for your note.
-- SP5474-RIPE Sergey Popovich
On Mon, Nov 11, 2013 at 10:08:30AM +0200, Sergey Popovich wrote:
And yes, really according to documentation we could match only on set with elements of same tyme.
That is true, IPs are matched against IP sets, while prefixes are matched against prefix sets. The main problem is that syntactic expression '[ 192.168.1.0/24 ]' could be interpreted either as prefix set containing one element, or as an shorthand for ip set containing 256 such addresses. There is a way (although less convenient) how to write such ip sets even in the current code: [ 192.168.1.0 .. 192.168.1.255 ].
On the other hand, an ip type may be easily represented as prefix with length of max AFI prefix length (32 - IPv4, 128 - IPv6, so I see no problem using this conversion of ip to prefix type.
There is one major problem related to such change. The intuitive way to write such expression is: 192.168.1.1 ~ [ 192.168.0.0/16 ] In current code, user gets an error and notices that. After your patch, user wouldn't get error, but the expression wouldn't work as expected (because it has to be '[ 192.168.0.0/16+ ]', which makes less sense). I don't see a good solution for this problem, just several bad ones. Perhaps to write a specialised match function for ip ~ pxset, which walks the trie and returns true if any prefix matches.
Moreover on IPv4 BIRD build there is implicit conversion of ip type to quad as on IPv4 they basically represent value with same format.
Which is a major PITA in the filter code. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
participants (3)
-
John Jensen -
Ondrej Zajicek -
Sergey Popovich