Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TFTP bug: response source IP is not client request #122

Open
qin-nz opened this issue Oct 10, 2020 · 1 comment
Open

TFTP bug: response source IP is not client request #122

qin-nz opened this issue Oct 10, 2020 · 1 comment

Comments

@qin-nz
Copy link

qin-nz commented Oct 10, 2020

Hi,
My machine has two IPs, one on loopback interface and another on an ethernet interface.
I hope client can use loopback address as tftp server address.

My IP is:

lo: 192.0.2.255/32
xgbe0: 192.0.2.1/31

tftpd is listened on 0.0.0.0 using s.ListenAndServe(":69")

If client request 192.0.2.255, server will got following err

"client-ip:port": sending data packet 1: read udp 192.0.2.1:port->client-ip:port: read: connection refused

Please notes source of response packet use xgbe0's IP as source.

If client request 192.0.2.1, it's ok.


If listened on loopback, using s.ListenAndServe("192.0.2.255:69"), and client request 192.0.2.255. It still use xgbe0's ip to response.

@qin-nz
Copy link
Author

qin-nz commented Oct 10, 2020

This can be fixed by update Linux kernel routing table, using following command

ip route add [client-subnet] via [gateway] dev xgbe0 src 192.0.2.255

But I think this is still a bug, and xinetd tftp can handle it correctly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant