Lighttpd

Please try 'strace' on that test to see what system call is actually being made. My guess is that lighttpd is calling accept4() (not a typo) and there is a library stub for accept4() but it is not implemented in your kernel. If that is the case, it might work for you if I provide a patch that falls back to accept() if accept4() returns -1 with errno == ENOSYS

Thanks - output from strace. First couple of lines are at idle followed by the attempt to connect. The last four lines just keep repeating. Kernel is at 2.6.30 which I doubt we could change.

I did try updating to 1.4.41 and that worked without issues so somewhere between 41 and 48 we have an issue with our board. 41 looks to be the last version with security updates.

Mike

gettimeofday({tv_sec=1518643068, tv_usec=647464}, NULL) = 0
epoll_wait(5, [], 1025, 1000)           = 0
gettimeofday({tv_sec=1518643069, tv_usec=646620}, NULL) = 0
epoll_wait(5, [], 1025, 1000)           = 0
gettimeofday({tv_sec=1518643070, tv_usec=643809}, NULL) = 0
epoll_wait(5, [], 1025, 1000)           = 0
gettimeofday({tv_sec=1518643071, tv_usec=647723}, NULL) = 0
epoll_wait(5, [], 1025, 1000)           = 0
gettimeofday({tv_sec=1518643072, tv_usec=646632}, NULL) = 0
epoll_wait(5, [{EPOLLIN, {u32=3, u64=3}}], 1025, 1000) = 1
gettimeofday({tv_sec=1518643072, tv_usec=670815}, NULL) = 0
send(4, "<27>Feb 14 15:17:52 lighttpd[954"..., 98, MSG_NOSIGNAL) = 98
gettimeofday({tv_sec=1518643072, tv_usec=677722}, NULL) = 0
epoll_wait(5, [{EPOLLIN, {u32=3, u64=3}}], 1025, 1000) = 1
gettimeofday({tv_sec=1518643072, tv_usec=679544}, NULL) = 0
send(4, "<27>Feb 14 15:17:52 lighttpd[954"..., 98, MSG_NOSIGNAL) = 98
gettimeofday({tv_sec=1518643072, tv_usec=681833}, NULL) = 0
epoll_wait(5, [{EPOLLIN, {u32=3, u64=3}}], 1025, 1000) = 1
gettimeofday({tv_sec=1518643072, tv_usec=683839}, NULL) = 0
send(4, "<27>Feb 14 15:17:52 lighttpd[954"..., 98, MSG_NOSIGNAL) = 98
gettimeofday({tv_sec=1518643072, tv_usec=686119}, NULL) = 0
epoll_wait(5, [{EPOLLIN, {u32=3, u64=3}}], 1025, 1000) = 1
gettimeofday({tv_sec=1518643072, tv_usec=687834}, NULL) = 0
send(4, "<27>Feb 14 15:17:52 lighttpd[954"..., 98, MSG_NOSIGNAL) = 98
gettimeofday({tv_sec=1518643072, tv_usec=690095}, NULL) = 0
epoll_wait(5, [{EPOLLIN, {u32=3, u64=3}}], 1025, 1000) = 1
gettimeofday({tv_sec=1518643072, tv_usec=691800}, NULL) = 0

That looks like your client, not the lighttpd server. Please strace the lighttpd process. If you have multiple lighttpd workers, please comment that out of your config and run and strace a single lighttpd process.

Also, your kernel, as you seem to know, is quite ancient. If the strace shows that accept4() is not implemented, then you'll have to modify the lighttpd code to avoid accept4().

If accept4 is just implemented as stub in libc you won't see it in the strace. The strace looks valid to me; epoll wakes up on always the same fd (3), tries to call accept4, fails, sends a message to syslog, goes back to epoll.

That should be the server. I ran the following from a command line:

strace lighttpd -Df /etc/lighttpd.conf

Thank you for the feedback; I at least have a place to start. Due to time constraints, I will update to 1.4.41 for now and work on either updating the kernel or looking at patching the server source as time permits in case we need to update to a newer version for security updates.

I know other threads have been marked [solved] but it may be a bit before I can dig into it. What should it be marked as?

If I do find a solution I will update and attach any patches used.

Mike

Untested patch for lighttpd 1.4.48 for your obscenely old kernel.

--- a/src/fdevent.c
+++ b/src/fdevent.c
@@ -568,6 +568,12 @@ int fdevent_accept_listenfd(int listenfd, struct sockaddr *addr, size_t *addrlen
        fd = (use_sock_cloexec)
          ? accept4(listenfd, addr, &len, SOCK_CLOEXEC | SOCK_NONBLOCK)
          : accept(listenfd, addr, &len);
+       if (fd < 0 && errno == ENOSYS) { /* && use_sock_cloexec */
+               fd = accept(listenfd, addr, &len);
+               if (fd >= 0) {
+                       force_assert(-1 != fdevent_fcntl_set_nb_cloexec(NULL, fd));
+               }
+       }
        #endif
       #else
        fd = accept(listenfd, addr, &len);

You talk about security updates in lighttpd, and you probably haven't read the lighttpd changelogs. Then again, if you're interested in security, you also shouldn't be running such an old kernel. Linux 2.6.30 was released on the 9th of June, 2009.
https://www.cvedetails.com/vulnerability-list.php?vendor_id=33&product_id=47&version_id=91559&page=1&hasexp=0&opdos=0&opec=0&opov=0&opcsrf=0&opgpriv=0&opsqli=0&opxss=0&opdirt=0&opmemc=0&ophttprs=0&opbyp=0&opfileinc=0&opginf=0&cvssscoremin=0&cvssscoremax=0&year=0&month=0&cweid=0&order=1&trc=230&sha=06eff2748331fd6c08901f4ed1b51ff62c1d0852

I am going to mark this "[Solved]" since a probable workaround has been provided, and the real answer is "don't do that", i.e. don't run such an obscenely old kernel and even suggest that you are secure.

Thank you for the patch and the link.

Points well taken. Updating the kernel would be difficult due to the age of the hardware involved.

Difficult should never be used as an excuse though and I will see what can be done about getting the kernel updated.

Mike