Re: Fix for USB keyboards eating keys, a DDB story
On 5/10/17 5:19 PM, Hrvoje Popovski wrote: > On 10.5.2017. 15:22, Martin Pieuchot wrote: >> This big hammer of delaying every input via a timeout introduced a nasty >> side effect. Since only one element can be queued, we can lose inputs >> if the keyboard is too fast. >> >> Here are some bug reports: >> >> https://marc.info/?l=openbsd-bugs=147284987417838=2 >> https://marc.info/?l=openbsd-tech=142082432912041=1 > > > Hi all, > > i've applied this patch on boxes below and remote virtual console no > longer lose their characters: > > Dell R620 - iDRAC7 > Dell R630 - iDRAC8 > Supermicro 1018R-WR - iKVM > IBM x3550M4 - IMM2 - was working and working after patch > > i don't have HP ILO console to test on... > > mpi many thanks for this patch, it's a lifesaver > Thank you, it works on a R330 too!
DDB causing lost keystrokes on Dell iDRAC console (not inside ddb)
Hello, I have a few Dell servers which I've installed OpenBSD for testing but ran into a problem with keystroke loss on the console when used through the Dell iDRAC remote graphical console. Surprisingly it operates perfectly fine in the installer (thankfully) but when booted from a formal install, I lose 25-50% of my keystrokes. The speed that I type does not matter, the keys I type do not matter, they are randomly lost. This is any typing, for example at the login prompt (where it becomes very difficult to login). Example: login: Tisis metypingat he onole should have shown: This is me typing at the console I was able to determine having "option DDB" in the kernel is a single factor leading to keystroke loss. If I recompile the GENERIC amd64 5.8 kernel without DDB, I have no keystroke loss. Also, if I enter DDB while the kernel is running, I have no keystroke loss. I have noticed this issue on 5.8 release, a recent 5.9 snapshot, and at least the Dell models R420 and R430. The iDRAC supplies a virtual usb keyboard to the OS. I have not had this issue with other OSes. I should generally be able to perform further tests as requested especially this weekend. Does anyone have suggestions? Can I disable DDB without recompiling? Thanks.
pfctl interprets "# ... \" as multi-line comment and can skip rules
I've been using pf for years and really like it. I accidentally discovered some undesirable behavior from the rule parser that caused some rules to be skipped. This has happened to me twice and there was much hair pulling. The short version is rules starting with # but ending in \ get treated as a multi-line comment instead of a single-line comment and it has the risk of silently ignoring a wanted rule immediately below. This does not match the behavior I'd expect, for example a line starting with # is entirely ignored in /bin/sh: # echo this is a comment \ echo this is not a comment \ or is it? # sh test.sh this is not a comment or is it? But in pf.conf: #pass in on $int_if proto tcp from 1.1.1.1 \ pass in on $int_if proto tcp from 1.2.3.4 \ to any port 12345 # pfctl -f /etc/pf.conf # pfctl -sr | grep 12345 # If you add a line between then: #pass in on $int_if proto tcp from 1.1.1.1 \ pass in on $int_if proto tcp from 1.2.3.4 \ to any port 12345 # pfctl -f /etc/pf.conf # pfctl -sr | grep 12345 pass in on re2 inet proto tcp from 1.2.3.4 to any port = 12345 flags S/SA keep state (if-bound) I try to keep my firewall rules less than 80 chars in case I need to edit them on a dumb terminal. Sometimes I end up duplicating a continued line to make changes to an alternate copy and comment out the original, but if the newly commented out line ends in a backslash, my intended replacement is ignored. I think pfctl should act like sh and ignore a line entirely if it begins with a comment. Thanks for your consideration.
