Hello,
On Thu, Jan 04, 2024 at 01:01:30AM +0300, Alexander Okonnikov wrote:
> Hi Alexandr,
>
> The fact that new IP address to be used for new sessions makes sense. Though,
> such behavior could pose problems like follow:
>
> 00:48:30.266195 172.16.0.2 > 172.16.1.3: icmp: echo request
>
On Wed, Jan 03, 2024 at 01:04:05PM +0100, Alexander Bluhm wrote:
> On Wed, Jan 03, 2024 at 04:51:39PM +1000, Jonathan Matthew wrote:
> > On Wed, Jan 03, 2024 at 01:50:06AM +0100, Alexander Bluhm wrote:
> > > On Wed, Jan 03, 2024 at 12:26:26AM +0100, Hrvoje Popovski wrote:
> > > > While testing
> On 3 Jan 2024, at 16:54, Stuart Henderson wrote:
>
> On 2024/01/02 23:49, Stuart Henderson wrote:
>> On 2024/01/02 20:02, Vitaliy Makkoveev wrote:
>>> On Tue, Jan 02, 2024 at 03:45:10PM +, Stuart Henderson wrote:
Badly OCR'd and manually quickly corrected screen capture below
Hi bugs,
As the topic says. Seen as of a couple of minutes ago in
- http://ftp.openbsd.org/pub/OpenBSD/snapshots/amd64/SHA256{,.sig}
- http://cdn.openbsd.org/pub/OpenBSD/snapshots/amd64/SHA256{,.sig}
SHA256.sig:
untrusted comment: verify with openbsd-74-base.pub
Hello,
I'm not able to comment on route changes when interface
address changes or when interface comes up/down.
I'm able to provide hints on pf(4) part.
On Wed, Jan 03, 2024 at 11:21:38PM +0300, Alexander Okonnikov wrote:
> According to pf.conf man:
>
> "When the interface name is surrounded
Hi,
According to pf.conf man:
"When the interface name is surrounded by parentheses, the rule is
automatically updated whenever the interface changes its address. The ruleset
does not need to be reloaded. This is especially useful with NAT."
In fact it is not true. Moreover, even reloading
Hi,
According to pf.conf man:
"When the interface name is surrounded by parentheses, the rule is
automatically updated whenever the interface changes its address. The ruleset
does not need to be reloaded. This is especially useful with NAT."
In fact it is not true. Moreover, even reloading
Hi, thanks for responding. It appeared as though my DMARC policy had caused
problems with this mailing list, but I guess not.
Our backup system running 7.4 has not panicked or experienced the ix
failure recently. This may be related to an STP issue we addressed on our
switches that we discovered
On 2024/01/02 23:49, Stuart Henderson wrote:
> On 2024/01/02 20:02, Vitaliy Makkoveev wrote:
> > On Tue, Jan 02, 2024 at 03:45:10PM +, Stuart Henderson wrote:
> > > Badly OCR'd and manually quickly corrected screen capture below
> > > (tesseract doesn't do _at all_ well with digits and the
Hi,
this is a Pinebook/arm64, running OpenBSD 7.3
Last thing i did was syspatch as far as i remember and after reboot it now
looks like this. Here's the outputs from ddb, if you need anything else let me
know, i have full serial console access to the machine.
[...]OpenBSD 7.3 (GENERIC.MP) #1:
On Wed, Jan 03, 2024 at 04:51:39PM +1000, Jonathan Matthew wrote:
> On Wed, Jan 03, 2024 at 01:50:06AM +0100, Alexander Bluhm wrote:
> > On Wed, Jan 03, 2024 at 12:26:26AM +0100, Hrvoje Popovski wrote:
> > > While testing kettenis@ ipl diff from tech@ and doing iperf3 to bnxt
> > > interface and
On 3.1.2024. 7:51, Jonathan Matthew wrote:
> On Wed, Jan 03, 2024 at 01:50:06AM +0100, Alexander Bluhm wrote:
>> On Wed, Jan 03, 2024 at 12:26:26AM +0100, Hrvoje Popovski wrote:
>>> While testing kettenis@ ipl diff from tech@ and doing iperf3 to bnxt
>>> interface and ifconfig bnxt0 down/up at the
12 matches
Mail list logo
