-
Notifications
You must be signed in to change notification settings - Fork 120
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
dyn_func_file needs an api that includes client metadata #51
Comments
Hmm. Maybe dyn_func_file needs to have more of an api instead of just being passed the filename. Your requirement is a common one. |
How would you know the source MAC address? That's not in an RRQ. |
In my case, the TFTP request is being made on the local LAN, and therefore we can determine the MAC from the IP. Appreciate that when TFTP is routed, this doesn't work. You can blame ${network_vendor} for using the same TFTP filename (and a TFTP address of 255.255.255.255) regardless of device for this seemingly insane requirement.... |
+1 for a way to access client IP from within dyn_file_func |
Hmm. This seems worth doing, if we can figure out an elegant way to make it work. More coffee. |
hello! but you already fixed this here 77af4ea#diff-cd9e2bec9ae335a07d2a0151d9f9bc59R301 @oriordan snuck it in in the big 2to3 commit. since 0.8.0 dyn_file_func() now gets raddress and rport making it possible to identify the client. We've been using stock unpatched tftpy since then. Thanks! |
dyn_file_func currently accepts just the filename. In the application I wish to use tftpy, I need to serve up files using dyn_file_func based on the source MAC address. To do this, I'd want to just change line 302 of TftpStates.py to pass self.context, rather than self.context.file_to_transfer, but that's clearly going to break things.
I'll try and work a backwards-compatible patch (probably using inspect to check the number of arguments), then issue a PR.
The text was updated successfully, but these errors were encountered: