Maintenance: (man|cvsweb).openbsd.org, (openbsd|obsdacvs).cs.toronto.edu

[Nick Holland]

hi.

The following servers will likely be inaccessible at times or
completely, April 14, from 7am to 8pm Eastern Daylight Time (UTC-4)
(yes -- 13 hour window) for site network maintenance.

  * man.openbsd.org
  * cvsweb.openbsd.org
  * obsdacvs.cs.toronto.edu
  * openbsd.cs.toronto.edu

Nick.

Re: Will windows 10 boot after installing openBSD?

[Abel Abraham Camarillo Ojeda]

On Monday, April 13, 2020, Никита Степанов 
wrote:

>
Yes

Re: WLAN throughput less 10Mb/s

[Mario Theodoridis]

On 13.04.2020 20:34, Stefan Sperling wrote:

On Mon, Apr 13, 2020 at 07:03:27PM +0200, Mario Theodoridis wrote:

Hi everyone.

I'm running a APU2 board with an Atheros wlan chipset.
I've been plagued by rather slow WLAN throughput rates < 10Mb/s.
Is that normal or not. If not, how would i go about debugging this?
Any other info i should provide?


Is this a new problem or has it always been like this for you?


It has always been this way. Always being on 6.2 and 6.6.


Here's an ifconfig
athn0: flags=8943 mtu 1500


There are several known performance issues with athn(4).

...
And our automatic rate selection has some performance issues of its own.


Ok, so i take it issues aren't uncommon then.



Also, athn(4) does not support Tx aggregation yet, and 40 MHz channels are
not yet suppored either. In practice this means the driver won't be noticably
faster in 11n mode than it is in 11a/g modes. For now, I would recommend
using 11a mode if you want it to be as fast as possible.


Hmm, using
media autoselect mode 11a mediaopt hostap
nwid foo
wpaprotos wpa2
wpakey mysecret
up

Brings the inteface up alright, but i don't see any 5 or 2.4 GHz signal 
with a Wifi analyzer nor can i connect.




I do want to fix all of these issues, but it will take time and help
would be very welcome.


I'm open to that. Maybe PM me with details.



Another important factor is your RF environment. No amount of bug fixing
is going to help when your channel is heavily used by one or more other
wifi networks. Ensure that your AP is running on a channel where no other
wifi networks can be seen in a scan.


The channel is available, but i am only using one antenna. I remember 
trying with both didn't help, though.





OpenBSD 6.6 (GENERIC.MP) #7: Thu Mar 12 11:55:22 MDT 2020


One way you could help is to keep following -current, upgrade a day or so
after any wifi-related commits happen, and letting us know if things are
better or worse compared to a previous snapshots.


I'm looking into that.

Meanwhile is there a mini PCI chipset that will do 54Mb or more in 
hostap mode?



Mit freundlichen Grüßen/Best regards

Mario Theodoridis

Will windows 10 boot after installing openBSD?

[Никита Степанов]

Re: OSPF seems to stops processing updates

[Remi Locherer]

On Mon, Apr 13, 2020 at 03:30:12PM +0100, Stuart Henderson wrote:
> On 2020/04/13 15:21, Richard Chivers wrote:
> > Hi,
> > 
> > Thanks everyone, we will update to start with and see how it goes from 
> > there. If the issues
> > continue we will dump the ospf traffic.
> > 
> > When we were looking at these issues I noticed when running ospfctl sh nei 
> > that we had two DR.
> 
> That will definitely happen with pre-6.3 versions after some flaps.

Seeing two DRs in the output of "ospfctl sh nei" is not an issue. There
must be a DR for each broadcast or NBMA network.

But you should not see multiple DR neighbors on the same link.

> 
> > I thought there could/should only be a single one.
> > 
> > Any ideas on this, are there snearios where this is valid? We only run a 
> > single area.
> > 
> > Thanks
> > 
> > Richard
> > 
> > 
> > 
> > On Mon, 13 Apr 2020, 14:39 Stuart Henderson,  wrote:
> > 
> > On 2020-04-13, Claudio Jeker  wrote:
> > > On Mon, Apr 13, 2020 at 02:08:31PM +0200, Remi Locherer wrote:
> > >> On Mon, Apr 13, 2020 at 12:05:10PM +0100, Richard Chivers wrote:
> > >> > On Mon, 13 Apr 2020, 10:18 Remi Locherer,  
> > wrote:
> > >> > >
> > >> > > On Mon, Apr 13, 2020 at 08:38:31AM +0100, Richard Chivers wrote:
> > >> > > > We have been having a strange issue, whereby OSPF stops 
> > updating
> > >> > > properly.
> > >> > > >
> > >> > > > We can see an entry for an ip route in the database but it is 
> > not in the
> > >> > > > kernel routing table, and when it is the DR, other routers 
> > then do not
> > >> > > have
> > >> > > > the route at all.
> > >> > > >
> > >> > > > We are seeing this across multiple boxes. We have 10+ ospf 
> > speakers, and
> > >> > > > seem to see the issue at different times.
> > >> > > >
> > >> > > > The problem starts with:
> > >> > > >
> > >> > > > ospfd[6960]: recv_db_description: neighbor ID x.x.x.x: seq num 
> > mismatch,
> > >> > > > bad flags
> > >> > >
> > >> > > The neighbor sent a db desc with the master flag set differently 
> > than what
> > >> > > this ospfd instance recorded before for that particular neighbor.
> > >> > >
> > >> > > See 2nd last item on page 100 of RFC 2328:
> > >> > > https://tools.ietf.org/html/rfc2328#page-100
> > >> >
> > >> >
> > >> > Thanks, should the routers just recover then from this scenario 
> > even if it
> > >> > was happening due to lost packets, CPU pause etc.
> > >>
> > >> I think so. But it may take quite a while. It might also be an bug 
> > in ospfd
> > >> or in another implementation.
> > 
> > On my 6.6/current boxes it seems to recover fairly quickly from this (30
> > seconds or so). I've definitely seen it take a long time in the past 
> > though.
> > 
> > > Since this issues happen with 5.8 and 6.4 ospfd I would suggest to 
> > update
> > > to at least 6.6 (especially the 5.8). IIRC there was some issue with 
> > ospfd
> > > neighbor selection that caused troubles when sessions flapped. This 
> > was
> > > fixed some time ago but I doubt 5.8 has that fix in.
> > 
> > That one was fixed in 6.3.
> > 
> > If you also run bgpd then be aware there are crashes with the version in
> > 6.6 release - fixed in syspatches (and of course in snapshots), but one
> > of the crashes is at startup with some configurations and it's hard to
> > run syspatch if you have no routing ;) so either be ready to cope with
> > that in case you run into it (e.g. pre-download the syspatch directory
> > and make sure you have console access), or consider skipping 6.6 (go
> > straight to a -current snapshot).
> > 
> > 
> > 
> 

Re: WLAN throughput less 10Mb/s

[Stefan Sperling]

On Mon, Apr 13, 2020 at 07:03:27PM +0200, Mario Theodoridis wrote:
> Hi everyone.
> 
> I'm running a APU2 board with an Atheros wlan chipset.
> I've been plagued by rather slow WLAN throughput rates < 10Mb/s.
> Is that normal or not. If not, how would i go about debugging this?
> Any other info i should provide?

Is this a new problem or has it always been like this for you?

> Here's an ifconfig
> athn0: flags=8943 mtu 1500

There are several known performance issues with athn(4).

One is that the device seems unable to send frames at the upper frame data
rates. At least in my environment the hardware throws Tx errors when it is
asked to send such frames. I don't understand where this is coming from.
Automatic rate selection works around it by detecting that some rates don't
work and then not using them. But it means we're only using slower rates
than the hardware is supposed to be able to transmit frames with.

Then are other factors that make things even worse:

I am not certain if the block ack Rx logic is correctly working in this driver.
It seems the device will only send block ack frames when its block ack window
is full (i.e. every 64 frames) or when the client asks for a block ack frame.
As far as I understand a block ack should be sent after every aggregate frame
which gets received, but this is not the case. This can lead to low throughput
for TCP due to redundantly re-transmitted packets or dropped packets.
This needs to be debugged and better understood before something can be done.

And our automatic rate selection has some performance issues of its own.

Also, athn(4) does not support Tx aggregation yet, and 40 MHz channels are
not yet suppored either. In practice this means the driver won't be noticably
faster in 11n mode than it is in 11a/g modes. For now, I would recommend
using 11a mode if you want it to be as fast as possible.
 
I do want to fix all of these issues, but it will take time and help
would be very welcome.

Another important factor is your RF environment. No amount of bug fixing
is going to help when your channel is heavily used by one or more other
wifi networks. Ensure that your AP is running on a channel where no other
wifi networks can be seen in a scan.

> OpenBSD 6.6 (GENERIC.MP) #7: Thu Mar 12 11:55:22 MDT 2020

One way you could help is to keep following -current, upgrade a day or so
after any wifi-related commits happen, and letting us know if things are
better or worse compared to a previous snapshots.

WLAN throughput less 10Mb/s

[Mario Theodoridis]

Hi everyone.

I'm running a APU2 board with an Atheros wlan chipset.
I've been plagued by rather slow WLAN throughput rates < 10Mb/s.
Is that normal or not. If not, how would i go about debugging this?
Any other info i should provide?

Here's an ifconfig
athn0: flags=8943 mtu 1500
lladdr nn:nn:nn:nn:nn:d7
index 1 priority 4 llprio 3
groups: wlan
media: IEEE802.11 autoselect mode 11g hostap
status: active
ieee80211: nwid foo chan 1 bssid nn:nn:nn:nn:nn:d7 -81dBm 
wpakey wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp


/etc/hostname.athn0:

media autoselect mode 11g mediaopt hostap chan 1
nwid foo
wpaprotos wpa2
wpakey mysecret
up

And a dmesg:

booting hd0a:/bsd: 12748104+2937872+34+0+708608 
[982948+128+1013280+741024]=0x12948e8

entry point at 0x81001000
[ using 2738408 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2019 OpenBSD. All rights reserved. 
https://www.OpenBSD.org


OpenBSD 6.6 (GENERIC.MP) #7: Thu Mar 12 11:55:22 MDT 2020

r...@syspatch-66-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 1996152832 (1903MB)
avail mem = 1923002368 (1833MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x77fb7020 (7 entries)
bios0: vendor coreboot version "4.0.7" date 02/28/2017
bios0: PC Engines APU2
acpi0 at bios0: ACPI 4.0
acpi0: sleep states S0 S1 S2 S3 S4 S5
acpi0: tables DSDT FACP SSDT APIC HEST SSDT SSDT HPET
acpi0: wakeup devices PWRB(S4) PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) 
PBR8(S4) UOH1(S3) UOH3(S3) UOH5(S3) XHC0(S4)

acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD GX-412TC SOC, 998.44 MHz, 16-30-01
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT
cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 
64b/line 16-way L2 cache

cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD GX-412TC SOC, 998.14 MHz, 16-30-01
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT
cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 
64b/line 16-way L2 cache

cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: AMD GX-412TC SOC, 998.17 MHz, 16-30-01
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT
cpu2: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 
64b/line 16-way L2 cache

cpu2: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu2: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: AMD GX-412TC SOC, 998.13 MHz, 16-30-01
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT
cpu3: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 
64b/line 16-way L2 cache

cpu3: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu3: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 4 pa 0xfec0, version 21, 24 pins
ioapic1 at mainbus0: apid 5 pa 0xfec2, version 21, 32 pins, remapped
acpihpet0 at acpi0: 14318180 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (PBR4)

Re: openbsd.org down?

[Eric Zylstra]

ezylstra ~ % traceroute openbsd.org
traceroute to openbsd.org (129.128.5.194), 64 hops max, 52 byte packets
 1  dslrouter (192.168.0.1)  0.811 ms  0.405 ms  0.295 ms
 2  stpl-dsl-gw13.stpl.qwest.net (207.109.2.13)  10.595 ms  10.860 ms  10.977 ms
 3  stpl-agw1.inet.qwest.net (207.109.3.97)  57.309 ms  14.162 ms  10.966 ms
 4  4.68.38.177 (4.68.38.177)  11.740 ms  11.695 ms  15.970 ms
 5  ae-0-25.bar3.minneapolis2.level3.net (4.69.218.182)  14.949 ms  12.693 ms  
11.964 ms
 6  v135.core1.msp1.he.net (184.105.52.221)  13.082 ms  11.910 ms  11.796 ms
 7  100ge10-1.core1.ywg1.he.net (184.105.64.86)  19.679 ms  19.895 ms  20.369 ms
 8  100ge5-2.core1.yxe1.he.net (184.104.192.70)  28.868 ms  28.466 ms  28.587 ms
 9  100ge11-2.core1.yeg1.he.net (72.52.92.61)  53.860 ms  53.360 ms  53.231 ms
10  university-of-alberta-sms.10gigabitethernet2-2.core1.yeg1.he.net 
(184.105.18.50)  54.089 ms  54.084 ms  54.264 ms
11  katzcore-esqgw.corenet.ualberta.ca (129.128.255.41)  54.326 ms
cabcore-esqgw.corenet.ualberta.ca (129.128.255.35)  54.093 ms  53.920 ms
12  * * *
13  * * *
14  * * *
15  obsd3.srv.ualberta.ca (129.128.5.194)  53.712 ms  54.430 ms  53.976 ms

Problems on campus at Alberta?

EZ


> On Apr 13, 2020, at 8:22 AM, Mario Theodoridis  wrote:
> 
> For me with /etc/mail/spamd.conf
> 
> nixspam:\
>:black:\
>:msg="Your address %A is in the nixspam list\n\
>See http://www.heise.de/ix/nixspam/dnsbl_en/ for details":\
>:method=http:\
>:file=www.openbsd.org/spamd/nixspam.gz
> 
> sleep $((RANDOM % 2048)) && /usr/libexec/spamd-setup
> 
> produces
> 
> ftp: connect: Operation timed out
> 
> since yesterday morning 4am CEST.
> 
> But running
> 
> wget http://www.openbsd.org/spamd/nixspam.gz
> --2020-04-13 14:59:07--  http://www.openbsd.org/spamd/nixspam.gz
> Resolving www.openbsd.org (www.openbsd.org)... 129.128.5.194
> Connecting to www.openbsd.org (www.openbsd.org)|129.128.5.194|:80... 
> connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 18025 (18K) [text/plain]
> Saving to: 'nixspam.gz'
> 
> nixspam.gz 
> 100%[=>]  
> 17.60K  37.7KB/sin 0.5s
> 
> 2020-04-13 14:59:08 (37.7 KB/s) - 'nixspam.gz' saved [18025/18025]
> 
> just now works.
> 
> Mit freundlichen Grüßen/Best regards
> 
> Mario Theodoridis
> 
> On 13.04.2020 14:02, infoomatic wrote:
>> not reachable for days now in Austria, Germany, Czech Republic
>> On 13.04.20 11:01, SP2L Tom wrote:
>>> Greetings.
>>> 
>>> 
>>> It was and it is still up
>>> At least, I can reach OpenBSD site.
>>> 
>>> 
>>> Best regards.
>>> Tom
>>> 
>>> W 13 kwietnia 2020 10:23:18 Sebastien Marie  napisał:
>>> 
 On Mon, Apr 13, 2020 at 10:14:00AM +0300, Ilya Mitrukov wrote:
> Hi,
> flushing the caches doesn't help and it's still unavailable.
> 
> Does anybody know where to report the issue?
> (I'd look at openbsd.org but ... )
 
 I suppose there is one or two openbsd developers which follow this
 list. So they
 might already know.
 
 Thanks.
 --
 Sebastien Marie
>>> 
>>> 
>>> 
> 

Re: openbsd.org down?

[Otto Moerbeek]

On Mon, Apr 13, 2020 at 10:13:47AM -0500, Eric Zylstra wrote:

> ezylstra ~ % traceroute openbsd.org
> traceroute to openbsd.org (129.128.5.194), 64 hops max, 52 byte packets
>  1  dslrouter (192.168.0.1)  0.811 ms  0.405 ms  0.295 ms
>  2  stpl-dsl-gw13.stpl.qwest.net (207.109.2.13)  10.595 ms  10.860 ms  10.977 
> ms
>  3  stpl-agw1.inet.qwest.net (207.109.3.97)  57.309 ms  14.162 ms  10.966 ms
>  4  4.68.38.177 (4.68.38.177)  11.740 ms  11.695 ms  15.970 ms
>  5  ae-0-25.bar3.minneapolis2.level3.net (4.69.218.182)  14.949 ms  12.693 ms 
>  11.964 ms
>  6  v135.core1.msp1.he.net (184.105.52.221)  13.082 ms  11.910 ms  11.796 ms
>  7  100ge10-1.core1.ywg1.he.net (184.105.64.86)  19.679 ms  19.895 ms  20.369 
> ms
>  8  100ge5-2.core1.yxe1.he.net (184.104.192.70)  28.868 ms  28.466 ms  28.587 
> ms
>  9  100ge11-2.core1.yeg1.he.net (72.52.92.61)  53.860 ms  53.360 ms  53.231 ms
> 10  university-of-alberta-sms.10gigabitethernet2-2.core1.yeg1.he.net 
> (184.105.18.50)  54.089 ms  54.084 ms  54.264 ms
> 11  katzcore-esqgw.corenet.ualberta.ca (129.128.255.41)  54.326 ms
> cabcore-esqgw.corenet.ualberta.ca (129.128.255.35)  54.093 ms  53.920 ms
> 12  * * *
> 13  * * *
> 14  * * *
> 15  obsd3.srv.ualberta.ca (129.128.5.194)  53.712 ms  54.430 ms  53.976 ms
> 
> Problems on campus at Alberta?

No need to speculate. The people taking care of the failing machine
are aware and are on it. It might take a while though, since it the
issues are hardware related.

-Otto

> 
> EZ
> 
> 
> > On Apr 13, 2020, at 8:22 AM, Mario Theodoridis  wrote:
> > 
> > For me with /etc/mail/spamd.conf
> > 
> > nixspam:\
> >:black:\
> >:msg="Your address %A is in the nixspam list\n\
> >See http://www.heise.de/ix/nixspam/dnsbl_en/ for details":\
> >:method=http:\
> >:file=www.openbsd.org/spamd/nixspam.gz
> > 
> > sleep $((RANDOM % 2048)) && /usr/libexec/spamd-setup
> > 
> > produces
> > 
> > ftp: connect: Operation timed out
> > 
> > since yesterday morning 4am CEST.
> > 
> > But running
> > 
> > wget http://www.openbsd.org/spamd/nixspam.gz
> > --2020-04-13 14:59:07--  http://www.openbsd.org/spamd/nixspam.gz
> > Resolving www.openbsd.org (www.openbsd.org)... 129.128.5.194
> > Connecting to www.openbsd.org (www.openbsd.org)|129.128.5.194|:80... 
> > connected.
> > HTTP request sent, awaiting response... 200 OK
> > Length: 18025 (18K) [text/plain]
> > Saving to: 'nixspam.gz'
> > 
> > nixspam.gz 
> > 100%[=>]
> >   17.60K  37.7KB/sin 0.5s
> > 
> > 2020-04-13 14:59:08 (37.7 KB/s) - 'nixspam.gz' saved [18025/18025]
> > 
> > just now works.
> > 
> > Mit freundlichen Grüßen/Best regards
> > 
> > Mario Theodoridis
> > 
> > On 13.04.2020 14:02, infoomatic wrote:
> >> not reachable for days now in Austria, Germany, Czech Republic
> >> On 13.04.20 11:01, SP2L Tom wrote:
> >>> Greetings.
> >>> 
> >>> 
> >>> It was and it is still up
> >>> At least, I can reach OpenBSD site.
> >>> 
> >>> 
> >>> Best regards.
> >>> Tom
> >>> 
> >>> W 13 kwietnia 2020 10:23:18 Sebastien Marie  napisał:
> >>> 
>  On Mon, Apr 13, 2020 at 10:14:00AM +0300, Ilya Mitrukov wrote:
> > Hi,
> > flushing the caches doesn't help and it's still unavailable.
> > 
> > Does anybody know where to report the issue?
> > (I'd look at openbsd.org but ... )
>  
>  I suppose there is one or two openbsd developers which follow this
>  list. So they
>  might already know.
>  
>  Thanks.
>  --
>  Sebastien Marie
> >>> 
> >>> 
> >>> 
> > 
> 

Re: openbsd.org down?

[Daniel Jakots]

On Sun, 12 Apr 2020 11:28:21 +0200, Salvatore Cuzzilla
 wrote:

> Can’t reach openbsd.org  - planned maintenance?

Until the problem is solved (which is known and being worked on), I just
forked openbsd/www on github and enabled github pages. You can reach the
website at https://danieljakots.github.io/openbsd-www/
Of course as there is my name there, you can guess it's not something
official.


Cheers,
Daniel

Re: openbsd.org down?

[Mario Theodoridis]

For me with /etc/mail/spamd.conf

nixspam:\
:black:\
:msg="Your address %A is in the nixspam list\n\
See http://www.heise.de/ix/nixspam/dnsbl_en/ for details":\
:method=http:\
:file=www.openbsd.org/spamd/nixspam.gz

sleep $((RANDOM % 2048)) && /usr/libexec/spamd-setup

produces

 ftp: connect: Operation timed out

since yesterday morning 4am CEST.

But running

wget http://www.openbsd.org/spamd/nixspam.gz
--2020-04-13 14:59:07--  http://www.openbsd.org/spamd/nixspam.gz
Resolving www.openbsd.org (www.openbsd.org)... 129.128.5.194
Connecting to www.openbsd.org (www.openbsd.org)|129.128.5.194|:80... 
connected.

HTTP request sent, awaiting response... 200 OK
Length: 18025 (18K) [text/plain]
Saving to: 'nixspam.gz'

nixspam.gz 
100%[=>] 
 17.60K  37.7KB/sin 0.5s


2020-04-13 14:59:08 (37.7 KB/s) - 'nixspam.gz' saved [18025/18025]

just now works.

Mit freundlichen Grüßen/Best regards

Mario Theodoridis

On 13.04.2020 14:02, infoomatic wrote:

not reachable for days now in Austria, Germany, Czech Republic


On 13.04.20 11:01, SP2L Tom wrote:

Greetings.


It was and it is still up
At least, I can reach OpenBSD site.


Best regards.
Tom

W 13 kwietnia 2020 10:23:18 Sebastien Marie  napisał:


On Mon, Apr 13, 2020 at 10:14:00AM +0300, Ilya Mitrukov wrote:

Hi,
flushing the caches doesn't help and it's still unavailable.

Does anybody know where to report the issue?
(I'd look at openbsd.org but ... )


I suppose there is one or two openbsd developers which follow this
list. So they
might already know.

Thanks.
--
Sebastien Marie

Re: openbsd.org down?

[Consus]

On Mon, Apr 13, 2020 at 04:53:22PM +0300, Gökşin Akdeniz wrote:
> On the other hand, DNS works.

Maybe it's related to the network?

$ ping -c 5 openbsd.org
PING openbsd.org (129.128.5.194) 56(84) bytes of data.
>From obsd3.srv.ualberta.ca (129.128.5.194) icmp_seq=1 Destination Port 
>Unreachable
>From obsd3.srv.ualberta.ca (129.128.5.194) icmp_seq=2 Destination Port 
>Unreachable
>From obsd3.srv.ualberta.ca (129.128.5.194) icmp_seq=3 Destination Port 
>Unreachable
>From obsd3.srv.ualberta.ca (129.128.5.194) icmp_seq=4 Destination Port 
>Unreachable
>From obsd3.srv.ualberta.ca (129.128.5.194) icmp_seq=5 Destination Port 
>Unreachable

--- openbsd.org ping statistics ---
5 packets transmitted, 0 received, +5 errors, 100% packet loss, time 9ms

$ ping -c 5 ftp.openbsd.org
PING ftp.openbsd.org (129.128.5.191) 56(84) bytes of data.
>From openbsd.sunsite.ualberta.ca (129.128.5.191) icmp_seq=1 Destination Port 
>Unreachable
>From openbsd.sunsite.ualberta.ca (129.128.5.191) icmp_seq=2 Destination Port 
>Unreachable
>From openbsd.sunsite.ualberta.ca (129.128.5.191) icmp_seq=3 Destination Port 
>Unreachable
>From openbsd.sunsite.ualberta.ca (129.128.5.191) icmp_seq=4 Destination Port 
>Unreachable
>From openbsd.sunsite.ualberta.ca (129.128.5.191) icmp_seq=5 Destination Port 
>Unreachable

--- ftp.openbsd.org ping statistics ---
5 packets transmitted, 0 received, +5 errors, 100% packet loss, time 9ms

$ ping -c 5 cvs.openbsd.org
PING cvs.openbsd.org (199.185.137.3) 56(84) bytes of data.
64 bytes from cvs.openbsd.org (199.185.137.3): icmp_seq=1 ttl=242 time=156 ms
64 bytes from cvs.openbsd.org (199.185.137.3): icmp_seq=2 ttl=242 time=154 ms
64 bytes from cvs.openbsd.org (199.185.137.3): icmp_seq=3 ttl=242 time=155 ms
64 bytes from cvs.openbsd.org (199.185.137.3): icmp_seq=4 ttl=242 time=154 ms
64 bytes from cvs.openbsd.org (199.185.137.3): icmp_seq=5 ttl=242 time=154 ms

--- cvs.openbsd.org ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 10ms
rtt min/avg/max/mdev = 154.154/154.627/155.517/0.637 ms

Re: OSPF seems to stops processing updates

[Stuart Henderson]

On 2020/04/13 15:21, Richard Chivers wrote:
> Hi,
> 
> Thanks everyone, we will update to start with and see how it goes from there. 
> If the issues
> continue we will dump the ospf traffic.
> 
> When we were looking at these issues I noticed when running ospfctl sh nei 
> that we had two DR.

That will definitely happen with pre-6.3 versions after some flaps.

> I thought there could/should only be a single one.
> 
> Any ideas on this, are there snearios where this is valid? We only run a 
> single area.
> 
> Thanks
> 
> Richard
> 
> 
> 
> On Mon, 13 Apr 2020, 14:39 Stuart Henderson,  wrote:
> 
> On 2020-04-13, Claudio Jeker  wrote:
> > On Mon, Apr 13, 2020 at 02:08:31PM +0200, Remi Locherer wrote:
> >> On Mon, Apr 13, 2020 at 12:05:10PM +0100, Richard Chivers wrote:
> >> > On Mon, 13 Apr 2020, 10:18 Remi Locherer,  
> wrote:
> >> > >
> >> > > On Mon, Apr 13, 2020 at 08:38:31AM +0100, Richard Chivers wrote:
> >> > > > We have been having a strange issue, whereby OSPF stops updating
> >> > > properly.
> >> > > >
> >> > > > We can see an entry for an ip route in the database but it is 
> not in the
> >> > > > kernel routing table, and when it is the DR, other routers then 
> do not
> >> > > have
> >> > > > the route at all.
> >> > > >
> >> > > > We are seeing this across multiple boxes. We have 10+ ospf 
> speakers, and
> >> > > > seem to see the issue at different times.
> >> > > >
> >> > > > The problem starts with:
> >> > > >
> >> > > > ospfd[6960]: recv_db_description: neighbor ID x.x.x.x: seq num 
> mismatch,
> >> > > > bad flags
> >> > >
> >> > > The neighbor sent a db desc with the master flag set differently 
> than what
> >> > > this ospfd instance recorded before for that particular neighbor.
> >> > >
> >> > > See 2nd last item on page 100 of RFC 2328:
> >> > > https://tools.ietf.org/html/rfc2328#page-100
> >> >
> >> >
> >> > Thanks, should the routers just recover then from this scenario even 
> if it
> >> > was happening due to lost packets, CPU pause etc.
> >>
> >> I think so. But it may take quite a while. It might also be an bug in 
> ospfd
> >> or in another implementation.
> 
> On my 6.6/current boxes it seems to recover fairly quickly from this (30
> seconds or so). I've definitely seen it take a long time in the past 
> though.
> 
> > Since this issues happen with 5.8 and 6.4 ospfd I would suggest to 
> update
> > to at least 6.6 (especially the 5.8). IIRC there was some issue with 
> ospfd
> > neighbor selection that caused troubles when sessions flapped. This was
> > fixed some time ago but I doubt 5.8 has that fix in.
> 
> That one was fixed in 6.3.
> 
> If you also run bgpd then be aware there are crashes with the version in
> 6.6 release - fixed in syspatches (and of course in snapshots), but one
> of the crashes is at startup with some configurations and it's hard to
> run syspatch if you have no routing ;) so either be ready to cope with
> that in case you run into it (e.g. pre-download the syspatch directory
> and make sure you have console access), or consider skipping 6.6 (go
> straight to a -current snapshot).
> 
> 
> 

Re: OSPF seems to stops processing updates

[Richard Chivers]

Hi,

Thanks everyone, we will update to start with and see how it goes from
there. If the issues continue we will dump the ospf traffic.

When we were looking at these issues I noticed when running ospfctl sh nei
that we had two DR.

I thought there could/should only be a single one.

Any ideas on this, are there snearios where this is valid? We only run a
single area.

Thanks

Richard



On Mon, 13 Apr 2020, 14:39 Stuart Henderson,  wrote:

> On 2020-04-13, Claudio Jeker  wrote:
> > On Mon, Apr 13, 2020 at 02:08:31PM +0200, Remi Locherer wrote:
> >> On Mon, Apr 13, 2020 at 12:05:10PM +0100, Richard Chivers wrote:
> >> > On Mon, 13 Apr 2020, 10:18 Remi Locherer, 
> wrote:
> >> > >
> >> > > On Mon, Apr 13, 2020 at 08:38:31AM +0100, Richard Chivers wrote:
> >> > > > We have been having a strange issue, whereby OSPF stops updating
> >> > > properly.
> >> > > >
> >> > > > We can see an entry for an ip route in the database but it is not
> in the
> >> > > > kernel routing table, and when it is the DR, other routers then
> do not
> >> > > have
> >> > > > the route at all.
> >> > > >
> >> > > > We are seeing this across multiple boxes. We have 10+ ospf
> speakers, and
> >> > > > seem to see the issue at different times.
> >> > > >
> >> > > > The problem starts with:
> >> > > >
> >> > > > ospfd[6960]: recv_db_description: neighbor ID x.x.x.x: seq num
> mismatch,
> >> > > > bad flags
> >> > >
> >> > > The neighbor sent a db desc with the master flag set differently
> than what
> >> > > this ospfd instance recorded before for that particular neighbor.
> >> > >
> >> > > See 2nd last item on page 100 of RFC 2328:
> >> > > https://tools.ietf.org/html/rfc2328#page-100
> >> >
> >> >
> >> > Thanks, should the routers just recover then from this scenario even
> if it
> >> > was happening due to lost packets, CPU pause etc.
> >>
> >> I think so. But it may take quite a while. It might also be an bug in
> ospfd
> >> or in another implementation.
>
> On my 6.6/current boxes it seems to recover fairly quickly from this (30
> seconds or so). I've definitely seen it take a long time in the past
> though.
>
> > Since this issues happen with 5.8 and 6.4 ospfd I would suggest to update
> > to at least 6.6 (especially the 5.8). IIRC there was some issue with
> ospfd
> > neighbor selection that caused troubles when sessions flapped. This was
> > fixed some time ago but I doubt 5.8 has that fix in.
>
> That one was fixed in 6.3.
>
> If you also run bgpd then be aware there are crashes with the version in
> 6.6 release - fixed in syspatches (and of course in snapshots), but one
> of the crashes is at startup with some configurations and it's hard to
> run syspatch if you have no routing ;) so either be ready to cope with
> that in case you run into it (e.g. pre-download the syspatch directory
> and make sure you have console access), or consider skipping 6.6 (go
> straight to a -current snapshot).
>
>
>

Re: openbsd.org down?

[Gökşin Akdeniz]

13.04.2020 16:07 tarihinde Ali Farzanrad yazdı:
> 
> Maybe that's a firefox bug:
> 
> https://support.mozilla.org/he/questions/1276819
> 

İt looks like it is down for all.

https://www.isitdownrightnow.com/openbsd.org.html

On the other hand, DNS works.


0xF4E1EEA55B6F910A.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: OSPF seems to stops processing updates

[Stuart Henderson]

On 2020-04-13, Claudio Jeker  wrote:
> On Mon, Apr 13, 2020 at 02:08:31PM +0200, Remi Locherer wrote:
>> On Mon, Apr 13, 2020 at 12:05:10PM +0100, Richard Chivers wrote:
>> > On Mon, 13 Apr 2020, 10:18 Remi Locherer,  wrote:
>> > >
>> > > On Mon, Apr 13, 2020 at 08:38:31AM +0100, Richard Chivers wrote:
>> > > > We have been having a strange issue, whereby OSPF stops updating
>> > > properly.
>> > > >
>> > > > We can see an entry for an ip route in the database but it is not in 
>> > > > the
>> > > > kernel routing table, and when it is the DR, other routers then do not
>> > > have
>> > > > the route at all.
>> > > >
>> > > > We are seeing this across multiple boxes. We have 10+ ospf speakers, 
>> > > > and
>> > > > seem to see the issue at different times.
>> > > >
>> > > > The problem starts with:
>> > > >
>> > > > ospfd[6960]: recv_db_description: neighbor ID x.x.x.x: seq num 
>> > > > mismatch,
>> > > > bad flags
>> > >
>> > > The neighbor sent a db desc with the master flag set differently than 
>> > > what
>> > > this ospfd instance recorded before for that particular neighbor.
>> > >
>> > > See 2nd last item on page 100 of RFC 2328:
>> > > https://tools.ietf.org/html/rfc2328#page-100
>> > 
>> > 
>> > Thanks, should the routers just recover then from this scenario even if it
>> > was happening due to lost packets, CPU pause etc.
>> 
>> I think so. But it may take quite a while. It might also be an bug in ospfd
>> or in another implementation.

On my 6.6/current boxes it seems to recover fairly quickly from this (30
seconds or so). I've definitely seen it take a long time in the past though.

> Since this issues happen with 5.8 and 6.4 ospfd I would suggest to update
> to at least 6.6 (especially the 5.8). IIRC there was some issue with ospfd
> neighbor selection that caused troubles when sessions flapped. This was
> fixed some time ago but I doubt 5.8 has that fix in.

That one was fixed in 6.3.

If you also run bgpd then be aware there are crashes with the version in 
6.6 release - fixed in syspatches (and of course in snapshots), but one 
of the crashes is at startup with some configurations and it's hard to 
run syspatch if you have no routing ;) so either be ready to cope with
that in case you run into it (e.g. pre-download the syspatch directory
and make sure you have console access), or consider skipping 6.6 (go
straight to a -current snapshot).

Re: openbsd.org down?

[Ali Farzanrad]

Monah Baki  wrote:
> firefox does not work
> 

Maybe that's a firefox bug:

https://support.mozilla.org/he/questions/1276819

Re: openbsd.org down?

[Monah Baki]

curl works
[ntis@fpc ~]$ curl https://www.openbsd.org



OpenBSD


https://www.openbsd.org/;>


  

IE works
firefox does not work

On Mon, Apr 13, 2020 at 8:25 AM infoomatic  wrote:

> not reachable for days now in Austria, Germany, Czech Republic
>
>
> On 13.04.20 11:01, SP2L Tom wrote:
> > Greetings.
> >
> >
> > It was and it is still up
> > At least, I can reach OpenBSD site.
> >
> >
> > Best regards.
> > Tom
> >
> > W 13 kwietnia 2020 10:23:18 Sebastien Marie  napisał:
> >
> >> On Mon, Apr 13, 2020 at 10:14:00AM +0300, Ilya Mitrukov wrote:
> >>> Hi,
> >>> flushing the caches doesn't help and it's still unavailable.
> >>>
> >>> Does anybody know where to report the issue?
> >>> (I'd look at openbsd.org but ... )
> >>
> >> I suppose there is one or two openbsd developers which follow this
> >> list. So they
> >> might already know.
> >>
> >> Thanks.
> >> --
> >> Sebastien Marie
> >
> >
> >
>
>

Re: OSPF seems to stops processing updates

[Claudio Jeker]

On Mon, Apr 13, 2020 at 02:08:31PM +0200, Remi Locherer wrote:
> On Mon, Apr 13, 2020 at 12:05:10PM +0100, Richard Chivers wrote:
> > Thanks. Please see my comments below.
> > 
> > On Mon, 13 Apr 2020, 10:18 Remi Locherer,  wrote:
> > 
> > > Hi Richard,
> > >
> > > On Mon, Apr 13, 2020 at 08:38:31AM +0100, Richard Chivers wrote:
> > > > We have been having a strange issue, whereby OSPF stops updating
> > > properly.
> > > >
> > > > We can see an entry for an ip route in the database but it is not in the
> > > > kernel routing table, and when it is the DR, other routers then do not
> > > have
> > > > the route at all.
> > > >
> > > > We are seeing this across multiple boxes. We have 10+ ospf speakers, and
> > > > seem to see the issue at different times.
> > > >
> > > > The problem starts with:
> > > >
> > > > ospfd[6960]: recv_db_description: neighbor ID x.x.x.x: seq num mismatch,
> > > > bad flags
> > >
> > > The neighbor sent a db desc with the master flag set differently than what
> > > this ospfd instance recorded before for that particular neighbor.
> > >
> > > See 2nd last item on page 100 of RFC 2328:
> > > https://tools.ietf.org/html/rfc2328#page-100
> > 
> > 
> > Thanks, should the routers just recover then from this scenario even if it
> > was happening due to lost packets, CPU pause etc.
> 
> I think so. But it may take quite a while. It might also be an bug in ospfd
> or in another implementation.

Since this issues happen with 5.8 and 6.4 ospfd I would suggest to update
to at least 6.6 (especially the 5.8). IIRC there was some issue with ospfd
neighbor selection that caused troubles when sessions flapped. This was
fixed some time ago but I doubt 5.8 has that fix in.

-- 
:wq Claudio

Re: OSPF seems to stops processing updates

[Remi Locherer]

On Mon, Apr 13, 2020 at 12:05:10PM +0100, Richard Chivers wrote:
> Thanks. Please see my comments below.
> 
> On Mon, 13 Apr 2020, 10:18 Remi Locherer,  wrote:
> 
> > Hi Richard,
> >
> > On Mon, Apr 13, 2020 at 08:38:31AM +0100, Richard Chivers wrote:
> > > We have been having a strange issue, whereby OSPF stops updating
> > properly.
> > >
> > > We can see an entry for an ip route in the database but it is not in the
> > > kernel routing table, and when it is the DR, other routers then do not
> > have
> > > the route at all.
> > >
> > > We are seeing this across multiple boxes. We have 10+ ospf speakers, and
> > > seem to see the issue at different times.
> > >
> > > The problem starts with:
> > >
> > > ospfd[6960]: recv_db_description: neighbor ID x.x.x.x: seq num mismatch,
> > > bad flags
> >
> > The neighbor sent a db desc with the master flag set differently than what
> > this ospfd instance recorded before for that particular neighbor.
> >
> > See 2nd last item on page 100 of RFC 2328:
> > https://tools.ietf.org/html/rfc2328#page-100
> 
> 
> Thanks, should the routers just recover then from this scenario even if it
> was happening due to lost packets, CPU pause etc.

I think so. But it may take quite a while. It might also be an bug in ospfd
or in another implementation.

> 
> >
> > > ospfd[30114]: lsa_check: bad age
> > >
> > > And these just then continue, until we restart ospfd, and the problem
> > > appears to go away.
> >
> > Is the neighbor also OpenBSD ospfd or something else?
> >
> >
> >
> The neighbors complaining are openbsd, we do however have a couple of
> differeent neighbors that are not openbsd.

What software (incl. version please) are these neighbors that make ospfd
log these messages? It should be easy to identify those neighbors since you
see the neighbor ID in the log message.

> 
> >
> > > We are running some old routers on 5.8 and some new on 6.4. We appreciate
> > > that we need to upgrade the 5.8 routers but we are keen to stabalise
> > things
> > > first.
> > >
> > > Having looked at the source, we can see the line generating the message:
> > >
> > > case NBR_STA_FULL:
> > > if (dd_hdr.bits & OSPF_DBD_I ||
> > > !(dd_hdr.bits & OSPF_DBD_MS) == !nbr->dd_master) {
> > > log_warnx("recv_db_description: neighbor ID %s: "..
> > >
> > > Could anyone explain the scenario in which this would be expected, so we
> > > can see how to resolve the issue.
> >
> > Please share a pcap file with the OSPF packets. With this we can better
> > understand how this happens and where to look for a bug.
> 
> 
> We will take a look at this. May be difficult to catch due to regularity.
> Every 30 mins or so.

Then just let tcpdump run for a few hours. If you filter for ospf it should
not need too much diskspace. And don't forget to raise the snaplen.

Eg: tcpdump -i em1 -s 1500 -w /tmp/ospf.pcap proto ospf

> 
> >
> > > We run some of our routers under VMware, could some sort of OS pause
> > cause
> > > this?
> >
> > Maybe if the router is not getting all OSPF packets because of this.
> >
> > Remi
> >

Re: openbsd.org down?

[infoomatic]

not reachable for days now in Austria, Germany, Czech Republic


On 13.04.20 11:01, SP2L Tom wrote:
> Greetings.
>
>
> It was and it is still up
> At least, I can reach OpenBSD site.
>
>
> Best regards.
> Tom
>
> W 13 kwietnia 2020 10:23:18 Sebastien Marie  napisał:
>
>> On Mon, Apr 13, 2020 at 10:14:00AM +0300, Ilya Mitrukov wrote:
>>> Hi,
>>> flushing the caches doesn't help and it's still unavailable.
>>>
>>> Does anybody know where to report the issue?
>>> (I'd look at openbsd.org but ... )
>>
>> I suppose there is one or two openbsd developers which follow this
>> list. So they
>> might already know.
>>
>> Thanks.
>> --
>> Sebastien Marie
>
>
>

Re: OSPF seems to stops processing updates

[Remi Locherer]

forgot to add misc@ ...

On Mon, Apr 13, 2020 at 11:18:17AM +0200, Remi Locherer wrote:
> Hi Richard,
> 
> On Mon, Apr 13, 2020 at 08:38:31AM +0100, Richard Chivers wrote:
> > We have been having a strange issue, whereby OSPF stops updating properly.
> > 
> > We can see an entry for an ip route in the database but it is not in the
> > kernel routing table, and when it is the DR, other routers then do not have
> > the route at all.
> > 
> > We are seeing this across multiple boxes. We have 10+ ospf speakers, and
> > seem to see the issue at different times.
> > 
> > The problem starts with:
> > 
> > ospfd[6960]: recv_db_description: neighbor ID x.x.x.x: seq num mismatch,
> > bad flags
> 
> The neighbor sent a db desc with the master flag set differently than what
> this ospfd instance recorded before for that particular neighbor.
> 
> See 2nd last item on page 100 of RFC 2328:
> https://tools.ietf.org/html/rfc2328#page-100
> 
> > ospfd[30114]: lsa_check: bad age
> > 
> > And these just then continue, until we restart ospfd, and the problem
> > appears to go away.
> 
> Is the neighbor also OpenBSD ospfd or something else?
> 
> > 
> > We are running some old routers on 5.8 and some new on 6.4. We appreciate
> > that we need to upgrade the 5.8 routers but we are keen to stabalise things
> > first.
> > 
> > Having looked at the source, we can see the line generating the message:
> > 
> > case NBR_STA_FULL:
> > if (dd_hdr.bits & OSPF_DBD_I ||
> > !(dd_hdr.bits & OSPF_DBD_MS) == !nbr->dd_master) {
> > log_warnx("recv_db_description: neighbor ID %s: "..
> > 
> > Could anyone explain the scenario in which this would be expected, so we
> > can see how to resolve the issue.
> 
> Please share a pcap file with the OSPF packets. With this we can better
> understand how this happens and where to look for a bug.
> 
> > 
> > We run some of our routers under VMware, could some sort of OS pause cause
> > this?
> 
> Maybe if the router is not getting all OSPF packets because of this.
> 
> Remi

Re: openbsd.org down?

[SP2L Tom]

Greetings.


It was and it is still up
At least, I can reach OpenBSD site.


Best regards.
Tom

W 13 kwietnia 2020 10:23:18 Sebastien Marie  napisał:


On Mon, Apr 13, 2020 at 10:14:00AM +0300, Ilya Mitrukov wrote:

Hi,
flushing the caches doesn't help and it's still unavailable.

Does anybody know where to report the issue?
(I'd look at openbsd.org but ... )


I suppose there is one or two openbsd developers which follow this list. So 
they

might already know.

Thanks.
--
Sebastien Marie

Re: openbsd.org down?

[STeve Andre']

The proper people know already.  It's useless to make
further comments.  --STeve Andre'

On Apr 13, 2020, 03:14, at 03:14, Ilya Mitrukov  wrote:
>Hi,
>flushing the caches doesn't help and it's still unavailable.
>
>Does anybody know where to report the issue?
>(I'd look at openbsd.org but ... )
>
>- Ilya
>
>On 2020-04-13 05:00, zeurk...@volny.cz wrote:
>> "Durial EB"  wrote:
>>> Still down for me.
>> Appears intermittent. Cc'ing webmaster@ (assuming it exists).
>>
>>  --zeurkous.
>>
>>> On Sun, Apr 12, 2020 at 5:44 PM  wrote:
>>>
> Hello.
>
> What happened to the openbsd.org?
> I seems to be down for 10+ hours for now.
 WFM. Empty your name swerver cache, it might help.

> Regards,
>
> Roman
 --zeur.

 --
 Friggin' Machines!

Re: openbsd.org down?

[Sebastien Marie]

On Mon, Apr 13, 2020 at 10:14:00AM +0300, Ilya Mitrukov wrote:
> Hi,
> flushing the caches doesn't help and it's still unavailable.
> 
> Does anybody know where to report the issue?
> (I'd look at openbsd.org but ... )
> 

I suppose there is one or two openbsd developers which follow this list. So they
might already know.

Thanks.
-- 
Sebastien Marie

Re: Iridium vs Chromium

[Stuart Henderson]

On 2020-04-12, Allan Streib  wrote:
> Patrick Harper  writes:
>
>> My understanding of -current is that it is meant for testing, not usage.
>
> Not strictly true. Depends on your needs, and tolerance for things not
> always working perfectly.

Things *should* work just as well in -current as -stable, it's just that
you will often need to update the whole system/packages before you can
install some new package otherwise you end up with a broken mixture of
old+new.

If that is not a problem then it absolutely is suitable.for real usage.
And in the cases where a new problem is accidentally introduced - that
problem is going to end up in a release if theee is nobody running
-current who finds it.

OSPF seems to stops processing updates

[Richard Chivers]

We have been having a strange issue, whereby OSPF stops updating properly.

We can see an entry for an ip route in the database but it is not in the
kernel routing table, and when it is the DR, other routers then do not have
the route at all.

We are seeing this across multiple boxes. We have 10+ ospf speakers, and
seem to see the issue at different times.

The problem starts with:

ospfd[6960]: recv_db_description: neighbor ID x.x.x.x: seq num mismatch,
bad flags
ospfd[30114]: lsa_check: bad age

And these just then continue, until we restart ospfd, and the problem
appears to go away.

We are running some old routers on 5.8 and some new on 6.4. We appreciate
that we need to upgrade the 5.8 routers but we are keen to stabalise things
first.

Having looked at the source, we can see the line generating the message:

case NBR_STA_FULL:
if (dd_hdr.bits & OSPF_DBD_I ||
!(dd_hdr.bits & OSPF_DBD_MS) == !nbr->dd_master) {
log_warnx("recv_db_description: neighbor ID %s: "..

Could anyone explain the scenario in which this would be expected, so we
can see how to resolve the issue.

We run some of our routers under VMware, could some sort of OS pause cause
this?

Thanks

Richard

Re: openbsd.org down?

[Ilya Mitrukov]

Hi,
flushing the caches doesn't help and it's still unavailable.

Does anybody know where to report the issue?
(I'd look at openbsd.org but ... )

- Ilya

On 2020-04-13 05:00, zeurk...@volny.cz wrote:
> "Durial EB"  wrote:
>> Still down for me.
> Appears intermittent. Cc'ing webmaster@ (assuming it exists).
>
>  --zeurkous.
>
>> On Sun, Apr 12, 2020 at 5:44 PM  wrote:
>>
 Hello.

 What happened to the openbsd.org?
 I seems to be down for 10+ hours for now.
>>> WFM. Empty your name swerver cache, it might help.
>>>
 Regards,

 Roman
>>> --zeur.
>>>
>>> -- 
>>> Friggin' Machines!