[syslinux] TFTP forking thousands of processes

Geert Stappers stappers at stappers.nl
Tue Nov 13 12:20:07 PST 2012


On Tue, Nov 13, 2012 at 06:45:29PM +0100, Geert Stappers wrote:
> On Tue, Nov 13, 2012 at 01:49:46PM +0100, Nikola Ciprich wrote:
> > 
> > We were trying to simulate the problem on test virtual guest and successfully
> > reproduced it:
> > 
> > - VM got setup as tftp server (tftp started as xinet service, details below)
> > - on host, we've blocked all outgoing tftp traffic using iptables.
> > 
> > then trying tftp request from some other machine spawns hanging tftp process
> > (running client 1000 times spawns 1000 in.tftpd processes)
> 
> > Anyways, I wonder whether forking so many processes hanging on select() is correct behaviour.

See below

> > My inet configuration looks like this:
> > 
> > service tftp
> > { 
> > 	disable	     = no
> > 	socket_type  = dgram 
> > 	protocol     = udp 
> > 	wait         = yes 
> > 	user         = root
> > 	server       = /usr/sbin/in.tftpd
> > 	server_args  = -s /tftpboot -v -v -v -c
> > 	per_source   = 11
> > 	cps          = 100 2 
> > 	flags        = IPv4
> > 	instances    = 500 
> > } 
> > 
> > Which I'd undetstand that no more then 500 in.tftpd processes should be spawned.
> > I guess tftp is forking on it's own, right? Is it possible it could block somewhere
> > unable to send replis, but forking on (repeated) requests?
> > 
> > Does somebody have an idea on where the problem could be,
> > or how should I proceed with debugging?
> 
> I would go for the TFTP server "stand alone", so not as a inetd proces.
> 

On second thought, that might give the same result.

TFTP is a some odd network protocol.

    server listens on port 69

                               client invites from port N the server at port 69
                               client waits on port N for server                              

    server picks a port, say port M and contacts client at port N
    server waits on port M

                               client recieves on port N from server port M
                               client sends from N to port M at server

    server recieves on port M from client port N
    server sends from M to port N at client

                               client recieves on port N from server port M
                               client sends from N to port M at server

    server recieves on port M from client port N
    server sends from M to port N at client

                               client recieves on port N from server port M
                               client sends from N to port M at server

 

I assume that each "listen on port M" is done with a new forked process.

I think that is a sane design decission.


Back to the original posting.

My advice: allow the clients only a power up or once a hour to fetch config files.


Stappers




More information about the Syslinux mailing list