Hello,
during building l2tp tunnel with xl2tpd-1.3.1 I was faced with its too
low upload performance. When download, the speed is 20 mbit/s at
nearly 100% CPU utilization. CPU is Pentium D 930 3 GHz. When upload,
the speed is below 2 mbit/s at nearly zero CPU utilization.
First, I
pppd(8) creates Reject message by moving with memcpy(3) rejected
option to left in buffer. If moving distance is less then option
length than it falls in coping between overlapping regions case. What
leads to crash.
The following patch fixes this issue by replacing memcpy(3)
Friday, June 12, 2015, 4:09:09 PM, you wrote:
pppd(8) creates Reject message by moving with memcpy(3) rejected
option to left in buffer. If moving distance is less then option
length than it falls in coping between overlapping regions case. What
leads to crash.
The following
2015-06-26 9:20 GMT+03:00 Claudio Jeker cje...@diehard.n-r-g.com:
On Fri, Jun 26, 2015 at 04:59:32AM +0300, Sergey Ryazanov wrote:
Hello,
during building l2tp tunnel with xl2tpd-1.3.1 I was faced with its too
low upload performance. When download, the speed is 20 mbit/s at
nearly 100
2015-06-26 9:20 GMT+03:00 Claudio Jeker cje...@diehard.n-r-g.com:
On Fri, Jun 26, 2015 at 04:59:32AM +0300, Sergey Ryazanov wrote:
Hello,
during building l2tp tunnel with xl2tpd-1.3.1 I was faced with its too
low upload performance. When download, the speed is 20 mbit/s at
nearly 100
2015-06-26 9:20 GMT+03:00 Claudio Jeker cje...@diehard.n-r-g.com:
On Fri, Jun 26, 2015 at 04:59:32AM +0300, Sergey Ryazanov wrote:
Hello,
during building l2tp tunnel with xl2tpd-1.3.1 I was faced with its too
low upload performance. When download, the speed is 20 mbit/s at
nearly 100
Hello,
I would like to announce that I finally reached 80 mbps of download
via pure L2TP tunnel (without IPsec).
I digged through ppp(4) and pppd(8) code several times and I could not
find any bottlenecks. Looks like we need to change whole design of
ppp(4) to reach any usable download speed.
Use bpf filter hook from the common interface structure. This simplifies
the code by unifying it and prepare ppp(4) for pipex(4) support.
Ok?
---
sys/net/if_ppp.c| 16
sys/net/if_pppvar.h | 1 -
2 files changed, 8 insertions(+), 9 deletions(-)
diff --git sys/net/if_ppp.c
Split checks from frame accepting with header removing in the common
PPP input function. This should fix packet capture on a PPP interfaces.
Also forbid IP/IPv6 frames (without PPP header) passing to BPF on
PPP interfaces to avoid mess.
Initialy this change was made as a part of pipex(4) and
Add support for parsing ppp frames with compressed address and(or)
protocol fields. Since we have no apriory information than try to
guess such frames by inability to parse a frame in a regular way.
ok?
---
usr.sbin/tcpdump/print-ppp.c | 29 +
1 file changed, 17
2 Hi Vitaliy,
On Tue, May 19, 2020 at 12:11 PM Vitaliy Makkoveev
wrote:
> On Mon, May 04, 2020 at 10:03:40PM +0300, Sergey Ryazanov wrote:
> > Split checks from frame accepting with header removing in the common
> > PPP input function. This should fix packet capture on a PPP inte
Hello,
On Wed, May 20, 2020 at 10:13 PM Vitaliy Makkoveev
wrote:
> On Wed, May 20, 2020 at 04:08:01AM +0300, Sergey Ryazanov wrote:
> > On Tue, May 19, 2020 at 12:11 PM Vitaliy Makkoveev
> > wrote:
> > > On Mon, May 04, 2020 at 10:03:40PM +0300, Sergey Ryazanov wrote:
&
Add minimal support for integration with pipex(4). Initialize interface
structure, pass IOCTLs to pipex(4) specific handler, etc.
Acceleration is working only in the DL path only at the moment.
Modification is not ready for applying. Work still in process.
---
sys/net/if_ppp.c| 16
Add dedicated option to activate kernel L2TP acceleration via
the pipex(4). The options should be passed by a L2TP tunnel
management daemon (e.g. xl2tpd).
This diff is complete, but kernel support in ppp(4) is not ready.
---
usr.sbin/pppd/ipcp.c| 5 +++
usr.sbin/pppd/options.c | 82
Hello Vitaliy,
On Sat, May 23, 2020 at 3:07 PM Vitaliy Makkoveev
wrote:
> > On 23 May 2020, at 13:11, Sergey Ryazanov wrote:
> > On Wed, May 20, 2020 at 10:13 PM Vitaliy Makkoveev
> > wrote:
> >> On Wed, May 20, 2020 at 04:08:01AM +0300, Sergey Ryazanov wrote:
>
On Tue, May 26, 2020 at 12:07 PM Vitaliy Makkoveev
wrote:
>> On 25 May 2020, at 22:04, Sergey Ryazanov wrote:
>> On Sat, May 23, 2020 at 3:07 PM Vitaliy Makkoveev
>> wrote:
>>> For example, each pipex session should have unique pair of `protocol’ and
>>> `
Hello!
On Mon, May 4, 2020 at 9:37 PM Sergey Ryazanov wrote:
> Add support for parsing ppp frames with compressed address and(or)
> protocol fields. Since we have no apriory information than try to
> guess such frames by inability to parse a frame in a regular way.
>
> ok?
Does s
On Wed, May 27, 2020 at 2:12 AM Vitaliy Makkoveev
wrote:
> > On 27 May 2020, at 01:29, Sergey Ryazanov wrote:
> > On Tue, May 26, 2020 at 12:07 PM Vitaliy Makkoveev
> > wrote:
> >>> On 25 May 2020, at 22:04, Sergey Ryazanov wrote:
> >>> On Sat,
On Tue, May 26, 2020 at 11:31 AM Claudio Jeker wrote:
> On Tue, May 26, 2020 at 09:22:28AM +0200, Martin Pieuchot wrote:
> > On 25/05/20(Mon) 21:42, Sergey Ryazanov wrote:
> > > Add dedicated option to activate kernel L2TP acceleration via
> > > the pipex(4). T
Hello Stefan,
sorry for the late reply, find my comments below.
On Wed, Nov 3, 2021 at 4:47 PM Stefan Sperling wrote:
> On Wed, Nov 03, 2021 at 04:03:08PM +0300, Sergey Ryazanov wrote:
>> This topic was discussed a couple of weeks ago on the hostapd mailing
>> list (http://list
Hello Stefan,
On Sun, Oct 31, 2021 at 9:25 PM Stefan Sperling wrote:
> Some access points advertise BSS load information in beacons in
> order to help clients make informed roaming decisions.
>
> BSS load information includes the number of associated stations,
> the channel utilization (this
21 matches
Mail list logo
