Den mån 10 feb. 2020 kl 20:53 skrev Simen Stavdal :
> I think the more complete solution is to run some gif/gre inside ipsec and
>> set low-enough MTU on that one, so it can correctly fragment incoming
>> packets, and optionally rebuild the packets at the remote end, while also
>> giving you an
Den mån 10 feb. 2020 kl 18:18 skrev Peter Müller :
> Hello Lucas,
> as far as I understood, setting MTU on encN interfaces is not supported
> since it is not mentioned by enc(4) and setting it manually fails:
>
> > machine# ifconfig enc0 mtu 1500
> > ifconfig: SIOCSIFMTU: Inappropriate ioctl for
On Feb 10 23:29:18, a...@caoua.org wrote:
> On Mon, Feb 10, 2020 at 10:45:02PM +0100, Jan Stary wrote:
> > I must be missing something obvious.
> > How does aucat mix two mono files into one stereo file
> > as the left and right channel, respectively?
> >
>
> You have to specify which file goes
On Feb 10 20:31:35, dp925...@gmail.com wrote:
> On 2/10/20 18:07, Jan Stary wrote:
> > +Create a stereo file having two given mono channels:
>
> Might be better to say:
>
> Combine two mono files into a single stereo file, one mono file per channel:
>
> "Create a stereo file" makes it sound
You rock! I’ll let you know it works for me when I get a chance.
EZ
Sent from my iPhone
> On Feb 10, 2020, at 11:19 PM, Aaron Bieber wrote:
>
> On Thu, 06 Feb 2020 at 23:31:01 -0600, Eric Zylstra wrote:
>> I’ve installed the ELK packages (Elasticsearch, Logstash, Kibana) using
>> pkg_add.
On Thu, 06 Feb 2020 at 23:31:01 -0600, Eric Zylstra wrote:
> I’ve installed the ELK packages (Elasticsearch, Logstash, Kibana) using
> pkg_add. Installs went fine. I checked out the pkg documentation
> (pkg_reames) and followed the steps for those that had documentation to
> follow.
>
> When
On Mon, Feb 10, 2020 at 12:12:12PM -0500, Allan Streib wrote:
> Antoine Jacoutot writes:
>
> > "patches waiting, but didn't do anything" might be interesting (i.e
> > patches are available); dunno...
>
> syspatch -c
?
--
Antoine
perfect!
I did a reboot, and gave it at the kernel prompt a "boot -c",
to enterinto UKC. It would allow to "find acpivideo", which
I disabled. Booting OpenBSD66 into xenodem will go with
full brightness, but once in a terminal window I can do:
$ doas wsconsctl display.brightness=6
On Feb 10 23:29:18, a...@caoua.org wrote:
> On Mon, Feb 10, 2020 at 10:45:02PM +0100, Jan Stary wrote:
> > I must be missing something obvious.
> > How does aucat mix two mono files into one stereo file
> > as the left and right channel, respectively?
> >
>
> You have to specify which file goes
On Tue, Feb 11, 2020 at 3:04 AM Adam Thompson wrote:
>
> [SNIP]
>
> The older the Latitude, the harder it is to open, but even an E6400 is
> pretty easy, even if you've never opened up a laptop before.
Yes. The E6400 and E6410 were favourites of mine, with a single
spring-mounted screw and a
On Mon, Feb 10, 2020 at 10:45:02PM +0100, Jan Stary wrote:
> I must be missing something obvious.
> How does aucat mix two mono files into one stereo file
> as the left and right channel, respectively?
>
You have to specify which file goes to which channel,
for instance:
aucat -n -c 0:0
I must be missing something obvious.
How does aucat mix two mono files into one stereo file
as the left and right channel, respectively?
This mixes the two mono files into the left channel,
leaving the right channel empty:
$ aucat -n -i 1.wav -i 2.wav -o mix.wav
That surprises me; the -j
On Mon, 10 Feb 2020 at 17:00, Janne Johansson wrote:
> Den mån 10 feb. 2020 kl 16:27 skrev Simen Stavdal :
>
>> This is more a discussion about scalability and practical implementation.
>> We both know that PMTU will work partly at best, your entire path back
>> must support this, and also, the
On 2020-02-08 06:03, Antoine Jacoutot wrote:
On Fri, Jan 31, 2020 at 09:03:59AM -0600, Adam Thompson wrote:
There's no mention of what syspatch(8) returns, in the manpage.
I can prove quickly enough that it exits(0) when there's nothing to
do, but
I'm more interested in knowing (for
Hello Lucas,
as far as I understood, setting MTU on encN interfaces is not supported
since it is not mentioned by enc(4) and setting it manually fails:
> machine# ifconfig enc0 mtu 1500
> ifconfig: SIOCSIFMTU: Inappropriate ioctl for device
If you do not want to use GRE tunnels or gif
Antoine Jacoutot writes:
> "patches waiting, but didn't do anything" might be interesting (i.e
> patches are available); dunno...
syspatch -c
Allan
I can even ping any internet host from road warrior's LAN interface when iked
is connected:
$ ping -I 192.168.0.1 remote_host.com -> works as should be
But no any traffic from 192.168.0.10 host except successful DNS
queries/responses from/to Road Warrior's local DNS resolver.
$ telnet
On 2020-02-10 09:36, Michael G Workman wrote:
Ok, thanks for the info.
For your E6400, see this guide:
https://www.parts-people.com/blog/2012/10/16/dell-latitude-e6420-cmos-battery-removal-and-installation/
I found E6400 CMOS batteries from multiple vendors on the first page of
Google
Den mån 10 feb. 2020 kl 16:27 skrev Simen Stavdal :
> This is more a discussion about scalability and practical implementation.
> We both know that PMTU will work partly at best, your entire path back
> must support this, and also, the "offending" client must allow inbound
> control messages on
Ok, thanks for the info.
*Michael G. Workman*
(321) 432-9295
michael.g.work...@gmail.com
On Sun, Feb 9, 2020 at 4:47 PM Adam Thompson wrote:
> On 2020-02-09 06:58, Michael G Workman wrote:
> > Hello,
> >
> > Shout out to the OpenBSD developers for making a great OS!
> >
> > I was able to
This is more a discussion about scalability and practical implementation.
We both know that PMTU will work partly at best, your entire path back must
support this, and also, the "offending" client must allow inbound control
messages on their host firewall for this to work.
And even if the packets
SIGKILL seems pretty harsh, have you tried SIGTERM instead?
On Sun, Feb 9, 2020 at 12:48 PM aisha wrote:
>
> You need to use pkill -9 to kill rspamd, which i think should be added
> to the stop part of the rspamd daemon.
>
> At least this is what I have been using, any other methods would be
Hello @misc,
I'm still can't resolve the issue with outgoing connections from OpenBSD
RoadWarrior's LAN clients, but connections from Road Warrior's localhost go tru
VPN as it should be.
Any Ideas what can be wrong in my setup would be highly appreciated.
Martin
‐‐‐ Original Message
On 2020-02-10, Paul de Weerd wrote:
>and I've told
> them to either stop filering ICMPv6 Packet Too Large errors or
> restrict the MSS to a lower value on their end (as they said they were
> doing) to fix this for all their users.
AFAIK
On 2020-02-08 16:40, Otto Moerbeek wrote:
> When booting, the contents of the existing dmesg buffer are examined.
> If the current contents are deemed to be a dmesg, it is not cleared.
> It's possible the (random) contents of the buffer are seen as valid by
> chance and are thus regarded as dmesg
On 2020/02/10 13:11, whistlez...@riseup.net wrote:
> On Mon, Feb 10, 2020 at 09:45:06AM -, Stuart Henderson wrote:
> > On 2020-02-10, Janne Johansson wrote:
> > > Den lör 8 feb. 2020 kl 11:31 skrev :
> > >
> > >> Hi,
> > >> I have some strange output from dmesg, what could be ?
> > >> At the
Den mån 10 feb. 2020 kl 12:15 skrev Simen Stavdal :
> True, but issue was related to downloading over http, which is over tcp.
> So, if http is your only concern I would go for this option.
>
To me, it sounds just a bit like "let this person notice the other errors
later".
> Most clients are
On Mon, Feb 10, 2020 at 09:45:06AM -, Stuart Henderson wrote:
> On 2020-02-10, Janne Johansson wrote:
> > Den lör 8 feb. 2020 kl 11:31 skrev :
> >
> >> Hi,
> >> I have some strange output from dmesg, what could be ?
> >> At the follwoing link I've posted some screenshots:
> >>
On Mon, Feb 10, 2020 at 12:15:37PM +0100, Simen Stavdal wrote:
| True, but issue was related to downloading over http, which is over tcp.
| So, if http is your only concern I would go for this option.
|
| Most clients are configured with an MTU of their physical NIC capabilities,
| and sometimes
True, but issue was related to downloading over http, which is over tcp.
So, if http is your only concern I would go for this option.
Most clients are configured with an MTU of their physical NIC capabilities,
and sometimes even with jumbo support.
MTU is a property of the OS in both ends, while
Den mån 10 feb. 2020 kl 11:58 skrev Simen Stavdal :
> Hi Lucas,
> Have you tried to manipulate the mss during conversation setup?
> This is done with the max-mss directive in pf.conf.
> Basically, it takes the three way handshake, and overrides the MSS value in
> the handshake to something lower
Hi Lucas,
Have you tried to manipulate the mss during conversation setup?
This is done with the max-mss directive in pf.conf.
Basically, it takes the three way handshake, and overrides the MSS value in
the handshake to something lower than the default.
Client (1500 bytes) -> pf (change to 1300
Hi Denis,
Denis wrote:
> It can be re-keying issue. You can check this out by adding to iked.conf
> on both ends:
I took this line off from the mail while cleaning up the config. I have
ikelifetime 3h lifetime 1h
in both ends.
> By the way, can your let us know "big files" exact
On 2020-02-10, Janne Johansson wrote:
> Den lör 8 feb. 2020 kl 11:31 skrev :
>
>> Hi,
>> I have some strange output from dmesg, what could be ?
>> At the follwoing link I've posted some screenshots:
>> https://postimg.cc/gallery/1o4wsaw74/
>>
>
> dmesg is contained in a memory buffer with
Den lör 8 feb. 2020 kl 11:31 skrev :
> Hi,
> I have some strange output from dmesg, what could be ?
> At the follwoing link I've posted some screenshots:
> https://postimg.cc/gallery/1o4wsaw74/
>
dmesg is contained in a memory buffer with (hopefully) room for more than
one dmesg, so you can get
It can be re-keying issue. You can check this out by adding to iked.conf
on both ends:
Intitiator:
...
ikelifetime 120m lifetime 180m bytes 200m \
tag IPSECWWW
Receiver:
...
ikelifetime 100m lifetime 160m bytes 250m \
tag IPSECWWW
The test result can be used for further investigations.
By the
36 matches
Mail list logo
