6 replies to this topic

[queisser]

First of all - I love TFTPD32. I use it for FW upgrades on my embedded systems, as a DHCP on an isolated Wifi test network and also as a syslog server. However, I do have a question about running on a PC with multiple NICs: I'm running the server on a box that has two NICs, one that goes to an access point for a Wifi test network and another one for the corporate network. Initially I set the interface to the Wifi NIC and left the corporate net plugged in. Pretty soon TFTPD32 was handing out addresses to unsuspecting clients on the corporate net so I disconnected the corporate LAN and only plug it in as needed after shutting down TFTPD32.

I did this with an older version of TFTPD32 and haven't tested it in a while since I don't want the LAN police to get me. I didn't find any mention in the log that says this was a known bug that was fixed so I'm wondering if it's safe to try the dual NIC again and what I would have to do to set it up correctly to only server a specific network interface.

Thanks,
Andrew

[Ph. Jounin]

Hello Andrew,

You can limit DHCP or TFTP services to one NIC :
In the settings windows, check the option Bind DHCP [TFTP] to this address and select the NIC address.

A common trouble will appear if your NIC address is assigned by a DHCP server. If your address changes, Tftpd32 will not be able to bind it and will report a bind error.

[mibr]

..
You can limit DHCP or TFTP services to one NIC :
In the settings windows, check the option Bind DHCP [TFTP] to this address and select the NIC address.
..

I have the same problem as the original poster (with v3.22). And, of course, I did check the bind option, but it does not work.

It worked fine with v2.84, but v2.84 does not work with DHCP request from a Linux box (src 0.0.0.0, dest 255.255.255.255).

Since the IT admin will kill me if my PC answers to in-house DHCP requests I have switch back to v2.84.

[queisser]

Hi all,

Sorry for starting a topic and never following up. I did check the option to bind to NIC and apparently some DHCP requests were still answered, like the other poster reports. I was running v3.0 so I guess I could drop back to 2.84.

Any updates whether this is a confirmed regression bug?

I also noted that when I went from v3.0 to the latest the DHCP config seemed to be all mixed up. I haven't tested a clean install but somehow the configuration between the two versions caused the DHCP server to not hand out any addresses.

Thanks,
Andrew

[Ph. Jounin]

I am really confused since i am unable to reproduce this behaviour.

Can you start Tftpd32 with the proper settings, then tcpview.exe (from sysinternals), disable the resolve address option (Ctlr R) and send me a copy of the tcpview's window.

[mibr]

Hello,

I attached two files. One for v2.84 and one for v3.22.

Here are the excerpts regarding Tftpd32. I activated only the TFTPD for the interface with IP address 192.168.1.254.
The TCP/IP properties of the corresponding interface are as follows:
IP address 192.168.1.254
Subnet mask 255.255.255.0
No other IP address is assigned to that interface.

tcpciew-tftpd32-v2.84.txt:
tftpd32.exe:3972 UDP 192.168.1.254:69 *:*

tcpciew-tftpd32-v3.22.txt:
tftpd32.exe:3132 TCP 127.0.0.1:1282 127.0.0.1:1994 ESTABLISHED
tftpd32.exe:3132 TCP 127.0.0.1:1994 127.0.0.1:1282 ESTABLISHED
tftpd32.exe:3132 UDP 192.168.1.254:69 *:*

Best regards, Michael.

Attached Files

•  tcpview_tftpd32_v2.84.txt   1.52KB   645 downloads
•  tcpview_tftpd32_v3.22.txt   1.58KB   598 downloads

[Ph. Jounin]

Thanks Michael,

tftpd32.exe:3972 UDP 192.168.1.254:69 *:*

In both releases, Tftpd32 binds the TFTP port (69) to the chosen interface (192.168.1.254) and not to any interfaces. Liek this, i think that Tftpd32 does its job.

tftpd32.exe:3132 TCP 127.0.0.1:1282 127.0.0.1:1994 ESTABLISHED
tftpd32.exe:3132 TCP 127.0.0.1:1994 127.0.0.1:1282 ESTABLISHED

This additional lines are the internal socket opened for daemon <-> GUI communication.