tftp timeout for ubuntu and debian client, but not for centos client

Asif Iqbal vadud3 at gmail.com
Mon Mar 10 15:30:29 UTC 2014 

On Fri, Mar 7, 2014 at 12:45 PM, Asif Iqbal <vadud3 at gmail.com> wrote:

>
>
>
> On Fri, Mar 7, 2014 at 6:06 AM, Robie Basak <robie.basak at ubuntu.com>wrote:
>
>> On Thu, Mar 06, 2014 at 05:36:57PM -0500, Asif Iqbal wrote:
>> > Any suggestion on how to troubleshoot this?
>>
>> Try tcpdump, to see what is actually not going out or not arriving.
>>
>
>
> ubuntu client (192.168.0.248) tries few times and then times out
>
> ~$ tftp 192.168.0.15
> tftp> get file
> Transfer timed out.
>
> tftp>
>
> tcpdump on ubuntu client (192.168.0.248)
>
> 12:33:32.086503 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP
> (17), length 44)
>     192.168.0.248.59695 > 192.168.0.15.69: [bad udp cksum c46c!]  16 RRQ
> "file" netascii
> 12:33:37.086528 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP
> (17), length 44)
>     192.168.0.248.59695 > 192.168.0.15.69: [bad udp cksum c46c!]  16 RRQ
> "file" netascii
> 12:33:42.086548 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP
> (17), length 44)
>     192.168.0.248.59695 > 192.168.0.15.69: [bad udp cksum c46c!]  16 RRQ
> "file" netascii
> 12:33:47.086569 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP
> (17), length 44)
>     192.168.0.248.59695 > 192.168.0.15.69: [bad udp cksum c46c!]  16 RRQ
> "file" netascii
> 12:33:52.086587 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP
> (17), length 44)
>     192.168.0.248.59695 > 192.168.0.15.69: [bad udp cksum c46c!]  16 RRQ
> "file" netascii
>
> tcpdump on ubuntu tftp server (192.168.0.15)
>
> 12:33:37.086694 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP
> (17), length 44)
>     192.168.0.248.59695 > 192.168.0.15.69: [udp sum ok]  16 RRQ "file"
> netascii
> 12:33:42.086684 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP
> (17), length 44)
>     192.168.0.248.59695 > 192.168.0.15.69: [udp sum ok]  16 RRQ "file"
> netascii
> 12:33:47.086739 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP
> (17), length 44)
>     192.168.0.248.59695 > 192.168.0.15.69: [udp sum ok]  16 RRQ "file"
> netascii
> 12:33:52.086761 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP
> (17), length 44)
>     192.168.0.248.59695 > 192.168.0.15.69: [udp sum ok]  16 RRQ "file"
> netascii
>
>
> centos client works right away when pulling the file from ubuntu tftpd
> server
>
> [vagrant at centos65 ~]$ tftp 192.168.0.15
> tftp> get file
> tftp>
>
> tcpdump from centos client (192.168.0.71)
>
> 17:42:16.398838 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP
> (17), length 44)
>     192.168.0.71.36536 > 192.168.0.15.tftp: [bad udp cksum e242!]  16 RRQ
> "file" netascii
>
> tcpdump from ubuntu tftpd server (192.168.0.15)
>
> 12:42:17.931861 IP (tos 0x0, ttl 50, id 0, offset 0, flags [none], proto
> UDP (17), length 44)
>     192.168.0.71.36536 > 192.168.0.15.69: [udp sum ok]  16 RRQ "file"
> netascii
>
>
>

I realized tcpdump only port 69 will miss all the other tftp related
traffic. Here is a better snapshot of tcpdump
from ubuntu client and ubuntu server during tftp. tftp is still timing out.

ubuntu client is 192.168.0.94 and ubuntu server is 192.168.0.15 (sanitized)

tcdump on ubuntu client
$ sudo tcpdump -nnieth0 host 192.168.0.15 and not port 22
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

11:22:05.145882 ARP, Request who-has 192.168.0.15 (ff:ff:ff:ff:ff:ff) tell
192.168.0.112, length 46
11:22:07.200985 IP 192.168.0.94.40554 > 192.168.0.15.69:  16 RRQ "file"
netascii
11:22:07.205970 IP 192.168.0.15.43112 > 192.168.0.94.40554: UDP, length 38
11:22:12.201170 IP 192.168.0.94.40554 > 192.168.0.15.69:  16 RRQ "file"
netascii
11:22:12.206110 IP 192.168.0.15.50574 > 192.168.0.94.40554: UDP, length 38
11:22:12.206254 IP 192.168.0.15.43112 > 192.168.0.94.40554: UDP, length 38
11:22:17.201323 IP 192.168.0.94.40554 > 192.168.0.15.69:  16 RRQ "file"
netascii
11:22:17.206211 IP 192.168.0.15.41961 > 192.168.0.94.40554: UDP, length 38
11:22:17.206489 IP 192.168.0.15.50574 > 192.168.0.94.40554: UDP, length 38
11:22:17.206607 IP 192.168.0.15.43112 > 192.168.0.94.40554: UDP, length 38
11:22:22.201477 IP 192.168.0.94.40554 > 192.168.0.15.69:  16 RRQ "file"
netascii
11:22:22.206360 IP 192.168.0.15.59041 > 192.168.0.94.40554: UDP, length 38
11:22:22.206977 IP 192.168.0.15.41961 > 192.168.0.94.40554: UDP, length 38
11:22:22.207016 IP 192.168.0.15.43112 > 192.168.0.94.40554: UDP, length 38
11:22:22.207206 IP 192.168.0.15.50574 > 192.168.0.94.40554: UDP, length 38
11:22:27.201625 IP 192.168.0.94.40554 > 192.168.0.15.69:  16 RRQ "file"
netascii
11:22:27.206519 IP 192.168.0.15.38812 > 192.168.0.94.40554: UDP, length 38
11:22:27.206644 IP 192.168.0.15.59041 > 192.168.0.94.40554: UDP, length 38
11:22:27.206757 ARP, Request who-has 192.168.0.15 tell 192.168.0.94, length
28
11:22:27.206978 ARP, Reply 192.168.0.15 is-at ac:16:2d:79:64:ec, length 46
11:22:27.207263 IP 192.168.0.15.41961 > 192.168.0.94.40554: UDP, length 38
11:22:27.207302 IP 192.168.0.15.43112 > 192.168.0.94.40554: UDP, length 38
11:22:27.207549 IP 192.168.0.15.50574 > 192.168.0.94.40554: UDP, length 38
11:22:32.206854 IP 192.168.0.15.38812 > 192.168.0.94.40554: UDP, length 38
11:22:32.207260 IP 192.168.0.15.59041 > 192.168.0.94.40554: UDP, length 38
11:22:32.207533 IP 192.168.0.15.41961 > 192.168.0.94.40554: UDP, length 38
11:22:32.207780 IP 192.168.0.15.50574 > 192.168.0.94.40554: UDP, length 38

tcpdump on the ubuntu server

$ sudo tcpdump -nnieth0 host 192.168.0.94 and not port 22
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

11:19:36.013763 IP 192.168.0.94.40554 > 192.168.0.15.69:  16 RRQ "file"
netascii
11:19:36.018476 IP 192.168.0.15.43112 > 192.168.0.94.40554: UDP, length 38
11:19:36.891384 IP 192.168.0.94.17500 > 255.255.255.255.17500: UDP, length
155
11:19:36.891991 IP 192.168.0.94.17500 > 192.168.0.255.17500: UDP, length 155
11:19:41.013686 IP 192.168.0.94.40554 > 192.168.0.15.69:  16 RRQ "file"
netascii
11:19:41.018380 IP 192.168.0.15.50574 > 192.168.0.94.40554: UDP, length 38
11:19:41.018526 IP 192.168.0.15.43112 > 192.168.0.94.40554: UDP, length 38
11:19:46.013625 IP 192.168.0.94.40554 > 192.168.0.15.69:  16 RRQ "file"
netascii
11:19:46.018241 IP 192.168.0.15.41961 > 192.168.0.94.40554: UDP, length 38
11:19:46.018483 IP 192.168.0.15.50574 > 192.168.0.94.40554: UDP, length 38
11:19:46.018649 IP 192.168.0.15.43112 > 192.168.0.94.40554: UDP, length 38
11:19:51.013542 IP 192.168.0.94.40554 > 192.168.0.15.69:  16 RRQ "file"
netascii
11:19:51.018153 IP 192.168.0.15.59041 > 192.168.0.94.40554: UDP, length 38
11:19:51.018778 IP 192.168.0.15.41961 > 192.168.0.94.40554: UDP, length 38
11:19:51.018821 IP 192.168.0.15.43112 > 192.168.0.94.40554: UDP, length 38
11:19:51.019003 IP 192.168.0.15.50574 > 192.168.0.94.40554: UDP, length 38
11:19:56.013443 IP 192.168.0.94.40554 > 192.168.0.15.69:  16 RRQ "file"
netascii
11:19:56.018067 IP 192.168.0.15.38812 > 192.168.0.94.40554: UDP, length 38
11:19:56.018211 IP 192.168.0.15.59041 > 192.168.0.94.40554: UDP, length 38
11:19:56.018531 ARP, Request who-has 192.168.0.15 tell 192.168.0.94, length
46
11:19:56.018554 ARP, Reply 192.168.0.15 is-at ac:16:2d:79:64:ec, length 28
11:19:56.018825 IP 192.168.0.15.41961 > 192.168.0.94.40554: UDP, length 38
11:19:56.018873 IP 192.168.0.15.43112 > 192.168.0.94.40554: UDP, length 38
11:19:56.019056 IP 192.168.0.15.50574 > 192.168.0.94.40554: UDP, length 38
11:20:01.018171 IP 192.168.0.15.38812 > 192.168.0.94.40554: UDP, length 38
11:20:01.018582 IP 192.168.0.15.59041 > 192.168.0.94.40554: UDP, length 38
11:20:01.018861 IP 192.168.0.15.41961 > 192.168.0.94.40554: UDP, length 38
11:20:01.019108 IP 192.168.0.15.50574 > 192.168.0.94.40554: UDP, length 38




> --
>
> Asif Iqbal
> PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
>
>


-- 
Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-server/attachments/20140310/69898c28/attachment.html>

More information about the ubuntu-server mailing list