The decision to allocate more storage is decided by an unexpected
usage pattern we encountered after the API was designed, which isn't
immediately obvious from the device name...
Some of these devices are designed for high-speed PPP. Some of them (in
particular on USB) actually move bytes faster
I just committed this, thank you :)
dlg
> On 16 May 2020, at 05:14, Caspar Schutijser wrote:
>
> Hi,
>
> Below is a patch that makes breaking out of the loop work when using
> a savefile.
>
> The pcap_breakloop() function was backported from tcpdump.org libpcap
> to OpenBSD libpcap by djm@
> 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, May 23, 2020 at 3:07 PM Vitaliy Makkoveev
>>> wrote:
For example, each pipex session should have unique
On Tue, May 26, 2020 at 4:52 PM Jason A. Donenfeld wrote:
> With regards to your crash, though, that's a bit more puzzling, and
> I'd be interested to learn more details. Because these structs are
> already naturally aligned, the __packed attribute, even with the odd
> nesting Matt had prior,
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, May 23, 2020 at 3:07 PM Vitaliy Makkoveev
> >>>
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 someone have any
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). The options should be passed by a
Hey Klemens, Theo,
On Tue, May 26, 2020 at 2:38 PM Klemens Nanni wrote:
>
> On Tue, May 26, 2020 at 02:23:06PM -0600, Jason A. Donenfeld wrote:
> > That's good news that it's working for you now, but I didn't change
> > anything within the last 24 hours (you mentioned "yesterday") that
> > would
On Tue, May 26, 2020 at 09:26:07PM +0200, Sven M. Hallberg wrote:
> hi all,
>
> i sent the following question to misc@ on march 29th but received no
> response. i hope you don't mind me retrying on tech@.
>
> while playing around with pf, i noticed that some connections that i
> thought should
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
>>> `session_id’. These values are passed
Please see attached diff.
Index: pcap_open_live.3
===
RCS file: /cvs/src/lib/libpcap/pcap_open_live.3,v
retrieving revision 1.3
diff -u -p -u -r1.3 pcap_open_live.3
--- pcap_open_live.325 Sep 2019 17:02:00 - 1.3
+++
Another trivial code readability comment:
I see 24 references to this in the code, 20 of which pass 0, and 4 of
which pass 1,000,000 as the parameter.
Passing 0 defaults to a baud of 115200. The baud determines the qlen,
which is 4096 for 115200 and 8192 for anything larger, so all it is
doing
On Tue, May 26, 2020 at 2:33 PM Theo de Raadt wrote:
>
> Jason A. Donenfeld wrote:
>
> > Hey Klemens,
> >
> > On Tue, May 26, 2020 at 9:13 AM Klemens Nanni wrote:
> > > I worked with the patches from the wireguard-openbsd repository after
> > > version one of this diff on tech@ became a bit
Jason A. Donenfeld wrote:
> Hey Klemens,
>
> On Tue, May 26, 2020 at 9:13 AM Klemens Nanni wrote:
> > I worked with the patches from the wireguard-openbsd repository after
> > version one of this diff on tech@ became a bit old.
> >
> > That was until yesterday; the kernel would panic due to
hi all,
i sent the following question to misc@ on march 29th but received no
response. i hope you don't mind me retrying on tech@.
while playing around with pf, i noticed that some connections that i
thought should be blocked, were in fact not. here is my fairly standard
bridge setup between a
Hey Klemens,
On Tue, May 26, 2020 at 9:13 AM Klemens Nanni wrote:
> I worked with the patches from the wireguard-openbsd repository after
> version one of this diff on tech@ became a bit old.
>
> That was until yesterday; the kernel would panic due to memory
> alignment issues in various spots,
Hey Tobias,
On Tue, May 26, 2020 at 5:28 AM Tobias Heider wrote:
> > + if (((SIZE_MAX - size) / sizeof(struct wg_aip_io)) < sc->sc_aip_num)
> > + goto error;
>
> I still think those two should return an error. 'goto error' is misleading as
> it doesn't actually set ret != 0.
`pppx_if' has `pxi_ready' field used to prevent access to incomplete
`pxi'. But we don't prevent access to `pxi' which we destroy.
pppx_if_destroy() can sleep so we can grab `pxi' which we already
destroying by concurrent thread and cause use-after-free issue. I guess
to use `pxi_ready' to prevent
During childsa last use checks, iked debug logs results, per SA, after a
successful pfkey_sa_last_used call.
This patch makes logging behavior more closely match that, on error.
I chose log_warn instead of log_debug since iked will complain about the
nonzero errno after pfkey_reply:
On Tue, May 26, 2020 at 08:09:48AM -0600, Theo de Raadt wrote:
> I'll let you know who has sparc64 machines to help out:
>
> kn was the developer who saw the problem. jca is also adept
> enough to look at this with you.
I worked with the patches from the wireguard-openbsd repository after
On Tue, May 26, 2020 at 03:54:15PM +0200, Otto Moerbeek wrote:
> On Tue, May 26, 2020 at 07:51:28AM -0600, Todd C. Miller wrote:
>
> > On Tue, 26 May 2020 12:07:21 +0200, Otto Moerbeek wrote:
> >
> > > Apart from the noting the strange Subject: I also like to mention one
> > > change in the way
I'll let you know who has sparc64 machines to help out:
kn was the developer who saw the problem. jca is also adept
enough to look at this with you.
On Tue, May 26, 2020 at 07:51:28AM -0600, Todd C. Miller wrote:
> On Tue, 26 May 2020 12:07:21 +0200, Otto Moerbeek wrote:
>
> > Apart from the noting the strange Subject: I also like to mention one
> > change in the way cylinder groups are scanned. The current code scans
> > forward and
On Tue, 26 May 2020 12:07:21 +0200, Otto Moerbeek wrote:
> Apart from the noting the strange Subject: I also like to mention one
> change in the way cylinder groups are scanned. The current code scans
> forward and backward, which causes an uneven distribution of full cgs
> (the upper end of the
> On 25 May 2020, at 22:04, Sergey Ryazanov wrote:
>
> 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
On Thu, May 14, 2020 at 10:07:30PM +0200, Tobias Heider wrote:
> Hi,
>
> currently iked(8) supports AES-GCM only for ESP.
> The diff below adds the ENCR_AES_GCM_16 and ENCR_AES_GCM_12 variants for IKE.
> (for more information see [1] and [2]).
> Both variants support the 128, 196, and 256 bit key
> On 26 May 2020, at 11:31, Claudio Jeker wrote:
>
> [skip]
>
> Is pppd(8) still using K function declarations? Can we please add new
> functions with ANSI declarations instead and convert the rest as well.
> Also it looks like something strange is going on with indentation (just
> look at
When enabling Tx queues in iwx_enable_data_tx_queues() the driver computes
the Tx queue index as:
int qid = ac + IWX_DQA_AUX_QUEUE + 1;
with:
#define IWX_DQA_AUX_QUEUE 1
In iwx_tx(), we use a different way of computing the Tx queue index,
which is a leftover from
On Tue, May 26, 2020 at 07:39:01PM +1000, Matt Dunwoodie wrote:
> Hi tech,
>
> After some feedback and comments, we've addressed the concerns, and
> fixed a few things from our side too. Overall the structure is familiar
> with no major changes, so any prior readings mostly carry over.
>
> This
On Tue, May 26, 2020 at 11:58:39AM +0200, Otto Moerbeek wrote:
> Hi,
>
> In theory ffs code support a maximum of UINT_MAX inodes, but in
> practice, due to integer overflows in the current code, the limit is
> INT_MAX inodes.
>
> This fixes that, and allows me to create and use filesystems with
Hi,
In theory ffs code support a maximum of UINT_MAX inodes, but in
practice, due to integer overflows in the current code, the limit is
INT_MAX inodes.
This fixes that, and allows me to create and use filesystems with more
than INT_MAX inodes. This is partly from FreeBSD code.
Main change is
Hey tech@,
A few things I thought I should add to our v2 revision:
First, the improvements we've made in the last few weeks have been
pretty substantial, and we've now got a much more faithful protocol
implementation. I've been running this on a few high traffic servers,
and I'll probably move
video(1) supports reading frames from a webcam via mmap(). To inform the
V4L2 device about the number of desired buffers containing the frames to
be memory-mapped, a VIDIOC_REQBUFS ioctl call is used.
At the moment the v4l2_requestbuffers struct used for the VIDIOC_REQBUFS ioctl
is only partially
On Tue, May 26, 2020 at 12:03:50AM +0200, Sebastian Benoit wrote:
> Solene Rapenne(sol...@perso.pw) on 2020.05.25 15:25:40 +0200:
> > Hi,
> >
> > I don't know if this will be accepted but I propose to add a -u [url]
> > parameter to use older snapshots from an archive server for example.
> >
> >
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). The options should be passed by a L2TP tunnel
> > management daemon (e.g. xl2tpd).
>
> What is the
On 25/05/20(Mon) 21:42, Sergey Ryazanov wrote:
> 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).
What is the difference between npppd(8) and pppd(8)? Aren't those two
redundant? Why
On Mon, May 25, 2020 at 11:27:27PM +0300, Tero Koskinen wrote:
> Hi,
>
> I have TP-Link TL-WN822N-EU v5 USB adapter[1] with
> USB VID/PID 2357:0108:
>
> $ usbdevs
> Controller /dev/usb0:
> addr 01: 1022: AMD, xHCI root hub
> addr 02: 2357:0108 Realtek, 802.11n NIC
> Controller /dev/usb1:
>
37 matches
Mail list logo
