* [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).