* [dpdk-users] Sequence Number [not found] <259d01f7a94e1c4eadf9e57fe89be7cc@upnet.gr> @ 2018-08-15 9:22 ` Konstantinos Schoinas 2018-08-15 14:17 ` [dpdk-users] Sequence Number /More info on the Subject Konstantinos Schoinas 0 siblings, 1 reply; 4+ messages in thread From: Konstantinos Schoinas @ 2018-08-15 9:22 UTC (permalink / raw) To: users -------- Αρχικό μήνυμα -------- Θέμα: Sequence Number Ημερομηνία: 2018-08-15 12:21 Αποστολέας: Konstantinos Schoinas <ece8537@upnet.gr> Παραλήπτης: users <users-bounces@dpdk.org> Hello, I am building an application blocks TLS session if i find a sepcific forbidden Server Name Indication. According to RFC i must make a response with Fatal Error (2) unrecognized name(112). When i receive the Client Hello and after i Extract the SNI and check it against a black list i do process the client hello in order to response to client and terminate the session. Although i am getting a lot of retransmit packets on wireshark so i suppose i am doing something wrong. I think i mights have seq and ack number wrong or something.If anyone could help i would appreciate. Here is the process of the packet after i check for the forbidden SNI: uint32_t client_receive_ack = ntohl(th->recv_ack); uint32_t client_send_seq = ntohl(th->sent_seq); th->sent_seq = th->recv_ack; th->recv_ack = htonl(client_send_seq + ntohs(iphdr->total_length)); uint16_t l = ntohs(ssl->length)-0x02; uint16_t ip_l = ntohs(iphdr->total_length) - l; rte_pktmbuf_trim(m,l); iphdr->total_length = htons(ip_l); ssl->length = htons(2); alert = (struct Alert *)((uint8_t *)ssl + 5); iphdr->src_addr = dst_ip; iphdr->dst_addr = src_ip; th->src_port = dst_port; th->dst_port = src_port; ssl->type = 21; //alert message alert->type = 2; // fatal error alert->description = 112; // Unrecognized name iphdr->hdr_checksum = 0; th->cksum = 0; iphdr->hdr_checksum = rte_ipv4_cksum(iphdr); th->cksum = rte_ipv4_udptcp_cksum(iphdr,th); Thanks for your time From contact@filipjaniszewski.com Wed Aug 15 11:45:53 2018 Return-Path: <contact@filipjaniszewski.com> Received: from delivery.mailspamprotection.com (delivery.mailspamprotection.com [108.178.24.182]) by dpdk.org (Postfix) with ESMTP id 90BBC235 for <users@dpdk.org>; Wed, 15 Aug 2018 11:45:53 +0200 (CEST) Received: from ns1.es18.siteground.eu ([37.60.250.193] helo=es18.siteground.eu) by se1.mailspamprotection.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from <contact@filipjaniszewski.com>) id 1fpsNC-0004bo-R7 for users@dpdk.org; Wed, 15 Aug 2018 04:45:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=filipjaniszewski.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:Subject:From:To:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Cp0GoIczdB8ZEWylpqPg/VwEX3ci36RN5mG0rApcUXI=; b=I1j1oVCr6qsSqTtTJQMMla6keT v1twKMp15RyqL9fSd1dV2JZ9FEeXi5N3pKCDwtpaNAjEgWNGVJmzH9mhigxibTqedRdTrNdmI0KxS iWdsw3E3Q8E/uDo1LunOKUpcjQkG2u/3bW2SevM1K0mYj9sWYt4ckAsoVklHehzw5mavK73QfbHKQ 40TImQ2bFwB4C3CMDeqPl1FYTC+NjWZwRFURBwNFIYdwyPieHmccmD07OdWDmUC8JU+JEz2dGNLxg B7srjMpqPyGrp9IwDKw0zedkrVrnp8sB1tvfjDreAots90//WgAYXh6425iMyuq6q5QoouDmKdg6Y BcO5RGCA==; Received: from [89.71.152.167] (port=36590 helo=localhost.localdomain) by es18.siteground.eu with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_34-9f6032f-XX) (envelope-from <contact@filipjaniszewski.com>) id 1fpsNB-0004Dq-Mc for users@dpdk.org; Wed, 15 Aug 2018 11:45:49 +0200 To: users@dpdk.org From: Filip Janiszewski <contact@filipjaniszewski.com> Message-ID: <86f9aa76-a323-635b-9078-d72f5897dcb9@filipjaniszewski.com> Date: Wed, 15 Aug 2018 11:45:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: 37.60.250.193 X-SpamExperts-Domain: es18.siteground.eu X-SpamExperts-Username: 37.60.250.193 Authentication-Results: mailspamprotection.com; auth=pass smtp.auth=37.60.250.193@es18.siteground.eu X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.39) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5n6O8gb0Gw4mpF61Kl5R3UB602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO1v+PcEVtX7KZY7H5dkGCkxVjyn5UrUp4n4yKOOaq9AxacYWqRomERmCuAnXCOsRR1Dj fzzJ6O8jiVhZi+WiYeCsScX6I9Dl5i6VrUM1b/j5uHRrANYT6OrDos7COMFNFeM0SnoZX29Ppjgp pjrn+Yqxkzc3MaPwhyyXNpaCoQ64z42+kaWZdt6N+q59XgE2+hrDr0cJJpOv+LTkhDH6DXqBaQIi fdaGzMoXcgXnOXfsRAwX31WVY5lWjWxuGSRuxccmgJnHEtQEnziG4yi2Z3GT/DEhJxe5dhb1MqnM 8MUhfNIIfXXHaPnmTS9BbIiM1U5lBnskkphd4sLN8tb0FI4YH6QrpfZiTMRk4xXw0fBcwpHVKZ/A NojJCxy+4SkWr5x5dk0bQRRsQsDS6/1iF05SHDEoKrXCm1PS2vgB4ghQfb7mDHg6F7DCQw/QmRVt g675dwLB7orJf0UsoeQy3tTonV+E7OMXRvgtdyMlnmWiqRumzYQFJNbg1Tn7GZGrn5515veWtL0b Yx9/1MBTpa07fLoHCX8f02z/66evGb4dLfS4W81x+rrQxVFyQUfUK9DDPBJXyrK8fJRpzDaCQdQb W60W7CHlWN8jD9itEkyZGE+a8VSkIb8M3aQUOSMfSrVhViqXl5q3cLpTIW82JfIRQCv7wlr06thf b7te8KtvA7ejfqPQ5FkXTHpg66rl5VwctSD0PU7lfIL/DWvwyBcU1zqm/evfkH8cHl25+qKdeQRO hR5flqvPGkX4boOQxmR1ywEglXHVF1s0TPc0gKacDKRwgh+74UfyyAce3gu7ORCFMChhciUOzNI4 nVmmwPGWQ8OjBtxPVOtqpyPhhPpl8xI24c6mthnPj8ttmyNdw6nIoDr0sXUZ7YZoZ/GZ+nIjX+mp Xo6Bh5QJKUq2dlJq8+mYzIQJqGIhcxvbJwcyx6ccQuTLNJgYNqLIM+J3AgT9fL1uqHa3zvHAM0nV lCctTBGCi2Yb6RqdbFEKnfeUHB5fZKdmbRsmSphdLeEDf/UgLbqHmPDwiOKeFQfhxXYxL7hrJSk6 0SF3F6RYOYr2 X-Report-Abuse-To: spam@quarantine1.mailspamprotection.com Subject: [dpdk-users] mempool metadata stored in private data section X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK usage discussions <users.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/users>, <mailto:users-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/users/> List-Post: <mailto:users@dpdk.org> List-Help: <mailto:users-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/users>, <mailto:users-request@dpdk.org?subject=subscribe> X-List-Received-Date: Wed, 15 Aug 2018 09:45:53 -0000 Hi, I'm using rte_mempool_create_empty (followed by rte_mempool_populate_default) to create a pool of buffers that have to be used by the application, along with the buffers I need to have a small set of meta information, so that when the user request an objects (rte_mempool_get) it gets back the buffer + the meta data. >From the documentation it seems that I could use the "private_data_size" field while creating the pool, but the description is not very clear to me: "The size of the private data appended after the mempool structure. This is useful for storing some private data after the mempool structure, as is done for rte_mbuf_pool for example." Are those private data stored after each mempool object? It's legal then do something like this: ((char*)buf_ptr + elt_size) to access the private section of the buffer? (Assuming buf_ptr is the pointer returned by rte_mempool_get, void*.). >From the code in rte_mempool.c I see that: . /*< * reserve a memory zone for this mempool: private data is< * cache-aligned< */< data_size = (private_data_size +< MEMPOOL_ALIGN_MASK) & (~RTE_MEMPOOL_ALIGN_MASK); . so it looks like that chunk of private data is just a big common buffer allocated along with the whole mempool, the objects within the pool do not have any private data by themselves. How can I add some private data to each object of the mempool? (I know the simpler solution would be to increase elt_size to cover the requirement of the meta data I want to add, but what's the purpose of private_data then??) Thanks -- BR, Filip +48 666 369 823 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [dpdk-users] Sequence Number /More info on the Subject 2018-08-15 9:22 ` [dpdk-users] Sequence Number Konstantinos Schoinas @ 2018-08-15 14:17 ` Konstantinos Schoinas 2018-08-15 14:52 ` Stephen Hemminger 2018-08-15 15:02 ` Shyam Shrivastav 0 siblings, 2 replies; 4+ messages in thread From: Konstantinos Schoinas @ 2018-08-15 14:17 UTC (permalink / raw) To: users Στις 2018-08-15 12:22, Konstantinos Schoinas έγραψε: > -------- Αρχικό μήνυμα -------- > Θέμα: Sequence Number > Ημερομηνία: 2018-08-15 12:21 > Αποστολέας: Konstantinos Schoinas <ece8537@upnet.gr> > Παραλήπτης: users <users-bounces@dpdk.org> > > Hello, > > I am building an application blocks TLS session if i find a sepcific > forbidden Server Name Indication. > According to RFC i must make a response with Fatal Error (2) > unrecognized name(112). > > When i receive the Client Hello and after i Extract the SNI and check > it against a black list i do process the client hello in order to > response to client and terminate the session. > > Although i am getting a lot of retransmit packets on wireshark so i > suppose i am doing something wrong. > > I think i mights have seq and ack number wrong or something.If anyone > could help i would appreciate. > Here is the process of the packet after i check for the forbidden SNI: > > uint32_t client_receive_ack = ntohl(th->recv_ack); > uint32_t client_send_seq = ntohl(th->sent_seq); > > th->sent_seq = th->recv_ack; > th->recv_ack = htonl(client_send_seq + ntohs(iphdr->total_length)); > > > uint16_t l = ntohs(ssl->length)-0x02; > uint16_t ip_l = ntohs(iphdr->total_length) - l; > > rte_pktmbuf_trim(m,l); > iphdr->total_length = htons(ip_l); > ssl->length = htons(2); > > alert = (struct Alert *)((uint8_t *)ssl + 5); > > > iphdr->src_addr = dst_ip; > iphdr->dst_addr = src_ip; > th->src_port = dst_port; > th->dst_port = src_port; > ssl->type = 21; //alert message > alert->type = 2; // fatal error > alert->description = 112; // Unrecognized name > > iphdr->hdr_checksum = 0; > th->cksum = 0; > iphdr->hdr_checksum = rte_ipv4_cksum(iphdr); > > th->cksum = rte_ipv4_udptcp_cksum(iphdr,th); > > > > > Thanks for your time I wanted to give some more information on the subject.I am adding a picture of wireshark with the mail to give more info.The problem of the retransmitted packet is that it doesnt end the TLS session even though i am sending a fatal-error alert with dpdk. I believe that i do something wrong with the process of client hello so it doesnt have the right format in order to get recognized by the client and end the tls Session. If you see my code above i change the source ,dest ip and port the seq and ack value.In addition i am cutting from SSL Record the data that it had and i am adding the alert message according to RFC. Is there any field i must change according to dpdk? ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [dpdk-users] Sequence Number /More info on the Subject 2018-08-15 14:17 ` [dpdk-users] Sequence Number /More info on the Subject Konstantinos Schoinas @ 2018-08-15 14:52 ` Stephen Hemminger 2018-08-15 15:02 ` Shyam Shrivastav 1 sibling, 0 replies; 4+ messages in thread From: Stephen Hemminger @ 2018-08-15 14:52 UTC (permalink / raw) To: Konstantinos Schoinas; +Cc: users On Wed, 15 Aug 2018 17:17:48 +0300 Konstantinos Schoinas <ece8537@upnet.gr> wrote: > Στις 2018-08-15 12:22, Konstantinos Schoinas έγραψε: > > -------- Αρχικό μήνυμα -------- > > Θέμα: Sequence Number > > Ημερομηνία: 2018-08-15 12:21 > > Αποστολέας: Konstantinos Schoinas <ece8537@upnet.gr> > > Παραλήπτης: users <users-bounces@dpdk.org> > > > > Hello, > > > > I am building an application blocks TLS session if i find a sepcific > > forbidden Server Name Indication. > > According to RFC i must make a response with Fatal Error (2) > > unrecognized name(112). > > > > When i receive the Client Hello and after i Extract the SNI and check > > it against a black list i do process the client hello in order to > > response to client and terminate the session. > > > > Although i am getting a lot of retransmit packets on wireshark so i > > suppose i am doing something wrong. > > > > I think i mights have seq and ack number wrong or something.If anyone > > could help i would appreciate. > > Here is the process of the packet after i check for the forbidden SNI: > > > > uint32_t client_receive_ack = ntohl(th->recv_ack); > > uint32_t client_send_seq = ntohl(th->sent_seq); > > > > th->sent_seq = th->recv_ack; > > th->recv_ack = htonl(client_send_seq + ntohs(iphdr->total_length)); > > > > > > uint16_t l = ntohs(ssl->length)-0x02; > > uint16_t ip_l = ntohs(iphdr->total_length) - l; > > > > rte_pktmbuf_trim(m,l); > > iphdr->total_length = htons(ip_l); > > ssl->length = htons(2); > > > > alert = (struct Alert *)((uint8_t *)ssl + 5); > > > > > > iphdr->src_addr = dst_ip; > > iphdr->dst_addr = src_ip; > > th->src_port = dst_port; > > th->dst_port = src_port; > > ssl->type = 21; //alert message > > alert->type = 2; // fatal error > > alert->description = 112; // Unrecognized name > > > > iphdr->hdr_checksum = 0; > > th->cksum = 0; > > iphdr->hdr_checksum = rte_ipv4_cksum(iphdr); > > > > th->cksum = rte_ipv4_udptcp_cksum(iphdr,th); > > > > > > > > > > Thanks for your time > > > > > I wanted to give some more information on the subject.I am adding a > picture of wireshark with the mail to give more info.The problem of the > retransmitted packet is that it doesnt end the TLS session even though i > am sending a fatal-error alert with dpdk. > > I believe that i do something wrong with the process of client hello so > it doesnt have the right format in order to get recognized by the client > and end the tls Session. > > If you see my code above i change the source ,dest ip and port the seq > and ack value.In addition i am cutting from SSL Record the data that it > had and i am adding the alert message according to RFC. > > Is there any field i must change according to dpdk? > > > > With wireshark, the easiest thing to attach is a pcap file with the flow in question. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [dpdk-users] Sequence Number /More info on the Subject 2018-08-15 14:17 ` [dpdk-users] Sequence Number /More info on the Subject Konstantinos Schoinas 2018-08-15 14:52 ` Stephen Hemminger @ 2018-08-15 15:02 ` Shyam Shrivastav 1 sibling, 0 replies; 4+ messages in thread From: Shyam Shrivastav @ 2018-08-15 15:02 UTC (permalink / raw) To: Konstantinos Schoinas; +Cc: users One obvious error that I can see in reply tcp segment is th->recv_ack = htonl(client_send_seq + ntohs(iphdr->total_length)); You need to acknowledge just the tcp payload which is { send seq + iphdr->total_length - (IP header len) - (TCP header len) } On Wed, Aug 15, 2018 at 7:47 PM, Konstantinos Schoinas <ece8537@upnet.gr> wrote: > Στις 2018-08-15 12:22, Konstantinos Schoinas έγραψε: > >> -------- Αρχικό μήνυμα -------- >> Θέμα: Sequence Number >> Ημερομηνία: 2018-08-15 12:21 >> Αποστολέας: Konstantinos Schoinas <ece8537@upnet.gr> >> Παραλήπτης: users <users-bounces@dpdk.org> >> >> Hello, >> >> I am building an application blocks TLS session if i find a sepcific >> forbidden Server Name Indication. >> According to RFC i must make a response with Fatal Error (2) >> unrecognized name(112). >> >> When i receive the Client Hello and after i Extract the SNI and check >> it against a black list i do process the client hello in order to >> response to client and terminate the session. >> >> Although i am getting a lot of retransmit packets on wireshark so i >> suppose i am doing something wrong. >> >> I think i mights have seq and ack number wrong or something.If anyone >> could help i would appreciate. >> Here is the process of the packet after i check for the forbidden SNI: >> >> uint32_t client_receive_ack = ntohl(th->recv_ack); >> uint32_t client_send_seq = ntohl(th->sent_seq); >> >> th->sent_seq = th->recv_ack; >> th->recv_ack = htonl(client_send_seq + ntohs(iphdr->total_length)); >> >> >> uint16_t l = ntohs(ssl->length)-0x02; >> uint16_t ip_l = ntohs(iphdr->total_length) - l; >> >> rte_pktmbuf_trim(m,l); >> iphdr->total_length = htons(ip_l); >> ssl->length = htons(2); >> >> alert = (struct Alert *)((uint8_t *)ssl + 5); >> >> >> iphdr->src_addr = dst_ip; >> iphdr->dst_addr = src_ip; >> th->src_port = dst_port; >> th->dst_port = src_port; >> ssl->type = 21; //alert message >> alert->type = 2; // fatal error >> alert->description = 112; // Unrecognized name >> >> iphdr->hdr_checksum = 0; >> th->cksum = 0; >> iphdr->hdr_checksum = rte_ipv4_cksum(iphdr); >> >> th->cksum = rte_ipv4_udptcp_cksum(iphdr,th); >> >> >> >> >> Thanks for your time >> > > > > > I wanted to give some more information on the subject.I am adding a > picture of wireshark with the mail to give more info.The problem of the > retransmitted packet is that it doesnt end the TLS session even though i am > sending a fatal-error alert with dpdk. > > I believe that i do something wrong with the process of client hello so it > doesnt have the right format in order to get recognized by the client and > end the tls Session. > > If you see my code above i change the source ,dest ip and port the seq and > ack value.In addition i am cutting from SSL Record the data that it had and > i am adding the alert message according to RFC. > > Is there any field i must change according to dpdk? > > > > > ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2018-08-15 15:02 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <259d01f7a94e1c4eadf9e57fe89be7cc@upnet.gr> 2018-08-15 9:22 ` [dpdk-users] Sequence Number Konstantinos Schoinas 2018-08-15 14:17 ` [dpdk-users] Sequence Number /More info on the Subject Konstantinos Schoinas 2018-08-15 14:52 ` Stephen Hemminger 2018-08-15 15:02 ` Shyam Shrivastav
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).