1

My TFTP client only seems to be getting responses from the TFTP server to its RRQ (download requests) if I watch the traffic in wireshark.

If I shut down wireshark (running on the TFTP server), the server does not respond to the RRQs from the client.

I cannot verify whether the RRQs are reaching the TFTP server or what (I'm just using Tftp32d), but I see the RRQ packets in wireshark...

So, what is different from the perspective of the TFTP server when I'm observing the transfer in wireshark?

Improve this question
6
  • when running wireshark, the nic is running in promiscuous mode, maybe that's what caused the difference. there might be another server in your environment that had same IP?
    – andycjw
    Commented Sep 8, 2011 at 8:19
  • 1
    I am writing the TFTP client code... don't close this question on the premise that I'm asking how to use software
    – vicatcu
    Commented Sep 8, 2011 at 14:05
  • @andycjw interesting point, so when wireshark is running my network card is configured differently and Tftp32d "inherits" that configuration... What's different about the traffic I'm generating that causes it to get through to the server only if the NIC is in promiscuous mode?
    – vicatcu
    Commented Sep 8, 2011 at 14:08
  • I can confirm that wireshark running on a third party machine (not involved in the transaction) sees the client packets, but the TFTP server remains unresponsive.
    – vicatcu
    Commented Sep 8, 2011 at 17:13
  • So, it turns out that if I just retry more times (10 is the magic number apparently, I was using 5), Tftpd32 eventually does establish the connection and all is well with the world. Why the heck is the connection established with zero retries when I'm watching in wireshark?
    – vicatcu
    Commented Sep 8, 2011 at 19:30

2 Answers 2

Reset to default
2

When you're running wireshark, the NIC will be running in promiscuous mode, meaning all network packet will be received, even if it's not addressed to your NIC mac address.

My suggestion would be to isolate your TFTP server and TFTP client in an individual LAN setup to test it out. My guess would be that there might be another server running in the same network segment, with possible same IP address that received your TFTP client RRQ request preemptively, but not doing anything with it.

When you run wireshark, all packet is received on the TFTP server, and therefore it was able to do a response to client request packet, it wouldn't have received the packet if it's not running in promiscuous mode.

p.s.: I can't add comment to the original post, that's why I am posting it here.

Improve this answer
2

I had the same problem and wanted to share my experience. Promiscuous mode allows client RRQ packets with protocol problems to reach the destination (TFTP server). In my case there was a problem in ARP and the Ethernet header of the RRQ was using all zero's for the destination MAC. With promiscuous mode on, the packets were being received by the TFTP server, but when turned off the packets were dropped because the MAC did not match.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .