* Re: operation failure on delete
2009-03-04 16:16 operation failure on delete Bryan Duff
@ 2009-03-04 18:12 ` Pablo Neira Ayuso
2009-03-04 19:01 ` Bryan Duff
0 siblings, 1 reply; 4+ messages in thread
From: Pablo Neira Ayuso @ 2009-03-04 18:12 UTC (permalink / raw)
To: Bryan Duff; +Cc: netfilter-devel
[-- Attachment #1: Type: text/plain, Size: 1192 bytes --]
Bryan Duff wrote:
> //snip - conntrack search and attempted delete.
> root@localhost / # conntrack -L -p gre unknown 47 27 src=60.60.60.151
> dst=192.168.2.2 packets=6 bytes=648 [UNREPLIED] src=10.10.10.100
> dst=60.60.60.151 packets=0 bytes=0 mark=2 use=1
> conntrack v0.9.11 (conntrack-tools): 1 flow entries has been shown.
> root@localhost / # conntrack -D -p gre
> conntrack v0.9.11 (conntrack-tools): Operation failed: invalid parameters
> //end snip
>
> But I can delete tcp, udp, icmp conntrack entries. I can only guess
> that there is a problem with "unknown" protocols like gre (haven't
> checked on esp, and so forth). Using the protocol number (in this case
> 47) also fails.
No, it seems that the problem is that libnetfilter_conntrack-0.0.99 does
not include support for GRE yet.
> I'm using libnfnetlink-0.0.40 and libnetfilter_conntrack-0.0.99
>
> Kernel version 2.6.29-rc7. The conntrack version is that released on
> the website (md5sum: ae97d335ad44e9611adde881490c8ec9).
The following patch should add it, it compiles, I didn't tested though.
I'd appreciate if you call tell me how it goes with it.
--
"Los honestos son inadaptados sociales" -- Les Luthiers
[-- Attachment #2: gre-support.patch --]
[-- Type: text/x-diff, Size: 2718 bytes --]
src: add support for GRE transport protocol
This patch adds support for GRE transport protocol.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
src/conntrack/build.c | 1 +
src/conntrack/snprintf_default.c | 9 +++++++--
src/conntrack/snprintf_xml.c | 14 +++++++++++++-
3 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/src/conntrack/build.c b/src/conntrack/build.c
index 9611508..a1569ab 100644
--- a/src/conntrack/build.c
+++ b/src/conntrack/build.c
@@ -50,6 +50,7 @@ void __build_tuple_proto(struct nfnlhdr *req,
case IPPROTO_UDP:
case IPPROTO_TCP:
case IPPROTO_SCTP:
+ case IPPROTO_GRE:
nfnl_addattr_l(&req->nlh, size, CTA_PROTO_SRC_PORT,
&t->l4src.tcp.port, sizeof(u_int16_t));
nfnl_addattr_l(&req->nlh, size, CTA_PROTO_DST_PORT,
diff --git a/src/conntrack/snprintf_default.c b/src/conntrack/snprintf_default.c
index 7cf28f8..a846af9 100644
--- a/src/conntrack/snprintf_default.c
+++ b/src/conntrack/snprintf_default.c
@@ -13,7 +13,8 @@ static char *proto2str[IPPROTO_MAX] = {
[IPPROTO_UDPLITE] = "udplite",
[IPPROTO_ICMP] = "icmp",
[IPPROTO_ICMPV6] = "icmpv6",
- [IPPROTO_SCTP] = "sctp"
+ [IPPROTO_SCTP] = "sctp",
+ [IPPROTO_GRE] = "gre"
};
static char *l3proto2str[AF_MAX] = {
@@ -162,7 +163,11 @@ int __snprintf_proto(char *buf,
ntohs(tuple->l4src.tcp.port),
ntohs(tuple->l4dst.tcp.port));
break;
-
+ case IPPROTO_GRE:
+ return snprintf(buf, len, "srckey=0x%x dstkey=0x%x ",
+ ntohs(tuple->l4src.all),
+ ntohs(tuple->l4dst.all));
+ break;
case IPPROTO_ICMP:
case IPPROTO_ICMPV6:
/* The ID only makes sense some ICMP messages but we want to
diff --git a/src/conntrack/snprintf_xml.c b/src/conntrack/snprintf_xml.c
index b14ff43..cb6fc03 100644
--- a/src/conntrack/snprintf_xml.c
+++ b/src/conntrack/snprintf_xml.c
@@ -59,7 +59,8 @@ static char *proto2str[IPPROTO_MAX] = {
[IPPROTO_UDPLITE] = "udplite",
[IPPROTO_ICMP] = "icmp",
[IPPROTO_ICMPV6] = "icmp6",
- [IPPROTO_SCTP] = "sctp"
+ [IPPROTO_SCTP] = "sctp",
+ [IPPROTO_GRE] = "gre"
};
static char *l3proto2str[AF_MAX] = {
[AF_INET] = "ipv4",
@@ -177,6 +178,17 @@ static int __snprintf_proto_xml(char *buf,
BUFFER_SIZE(ret, size, len, offset);
}
break;
+ case IPPROTO_GRE:
+ if (type == __ADDR_SRC) {
+ ret = snprintf(buf, len, "<srckey>0x%x</srckey>",
+ ntohs(tuple->l4src.all));
+ BUFFER_SIZE(ret, size, len, offset);
+ } else {
+ ret = snprintf(buf, len, "<dstkey>%u</dstkey>",
+ ntohs(tuple->l4dst.all));
+ BUFFER_SIZE(ret, size, len, offset);
+ }
+ break;
}
return ret;
^ permalink raw reply related [flat|nested] 4+ messages in thread