Marc.info
On Wed, Dec 12, 2018, at 5:56 PM, Paul Swanson wrote:
> Hi,
>
> Is there a facility for searching the mailing list archives?
>
> I can't seem to find one.
>
> Cheers,
>
> Paul Swanson
Hi,
Is there a facility for searching the mailing list archives?
I can't seem to find one.
Cheers,
Paul Swanson
On Thu, Dec 13, 2018 at 12:41:10AM +, Adam Steen wrote:
> Hi All
>
> The Solo5/Mirage tender is in the process of enforcing that guest executable
> code is not also writable (W^X), but it looks like vmm is not updating EPT
> to match the prot from mprotect().
>
> further information
>
Hi All
The Solo5/Mirage tender is in the process of enforcing that guest executable
code is not also writable (W^X), but it looks like vmm is not updating EPT
to match the prot from mprotect().
further information
https://github.com/Solo5/solo5/issues/303#issuecomment-446503933
copied here for
Hello again,
I am using PPTP VPN (npppd) and it works as expected on windows clients -
traffic to the "LAN behind that VPNgateway" is going through VPNgateway. The
"rest" is going through clients' gateway - DO NOT "use default gateway on
remote network".
I have been playing around with
Still having this issue on -current as of Dec10. machdep.allowaperture=2
does get me past this, but am seeing weird behavior, some regions of
screens/terminals not painting or refreshing.
So, as this is a major inconvenience I am looking to update the video
card.
Any recommendations for a
* Stuart Henderson le [10-12-2018 18:19:41 +]:
> On 2018-12-07, Thuban wrote:
> > * Stuart Henderson le [06-12-2018 13:44:50 +]:
> >> On 2018-12-06, Thuban wrote:
> >> > * Thuban le [02-12-2018 19:16:09 +0100]:
> >> >> Hi,
> >> >> I need help to write a correct rule in pf.conf.
> >>
Eric Furman wrote:
> On Tue, Dec 11, 2018, at 8:56 PM, Stanislav wrote:
> > OK. What can I do?
> > Could you recommend an action I can make?
> > Is it normal if I just wait for new version of rtwn?
> > Or does this situation mean that mentioned card probably never will be
> > supported?
> >
>
On Tue, Dec 11, 2018, at 8:56 PM, Stanislav wrote:
> OK. What can I do?
> Could you recommend an action I can make?
> Is it normal if I just wait for new version of rtwn?
> Or does this situation mean that mentioned card probably never will be
> supported?
>
> I have searched similar cases.
>
On Tue, Dec 11, 2018 at 06:56:22PM -0700, Stanislav wrote:
> OK. What can I do?
> Could you recommend an action I can make?
> Is it normal if I just wait for new version of rtwn?
> Or does this situation mean that mentioned card probably never will be
> supported?
>
> I have searched similar
OK. What can I do?
Could you recommend an action I can make?
Is it normal if I just wait for new version of rtwn?
Or does this situation mean that mentioned card probably never will be
supported?
I have searched similar cases.
Stefan Sperling's report at EuroBSDcon2017: "Sometimes just adding
Hi Aaron,
Thanks! I also tried gif. But the behavior is quite weird. Through the gif
devices, the gateway and VPN server can ping each other, while the packets on
gateway enc0 from the client routing to the gif device always got bad
checksums. I think it is related to the bugs on gif(4) man
Hi Siegfried
(Maintainers of the IPSec stack and ISAKMPD are welcome to tear my answer apart)
IPSec tunnels are, for want of a better term, entirely transparent -
the underlying OS and its clients have no idea that it exists. In
order to route across an IPSec tunnel, use gif(4) to create an
Dear list,
i want to block udp fragments to a specific host while the reassembling is
turned on for all other traffic:
In pf I would write something like this:
# reassemble fragmented packets (default yes)
set reassemble yes
# scrub all traffic
match all scrub (random-id no-df)
# block
Hello Stuart
thanks for the reply, already suspected something along those lines.
On 12/10/18 7:14 PM, Stuart Henderson wrote:
It's a bit awkward but can be done, you'll find some information at
15 matches
Mail list logo
