Modify

Opened 5 years ago

Last modified 5 years ago

#12357 accepted defect

uhttpd - Connection blocking

Reported by: lcbroich@… Owned by: jow
Priority: response-needed Milestone: Chaos Calmer 15.05
Component: packages Version: Trunk
Keywords: uhttpd blocking Cc:

Description

Hello,

After switching to attitude adjustment / trunk we have the issue that connections seem to be blocked when there are many requests to uhttpd.

We use uhttpd on port 81 for a splash redirect where the user has to accept the usage rules.
We encounter this problem when we have an client connected to the Wifi AP and it tries to send data to the internet. The connections get blocked for all users until a timeout is reached. I think some clients send out many requests at once which may confuse the web server.

The HTTP traffic gets redirected via iptables to the uhttpd server (unless the user has already accepted the rules)

This problem didn't occur with uhttpd version 28 (from backfire)
A downgrade of the package fixes this behaviour. Please investigate as this is a major bug for our Freifunk Firmware (Freifunk Rheinland)

Cheers
Linus

Attachments (1)

100-early-method-check.patch (1018 bytes) - added by jow 5 years ago.

Download all attachments as: .zip

Change History (7)

comment:1 Changed 5 years ago by jow

  • Milestone changed from Attitude Adjustment 12.09 to Barrier Breaker (trunk)
  • Owner changed from developers to jow
  • Priority changed from normal to low
  • Status changed from new to accepted

comment:2 Changed 5 years ago by jow

Recompile with debugging, start daemon in foreground (e.g. screen session) and provide a log dump of when it hangs. Alternatively hook into it with strace or gdb and see where it stalls.

Additionally provide the exact configuration of the webserver.

comment:3 Changed 5 years ago by jow

Also state whether SSL support is installed and used. If yes - with which library.

Changed 5 years ago by jow

comment:4 Changed 5 years ago by jow

  • Priority changed from low to response-needed

Please also test the attached patch.

comment:5 Changed 5 years ago by lcbroich@…

Hello,

Thanks for the quick reply.

Here a 'uci show uhttpd':
uhttpd.service=uhttpd
uhttpd.service.home=/www/service
uhttpd.service.listen_http=80
uhttpd.service.rfc1918_filter=1
uhttpd.service.cgi_prefix=/cgi-bin
uhttpd.service.script_timeout=10
uhttpd.service.network_timeout=30
uhttpd.service.tcp_keepalive=10
uhttpd.redirection=uhttpd
uhttpd.redirection.home=/www/redirection
uhttpd.redirection.listen_http=81
uhttpd.redirection.error_page=/redirect
uhttpd.redirection.index_page=redirect
uhttpd.redirection.cgi_prefix=/
uhttpd.redirection.rfc1918_filter=1
uhttpd.redirection.script_timeout=10
uhttpd.redirection.network_timeout=30
uhttpd.redirection.tcp_keepalive=10

I have compiled uhttpd with debug mode, with and without the patch.
My test setup is a laptop connected via wifi and my android tablet also connected via wifi.

The laptop has no active network connections over the router which i use to send many requests via curl.
With the tablet im trying to connect to various websites in order to get to the splash page on the router.

-- Without patch, debug output enabled ---

Curiosly the uhttpd daemon for the redirection hangs directly after starting it (no debug output!).
In this test phase the tablet is already connected to the wifi and is trying to send traffic to the internet.
The connections to the redirection uhttpd daemon are stalled and nothing happens which is the connection blocking.

-- With the patch, debug output enabled

With the patch the daemon starts and spits out a lot of debug data (also spamming about non valid HTTP requests).
The output increases when im typing in the browser url field (probably already search requests for google).

But the connections don't block as it is the case when launching the daemon without the patch.

You can find the log file here:
http://freifunk.fnordeingang.de/images/misc/ar71xx/uhttpd_redirect_early-method-check.log

I will try to supply a log without the patch enabled in the uhttpd daemon.

Thanks!

comment:6 Changed 5 years ago by lcbroich@…

After further testing I can confirm that the patch solves the issue. I didn't come across any more connection blocks.

Thanks :)

Add Comment

Modify Ticket

Action
as accepted .
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.