Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> a écrit :
On Mon, Jan 23, 2012 at 01:25:37PM -0500, Quentin Aebischer wrote:
[...]
>>index 01fe4fc..e1c4892 100644
>>--- a/src/read_config_lex.l
>>+++ b/src/read_config_lex.l
>>@@ -47,6 +47,7 @@ ip6_part {hex_255}":"?
>> ip6_form1 {ip6_part}{0,16}"::"{ip6_part}{0,16}
>> ip6_form2 ({hex_255}":"){16}{hex_255}
>> ip6 {ip6_form1}{ip6_cidr}?|{ip6_form2}{ip6_cidr}?
>>+tipc_name {integer}":"{integer}
>> string [a-zA-Z][a-zA-Z0-9\.\-]*
>> persistent [P|p][E|e][R|r][S|s][I|i][S|s][T|t][E|e][N|n][T|T]
>> nack [N|n][A|a][C|c][K|k]
>>@@ -63,9 +64,12 @@ notrack [N|n][O|o][T|t][R|r][A|a][C|c][K|k]
>> "IPv4_interface" { return T_IPV4_IFACE; }
>> "IPv6_interface" { return T_IPV6_IFACE; }
>> "Interface" { return T_IFACE; }
>>+"TIPC_Destination_Name" { return T_TIPC_DEST_NAME; }
>>+"TIPC_Name" { return T_TIPC_NAME; }
>> "Multicast" { return T_MULTICAST; }
>> "UDP" { return T_UDP; }
>> "TCP" { return T_TCP; }
>>+"TIPC" { return T_TIPC; }
>> "HashSize" { return T_HASHSIZE; }
>> "RefreshTime" { return T_REFRESH; }
>> "CacheTimeout" { return T_EXPIRE; }
>>@@ -149,6 +153,8 @@ notrack [N|n][O|o][T|t][R|r][A|a][C|c][K|k]
>> {signed_integer} { yylval.val = atoi(yytext); return T_SIGNED_NUMBER; }
>> {ip4} { yylval.string = strdup(yytext); return T_IP; }
>> {ip6} { yylval.string = strdup(yytext); return T_IP; }
>>+{tipc_name} { yylval.string = strdup(yytext); return T_TIPC_NAME_VAL; }
>
>Can you use T_STRING instead? Then, you can check in the parser that
>the TIPC name is well-formed, i.e. integer:integer.
>
>Otherwise, print one parsing error.
I implemented a new type 'tipc_name', since there was such types for
IPV4 and IPV6 addresses, and I considered a TIPC name was the
equivalent of an IP address, that's why I did this at first.
After thinking about it twice, TIPC name is more like UDP/TCP port,
and TIPC node address/network ID would be like the IP address.
I can still correct that if you want me to.
Make sense what you say, keep using the new type.
>>+ conf.channel_type_global = CHANNEL_TIPC;
>>+ conf.channel[conf.channel_num].channel_type = CHANNEL_TIPC;
>>+ // conf.channel[conf.channel_num].channel_flags = CHANNEL_F_BUFFERED;
Hm, I missed this. Using the buffered flag may be useful, why did you
decided to remove it?
Actually, I don't know what CHANNEL_F_BUFFERED flag would do here, so
I decided to temporarily remove it for the first tests, and then I
forgot to reactivate it.
I think there are other flags that are useful in case you use TIPC in
stream mode:
CHANNEL_F_STREAM
CHANNEL_F_ERRORS
BTW, does your patch support selecting what communication semantics you
want to use for TIPC? In other words, what TIPC working mode are we
using with your patch? (sorry, I'm lazy to look at your original patch
to see it by myself). Please, justify.
We are not using stream mode at the moment. We are using TIPC
SOCK_RDM, which is like SOCK_DGRAM, but guarantees that every messages
sent over the network is properly delivered to its destination node.
There's no flow control mechanism when using SOCK_RDM in
connectionless mode though (which is our case here), so if packets are
not consumed fast enough on the receiver node side, they are queued up
until we reach the maximum number of allowed messages in the queue.
This maximum number is defined by the importance level of the TIPC
messages sent by the sender (which is now a custom parameter in
conntrackd.conf like you suggested).
When we hit the limit, we then enter congestion mode on the receiving node.
Here, depending on the value of SRC_DEST_DROPPABLE, we either silently
drop the packets, or return them with an error code (which we can
detect on the sender side by looking for the return value of rcv(),
that's what I tried to implement for my debug operations).
So yeah, basically I don't know what CHANNEL_BUFFER does :X.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
