Date: Tue, 24 Feb 2015 14:54:41 +0100 From: Simone Lombardo <evil.lombo@gmail.com> To: FreeBSD Questions <freebsd-questions@freebsd.org> Cc: Adrian Chadd <adrian@freebsd.org> Subject: Re: HTTPS/TLS issue on a NDIS wrapped NIC Message-ID: <CALnnSEhso69YTmvo_7KUgixzDAci2-whhm8K0cwJE%2Bu%2BEBxThg@mail.gmail.com> In-Reply-To: <CALnnSEhKJv67sYb%2B_VXV0COfLYhtAgNZsy_fGM6PJHsAhCeQ=g@mail.gmail.com> References: <CALnnSEivExhv=v5jJ3xxFmJANCQs9Y%2BB7LFyEPeA1wtjk1zJwA@mail.gmail.com> <CAJ-Vmo=ggjvGPYqN5QS-cYF5zdLHMZixp7xXunDCE3s8xp2fmQ@mail.gmail.com> <CAJ-Vmon=UzYCqrTAS0C_CSB4sBnsU13TTWae5Wkxvhm01Aoozw@mail.gmail.com> <CALnnSEhKJv67sYb%2B_VXV0COfLYhtAgNZsy_fGM6PJHsAhCeQ=g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, still regarding the issue, I have made some more tests on the weekend. A---------------->B browser webserver Monitoring the packets on the NIC endpoints via Wireshark and doing HTTP and HTTPS/TLS calls to a demo webserver, I have found the origin of both the problems is due to the A nic not trasmitting packets while not reporting them as dropped. The TCP rentrasmission is due to B not receiving the packet and triggering the A fast rexmit routine due to missing ACK of the lost packet. The packet rexmit always fail and so after the retry count limit is hit, the connection is reset. I have made some more tuning and the issue seems related to TCP send buffer. With the default FreeBSD 10.1 value for net.inet.tcp.sendspace (32768) e net.inet.tcp.sendbuf_max (2097152), I can't transmit more than 15Kb of a binary via POST without provoking the issue. Changing them both to a certain values makes the behaviour better. For example, I have tried to set both oid it to 512,1024 and 5000 and now I could upload up to 1.5 Mb data without issue. But changing it to other values, for example 513, 1025 and 5001 makes the behaviour triggering. Since lowering the buffer makes the perfomance worse, I have thought about upload rate being much faster than the NIC could currently support so I have set up a IPFW filter and pipeing the data to a really limited outgoing bandwitch (for example 6kb/s) but it made no effect. I have the sensation it is due some buffer alignment from the TCP buffer size and the internal NIC buffer, but I have not yet investigate so far (that it would probably requires if_ndis module tweaking). The receiving buffer settings have no problems and changing MTU/MSS makes no effect in the test case. If someone has a sudden inspiration and advices, in the meantime I am collecting some more evidences :) Thanks, Simone 2015-02-08 15:59 GMT+01:00 Simone Lombardo <evil.lombo@gmail.com>: > Hi Adrian, > > thanks for the reply. I have not seen other side effect other than cited > ones. it works fine also with various P2P and FTP protocols for instance. > > I have probed the interface with netstat -id but the dropped and error > packet counters sign 0, so it doesn't seem explicity droppped by the > if_ndis module. > I guess further investigations requires a demo web server to check if it > is the remote peer to discard packets or the nic is falsely reporting their > transmission. > > Is there any sysctl or debug feature you know to check if it discarded by > the local upper layers? > > Thanks, > Simone > > 2015-02-07 17:30 GMT+01:00 Adrian Chadd <adrian@freebsd.org>: > >> .. or if that isn't breaking things, maybe there's some packet >> corruption going on that triggers encryption failures? Normally a >> corrupted packet would just be dropped by some part of the stack. >> >> >> -adrian >> > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CALnnSEhso69YTmvo_7KUgixzDAci2-whhm8K0cwJE%2Bu%2BEBxThg>