Hi All,
some time ago, I had problems with tftp on FC3. Finally found that there were 2 instances of tftp in xinetd.d dir, tftp and tftp~ which was making xinetd.d listen 2 times on port 69. I removed the other instance, tftp~, which I now know was created by gedit when editing tftp. Now, with only 1 tftp file in xinetd.d, I still get xinetd.d listening twice on port 69 after rebooting. Why is this.? tftp won't work whilst this is so. What command can I give in cli that shows what xinetd.d is doing and what files it's calling.? Cheers.
Mark Sargent.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Mark Sargent wrote: | Hi All, | | some time ago, I had problems with tftp on FC3. Finally found that there | were 2 instances of tftp in xinetd.d dir, tftp and tftp~ which was | making xinetd.d listen 2 times on port 69. I removed the other instance, | tftp~, which I now know was created by gedit when editing tftp. Now, | with only 1 tftp file in xinetd.d, I still get xinetd.d listening twice | on port 69 after rebooting.
Are you looking with something like
netstat -plutn
On a server here running TFTP, I just see the one entry for xinetd listening on port 69 UDP. I don't think it's possible to listen twice on the same port, so I wonder if the other listen you see is it somehow having been configured to listen on port 69 *TCP* too (these are completely different animals).
- -Andy
Andy Green wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Mark Sargent wrote: | Hi All, | | some time ago, I had problems with tftp on FC3. Finally found that there | were 2 instances of tftp in xinetd.d dir, tftp and tftp~ which was | making xinetd.d listen 2 times on port 69. I removed the other instance, | tftp~, which I now know was created by gedit when editing tftp. Now, | with only 1 tftp file in xinetd.d, I still get xinetd.d listening twice | on port 69 after rebooting.
Are you looking with something like
netstat -plutn
On a server here running TFTP, I just see the one entry for xinetd listening on port 69 UDP. I don't think it's possible to listen twice on the same port, so I wonder if the other listen you see is it somehow having been configured to listen on port 69 *TCP* too (these are completely different animals).
- -Andy
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFCUiqVjKeDCxMJCTIRAkf9AKCV3LSXnpj/ZiVF6Aqv95IrkMay2wCfTWek XJBuhBlQoPCJ79+Zk/w6Y34= =A6yp -----END PGP SIGNATURE-----
Hi All,
[root@localhost xinetd.d]# netstat -nutlp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:22273 0.0.0.0:* LISTEN 5137/jserver tcp 0 0 0.0.0.0:32769 0.0.0.0:* LISTEN 4534/rpc.statd tcp 0 0 0.0.0.0:2500 0.0.0.0:* LISTEN 4995/xinetd tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 5179/mysqld tcp 0 0 0.0.0.0:110 0.0.0.0:* LISTEN 4995/xinetd tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 4514/portmap tcp 0 0 0.0.0.0:10000 0.0.0.0:* LISTEN 5340/perl tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 4821/cupsd tcp 0 0 127.0.0.1:5335 0.0.0.0:* LISTEN 4787/mDNSResponder tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 5015/sendmail: acce tcp 0 0 :::80 :::* LISTEN 5046/httpd tcp 0 0 :::22 :::* LISTEN 4984/sshd udp 0 0 0.0.0.0:32768 0.0.0.0:* 4534/rpc.statd udp 0 0 0.0.0.0:10000 0.0.0.0:* 5340/perl udp 0 0 0.0.0.0:32791 0.0.0.0:* 7253/tftp udp 0 0 0.0.0.0:69 0.0.0.0:* 4995/xinetd udp 0 0 0.0.0.0:69 0.0.0.0:* 4995/xinetd udp 0 0 0.0.0.0:5353 0.0.0.0:* 4787/mDNSResponder udp 0 0 0.0.0.0:5353 0.0.0.0:* 4787/mDNSResponder udp 0 0 0.0.0.0:111 0.0.0.0:* 4514/portmap udp 0 0 0.0.0.0:631 0.0.0.0:* 4821/cupsd udp 0 0 0.0.0.0:894 0.0.0.0:* 4534/rpc.statd Cheers.
Mark Sargent.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Mark Sargent wrote:
| listening on port 69 UDP. I don't think it's possible to listen twice | on the same port, so I wonder if the other listen you see is it somehow
| udp 0 0 0.0.0.0:32791 0.0.0.0:* 7253/tftp
I don't see this on my server; maybe it's just I'm not looking at a good time. TFTP appears only under xinetd here.
| udp 0 0 0.0.0.0:69 0.0.0.0:* | 4995/xinetd | udp 0 0 0.0.0.0:69 0.0.0.0:* | 4995/xinetd
Lol... well, I learnt something today already.
- -Andy
On Tue, 2005-04-05 at 07:20 +0100, Andy Green wrote:
| udp 0 0 0.0.0.0:69 0.0.0.0:* | 4995/xinetd | udp 0 0 0.0.0.0:69 0.0.0.0:* | 4995/xinetd
Lol... well, I learnt something today already.
This might be a bug in netstat. I was fixing an issue recently that some entries appeard twice in tcp section. I didn't thought that this can happen also with udp stuff. Will try to investigate it ..
Radek
Radek Vokál wrote:
On Tue, 2005-04-05 at 07:20 +0100, Andy Green wrote:
| udp 0 0 0.0.0.0:69 0.0.0.0:* | 4995/xinetd | udp 0 0 0.0.0.0:69 0.0.0.0:* | 4995/xinetd
Lol... well, I learnt something today already.
This might be a bug in netstat. I was fixing an issue recently that some entries appeard twice in tcp section. I didn't thought that this can happen also with udp stuff. Will try to investigate it ..
Radek
Hi All,
I don't believe it to be a netstat bug, due to the fact that tftp is not transferring files to or from. This would be due to the fact of 2 instances running. Same as before when I didn't know that gedit was creating duplicates of edited files. Cheers.
Mark Sargent.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Radek Vokál wrote: | On Tue, 2005-04-05 at 07:20 +0100, Andy Green wrote: | | |>| udp 0 0 0.0.0.0:69 0.0.0.0:* |>| 4995/xinetd |>| udp 0 0 0.0.0.0:69 0.0.0.0:* |>| 4995/xinetd |> |>Lol... well, I learnt something today already. |> | | | This might be a bug in netstat. I was fixing an issue recently that some | entries appeard twice in tcp section. I didn't thought that this can | happen also with udp stuff. Will try to investigate it ..
Hi Radek -
I would find it a nice explanation if it is a bug, because my understanding of how the sockets work will not allow this scenario of a single process binding two sockets to the same port and listen()-ing to both. Of course my understanding can easily be broken and often is ;-)
Here's an idea for Mark, run lsof -n | grep xinetd and see if you can see two IPv4 sockets open in there or one. It's another way to look at the question of how many sockets are open and by whom. Here's what I get with tftp up in xinetd
[root@server root]# lsof -n | grep xinetd xinetd 3674 root cwd DIR 253,0 4096 2 / xinetd 3674 root rtd DIR 253,0 4096 2 / xinetd 3674 root txt REG 253,0 152348 7218038 /usr/sbin/xinetd xinetd 3674 root mem REG 253,0 47496 4587569 /lib/libnss_files-2.3.4.so xinetd 3674 root mem REG 253,0 97736 4587567 /lib/libnsl-2.3.4.so xinetd 3674 root mem REG 253,0 108332 4587529 /lib/ld-2.3.4.so xinetd 3674 root mem REG 253,0 215272 4587573 /lib/tls/libm-2.3.4.so xinetd 3674 root mem REG 253,0 28632 4587552 /lib/libcrypt-2.3.4.so xinetd 3674 root mem REG 253,0 28504 7217911 /usr/lib/libwrap.so.0.7.6 xinetd 3674 root mem REG 253,0 1524828 4587533 /lib/tls/libc-2.3.4.so xinetd 3674 root 0r CHR 1,3 1806 /dev/null xinetd 3674 root 1r CHR 1,3 1806 /dev/null xinetd 3674 root 2r CHR 1,3 1806 /dev/null xinetd 3674 root 3r FIFO 0,5 7715 pipe xinetd 3674 root 4w FIFO 0,5 7715 pipe xinetd 3674 root 5u IPv4 7837 UDP *:tftp xinetd 3674 root 7u unix 0xef733dc0 7719 socket
- -Andy
Andy Green wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Radek Vokál wrote: | On Tue, 2005-04-05 at 07:20 +0100, Andy Green wrote: | | |>| udp 0 0 0.0.0.0:69 0.0.0.0:* |>| 4995/xinetd |>| udp 0 0 0.0.0.0:69 0.0.0.0:* |>| 4995/xinetd |> |>Lol... well, I learnt something today already. |> | | | This might be a bug in netstat. I was fixing an issue recently that some | entries appeard twice in tcp section. I didn't thought that this can | happen also with udp stuff. Will try to investigate it ..
Hi Radek -
I would find it a nice explanation if it is a bug, because my understanding of how the sockets work will not allow this scenario of a single process binding two sockets to the same port and listen()-ing to both. Of course my understanding can easily be broken and often is ;-)
Here's an idea for Mark, run lsof -n | grep xinetd and see if you can see two IPv4 sockets open in there or one. It's another way to look at the question of how many sockets are open and by whom. Here's what I get with tftp up in xinetd
[root@server root]# lsof -n | grep xinetd xinetd 3674 root cwd DIR 253,0 4096 2 / xinetd 3674 root rtd DIR 253,0 4096 2 / xinetd 3674 root txt REG 253,0 152348 7218038 /usr/sbin/xinetd xinetd 3674 root mem REG 253,0 47496 4587569 /lib/libnss_files-2.3.4.so xinetd 3674 root mem REG 253,0 97736 4587567 /lib/libnsl-2.3.4.so xinetd 3674 root mem REG 253,0 108332 4587529 /lib/ld-2.3.4.so xinetd 3674 root mem REG 253,0 215272 4587573 /lib/tls/libm-2.3.4.so xinetd 3674 root mem REG 253,0 28632 4587552 /lib/libcrypt-2.3.4.so xinetd 3674 root mem REG 253,0 28504 7217911 /usr/lib/libwrap.so.0.7.6 xinetd 3674 root mem REG 253,0 1524828 4587533 /lib/tls/libc-2.3.4.so xinetd 3674 root 0r CHR 1,3 1806 /dev/null xinetd 3674 root 1r CHR 1,3 1806 /dev/null xinetd 3674 root 2r CHR 1,3 1806 /dev/null xinetd 3674 root 3r FIFO 0,5 7715 pipe xinetd 3674 root 4w FIFO 0,5 7715 pipe xinetd 3674 root 5u IPv4 7837 UDP *:tftp xinetd 3674 root 7u unix 0xef733dc0 7719 socket
- -Andy
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFCUpHfjKeDCxMJCTIRAoM1AKCFUosI/+BFZr3PVfV2lFPkwYO5VwCgiAKU CeWphxIqUtB962j6EI2D3lE= =QkFJ -----END PGP SIGNATURE-----
Hi All,
ok, will do this at work tomorrow, as the machne is there. Cheers.
Mark Sargent.
Mark Sargent wrote:
Andy Green wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Radek Vokál wrote: | On Tue, 2005-04-05 at 07:20 +0100, Andy Green wrote: | | |>| udp 0 0 0.0.0.0:69 0.0.0.0:* |>| 4995/xinetd |>| udp 0 0 0.0.0.0:69 0.0.0.0:* |>| 4995/xinetd |> |>Lol... well, I learnt something today already. |> | | | This might be a bug in netstat. I was fixing an issue recently that some | entries appeard twice in tcp section. I didn't thought that this can | happen also with udp stuff. Will try to investigate it ..
Hi Radek -
I would find it a nice explanation if it is a bug, because my understanding of how the sockets work will not allow this scenario of a single process binding two sockets to the same port and listen()-ing to both. Of course my understanding can easily be broken and often is ;-)
Here's an idea for Mark, run lsof -n | grep xinetd and see if you can see two IPv4 sockets open in there or one. It's another way to look at the question of how many sockets are open and by whom. Here's what I get with tftp up in xinetd
[root@server root]# lsof -n | grep xinetd xinetd 3674 root cwd DIR 253,0 4096 2 / xinetd 3674 root rtd DIR 253,0 4096 2 / xinetd 3674 root txt REG 253,0 152348 7218038 /usr/sbin/xinetd xinetd 3674 root mem REG 253,0 47496 4587569 /lib/libnss_files-2.3.4.so xinetd 3674 root mem REG 253,0 97736 4587567 /lib/libnsl-2.3.4.so xinetd 3674 root mem REG 253,0 108332 4587529 /lib/ld-2.3.4.so xinetd 3674 root mem REG 253,0 215272 4587573 /lib/tls/libm-2.3.4.so xinetd 3674 root mem REG 253,0 28632 4587552 /lib/libcrypt-2.3.4.so xinetd 3674 root mem REG 253,0 28504 7217911 /usr/lib/libwrap.so.0.7.6 xinetd 3674 root mem REG 253,0 1524828 4587533 /lib/tls/libc-2.3.4.so xinetd 3674 root 0r CHR 1,3 1806 /dev/null xinetd 3674 root 1r CHR 1,3 1806 /dev/null xinetd 3674 root 2r CHR 1,3 1806 /dev/null xinetd 3674 root 3r FIFO 0,5 7715 pipe xinetd 3674 root 4w FIFO 0,5 7715 pipe xinetd 3674 root 5u IPv4 7837 UDP *:tftp xinetd 3674 root 7u unix 0xef733dc0 7719 socket
- -Andy
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFCUpHfjKeDCxMJCTIRAoM1AKCFUosI/+BFZr3PVfV2lFPkwYO5VwCgiAKU CeWphxIqUtB962j6EI2D3lE= =QkFJ -----END PGP SIGNATURE-----
Hi All,
ok, will do this at work tomorrow, as the machne is there. Cheers.
Mark Sargent.
Hi All,
below is the results. I have no idea what I'm looking at/for.
[root@localhost base-1.1]# lsof -n | grep xinetd xinetd 5105 root cwd DIR 3,3 4096 2 / xinetd 5105 root rtd DIR 3,3 4096 2 / xinetd 5105 root txt REG 3,3 152348 122966 /usr /sbin/xinetd xinetd 5105 root mem REG 3,3 215272 356961 /lib /tls/libm-2.3.4.so xinetd 5105 root mem REG 3,3 97736 357071 /lib /libnsl-2.3.4.so xinetd 5105 root mem REG 3,3 28504 123002 /usr /lib/libwrap.so.0.7.6 xinetd 5105 root mem REG 3,3 1524828 356936 /lib /tls/libc-2.3.4.so xinetd 5105 root mem REG 3,3 47496 778949 /lib /libnss_files-2.3.4.so xinetd 5105 root mem REG 3,3 28632 357090 /lib /libcrypt-2.3.4.so xinetd 5105 root mem REG 3,3 108332 356935 /lib /ld-2.3.4.so xinetd 5105 root 0r CHR 1,3 1980 /dev /null xinetd 5105 root 1r CHR 1,3 1980 /dev /null xinetd 5105 root 2r CHR 1,3 1980 /dev /null xinetd 5105 root 3r FIFO 0,5 9850 pipe xinetd 5105 root 4w FIFO 0,5 9850 pipe xinetd 5105 root 5u IPv4 9911 TCP *:25 00 (LISTEN) xinetd 5105 root 6u IPv4 9912 TCP *:po p3 (LISTEN) xinetd 5105 root 7u unix 0xcedda940 9852 sock et xinetd 5105 root 8u IPv4 9913 UDP *:tf tp xinetd 5105 root 9u IPv4 9914 UDP *:tf tp
Cheers.
Mark Sargent.
On Wed, 2005-04-06 at 16:15 +0900, Mark Sargent wrote:
Mark Sargent wrote:
Andy Green wrote:
Here's an idea for Mark, run lsof -n | grep xinetd and see if you can see two IPv4 sockets open in there or one. It's another way to look at the question of how many sockets are open and by whom. Here's what I get with tftp up in xinetd
[root@server root]# lsof -n | grep xinetd xinetd 3674 root cwd DIR 253,0 4096 2 / xinetd 3674 root rtd DIR 253,0 4096 2 / xinetd 3674 root txt REG 253,0 152348 7218038 /usr/sbin/xinetd xinetd 3674 root mem REG 253,0 47496 4587569 /lib/libnss_files-2.3.4.so xinetd 3674 root mem REG 253,0 97736 4587567 /lib/libnsl-2.3.4.so xinetd 3674 root mem REG 253,0 108332 4587529 /lib/ld-2.3.4.so xinetd 3674 root mem REG 253,0 215272 4587573 /lib/tls/libm-2.3.4.so xinetd 3674 root mem REG 253,0 28632 4587552 /lib/libcrypt-2.3.4.so xinetd 3674 root mem REG 253,0 28504 7217911 /usr/lib/libwrap.so.0.7.6 xinetd 3674 root mem REG 253,0 1524828 4587533 /lib/tls/libc-2.3.4.so xinetd 3674 root 0r CHR 1,3 1806 /dev/null xinetd 3674 root 1r CHR 1,3 1806 /dev/null xinetd 3674 root 2r CHR 1,3 1806 /dev/null xinetd 3674 root 3r FIFO 0,5 7715 pipe xinetd 3674 root 4w FIFO 0,5 7715 pipe xinetd 3674 root 5u IPv4 7837 UDP *:tftp xinetd 3674 root 7u unix 0xef733dc0 7719 socket
- -Andy
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFCUpHfjKeDCxMJCTIRAoM1AKCFUosI/+BFZr3PVfV2lFPkwYO5VwCgiAKU CeWphxIqUtB962j6EI2D3lE= =QkFJ -----END PGP SIGNATURE-----
Hi All,
ok, will do this at work tomorrow, as the machne is there. Cheers.
Mark Sargent.
Hi All,
below is the results. I have no idea what I'm looking at/for.
[root@localhost base-1.1]# lsof -n | grep xinetd xinetd 5105 root cwd DIR 3,3 4096 2 / xinetd 5105 root rtd DIR 3,3 4096 2 / xinetd 5105 root txt REG 3,3 152348 122966 /usr /sbin/xinetd xinetd 5105 root mem REG 3,3 215272 356961 /lib /tls/libm-2.3.4.so xinetd 5105 root mem REG 3,3 97736 357071 /lib /libnsl-2.3.4.so xinetd 5105 root mem REG 3,3 28504 123002 /usr /lib/libwrap.so.0.7.6 xinetd 5105 root mem REG 3,3 1524828 356936 /lib /tls/libc-2.3.4.so xinetd 5105 root mem REG 3,3 47496 778949 /lib /libnss_files-2.3.4.so xinetd 5105 root mem REG 3,3 28632 357090 /lib /libcrypt-2.3.4.so xinetd 5105 root mem REG 3,3 108332 356935 /lib /ld-2.3.4.so xinetd 5105 root 0r CHR 1,3 1980 /dev /null xinetd 5105 root 1r CHR 1,3 1980 /dev /null xinetd 5105 root 2r CHR 1,3 1980 /dev /null xinetd 5105 root 3r FIFO 0,5 9850 pipe xinetd 5105 root 4w FIFO 0,5 9850 pipe xinetd 5105 root 5u IPv4 9911 TCP *:25 00 (LISTEN) xinetd 5105 root 6u IPv4 9912 TCP *:po p3 (LISTEN) xinetd 5105 root 7u unix 0xcedda940 9852 sock et xinetd 5105 root 8u IPv4 9913 UDP *:tf tp xinetd 5105 root 9u IPv4 9914 UDP *:tf tp
Did you get rid of all the backup files from /etc/xinetd.d?
Paul.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Mark Sargent wrote: | Andy Green wrote:
|> I would find it a nice explanation if it is a bug, because my |> understanding of how the sockets work will not allow this scenario of a |> single process binding two sockets to the same port and listen()-ing to |> both. Of course my understanding can easily be broken and often is ;-)
| below is the results. I have no idea what I'm looking at/for.
| xinetd 5105 root 8u IPv4 9913 | UDP *:tf tp | xinetd 5105 root 9u IPv4 9914 | UDP *:tf tp
lsof shows you all the "file" type assets a process has open, sockets being "files" for this purpose. The lines above show that the xinetd process 5105 does indeed hold two IPv4 UDP sockets listening on the tftp port and so it's presumably not a netstat bug.
Maybe it's worth copying your version of
[root@server html]# cat /etc/xinetd.d/tftp # default: off # description: The tftp server serves files using the trivial file transfer \ # protocol. The tftp protocol is often used to boot diskless \ # workstations, download configuration files to network-aware printers, \ # and to start the installation process for some operating systems. service tftp { ~ socket_type = dgram ~ protocol = udp ~ wait = yes ~ user = root ~ server = /usr/sbin/in.tftpd ~ server_args = -s /tftpboot ~ disable = no ~ per_source = 11 ~ cps = 100 2 ~ flags = IPv4
... just in case. And really just in case
cd /etc/xinetd.d grep tftp *
- -Andy
Andy Green wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Mark Sargent wrote: | Andy Green wrote:
|> I would find it a nice explanation if it is a bug, because my |> understanding of how the sockets work will not allow this scenario of a |> single process binding two sockets to the same port and listen()-ing to |> both. Of course my understanding can easily be broken and often is ;-)
| below is the results. I have no idea what I'm looking at/for.
| xinetd 5105 root 8u IPv4 9913 | UDP *:tf tp | xinetd 5105 root 9u IPv4 9914 | UDP *:tf tp
lsof shows you all the "file" type assets a process has open, sockets being "files" for this purpose. The lines above show that the xinetd process 5105 does indeed hold two IPv4 UDP sockets listening on the tftp port and so it's presumably not a netstat bug.
Maybe it's worth copying your version of
[root@server html]# cat /etc/xinetd.d/tftp # default: off # description: The tftp server serves files using the trivial file transfer \ # protocol. The tftp protocol is often used to boot diskless \ # workstations, download configuration files to network-aware printers, \ # and to start the installation process for some operating systems. service tftp { ~ socket_type = dgram ~ protocol = udp ~ wait = yes ~ user = root ~ server = /usr/sbin/in.tftpd ~ server_args = -s /tftpboot ~ disable = no ~ per_source = 11 ~ cps = 100 2 ~ flags = IPv4
... just in case. And really just in case
cd /etc/xinetd.d grep tftp *
- -Andy
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFCU48RjKeDCxMJCTIRAgaXAKCSmRwtTMM+aYzPVR2VEEBLEeN5EwCffcUj NVhzK3YR7BZLpMDQLYUZlA4= =3jwd -----END PGP SIGNATURE-----
Hi All, ok, I copied the tftp file from xinetd.d to another location and rebooted. Guess what, xinetd is still listening on port 69 udp. This is weird. I can't get my head around it, eh. Cheers.
Mark Sargent.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
| | cd /etc/xinetd.d | grep tftp * | | -Andy |> | Hi All, | ok, I copied the tftp file from xinetd.d to another location and | rebooted. Guess what, xinetd is still listening on port 69 udp. This is | weird. I can't get my head around it, eh. Cheers.
| Mark Sargent.
Hi Mark -
Actually I meant copy the file in an email here. Also run the
cd /etc/xinetd.d grep tftp *
commands, which will show up any file in the directory containing "tftp" whatever it is named.
Also, maybe worth emailing to the list the contents of you /etc/xinetd.conf in case that has something exciting.
- -Andy
Andy Green wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
| | cd /etc/xinetd.d | grep tftp * | | -Andy |> | Hi All, | ok, I copied the tftp file from xinetd.d to another location and | rebooted. Guess what, xinetd is still listening on port 69 udp. This is | weird. I can't get my head around it, eh. Cheers.
| Mark Sargent.
Hi Mark -
Actually I meant copy the file in an email here. Also run the
cd /etc/xinetd.d grep tftp *
commands, which will show up any file in the directory containing "tftp" whatever it is named.
Also, maybe worth emailing to the list the contents of you /etc/xinetd.conf in case that has something exciting.
- -Andy
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFCU5UUjKeDCxMJCTIRArNYAJ478ugVOE/JXjH//V4X03h+aiYKogCeMJ12 4uctTjD7Tg920omD/Erp5So= =PTiv -----END PGP SIGNATURE-----
Hi All,
well, well, well, think I may have found the culprit,
[root@localhost tftp]# cat /etc/xinetd.conf # # Simple configuration file for xinetd # # Some defaults, and include /etc/xinetd.d/
defaults { instances = 60 log_type = SYSLOG authpriv log_on_success = HOST PID log_on_failure = HOST cps = 25 30 }
includedir /etc/xinetd.d
service tftp { socket_type = dgram protocol = udp wait = yes user = root server = /usr/bin/tftp server_args = -c -s /tftpboot disable = no per_source = 11 cps = 100 2 } Ok, now, how does that get there..? I certainly didn't put it there. Is it put there by default by another process..? Cheers.
Mark Sargent.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Mark Sargent wrote:
| [root@localhost tftp]# cat /etc/xinetd.conf ... | service tftp | { | socket_type = dgram | protocol = udp | wait = yes | user = root | server = /usr/bin/tftp | server_args = -c -s /tftpboot | disable = no | per_source = 11 | cps = 100 2 | } | Ok, now, how does that get there..? I certainly didn't put it there. Is | it put there by default by another process..? Cheers.
Shouldn't be. This idea of a directory of config files was invented to allow optionally present stuff to easily add and remove its personal config from the main program without having to parse a single master config file and append / rip bits out of it. It's clear that the tftp package does generate its /etc/xinetd.d/ tftp file for its config. So it's hard to understand it would also append its config to the master file.
Anyway, rip out the appended stuff from /etc/xinetd.conf and restart the xinetd service and I guess you'll be okay.
But I am still bemused by the two listening sockets on the same port being possible. Maybe it is some kind of cool load balancing feature I never heard of. Can anyone else here explain how it can be?
- -Andy
Andy Green wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Mark Sargent wrote:
| [root@localhost tftp]# cat /etc/xinetd.conf ... | service tftp | { | socket_type = dgram | protocol = udp | wait = yes | user = root | server = /usr/bin/tftp | server_args = -c -s /tftpboot | disable = no | per_source = 11 | cps = 100 2 | } | Ok, now, how does that get there..? I certainly didn't put it there. Is | it put there by default by another process..? Cheers.
Shouldn't be. This idea of a directory of config files was invented to allow optionally present stuff to easily add and remove its personal config from the main program without having to parse a single master config file and append / rip bits out of it. It's clear that the tftp package does generate its /etc/xinetd.d/ tftp file for its config. So it's hard to understand it would also append its config to the master file.
Anyway, rip out the appended stuff from /etc/xinetd.conf and restart the xinetd service and I guess you'll be okay.
But I am still bemused by the two listening sockets on the same port being possible. Maybe it is some kind of cool load balancing feature I never heard of. Can anyone else here explain how it can be?
- -Andy
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFCU5xDjKeDCxMJCTIRAm4FAJ4msaizDJzo3+RWAnCmoy9KwsyjigCdHTJw EFHYw6pYB5TJOxbQoWj+S6w= =J8k0 -----END PGP SIGNATURE-----
Hi All,
it just keeps getting more interesting. Now, with restarting xinetd and confirming only 1 instance of xinetd.d listening on port 69 udp and connecting via the tftp client I keep getting an error when trying to test a put,
tftp> put /home/coolboarderguy/downloads/tftptest /etc/xinetd.d/tftptest Error code 1: File not found
Now, that file is definitely there,
[root@localhost downloads]# ls acid cobalt firmware packetshaper snort tftp browsers databases fonts plugins solaris tftptest buffalolpc4-clx emailers langtools rescuetools status tripwire chkrootkit fcheck linuxntfs samag summit webmin cisco firewalls netscreen smartswitch syslog-ng ZyXEL
I am tired..hehe...any ideas.? Is this just me this time..? Cheers.
Mark Sargent.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Mark Sargent wrote:
| tftp> put /home/coolboarderguy/downloads/tftptest /etc/xinetd.d/tftptest | Error code 1: File not found
permissions on the file?
- -Andy
Andy Green wrote:
But I am still bemused by the two listening sockets on the same port being possible. Maybe it is some kind of cool load balancing feature I never heard of. Can anyone else here explain how it can be?
- -Andy
May be this is a dumb question from a clueless neophyte, but does the phenomenon constitute a security problem that needs to be addressed?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
David Curry wrote: | Andy Green wrote: | |> |> But I am still bemused by the two listening sockets on the same port |> being possible. Maybe it is some kind of cool load balancing feature I |> never heard of. Can anyone else here explain how it can be? |> |> - -Andy | | | | May be this is a dumb question from a clueless neophyte, but does the | phenomenon constitute a security problem that needs to be addressed?
Probably not, because I'm pretty sure it will only allow it if the two listens are coming from inside the same process ID.
For example in one window
[root@server root]# nc -l -p 1234
works and is listening
[root@server root]# netstat -plutn | grep 1234 tcp 0 0 0.0.0.0:1234 0.0.0.0:* ~ LISTEN 19055/nc
If you try to start a second nc to the same port in another window...
[root@server root]# nc -l -p 1234 Can't grab 0.0.0.0:1234 with bind
So it seems that maybe it's just a (little-known?) feature for a single process rather than a bug?
- -Andy
Andy Green wrote:
David Curry wrote: | Andy Green wrote: | |> |> But I am still bemused by the two listening sockets on the same port |> being possible. Maybe it is some kind of cool load balancing feature I |> never heard of. Can anyone else here explain how it can be? |> |> - -Andy | | | | May be this is a dumb question from a clueless neophyte, but does the | phenomenon constitute a security problem that needs to be addressed?
Probably not, because I'm pretty sure it will only allow it if the two listens are coming from inside the same process ID.
For example in one window
[root@server root]# nc -l -p 1234
works and is listening
[root@server root]# netstat -plutn | grep 1234 tcp 0 0 0.0.0.0:1234 0.0.0.0:* ~ LISTEN 19055/nc
If you try to start a second nc to the same port in another window...
[root@server root]# nc -l -p 1234 Can't grab 0.0.0.0:1234 with bind
So it seems that maybe it's just a (little-known?) feature for a single process rather than a bug?
No, you've been setting up TCP sockets. If you do it with UDP sockets (nc -l -u -p 1234) you can have multiple listeners, and they don't have to be the same process or even started by the same user.
Paul.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Paul Howarth wrote:
| No, you've been setting up TCP sockets. If you do it with UDP sockets | (nc -l -u -p 1234) you can have multiple listeners, and they don't have | to be the same process or even started by the same user.
My mistake :-/ You're completely right. Rerunning that test with -u gives both listening.
[root@server html]# netstat -plutn | grep 1234 udp 0 0 0.0.0.0:1234 0.0.0.0:* ~ 19122/nc udp 0 0 0.0.0.0:1234 0.0.0.0:* ~ 19121/nc
It's not loadbalancing either -- only the last guy to listen gets all the traffic sent on the port.
Hum.
- -Andy
Paul Howarth wrote:
Andy Green wrote:
David Curry wrote: | Andy Green wrote: | |> |> But I am still bemused by the two listening sockets on the same port |> being possible. Maybe it is some kind of cool load balancing feature I |> never heard of. Can anyone else here explain how it can be? |> |> - -Andy | | | | May be this is a dumb question from a clueless neophyte, but does the | phenomenon constitute a security problem that needs to be addressed?
Probably not, because I'm pretty sure it will only allow it if the two listens are coming from inside the same process ID.
For example in one window
[root@server root]# nc -l -p 1234
works and is listening
[root@server root]# netstat -plutn | grep 1234 tcp 0 0 0.0.0.0:1234 0.0.0.0:* ~ LISTEN 19055/nc
If you try to start a second nc to the same port in another window...
[root@server root]# nc -l -p 1234 Can't grab 0.0.0.0:1234 with bind
So it seems that maybe it's just a (little-known?) feature for a single process rather than a bug?
No, you've been setting up TCP sockets. If you do it with UDP sockets (nc -l -u -p 1234) you can have multiple listeners, and they don't have to be the same process or even started by the same user.
Paul.
Thanks for the ed info, gentlemen.
David Curry wrote:
Andy Green wrote:
But I am still bemused by the two listening sockets on the same port being possible. Maybe it is some kind of cool load balancing feature I never heard of. Can anyone else here explain how it can be?
- -Andy
May be this is a dumb question from a clueless neophyte, but does the phenomenon constitute a security problem that needs to be addressed?
Hi All,
David, do you mean as to how the file /etc/xine.conf came to have the data regarding tftp.? It is rather interesting that it did, as I most certainly didn't add it. I even reproduced the installation process, of both the rpm install, and the original install, via yum, and neither add anything to the .conf of xinetd. They only add tftp files to xinetd.d. Cheers.
Mark Sargent.
Mark Sargent wrote:
David Curry wrote:
Andy Green wrote:
But I am still bemused by the two listening sockets on the same port being possible. Maybe it is some kind of cool load balancing feature I never heard of. Can anyone else here explain how it can be?
- -Andy
May be this is a dumb question from a clueless neophyte, but does the phenomenon constitute a security problem that needs to be addressed?
Hi All,
David, do you mean as to how the file /etc/xine.conf came to have the data regarding tftp.? It is rather interesting that it did, as I most certainly didn't add it. I even reproduced the installation process, of both the rpm install, and the original install, via yum, and neither add anything to the .conf of xinetd. They only add tftp files to xinetd.d. Cheers.
Mark Sargent.
In part, yes. The question had dual context. One dimension was whether your situation arose from being hacked. The other more general context was whther or not dual listening on a port presented an opportunity for security exploit.
David Curry wrote:
Mark Sargent wrote:
David Curry wrote:
Andy Green wrote:
But I am still bemused by the two listening sockets on the same port being possible. Maybe it is some kind of cool load balancing feature I never heard of. Can anyone else here explain how it can be?
- -Andy
May be this is a dumb question from a clueless neophyte, but does the phenomenon constitute a security problem that needs to be addressed?
Hi All,
David, do you mean as to how the file /etc/xine.conf came to have the data regarding tftp.? It is rather interesting that it did, as I most certainly didn't add it. I even reproduced the installation process, of both the rpm install, and the original install, via yum, and neither add anything to the .conf of xinetd. They only add tftp files to xinetd.d. Cheers.
Mark Sargent.
In part, yes. The question had dual context. One dimension was whether your situation arose from being hacked. The other more general context was whther or not dual listening on a port presented an opportunity for security exploit.
Hi All,
ok, I'm gonna go a little off-topic here, maybe. When I 1st started at this company 3mths ago, about the 2nd week, I think, I posted a lot on Cisco's forums, as I was hired by a hardware reseller to reinstall/reset to defaults etc Cisco switches/routers. Now, I'm not a pro, as I was intro'd to this job by 2 friends, both CCNPs who work in IT here in Tokyo. They know the shop owner. Anyway, back to that 2nd week, and after I had posted something on Cisco's forum, I think perhaps the next day, I did a google for something that was similar to the post I had posted. Anyway, that post, or part of it, appeared as one of goolge's finds, only, that the post had this as the lead in to what "I" had "wrote". "If only my employer knew how long I was spending on the cisco forums". And the rest was from my post. Now, I thought, woah, what the.....but, well, just put it down to, well, something weird. Anyway, I don't know if it's related or not. My firm has no real data that is worth hacking, that I can think of, but, well, one never knows. My PC is running Firestarter and is also behind a router with it's firewall set. I've even tested it at the security testing sites. Ah, well, as I said, probably off-topic, eh. Cheers.
Mark Sargent.
Mark Sargent wrote:
David Curry wrote:
Mark Sargent wrote:
David Curry wrote:
Andy Green wrote:
But I am still bemused by the two listening sockets on the same port being possible. Maybe it is some kind of cool load balancing feature I never heard of. Can anyone else here explain how it can be?
- -Andy
May be this is a dumb question from a clueless neophyte, but does the phenomenon constitute a security problem that needs to be addressed?
Hi All,
David, do you mean as to how the file /etc/xine.conf came to have the data regarding tftp.? It is rather interesting that it did, as I most certainly didn't add it. I even reproduced the installation process, of both the rpm install, and the original install, via yum, and neither add anything to the .conf of xinetd. They only add tftp files to xinetd.d. Cheers.
Mark Sargent.
In part, yes. The question had dual context. One dimension was whether your situation arose from being hacked. The other more general context was whther or not dual listening on a port presented an opportunity for security exploit.
Hi All,
ok, I'm gonna go a little off-topic here, maybe. When I 1st started at this company 3mths ago, about the 2nd week, I think, I posted a lot on Cisco's forums, as I was hired by a hardware reseller to reinstall/reset to defaults etc Cisco switches/routers. Now, I'm not a pro, as I was intro'd to this job by 2 friends, both CCNPs who work in IT here in Tokyo. They know the shop owner. Anyway, back to that 2nd week, and after I had posted something on Cisco's forum, I think perhaps the next day, I did a google for something that was similar to the post I had posted. Anyway, that post, or part of it, appeared as one of goolge's finds, only, that the post had this as the lead in to what "I" had "wrote". "If only my employer knew how long I was spending on the cisco forums". And the rest was from my post. Now, I thought, woah, what the.....but, well, just put it down to, well, something weird. Anyway, I don't know if it's related or not. My firm has no real data that is worth hacking, that I can think of, but, well, one never knows. My PC is running Firestarter and is also behind a router with it's firewall set. I've even tested it at the security testing sites. Ah, well, as I said, probably off-topic, eh. Cheers.
Mark Sargent.
Hi All,
well, this just keeps improving. Now, with only 1 instance of xinetd listening on port 69 udp and tftp definitely installed,
[root@localhost ~]# netstat -nutlp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:22273 0.0.0.0:* LISTEN 5254/jserver tcp 0 0 0.0.0.0:32769 0.0.0.0:* LISTEN 4651/rpc.statd tcp 0 0 0.0.0.0:2500 0.0.0.0:* LISTEN 5112/xinetd tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 5297/mysqld tcp 0 0 0.0.0.0:110 0.0.0.0:* LISTEN 5112/xinetd tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 4631/portmap tcp 0 0 0.0.0.0:10000 0.0.0.0:* LISTEN 5467/perl tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 4938/cupsd tcp 0 0 127.0.0.1:5335 0.0.0.0:* LISTEN 4904/mDNSResponder tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 5132/sendmail: acce tcp 0 0 :::80 :::* LISTEN 5163/httpd tcp 0 0 :::22 :::* LISTEN 5101/sshd udp 0 0 0.0.0.0:32768 0.0.0.0:* 4651/rpc.statd udp 0 0 0.0.0.0:10000 0.0.0.0:* 5467/perl udp 0 0 0.0.0.0:69 0.0.0.0:* 5112/xinetd udp 0 0 0.0.0.0:5353 0.0.0.0:* 4904/mDNSResponder udp 0 0 0.0.0.0:5353 0.0.0.0:* 4904/mDNSResponder udp 0 0 0.0.0.0:111 0.0.0.0:* 4631/portmap udp 0 0 0.0.0.0:1011 0.0.0.0:* 4651/rpc.statd udp 0 0 0.0.0.0:631 0.0.0.0:* 4938/cupsd [root@localhost ~]# cat /etc/xinetd.d/tftp # default: off # description: The tftp server serves files using the trivial file transfer # protocol. The tftp protocol is often used to boot diskless # workstations, download configuration files to network-aware printers, # and to start the installation process for some operating systems. service tftp { socket_type = dgram protocol = udp wait = yes user = root server = /usr/sbin/in.tftpd server_args = -c -s /tftpboot disable = no per_source = 11 cps = 100 2 flags = IPv4 } [root@localhost ~]# cd /usr/sbin [root@localhost sbin]# ls accept nfsstat accton nhfsgraph acpid nhfsnums adduser nhfsrun adsl-connect nhfsstone adsl-setup nmbd adsl-start nscd adsl-status nstat adsl-stop ntpd alsactl ntpdate alternatives ntpdc anacron ntp-keygen apachectl ntpq apmd ntptime arping ntptrace atd ntp-wait atrun ntsysv authconfig packer automount pcbitctl avcstat ping6 avmcapictrl pmap_dump bonobo-activation-sysconf pmap_set build-locale-archive pppd cannakill pppdump cannaserver pppoe capiinit pppoe-relay capinfos pppoe-server chat pppoe-sniff chkfontpath pppstats chpasswd praliases chroot prelink clockdiff printconf convertquota printconf-backend cpfs.reiserfs printconf-tui cpuspeed pvchange crond pvcreate cupsaccept pvdisplay cupsaddsmb pvmove cupsd pvremove cupsreject pvresize dbconverter-2 pvs dbskkd-cdb pvscan ddcprobe pwck dftest pwconv dhcpd pwmconfig dhcrelay pwunconv dmidecode qtparted dongle_attach quotastats dump-acct ramsize dump-utmp rcapid editcap rdev edquota rdistd ethereal readahead ethtool readprofile execcap reject exportfs repquota ext2online resizefs.reiserfs fancontrol rhn_check fancontrol.pl rhn_register fbset rhnreg_ks filefrag rhnsd findchip rootflags firestarter rotatelogs firstboot rpc.gssd fix-mouse-psaux rpc.idmapd foomatic-addpjloptions rpcinfo foomatic-fix-xml rpc.mountd foomatic-getpjloptions rpc.nfsd foomatic-kitload rpc.rquotad foomatic-nonumericalids rpc.svcgssd foomatic-ppdload rtacct foomatic-preferred-driver rtstat foomatic-printermap-to-gimp-print-xml run_init foomatic-replaceoldprinterids run_qtparted fstab-sync sa gdmconfig safe_finger gdm-restart saned gdm-safe-restart sasl2-shared-mechlist gdmsetup sasl2-static-mechlist gdm-stop saslauthd genhomedircon saslauthd1-checkpass getenforce sasldblistusers getpcaps sasldblistusers2 getsebool saslpasswd glibc_post_upgrade saslpasswd2 glibc_post_upgrade.i686 selinuxenabled gnome-pty-helper sendmail gpm sendmail.sendmail groupadd sensors-detect groupdel serviceconf groupmod sesh grpck sestatus grpconv setenforce grpunconv setfiles hald setpcaps hardlink setquota hisaxctrl setsebool hotsmtpd setup hotwayd showmount htt siggen httpd smartctl httpd.worker smartd htt_server smartd-conf.py hwclock smbd i2cdetect smrsh i2cdump snmpd i2cset snmptrapd ibod ss icnctrl sshd iconvconfig stunnel iconvconfig.i686 sucap idl2eth suexec imon system-cdinstall-helper imontty system-config-kickstart inetdconvert system-config-network inputattach system-config-network-cmd internet-druid system-config-network-druid in.tftpd system-config-network-gui ipppd system-config-network-tui ipppstats system-config-packages iprofd system-config-printer irattach system-config-printer-tui irdaping system-config-services irqbalance system-install-packages isadump sys-unconfig isaset tcpd isdnctrl tcpdump isdndial tcpslice isdnhangup testsaslauthd isdnlog tethereal isdnstatus text2pcap javaconfig tickadj kbdrate timeconfig ksconfig tmpwatch kudzu togglesebool lchage tracepath lgroupadd tracepath6 lgroupdel traceroute lgroupmod traceroute6 libgcc_post_upgrade tripwire lid try-from lnewusers tunefs.reiserfs load_policy tunelp lockdev twadmin logrotate twprint logwatch up2date lokkit up2date-config longrun up2date-nox loopctrl update-alternatives lpadmin useradd lpasswd userdel lpc userhelper lpc.cups userisdnctl lpinfo usermod lpmove usernetctl lsof utempter luseradd vboxd luserdel vgcfgbackup lusermod vgcfgrestore lvchange vgchange lvcreate vgck lvdisplay vgconvert lvextend vgcreate lvm vgdisplay lvmchange vgexport lvmdiskscan vgextend lvmsadc vgimport lvmsar vgmerge lvreduce vgmknodes lvremove vgreduce lvrename vgremove lvresize vgrename lvs vgs lvscan vgscan mailstats vgsplit makemap vidmode mergecap vigr mkdict vipw mklost+found visudo mksock warnquota mkzonedb winbindd modeline2fb x86info module_upgrade xinetd mouseconfig yppoll mtr ypset neat yptest neat-tui zdump netconfig zic newusers
it is now not working. If I try to put a file from say host pc /tftptest to /tftpboot or if I try to upload a file from a switch nothing happens,
Switch#copy start tftp Address or name of remote host []? 192.168.168.12 Destination filename [switch-confg]? Switch#
[root@localhost ~]# tftp tftp> connect (to) 192.168.168.12 tftp> status Connected to 192.168.168.12. Mode: netascii Verbose: off Tracing: off Rexmt-interval: 5 seconds, Max-timeout: 25 seconds tftp> put /tftptest /tftpboot tftp>
Now, I can definitely ping from/to the pc/switch. Firewall allows connection. /tftptest permissions,
[root@localhost ~]# ls -alh /tftptest -rwxrwxrwx 1 root root 0 Apr 7 13:20 /tftptest
Does someone upstairs not want me to be able to tftp..? Driving me nutz. Cheers.
Mark Sargent.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Mark Sargent wrote:
| Hi All, | | well, this just keeps improving. Now, with only 1 instance of xinetd | listening on port 69 udp and tftp definitely installed,
~From man tftpd
~ -c Allow new files to be created. By default, tftpd will only allow upload of files that already exist. Files are created with default permissions allowing anyone to read or write them, ~ unless the -p or -U options are specified.
So add this to the "server_args" line of /etc/xinetd.d/tftp
- -Andy
Andy Green wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Mark Sargent wrote:
| Hi All, | | well, this just keeps improving. Now, with only 1 instance of xinetd | listening on port 69 udp and tftp definitely installed,
~From man tftpd
~ -c Allow new files to be created. By default, tftpd will only allow upload of files that already exist. Files are created with default permissions allowing anyone to read or write them, ~ unless the -p or -U options are specified.
So add this to the "server_args" line of /etc/xinetd.d/tftp
- -Andy
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFCVNgMjKeDCxMJCTIRAivfAJ4p1yxAUrbbY/j8s+wPS/b0OxQDlACfZOvh R3My60OlL6BSu9OQnJFKJrk= =2guo -----END PGP SIGNATURE-----
Hi All,
Andy, I already posted the contents of my /etc/xinetd.d/tftp file, and it contains -c as a server_args option...perhaps you missed it..? Cheers.
Mark Sargent.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Mark Sargent wrote: | Andy Green wrote: | | Mark Sargent wrote: | | | Hi All, | | | | well, this just keeps improving. Now, with only 1 instance of xinetd | | listening on port 69 udp and tftp definitely installed, | | ~From man tftpd | | ~ -c Allow new files to be created. By default, tftpd will | only allow upload of files that already exist. Files are created with | default permissions allowing anyone to read or write them, | ~ unless the -p or -U options are specified. | | So add this to the "server_args" line of /etc/xinetd.d/tftp | | -Andy |> | Hi All,
| Andy, I already posted the contents of my /etc/xinetd.d/tftp file, and | it contains -c as a server_args option...perhaps you missed it..? Cheers.
Yep I missed it, sorry. Did you service xinetd restart since adding it?
One thought.... does the xinetd process user have write permissions in the destination directory?
- -Andy
Andy Green wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Mark Sargent wrote: | Andy Green wrote: | | Mark Sargent wrote: | | | Hi All, | | | | well, this just keeps improving. Now, with only 1 instance of xinetd | | listening on port 69 udp and tftp definitely installed, | | ~From man tftpd | | ~ -c Allow new files to be created. By default, tftpd will | only allow upload of files that already exist. Files are created with | default permissions allowing anyone to read or write them, | ~ unless the -p or -U options are specified. | | So add this to the "server_args" line of /etc/xinetd.d/tftp | | -Andy |> | Hi All,
| Andy, I already posted the contents of my /etc/xinetd.d/tftp file, and | it contains -c as a server_args option...perhaps you missed it..? Cheers.
Yep I missed it, sorry. Did you service xinetd restart since adding it?
One thought.... does the xinetd process user have write permissions in the destination directory?
- -Andy
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFCVOq4jKeDCxMJCTIRAnFYAJ9xpI7QBvGGeyFsqsvcvvr+tJz62QCeLck4 urvak6ZZXTLRzwqKlmP6HGE= =WzW5 -----END PGP SIGNATURE-----
Hi All,
yes, Andy, I have restarted, even rebooted with no change. With your permissions Q, are you referring to the dir tftpboot.? What do you mean by, xinetd process user..? Below is the permissions/ownership details for tftpboot,
[root@localhost etc]# cd /tftpboot [root@localhost tftpboot]# ls -alh . total 16K drwxr-xr-x 2 root root 4.0K Apr 7 13:24 . drwxr-xr-x 24 root root 4.0K Apr 7 12:55 .. -rw-rw-rw- 1 nobody nobody 363 Mar 28 16:09 router-confg -rwxrwxrwx 1 root root 0 Mar 25 14:04 startup -rw-rw-rw- 1 nobody nobody 506 Mar 28 13:57 tftp -rwxrwxrwx 1 nobody nobody 0 Apr 7 13:21 tftpboot
Cheers.
Mark Sargent.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Mark Sargent wrote:
| yes, Andy, I have restarted, even rebooted with no change. With your | permissions Q, are you referring to the dir tftpboot.? What do you mean | by, xinetd process user..? Below is the permissions/ownership details | for tftpboot,
| -rwxrwxrwx 1 nobody nobody 0 Apr 7 13:21 tftpboot
[root@server nzb]# ps -Af | grep xinetd root 3674 1 0 Mar29 ? 00:00:00 xinetd -stayalive - -pidfile /var/run/xinetd.pid
xinetd is apparently executing with the privs of the root user, but if I do a strings on in.tftpd there is a string in there
cannot drop privileges: %m
suggesting that tftpd doesn't run as root. In fact the man page says it runs as nobody by default I see now.
Anyway it's moot because you show tftpboot wide open for anyone to write into.
Nothing in /var/log/messages about the failed write? Add -v -v -v to the options in /etc/xinetd.d/tftp and restart xinetd, then try again... it should be chattier in the log and maybe you get a clue.
- -Andy
Andy Green wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Mark Sargent wrote:
| yes, Andy, I have restarted, even rebooted with no change. With your | permissions Q, are you referring to the dir tftpboot.? What do you mean | by, xinetd process user..? Below is the permissions/ownership details | for tftpboot,
| -rwxrwxrwx 1 nobody nobody 0 Apr 7 13:21 tftpboot
[root@server nzb]# ps -Af | grep xinetd root 3674 1 0 Mar29 ? 00:00:00 xinetd -stayalive
- -pidfile /var/run/xinetd.pid
xinetd is apparently executing with the privs of the root user, but if I do a strings on in.tftpd there is a string in there
cannot drop privileges: %m
suggesting that tftpd doesn't run as root. In fact the man page says it runs as nobody by default I see now.
Anyway it's moot because you show tftpboot wide open for anyone to write into.
Nothing in /var/log/messages about the failed write? Add -v -v -v to the options in /etc/xinetd.d/tftp and restart xinetd, then try again... it should be chattier in the log and maybe you get a clue.
- -Andy
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFCVPNbjKeDCxMJCTIRAnwSAJ0Tbjwv9PFeHXZv4fMY8PPLevxrcwCgjJu0 e/UG97O8xjW1GoXHWKosmQ8= =vJaz -----END PGP SIGNATURE-----
Hi All,
guys, what is this..?
Apr 8 04:24:53 localhost in.tftpd[6352]: WRQ from 192.168.168.12 filename /tftp boot
Found in /var/log/messages today after I added -v -v -v to /etc/xinetd.d/tftp as suggested by Andy Green. What I don't un, is, why does it show the time as 04:24:53 when others are per the pc clock time..? Cheers.
Mark Sargent.
Mark Sargent wrote:
Andy Green wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Mark Sargent wrote:
| yes, Andy, I have restarted, even rebooted with no change. With your | permissions Q, are you referring to the dir tftpboot.? What do you mean | by, xinetd process user..? Below is the permissions/ownership details | for tftpboot,
| -rwxrwxrwx 1 nobody nobody 0 Apr 7 13:21 tftpboot
[root@server nzb]# ps -Af | grep xinetd root 3674 1 0 Mar29 ? 00:00:00 xinetd -stayalive
- -pidfile /var/run/xinetd.pid
xinetd is apparently executing with the privs of the root user, but if I do a strings on in.tftpd there is a string in there
cannot drop privileges: %m
suggesting that tftpd doesn't run as root. In fact the man page says it runs as nobody by default I see now.
Anyway it's moot because you show tftpboot wide open for anyone to write into.
Nothing in /var/log/messages about the failed write? Add -v -v -v to the options in /etc/xinetd.d/tftp and restart xinetd, then try again... it should be chattier in the log and maybe you get a clue.
- -Andy
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFCVPNbjKeDCxMJCTIRAnwSAJ0Tbjwv9PFeHXZv4fMY8PPLevxrcwCgjJu0 e/UG97O8xjW1GoXHWKosmQ8= =vJaz -----END PGP SIGNATURE-----
Hi All,
guys, what is this..?
Apr 8 04:24:53 localhost in.tftpd[6352]: WRQ from 192.168.168.12 filename /tftp boot
Found in /var/log/messages today after I added -v -v -v to /etc/xinetd.d/tftp as suggested by Andy Green. What I don't un, is, why does it show the time as 04:24:53 when others are per the pc clock time..? Cheers.
Mark Sargent.
Hi All,
ok, this is working now. Both from a switch and from the pc itself via tftp client. I wanna thank everybody for their help/patience..most of all their patience with me. As Andy pointed out, the server changes from root to user id, so, to get the tftp client to put a file I had to make that file the ownership of the user running tftp-server. Oh well, it's all a learning experience, and heck, I've learnt a lot. Cheers.
Mark Sargent.
-
Andy Green -
David Curry -
Mark Sargent -
Paul Howarth -
Radek Vokál