From jklimes at redhat.com Thu Sep 3 05:23:51 2015 From: jklimes at redhat.com (=?UTF-8?q?Ji=C5=99=C3=AD=20Klime=C5=A1?=) Date: Thu, 3 Sep 2015 14:23:51 +0200 Subject: [PATCH 0/2] Fixes for VLAN flags Message-ID: <1441283033-19515-1-git-send-email-jklimes@redhat.com> Fixes for VLAN flags. Ji?? Klime? (2): vlan: add VLAN flags to trans_tbl to print them properly vlan: add MVRP VLAN flag include/linux-private/linux/if_vlan.h | 1 + lib/route/link/vlan.c | 3 +++ 2 files changed, 4 insertions(+) -- 2.1.0 From jklimes at redhat.com Thu Sep 3 05:23:52 2015 From: jklimes at redhat.com (=?UTF-8?q?Ji=C5=99=C3=AD=20Klime=C5=A1?=) Date: Thu, 3 Sep 2015 14:23:52 +0200 Subject: [PATCH 1/2] vlan: add VLAN flags to trans_tbl to print them properly In-Reply-To: <1441283033-19515-1-git-send-email-jklimes@redhat.com> References: <1441283033-19515-1-git-send-email-jklimes@redhat.com> Message-ID: <1441283033-19515-2-git-send-email-jklimes@redhat.com> nl-link-list only showed reorder_hdr. $ ip -d link show dev em1.444 28: em1.444 at em1: mtu 1500 qdisc noqueue state UP mode DEFAULT group default link/ether 3c:97:0e:58:1d:c1 brd ff:ff:ff:ff:ff:ff promiscuity 0 vlan protocol 802.1Q id 444 ingress-qos-map { 1:3 4:2 } egress-qos-map { 2:6 9:5 } $ /usr/sbin/nl-link-list --details -i 28 em1.444 ether 3c:97:0e:18:2e:a1 slave-of em1 group 0 vlan-id 444 mtu 1500 txqlen 0 weight 0 qdisc noqueue index 28 txq 1 rxq 1 brd ff:ff:ff:ff:ff:ff state up mode default carrier up vlan-info id 444 vlan protocol <129> ingress vlan prio -> qos/socket prio mapping: 1 -> 0x000003, 4 -> 0x000002, egress qos/socket prio -> vlan prio mapping: 0x000002 -> 6, 0x000009 -> 5, ... Signed-off-by: Ji?? Klime? --- lib/route/link/vlan.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lib/route/link/vlan.c b/lib/route/link/vlan.c index 9dc0d42..d815f65 100644 --- a/lib/route/link/vlan.c +++ b/lib/route/link/vlan.c @@ -610,6 +610,8 @@ struct vlan_map *rtnl_link_vlan_get_egress_map(struct rtnl_link *link, static const struct trans_tbl vlan_flags[] = { __ADD(VLAN_FLAG_REORDER_HDR, reorder_hdr), + __ADD(VLAN_FLAG_GVRP, gvrp), + __ADD(VLAN_FLAG_LOOSE_BINDING, loose_binding), }; /** -- 2.1.0 From jklimes at redhat.com Thu Sep 3 05:23:53 2015 From: jklimes at redhat.com (=?UTF-8?q?Ji=C5=99=C3=AD=20Klime=C5=A1?=) Date: Thu, 3 Sep 2015 14:23:53 +0200 Subject: [PATCH 2/2] vlan: add MVRP VLAN flag In-Reply-To: <1441283033-19515-1-git-send-email-jklimes@redhat.com> References: <1441283033-19515-1-git-send-email-jklimes@redhat.com> Message-ID: <1441283033-19515-3-git-send-email-jklimes@redhat.com> Kernel patch: http://patchwork.ozlabs.org/patch/219040/ iproute2 patch: http://patchwork.ozlabs.org/patch/219364/ Signed-off-by: Ji?? Klime? --- include/linux-private/linux/if_vlan.h | 1 + lib/route/link/vlan.c | 1 + 2 files changed, 2 insertions(+) diff --git a/include/linux-private/linux/if_vlan.h b/include/linux-private/linux/if_vlan.h index 67affd1..bae71c5 100644 --- a/include/linux-private/linux/if_vlan.h +++ b/include/linux-private/linux/if_vlan.h @@ -33,6 +33,7 @@ enum vlan_flags { VLAN_FLAG_REORDER_HDR = 0x1, VLAN_FLAG_GVRP = 0x2, VLAN_FLAG_LOOSE_BINDING = 0x4, + VLAN_FLAG_MVRP = 0x8, }; enum vlan_name_types { diff --git a/lib/route/link/vlan.c b/lib/route/link/vlan.c index d815f65..d266b7e 100644 --- a/lib/route/link/vlan.c +++ b/lib/route/link/vlan.c @@ -612,6 +612,7 @@ static const struct trans_tbl vlan_flags[] = { __ADD(VLAN_FLAG_REORDER_HDR, reorder_hdr), __ADD(VLAN_FLAG_GVRP, gvrp), __ADD(VLAN_FLAG_LOOSE_BINDING, loose_binding), + __ADD(VLAN_FLAG_MVRP, mvrp), }; /** -- 2.1.0 From thaller at redhat.com Thu Sep 3 09:29:18 2015 From: thaller at redhat.com (Thomas Haller) Date: Thu, 03 Sep 2015 18:29:18 +0200 Subject: [PATCH 0/2] Fixes for VLAN flags In-Reply-To: <1441283033-19515-1-git-send-email-jklimes@redhat.com> References: <1441283033-19515-1-git-send-email-jklimes@redhat.com> Message-ID: <1441297758.3057.2.camel@redhat.com> On Thu, 2015-09-03 at 14:23 +0200, Ji?? Klime? wrote: > Fixes for VLAN flags. > > Ji?? Klime? (2): > vlan: add VLAN flags to trans_tbl to print them properly > vlan: add MVRP VLAN flag > > include/linux-private/linux/if_vlan.h | 1 + > lib/route/link/vlan.c | 3 +++ > 2 files changed, 4 insertions(+) Both patches merged as https://github.com/thom311/libnl/commit/2955fd00 3de43672391fe7ded87f61afad66b13a Thank you!! Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From avagin at openvz.org Mon Sep 14 08:59:58 2015 From: avagin at openvz.org (Andrey Vagin) Date: Mon, 14 Sep 2015 18:59:58 +0300 Subject: [PATCH] libnl: report an error if unexpected control data was received Message-ID: <1442246398-5303-1-git-send-email-avagin@openvz.org> Currently, we try to handle MSG_CTRUNC, but if msg_controllen is zero, we make double free for the same address. realloc(0, 0) returns non-zero address realloc(addr, 0) returns zero and free(addr) has already been called Then we call free(addr) again and get an error like this: *** Error in `./task_diag_all': double free or corruption (fasttop): 0x0000000000f9c160 *** ======= Backtrace: ========= /lib64/libc.so.6(+0x77e9d)[0x7f360ed96e9d] /lib64/libc.so.6(+0x7f53c)[0x7f360ed9e53c] /lib64/libc.so.6(cfree+0x4c)[0x7f360eda2e9c] /lib64/libnl-3.so.200(nl_recv+0x221)[0x7f360f2f6361] /lib64/libnl-3.so.200(nl_recvmsgs_report+0x555)[0x7f360f2f6a95] /lib64/libnl-3.so.200(nl_recvmsgs+0x9)[0x7f360f2f6d89] ./task_diag_all[0x400f8d] /lib64/libc.so.6(__libc_start_main+0xf0)[0x7f360ed3f790] ./task_diag_all[0x401169] Signed-off-by: Andrey Vagin --- lib/nl.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/lib/nl.c b/lib/nl.c index c93b6a5..cba4217 100644 --- a/lib/nl.c +++ b/lib/nl.c @@ -721,6 +721,13 @@ retry: if (msg.msg_flags & MSG_CTRUNC) { void *tmp; + + if (msg.msg_controllen == 0) { + retval = -NLE_MSG_TRUNC; + NL_DBG(4, "recvmsg(%p): Received unexpected control data", sk); + goto abort; + } + msg.msg_controllen *= 2; tmp = realloc(msg.msg_control, msg.msg_controllen); if (!tmp) { -- 2.4.3 From ranker72 at gmail.com Wed Sep 16 14:25:54 2015 From: ranker72 at gmail.com (ferran) Date: Wed, 16 Sep 2015 23:25:54 +0200 Subject: resource cleanup in cyclic calls to netlink In-Reply-To: <20150916080428.M82206@cdot.in> References: <20150916080428.M82206@cdot.in> Message-ID: <55F9DE62.7060602@gmail.com> Hi Surabhi, I finally solved that. My issue was totally particular to my environment. I already had an open socket and was confused about which I was connecting to. The solution was to open the netlink socket to a different port, because somehow, when trying to free a socket "sk" binded to the default port, the application crashed as if I didn't own that piece of memory. Be sure to free your socket like this: sk = nl_socket_alloc(); nl_socket_set_local_port(sk, YOUR_PORT); genl_connect(sk); /* use socket */ nl_socket_free(sk); Be sure also to free the socket even if you have some error and don't get to talk to the kernel. You can look at the source code of "iw" https://kernel.org/pub/software/network/iw/iw-4.1.tar.gz The netlink communication cycle kind of starts at line 340 of "iw.c". Be aware that iw performs just one command per execution, meaning that it doesn't reuse resources as our applications. Regarding the "36 bytes leftover" message, it looks like it's nla_parse who warns it http://www.spinics.net/lists/netdev/msg193475.html Maybe you have missed some parameters at "nla_policy" when doing nla_parse_nested? It's just an idea, I recommend you to browse libnl source code and go find the origin of that message. Feel free to post some code so that we can understand when you are allocating memory and when freeing it. Best regards, Ferran On 16/09/15 10:04, Surabhi Goswami wrote: > Hi, > > I just came across your question regarding resource cleanup : > > http://lists.infradead.org/pipermail/libnl/2015-June/001905.html > > I am also facing a similar kind of issue, I am trying to port meshd-nl80211 on my embedded > system ,although the connection gets established but there is a constant memory leak due > to the nlmsg_alloc. > > I tried to allocate a single msg globally and reuse it, but I encounter this print > "netlink: 36 bytes leftover after parsing attributes." continuously. > > I wished to know if you were able to solve the memory leak issue. > > Any help would be appreciated. > > Thanks in advance! From Andy.DeWolfe at exinda.com Thu Sep 17 08:05:51 2015 From: Andy.DeWolfe at exinda.com (Andy DeWolfe) Date: Thu, 17 Sep 2015 15:05:51 +0000 Subject: Question: No cache/hash support for qdisc and class Message-ID: <14FCE5D5D3B5FC40B5922C301A11C184200C26@mbx026-e1-nj-4.exch026.domain.local> Hi all, first time posting. Back in Nov 2012, Roopa Prabhu submitted patches to "Add hash support to libnl caches" and "adds keygen functions to link, neigh and route objects". Is there any reason why this was not ( or should not be ) extended to qdisc and class objects? I'm dealing with a tc model that has thousands of qdiscs and nl_cache_refill is taking 10+ seconds. I've implemented my own keygen rountine for qdisc that drops that down to under 1 second, but I'm just curious why this functionality does not already exist. Andy From roopa at cumulusnetworks.com Thu Sep 17 10:42:45 2015 From: roopa at cumulusnetworks.com (roopa) Date: Thu, 17 Sep 2015 10:42:45 -0700 Subject: Question: No cache/hash support for qdisc and class In-Reply-To: <14FCE5D5D3B5FC40B5922C301A11C184200C26@mbx026-e1-nj-4.exch026.domain.local> References: <14FCE5D5D3B5FC40B5922C301A11C184200C26@mbx026-e1-nj-4.exch026.domain.local> Message-ID: <55FAFB95.8080507@cumulusnetworks.com> On 9/17/15, 8:05 AM, Andy DeWolfe wrote: > Hi all, first time posting. > > Back in Nov 2012, Roopa Prabhu submitted patches to "Add hash support to libnl caches" and "adds keygen functions to link, neigh and route objects". > > Is there any reason why this was not ( or should not be ) extended to qdisc and class objects? > > I'm dealing with a tc model that has thousands of qdiscs and nl_cache_refill is taking 10+ seconds. I've implemented my own keygen rountine for qdisc that drops that down to under 1 second, but I'm just curious why this functionality does not already exist. I don't see any reason why it cannot be used. When I submitted these patches, we targeted only a few caches because those were the only ones we used heavily and were able to test it. Glad to know that it is works well for qdiscs as well. From mistry.p.bhavesh at gmail.com Wed Sep 16 20:26:15 2015 From: mistry.p.bhavesh at gmail.com (Bhavesh Mistry) Date: Wed, 16 Sep 2015 20:26:15 -0700 Subject: Fwd: Accessing Linux Namespace from Java In-Reply-To: References: Message-ID: Hi libnl Team, I was wondering if you know or is there any planing to expose this API as Java Lib to talk from different Linux namespace (via JNDI ). I have posted question on stack-flow to give ability to connect to IP address with name space. http://stackoverflow.com/questions/32531379/linux-network-namespaces-and-connecting-from-java-program-using-linux-network-na Any hint or pointer are greatly appreciated. Thanks, Bhavesh From thaller at redhat.com Sat Sep 19 07:28:02 2015 From: thaller at redhat.com (Thomas Haller) Date: Sat, 19 Sep 2015 16:28:02 +0200 Subject: Question: No cache/hash support for qdisc and class In-Reply-To: <14FCE5D5D3B5FC40B5922C301A11C184200C26@mbx026-e1-nj-4.exch026.domain.local> References: <14FCE5D5D3B5FC40B5922C301A11C184200C26@mbx026-e1-nj-4.exch026.domain.local> Message-ID: <1442672882.22351.6.camel@redhat.com> On Thu, 2015-09-17 at 15:05 +0000, Andy DeWolfe wrote: > Hi all, first time posting. > > Back in Nov 2012, Roopa Prabhu submitted patches to "Add hash support > to libnl caches" and "adds keygen functions to link, neigh and route > objects". > > Is there any reason why this was not ( or should not be ) extended to > qdisc and class objects? > > I'm dealing with a tc model that has thousands of qdiscs and > nl_cache_refill is taking 10+ seconds. I've implemented my own > keygen rountine for qdisc that drops that down to under 1 second, but > I'm just curious why this functionality does not already exist. > > Andy Hi Andy, The only reason it is not there, is because nobody implemented it yet. Patches welcome :) cheers, Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From thaller at redhat.com Sat Sep 19 07:50:16 2015 From: thaller at redhat.com (Thomas Haller) Date: Sat, 19 Sep 2015 16:50:16 +0200 Subject: Fwd: Accessing Linux Namespace from Java In-Reply-To: References: Message-ID: <1442674216.22351.18.camel@redhat.com> On Wed, 2015-09-16 at 20:26 -0700, Bhavesh Mistry wrote: > Hi libnl Team, > > I was wondering if you know or is there any planing to expose this > API > as Java Lib to talk from different Linux namespace (via JNDI ). > > I have posted question on stack-flow to give ability to connect to IP > address with name space. > http://stackoverflow.com/questions/32531379/linux-network-namespaces- > and-connecting-from-java-program-using-linux-network-na from your description and the link it is not exactly clear to me what you want to do. Do you want to connect to a service that runs inside that other netns? Can you not just setup the routes and addresses properly, and connect to that namespace from outside? I guess, you can also switch into that other netns, and connect from there. I don't know because I never tried that. How about you switch netns before creating/binding the socket (and thus having the socket connected inside the other netns). Then you then switch back to your original netns? You would switch namespace using the "setns" systemcall (see `man setns`). AFAIU, you wouldn't use netlink or libnl for that but a systemcall. Obviously, you might need proper permissions to do setns, and Java must give you a way to do that (possibly by calling into native code). Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From thaller at redhat.com Mon Sep 21 03:00:58 2015 From: thaller at redhat.com (Thomas Haller) Date: Mon, 21 Sep 2015 12:00:58 +0200 Subject: [PATCH] libnl: report an error if unexpected control data was received In-Reply-To: <1442246398-5303-1-git-send-email-avagin@openvz.org> References: <1442246398-5303-1-git-send-email-avagin@openvz.org> Message-ID: <1442829658.15319.16.camel@redhat.com> On Mon, 2015-09-14 at 18:59 +0300, Andrey Vagin wrote: > Currently, we try to handle MSG_CTRUNC, but if msg_controllen is > zero, we make > double free for the same address. > > realloc(0, 0) returns non-zero address > realloc(addr, 0) returns zero and free(addr) has already been called > > Then we call free(addr) again and get an error like this: Hi Andrey, could you elaborate a bit on the circumstances when you hit this error? Did the kernel set msg_controllen to zero? Do you know why? Anyway, thanks for the patch!! Applied as https://github.com/thom311/libnl/commit/fd9d1da28c9d989f88b6c5edaa352c01976f82ac Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From thaller at redhat.com Mon Sep 21 03:56:28 2015 From: thaller at redhat.com (Thomas Haller) Date: Mon, 21 Sep 2015 12:56:28 +0200 Subject: libnl 3.2.27-rc1 released Message-ID: <1442832988.15319.19.camel@redhat.com> Dear libnl community, We are happy to announce the availability of libnl 3.2.27-rc1. NOTE This is a release candidate. The final 3.2.27 release will occur later. We kindly request everybody to test the tarball and report bugs to the mailing list. Source: https://github.com/thom311/libnl/releases/tag/libnl3_2_27rc1 Thanks to everyone who contributed to the upcoming release: Andrey Vagin (1): libnl: report an error if unexpected control data was received Arend van Spriel (4): python: disable swig debug print messages python: capi: expose multicast membership functions python: capi: add nla_put() function to python capi python: genl: capi: add genlmsg_hdr() to capi Cong Wang (2): ipvlan: add ipvlan support ipvlan: add a testcase for ipvlan David Chappelle (1): route: remove unnecessary include of private linux/if.h Ji?? Klime? (2): vlan: add VLAN flags to trans_tbl to print them properly vlan: add MVRP VLAN flag Jonas Johansson (1): neigh: add support for NDA_VLAN nl attribute J?rg Krause (1): lib/nl: add missing header Kir Kolyshkin (4): m4/ax_python.m4: remove m4/ax*.m4: remove doc/configure.ac: simplify python check doc/Makefile.am: don't use asciidoc if disabled Steffen Vogel (4): route/qdisc: added more attributes to netem dump route/tc: improved statistics dump (just alignment) route/qdisc: fixe printing whitespace in qdisc_dump_details() doc: enable generation of Doxygen tagfile for libnl API reference Thomas Egerer (1): lib: return error if an incomplete message was read Thomas Haller (26): lib/socket: detect protocol in nl_socket_set_fd() build: revert moving unstable symbols from libnl_3 linker section build/trivial: sort PROGRAMS list in src/Makefile.am build: extend configure option --enable-cli and install all cli programs utils: add code comment about capability number assignment route/link: fix indention in inet6_dump_details() libnl-3.2.26 release xfrm: trival refactoring initialization of stack-allocated arguments to nl_send_simple() lib/doc: clearify return value of send_simple() functions route/link: fix memleaks in link_msg_parser() utils: add missing link layer protocol translations lib: fix spelling of NL_CAPABILITY_NL_RECV_FAIL_TRUNC_NO_PEEK neigh: accept "norarp" in rtnl_neigh_state2str() ipvlan: fix signature of rtnl_link_ipvlan_get_mode() to signal error ipvlan: don't check for valid @mode argument in rtnl_link_ipvlan_set_mode() ipvlan: fix return error code for rtnl_link_ipvlan_get_mode() route/tc: use plain format string in rtnl_tc_dump_stats() socket: clear port when unable to generate local port socket: add fallback for nl_connect() by trying to bind to unspecified local port lib/socket: in nl_socket_set_fd() always reset the local port include/linux: update copy of kernel header "if_link.h" route/link: add support for IFLA_LINK_NETNSID lib/attr: add nla utility functions for s32 route/link: make link_netnsid argument (signed) int32_t socket: fix assertion in nl_connect() when all ports are already in use libnl-3.2.27-rc1 release Tobias Jungel (1): neigh: fix type for NUD_NOARP flag in trans_tbl Tobias Klauser (6): utils: Add translations for NETLINK_RDMA and NETLINK_CRYPTO route/tc: remove unnecessary check for tc_kind member of struct rtnl_tc xfrm: fix potential NULL dereference utils: update link layer protocol translations route/link: Remove unnecessary NULL check before release_link_info() route/link: add missing link_attrs translations jfarrell (1): build: fix path to cli linker version script for out-of-tree build matben2 (1): link: set ifi_change in link message ????????? ???? (1): nf: fix potential bug in nfnl_queue_msg_set_payload() when malloc() failed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From avagin at openvz.org Mon Sep 21 04:59:50 2015 From: avagin at openvz.org (Andrey Vagin) Date: Mon, 21 Sep 2015 14:59:50 +0300 Subject: [PATCH] libnl: report an error if unexpected control data was received In-Reply-To: <1442829658.15319.16.camel@redhat.com> References: <1442246398-5303-1-git-send-email-avagin@openvz.org> <1442829658.15319.16.camel@redhat.com> Message-ID: 2015-09-21 13:00 GMT+03:00 Thomas Haller : > On Mon, 2015-09-14 at 18:59 +0300, Andrey Vagin wrote: >> Currently, we try to handle MSG_CTRUNC, but if msg_controllen is >> zero, we make >> double free for the same address. >> >> realloc(0, 0) returns non-zero address >> realloc(addr, 0) returns zero and free(addr) has already been called >> >> Then we call free(addr) again and get an error like this: > > Hi Andrey, > > > could you elaborate a bit on the circumstances when you hit this error? It was my fault. I used setsockopts to set SO_PASSCREDS instead of nl_socket_set_passcred, so NL_SOCK_PASSCRED was not set for the nl_sock object and libnl didn't expect to get control data. Thanks, Andrew. > Did the kernel set msg_controllen to zero? Do you know why? > > > Anyway, thanks for the patch!! > Applied as https://github.com/thom311/libnl/commit/fd9d1da28c9d989f88b6c5edaa352c01976f82ac > > > > Thomas From thaller at redhat.com Wed Sep 30 05:00:22 2015 From: thaller at redhat.com (Thomas Haller) Date: Wed, 30 Sep 2015 14:00:22 +0200 Subject: Issues with rtnl_neigh_get on RHEL 7.0 and RHEL 7.1 In-Reply-To: References: Message-ID: <1443614422.29224.6.camel@redhat.com> On Tue, 2015-08-18 at 14:32 +0000, Haggai Abramovsky wrote: > The following commit: > 64fcb47 Add AF_BRIDGE support to neigh cache > > Added the following check: > @@ -496,7 +515,8 @@ struct rtnl_neigh * rtnl_neigh_get(struct > nl_cache *cache, int ifindex, > struct rtnl_neigh *neigh; > > nl_list_for_each_entry(neigh, &cache->c_items, ce_list) { > - if (neigh->n_ifindex == ifindex && > + if (neigh->n_family == AF_UNSPEC && > + neigh->n_ifindex == ifindex && > !nl_addr_cmp(neigh->n_dst, dst)) { > nl_object_get((struct nl_object *) neigh); > return neigh; > > Which was later removed by the following commit: > 8571f58 neigh: Remove check for AF_UNSPEC in rtnl_neigh_get() > > Between these two commits, when the n_family doesn't equal to > AF_UNSPEC, the libnl won't search for neighbor in the cache, and will > return NULL. > > RHEL 7.0 and RHEL 7.1 has the previous check, which causes our > library, that uses the libnl, to fail although the neighbor is in > cache. as a follow-up for the libnl mailinglist: in RHEL-7.2 this will be fixed by version libnl3-3.2.21-10.el7 ( https://bugzilla.redhat.com/show_bug.cgi?id=1261028 ) Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: