Re: Crash when unplugging a UPS USB connection
I apologise for not following up. I relocated my UPS and a Pi is acting as the NUT server now, running several devices. As a result I am unable to easily connect my main OpenBSD desktop to test. However I am setting up another machine and will have a chance to test the fix soon. I am still running upsmon on my desktop which is working fine but this is just the net client. Thanks to everyone for the rapid fix, and in particular sthen@ for his prompt and helpful responses. Regards, Anindya
Re: LMTP dovecot timeout when sieve's run script
On 2021-08-06, pas...@pascallen.nl wrote: > --=-auHtfLlFC+dDT6m6OqcT > Content-Type: text/plain; charset="UTF-8" > Content-Transfer-Encoding: 7bit > > Hallo, > > > Dovecot lmtp is timing out when running a script started from sieve. > This happens when emails are to big. Have attachments that are to big. > > How can I change the time out? https://doc.dovecot.org/configuration_manual/sieve/plugins/extprograms/
LMTP dovecot timeout when sieve's run script
Hallo,
Dovecot lmtp is timing out when running a script started from sieve.
This happens when emails are to big. Have attachments that are to big.
How can I change the time out?
Output:
Jul 1 13:28:55 router dovecot: lmtp(pas...@pascallen.nl)<90734>: Error: program
exec:/usr/local/lib/dovecot/sieve/gpgit.pl (93645): Execution timed
out (> 1 msecs)
Jul 1 13:28:56 router dovecot: lmtp(pas...@pascallen.nl)<90734>: Error: program
exec:/usr/local/lib/dovecot/sieve/gpgit.pl (93645): Forcibly
terminated with signal 15
Jul 1 13:28:56 router dovecot: lmtp(pas...@pascallen.nl)<90734>: Panic: output stream (temp iostream in
/tmp/dovecot.lmtp. for (program client seekable output)) is missing
error handling
Jul 1 13:28:56 router dovecot:
lmtp(pas...@pascallen.nl)<90734>: Fatal:
master: service(lmtp): child 90734 killed with signal 6 (core not
dumped - https://dovecot.org/bugreport.html#coredumps - set service
lmtp { drop_priv_before_exec=yes })
--
Met vriendelijke groet,
Pascal Huisman
Penn's aunts made great apple pies at low prices. No one else in
town could compete with the pie rates of Penn's aunts.
signature.asc
Description: This is a digitally signed message part
Minimum RAM for Chrome
I've got a spare laptop that I use for web browsing. Since it only has
4GB RAM, OpenBSD seemed a good fit for it.
However Chrome is extremely slow. I've increased system resource limits
as mentioned in the email list archives, but that didn't resolve the
issue.
If I turn off video acceleration blacklisting in Chrome, videos play
faster but starting the browser takes ages and sometimes fails entirely.
Regardless, there is still lots of lag when loading pages.
Am I running into system memory limits ("minimum 8GB RAM to surf the
web"? what is the world coming to?) or is another issue likely the
cause?
Re: 50Gbe
Also SFP28 ports are backwards compatible with SFP+ optics. On Fri, Aug 6, 2021 at 9:12 PM Joel Wirāmu Pauling wrote: > SFP28 (25gbit) is the way to go for density on x86 as it matches CPU > bound bus architecture well. QSFP28 to 4*SFP28 offers the best price per > port density both for interconnects (the DAC TwinAX 'squid' cables are > cheap as chips) > > Network Stack Throughput through CPU on modern Intel x86 _64 even on perf > tuned OS's tops out around 40Gbit locally so 50gbit ports don't make a lot > of sence bar for specific use cases. Going faster means SmartNIC offloads, > which are fine for certain use cases or if you just want to push packets > without doing anything with them (i.e NIC to NVME etc, or switching). > > On Fri, Aug 6, 2021 at 7:33 PM Stuart Henderson > wrote: > >> On 2021-08-06, ha...@sdf.org wrote: >> >> Hi folks! >> >> >> >> I wonder if OBSD supports 50Gbe network cards. And what is the cable >> >> standard to support such data transfers ? >> >> >> >> Thanks. >> >> >> >> -- >> >> The lion and the tiger may be more powerful, but the wolves do not >> perform >> >> in the circus >> > >> > $ apropos 50gb >> > bnxt(4) - Broadcom NetXtreme-C/E 10/25/40/50Gb Ethernet device >> > >> > https://man.openbsd.org/bnxt.4 >> > >> > >> >> Cable is usually single-mode fibre (duplex or simplex depending on which >> QSFP28 you use) or twinax DACs. There might also be some using multimode >> MTP cables but if there are, they're less common. >> >> Don't expect to get anywhere close to line rate with OpenBSD. >> >> >>
Re: 50Gbe
SFP28 (25gbit) is the way to go for density on x86 as it matches CPU bound bus architecture well. QSFP28 to 4*SFP28 offers the best price per port density both for interconnects (the DAC TwinAX 'squid' cables are cheap as chips) Network Stack Throughput through CPU on modern Intel x86 _64 even on perf tuned OS's tops out around 40Gbit locally so 50gbit ports don't make a lot of sence bar for specific use cases. Going faster means SmartNIC offloads, which are fine for certain use cases or if you just want to push packets without doing anything with them (i.e NIC to NVME etc, or switching). On Fri, Aug 6, 2021 at 7:33 PM Stuart Henderson wrote: > On 2021-08-06, ha...@sdf.org wrote: > >> Hi folks! > >> > >> I wonder if OBSD supports 50Gbe network cards. And what is the cable > >> standard to support such data transfers ? > >> > >> Thanks. > >> > >> -- > >> The lion and the tiger may be more powerful, but the wolves do not > perform > >> in the circus > > > > $ apropos 50gb > > bnxt(4) - Broadcom NetXtreme-C/E 10/25/40/50Gb Ethernet device > > > > https://man.openbsd.org/bnxt.4 > > > > > > Cable is usually single-mode fibre (duplex or simplex depending on which > QSFP28 you use) or twinax DACs. There might also be some using multimode > MTP cables but if there are, they're less common. > > Don't expect to get anywhere close to line rate with OpenBSD. > > >
Re: How to troubleshoot DHCP issues?
hopefully copying to bugs@ (if I remember how to do that correctly from slrn/gmane..) Please keep that in CC's when replying. Earlier misc@ mail copied in below to keep things together in one place. On 2021-08-06, beebeet...@posteo.de wrote: > > My first suggestion might be to stay with a single lladdr for a > > while to see if your setup works for more than a day and a half. > > Thanks for the suggestion! > It seems that with `lladdr random` removed, the problem does not > seem to disappear. On 2021-08-06, beebeet...@posteo.de wrote: > Sorry, there was a typo: The problem *does disappear* with > `lladdr random` removed . Good, so you have a workaround for now. lladdr random >>> >>> Why this line? >> >> I was wondering the same thing. What problem do you think you are >> solving by doing this? > > I try to make it harder for my ISP to gather information about the > device I'm using, thus was using random MAC address. > > > > The "random" lladdr catches my eye. But I don't know how > > frequently that changes. Could it change every time the lease > > is renewed? > > Skimming through the code for dhcpleased, looks like there's no > invocation of the SIOCSIFLLADDR ioctl, so I would assume that the > lladdr stays the same unless the netstart script is re-run (thus > invoking ifconfig to change lladdr), but I will to test that to > make sure. > > It smells of a bug somewhere... I mean, as long as the lladdr does > not change in the middle of the lease, then the router should have > been able to successfully obtain a new IP address, right? It only changes when "ifconfig $_iface lladdr random" is actually called, i.e. normally just when the interface is configured at boot, unless you re-run netstart. I don't think it will be a problem of using a random lladdr in particular but more likely if the MAC address is changed at all. One area that might be implicated is the hardware address filters which need to be reprogrammed by the driver when the address is changed. Though the fact that it happens with at least ure, bse, axe makes me think that it might be some other issue. I'm still pondering the fact that you don't see incoming packets even when tcpdump is running, as (unless you used tcpdump -p) that would set the nic in promiscuous mode.. On 2021-08-03, beebeet...@posteo.de wrote: > Can anyone offer some suggestions on what I can do to nail down > the issue? > > Below are some of the observations I've made so far: > > - Doesn't matter whether I'm using dhclient of dhcpleased, same >issue. > > - When it stops working, tcpdump still shows outgoing packets, >checksums all OK, but no incoming packets. > > - `dhcpleasectl show interface ` shows that there is still >one day before the lease expires. > > - When this first happens, `arp -a` shows that the link layer >address of the gateway is still in the ARP table. But of course >it will expire after some time, and the router won't be able to >obtain the link layer address of the gateway again after that. > > - The `netstat -R` still shows the IP address of the gateway. > > - My ISP would offer a few short leases at first, and then offer a >two day lease. This issue seems always to occur around half way >of the two day lease period. > > - I tried several interface cards with drivers including axen, ure, >axe, bse. axen dies every 10-20 min, outputing some watchdog >timeout error; ure has the same issue described here, but throws >some rx/tx error to dmesg in addition; bse and axe doesn't seem >to output any errors, but both have the issue described here. > > - The issue doesn't occur when the IP address is statically >assigned. > > - Didn't experience this problem when I was running Linux on the >same machine (raspberry pi 4B).
Re: 50Gbe
On 2021-08-06, ha...@sdf.org wrote: >> Hi folks! >> >> I wonder if OBSD supports 50Gbe network cards. And what is the cable >> standard to support such data transfers ? >> >> Thanks. >> >> -- >> The lion and the tiger may be more powerful, but the wolves do not perform >> in the circus > > $ apropos 50gb > bnxt(4) - Broadcom NetXtreme-C/E 10/25/40/50Gb Ethernet device > > https://man.openbsd.org/bnxt.4 > > Cable is usually single-mode fibre (duplex or simplex depending on which QSFP28 you use) or twinax DACs. There might also be some using multimode MTP cables but if there are, they're less common. Don't expect to get anywhere close to line rate with OpenBSD.
