Hi, I've found the issue! It's way less exiting than it sounded...
On Sun Jun 28, 2026 at 6:44 PM CEST, Philipp wrote:
As a workaround you could move the fcntl for nonblocking at the end of
ldap_open().
I tried to, but the result is still the same
This is strange, because I don't see a path how pfd.events get set
again. It's only set when read() returns EAGAIN and this only happens
on non blocking fds (acording to the docs). Have you forgotten to
rebuild or forgotten to remove the first fcntl?
I had moved it at the end of ldap_connect() instead of ldap_open().
However, delaying the O_NONBLOCK still results in a blocked process.
Adding more logging:
# echo 'config|ready' | ./table-ldap ../ldap_users.conf
table-ldap[70294]: debug: reading key "url" -> "ldap://192.168.122.180";
table-ldap[70294]: debug: reading key "username" ->
"cn=nextcloud,ou=services,dc=pappacoda,dc=it"
table-ldap[70294]: debug: reading key "password" -> "test"
table-ldap[70294]: debug: reading key "basedn" ->
"ou=users,dc=pappacoda,dc=it"
table-ldap[70294]: warn: no service registered
table-ldap[70294]: debug: done reading config
table-ldap[70294]: ldap connect to: 192.168.122.180:389
*** aldap_bind
len 59 class: universal(0) type: sequence(16) encoding 16
len 1 class: universal(0) type: integer(2) encoding 2 value 1
len 54 class: application(1) type: bind(0) encoding 16
len 1 class: universal(0) type: integer(2) encoding 2 value 3
len 43 class: universal(0) type: octet-string(4) encoding 4 string
"cn=nextcloud,ou=services,dc=pappacoda,dc=it"
len 4 class: context(2) type: auth simple(0) encoding 4 string "test"
write ber element of 61 bytes length
table-ldap[70294]: about to read. retry: 0, evbuffer_length: 0
table-ldap[70294]: before read
table-ldap[70294]: after read, ret: 14
table-ldap[70294]: new evbuffer_length: 0
table-ldap[70294]: about to read. retry: 0, evbuffer_length: 0
table-ldap[70294]: before read
Here I noticed that evbuffer_lenght remained 0 even after evbuffer_add,
suggesting something was off with libevent itself.
Indeed, the issue is related with including the event.h header, which is
part of OpenBSD-base and comes from libevent 1. Its EVBUFFER_LENGTH
macro definition does not work with the new evbuffer struct, and somehow
resulted in an always-zero result.
Changing the include to event2/buffer.h and event2/buffer_compat.h fixes
the issue:
# echo 'config|ready' | ./table-ldap ../ldap_users.conf
table-ldap[20252]: debug: reading key "url" -> "ldap://192.168.122.180";
table-ldap[20252]: debug: reading key "username" ->
"cn=nextcloud,ou=services,dc=pappacoda,dc=it"
table-ldap[20252]: debug: reading key "password" -> "test"
table-ldap[20252]: debug: reading key "basedn" ->
"ou=users,dc=pappacoda,dc=it"
table-ldap[20252]: warn: no service registered
table-ldap[20252]: debug: done reading config
table-ldap[20252]: ldap connect to: 192.168.122.180:389
*** aldap_bind
len 59 class: universal(0) type: sequence(16) encoding 16
len 1 class: universal(0) type: integer(2) encoding 2 value 1
len 54 class: application(1) type: bind(0) encoding 16
len 1 class: universal(0) type: integer(2) encoding 2 value 3
len 43 class: universal(0) type: octet-string(4) encoding 4 string
"cn=nextcloud,ou=services,dc=pappacoda,dc=it"
len 4 class: context(2) type: auth simple(0) encoding 4 string "test"
write ber element of 61 bytes length
table-ldap[20252]: about to read. retry: 0, evbuffer_length: 0
table-ldap[20252]: before read
table-ldap[20252]: after read, ret: 14
table-ldap[20252]: new evbuffer_length: 14
read ber elements, root 0xbbfd9d57800
ber read got class 0 type 16, constructed
ber read element size 12
ber read got class 0 type 2, primitive
ber read element size 1
ber read got class 1 type 1, constructed
ber read element size 7
ber read got class 0 type 10, primitive
ber read element size 1
ber read got class 0 type 4, primitive
ber read element size 0
ber read got class 0 type 4, primitive
ber read element size 0
*** message
len 12 class: universal(0) type: sequence(16) encoding 16
len 1 class: universal(0) type: integer(2) encoding 2 value 1
len 7 class: application(1) type: bind(1) encoding 16
len 1 class: universal(0) type: enumerated(10) encoding 10 value 0
len 0 class: universal(0) type: octet-string(4) encoding 4 string ""
len 0 class: universal(0) type: octet-string(4) encoding 4 string ""
table-ldap[20252]: debug: ldap server accepted credentials
table-ldap[20252]: debug: connected
In any case, you can see the code I'm currently working at this branch
that I use to sync code between my host and the VM (yeah I know, it's a
bit overkill): <https://git.sr.ht/~tachi/table-ldap/tree/openbsd-debug>
If you want to have a bit more fun, attach a debugger and set a memory
watchpoint to the pfd struct. It should be only written at line 430.
I tried to, but I think that in my VM setup memory watchpoints don't
work:
(lldb) watchpoint set expression -- &pfd
error: Watchpoint creation failed (addr=0x79908ed90fa0, size=8).
error: Target supports (0) hardware watchpoint slots.
Anyway, as the issue is now fixed, I'll soon submit patches to fix the
OpenBSD issues. Later, I'll polish the K_AUTH support.
Bye!
