Re: bug tracking system for OpenBSD
Agreed, partially, with both of you. It may be possible to automatically filter some of the chaff (user errors and support requests in disguise) in one large batch so to pressed the DB but forwarding mailing list touches to the bug tracker would make things ugly fast. What would be involved to pull the current state of bugs@ and tech@? > On Dec 25, 2017, at 12:21, Stuart Henderson wrote: > >> On 2017-12-23, Kapetanakis Giannis wrote: >>> On 23/12/17 12:24, Stuart Henderson wrote: >>> Forwarded? No way! Same for bugs@ as tech@. It needs manual work to >>> triage, identify what is a bug, follow up with the reporter to make >>> sure the report is accurate and has enough information to be useful. >>> Same whatever the entry point is. If reporters can add bugs to it >>> directly, they need to go into a triage queue and *not* appear in the >>> main system until that's done. >>> >>> The idea of a bug tracking system is to spread the work and help >>> people remember things. It should *reduce* work done by devs because >>> they no longer have to drag even the most basic information out >>> of a reporter and figure out whether it's a bug or user error >>> or a support request in disguise. >>> >>> If it means *extra* work for devs, it's not going to work. >>> >>> >> >> I still don't agree with you about maintaining both @tech/@bugs in >> correlation with a web interface (bugtracking). >> Not a gain, just extra trouble. > > Probably not long term, but looking at existing unfixed bug reports on > lists would be a good way to seed the database. And information spread > across multiple mails can be synthesized into a coherent report, > hopefully going some way to showing others what a proper bug > submission should actually look like. > >> What happens in other places is that if a mail comes that looks like a >> possible ticket (not resolvable by mail), someone replies and says >> "please open bug report in https://..."; >> so we can track it. >> However you 're right with the last paragraph above and it's something I >> haven't thought before. >> More people might get involved and eventually this might get some work >> out of the devs. > >
Re: Reboot trouble with APU2
On 25.12.2017 12:04, Christer Solskogen wrote: All of a sudden, whenever I reboot my APU2 (this does not happen on my APU1) - it stops. OpenBSD reboots successfully, but as soon as it boots up (I can see the bios menu on the serial console) it just stops. I can not see the OpenBSD boot loader. This started happening approx 2 weeks ago, so it might be that my hardware is failing. Or it might be a OpenBSD problem. Power cycling the device "fixes" the issue. As in, I can boot normally. No other problems, apparently. I've been running on snapshots (amd64) Normally I only reboot it when upgrading to a newer snapshot, and at first I suspected it was installboot that was causing it. Just now I tried upgrading it chose /not/ to run installboot. Still same problem, so installboot was just a red herring. What can I do to help investigate this futher? For what it's worth, I encountered this issue on the APU2 while using certain kinds of USB Flash Drives. Anything other than a Kingston Datatraveler would cause the APU to hang. I just replaced the USB drive in one case, and vaguely recall updating the board's coreboot to the latest version also helped in at least one other. It was a while ago now, but something to do with changing the boot order not saving, so it would never try anything other than USB first if connected.
Re: DUMP: Invalid argument: [block -25232932859]
On Mon, Dec 25, 2017 at 11:48:22AM +0100, Jan Stary wrote:
> This is current/amd64. The nightly dump (full mail and daily.local
> and df -hi at the bottom) reports a lot of errors such as
>
> read error from /dev/rsd2a: Invalid argument: [block -25232932862]:
> count=10240
>
> Obviously, there is no block -25232932862, but dump(8) must mean
> some certain block by that, if it knows the count.
> Is this simply an overflow in the (traverse.c)
>
>msg("read error from %s: %s: [block %lld]: count=%d\n",
> disk, strerror(errno), (long long)blkno, size);
>
> or the previous pread()? The disk seems to be working just fine,
> and a complete dd read of sd2c reports no errors:
>
> sd2:
> 3815602+1 records in
> 3815602+1 records out
> 250059350016 bytes transferred in 46028.063 secs (5432758 bytes/sec)
I would start with unmounting the filesystem and doing a (forced) fsck
to see if your filesystem is corrupted.
-Otto
Re: bug tracking system for OpenBSD
On 2017-12-23, Kapetanakis Giannis wrote: > On 23/12/17 12:24, Stuart Henderson wrote: >> Forwarded? No way! Same for bugs@ as tech@. It needs manual work to >> triage, identify what is a bug, follow up with the reporter to make >> sure the report is accurate and has enough information to be useful. >> Same whatever the entry point is. If reporters can add bugs to it >> directly, they need to go into a triage queue and *not* appear in the >> main system until that's done. >> >> The idea of a bug tracking system is to spread the work and help >> people remember things. It should *reduce* work done by devs because >> they no longer have to drag even the most basic information out >> of a reporter and figure out whether it's a bug or user error >> or a support request in disguise. >> >> If it means *extra* work for devs, it's not going to work. >> >> > > I still don't agree with you about maintaining both @tech/@bugs in > correlation with a web interface (bugtracking). > Not a gain, just extra trouble. Probably not long term, but looking at existing unfixed bug reports on lists would be a good way to seed the database. And information spread across multiple mails can be synthesized into a coherent report, hopefully going some way to showing others what a proper bug submission should actually look like. > What happens in other places is that if a mail comes that looks like a > possible ticket (not resolvable by mail), someone replies and says > "please open bug report in https://..."; > so we can track it. > However you 're right with the last paragraph above and it's something I > haven't thought before. > More people might get involved and eventually this might get some work > out of the devs.
Reboot trouble with APU2
All of a sudden, whenever I reboot my APU2 (this does not happen on my APU1) - it stops. OpenBSD reboots successfully, but as soon as it boots up (I can see the bios menu on the serial console) it just stops. I can not see the OpenBSD boot loader. This started happening approx 2 weeks ago, so it might be that my hardware is failing. Or it might be a OpenBSD problem. Power cycling the device "fixes" the issue. As in, I can boot normally. No other problems, apparently. I've been running on snapshots (amd64) Normally I only reboot it when upgrading to a newer snapshot, and at first I suspected it was installboot that was causing it. Just now I tried upgrading it chose /not/ to run installboot. Still same problem, so installboot was just a red herring. What can I do to help investigate this futher?
Re: relayd stops processing traffic intermittently
> On 24 Dec 2017, at 19:07, Claudio Jeker wrote:
> On Sat, Dec 23, 2017 at 02:04:19PM +0100, Mischa Peters wrote:
>>> On 23 Dec 2017, at 13:08, Claudio Jeker wrote:
On Sat, Dec 23, 2017 at 11:40:57AM +0100, Mischa wrote:
Hi All,
Since OpenBSD 6.2, just confirmed this in the latest snapshot
(GENERIC.MP#305) as well, for some reason relayd stops processing traffic
and starts flooding the log file with the following message:
Dec 23 11:19:11 lb2 relayd[22515]: rsae_send_imsg: poll timeout
Dec 23 11:19:12 lb2 relayd[52110]: rsae_send_imsg: poll timeout
Dec 23 11:19:12 lb2 relayd[69641]: rsae_send_imsg: poll timeout
Dec 23 11:19:12 lb2 relayd[22515]: rsae_send_imsg: poll timeout
[snip]
Dec 23 11:19:17 lb2 relayd[69641]: rsae_send_imsg: poll timeout
Dec 23 11:19:18 lb2 relayd[22515]: rsae_send_imsg: poll timeout
Dec 23 11:19:18 lb2 relayd[52110]: rsae_send_imsg: poll timeout
Dec 23 11:19:18 lb2 relayd[69641]: rsae_send_imsg: poll timeout
...etc...
Restarting the daemon "fixes" the problem.
Not sure how to trouble shoot this but I am able to reproduce this
consistently by pointing SSLLabs towards relayd.
Would be great to get some pointers.
>>>
>>> I have seen this as well on our production systems. This is a problem in
>>> the privsep part of the TLS code. I could not do more testing yet but my
>>> assumption is that a new option / feature is freaking this code out.
>>
>> Anything I can do or collect to give you more information?
>
> So, I think I found the problem. The ca process did not handle errors from
> RSA_private_encrypt correctly. So once you got a bad signature in the
> system chocked and stopped. This diff seems to work for me (against
> SSLlabs).
Awesome! Can confirm that it continues processing traffic when hitting it with
sslabs.
Will also move it to a more bussier machine to see how that handles.
I am seeing the following messages now:
Dec 25 15:51:07 lb2 relayd[7541]: ca_dispatch_relay: error:04FFF06B:rsa
routines:CRYPTO_internal:block type is not 02
Dec 25 15:51:08 lb2 relayd[27420]: ca_dispatch_relay: error:04FFF071:rsa
routines:CRYPTO_internal:null before block missing
Dec 25 15:51:17 lb2 relayd[7541]: ca_dispatch_relay: error:04FFF072:rsa
routines:CRYPTO_internal:padding check failed
Dec 25 15:51:33 lb2 relayd[73631]: ca_dispatch_relay: error:04FFF071:rsa
routines:CRYPTO_internal:null before block missing
Mischa
>
> Cheers
> --
> :wq Claudio
>
> Index: ca.c
> ===
> RCS file: /cvs/src/usr.sbin/relayd/ca.c,v
> retrieving revision 1.31
> diff -u -p -r1.31 ca.c
> --- ca.c 28 Nov 2017 00:20:23 - 1.31
> +++ ca.c 24 Dec 2017 18:01:20 -
> @@ -266,9 +266,15 @@ ca_dispatch_relay(int fd, struct privsep
> break;
> }
>
> + if (cko.cko_tlen == -1) {
> + char buf[256];
> + log_warnx("%s: %s", __func__,
> + ERR_error_string(ERR_get_error(), buf));
> + }
> +
> iov[c].iov_base = &cko;
> iov[c++].iov_len = sizeof(cko);
> - if (cko.cko_tlen) {
> + if (cko.cko_tlen > 0) {
> iov[c].iov_base = to;
> iov[c++].iov_len = cko.cko_tlen;
> }
> @@ -381,12 +387,12 @@ rsae_send_imsg(int flen, const u_char *f
>
> IMSG_SIZE_CHECK(&imsg, (&cko));
> memcpy(&cko, imsg.data, sizeof(cko));
> - if (IMSG_DATA_SIZE(&imsg) !=
> - (sizeof(cko) + cko.cko_tlen))
> - fatalx("data size");
>
> ret = cko.cko_tlen;
> - if (ret) {
> + if (ret > 0) {
> + if (IMSG_DATA_SIZE(&imsg) !=
> + (sizeof(cko) + ret))
> + fatalx("data size");
> toptr = (u_char *)imsg.data + sizeof(cko);
> memcpy(to, toptr, ret);
> }
>
Re: ssh from cisco to OpenBSD 6.2 error status 0
On 12/25/17 11:13, Marko Cupać wrote: > Hi, > > I noticed I can't ssh from cisco router running IOS 15.X to OpenBSD > 6.2. No problem with 6.1. > > Anyone else with this problem? Any idea how to solve it or where to > start digging? I'd start by looking for messages in /var/log/authlog on the OpenBSD machine, and if possible running with ssh -v or -vv (I forget how many you can usefully put in, or if the Cisco boxes even use the same options) to get more detail on what happens. My hunch is that you will be looking at resolving a gap in ciphers offered as available at either end. Newer ssh versions have incrementally dropped or disabled by default the unsafe ones, but increasing the message verbosity will point you in the right direction. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: OpenBSD 6.2 (up2date with syspatch) - HANGING
On Fri, 22 Dec 2017 13:43:35 +0100 Florian Obser wrote: > Yes, quite a lot of effort and money (think travel cost to hackathons) > was spent by developers between 5.9 and 6.2 releases. > You are welcome. Somehow I have the impression that most of the OpenBSD code wasn't written in fancy guest facilities where priesthood arrives and departs by means of business class flights to churn out some lines of code. The time when it wasn't all about MONEY. But yeah, we have to embrace modern times and not hold on to the past. Still, OpenBSD is the best :) -- Before enlightenment - chop wood, draw water. After enlightenment - chop wood, draw water. Marko Cupać https://www.mimar.rs/
Re: bug tracking system for OpenBSD
While not exactly bug tracker, more like general-purpose issue tracker, I have successfully implemented rt44 in a company I work for: [https://docs.bestpractical.com/rt/4.4.2/README.html] The reason why I succeeded with rt44, and failed with other, shinier trackers with more bells and whistles, is its integration with email. All of my users want single email address where they can report issues. Some of my colleagues in IT want to continue using email-only correspondence while dealing with users' issues, while others prefer to use additional features in rt44's web interface. All of them can have their way with rt. No one was forced to something new, something different. Email-only is still there, with the addition of web interface for those who want/like it. If OpenBSD people are interested, I can provide complete rt44-based solution directly from my servers, or I can help building and integrating it on some other hardware. Regards, -- Before enlightenment - chop wood, draw water. After enlightenment - chop wood, draw water. Marko Cupać https://www.mimar.rs/
ssh from cisco to OpenBSD 6.2 error status 0
Hi, I noticed I can't ssh from cisco router running IOS 15.X to OpenBSD 6.2. No problem with 6.1. Anyone else with this problem? Any idea how to solve it or where to start digging? Thank you in advance, -- Before enlightenment - chop wood, draw water. After enlightenment - chop wood, draw water. Marko Cupać https://www.mimar.rs/
