2015-05-21 16:59 GMT+02:00 Ron <r...@debian.org>: > > Hi Norbert, > > On Thu, May 21, 2015 at 10:25:38AM +0200, Norbert Lange wrote: >> Hello, >> >> since this behaviour is still on Jessie and is rather inconvenient. >> Whats the recommended workaround nowadays? > > Can you elaborate a little more on exactly what configuration you have > with Jessie that you see this happening on? > (ie. what init system, what brings up you network(s) etc.)
Bog standard Jessie x86_64 Gnome3-Desktop. Systemd and Networkmanager I guess, the point is that installing tftpd-hpa doesnt work out-of-the-box > > If there's still a real bug on that side of things, I'd rather we know > about it and address it at the source than just sweep it under the rug > here, since the latter would just push the bug off onto some other use > case for people to run into again. Sure, and I couldnt tell whats the current state from looking at this thread. >> I want to serve on 2 networks, so setting my ip address wont cut it. > > I have this serving on 4 networks with an address set, so that alone > isn't a problem. What's the situation in your case that it won't? Networks as in 2 separate network interfaces with 2 separate IPs, one is a local 192.168.x.x network at my desk and the other a bigger 10.x.x.x network. Id bet some real money that the primary use for tftp is that its run on some servers, not having a laptop and identifying your home/internal network by the ip address you got assigned. Thats the usecase you are talking about? Just wondering about the reasoning here, I would `ve never thought someone would "secure" his important data on a "trivial" ftp server by expecting you get a different IP than at home in wireless networks (nevertheless someone malevolently giving your laptop the special IP via DHCP) To each his own and its nice its working for you, but I really cant follow the arguments (), but then I dont know everything about the involved network stacks. I will just state the issue more clearly and what I expect. Problem: I want to host a tftp for fetching firmwares via a bootloader. I have two network interface where I want the files accessible. Securing the tftp doesnt matter for me (if, then Id prefer locking to interfaces), I want a painless and easy setup, ideally for providing the company with simple steps to reproduce (apt-get install tftpd-hpa; echo done) State: We are using Wheezy and I added an if-up hook (which I consider a mean hack). Sometime we will change to Jessie, means I tested an untouched installation and wrote down the steps necessary. Issue: tftpd service will fail when booting (as in the service is stopped), supposedly because the network interface(s) arent up. Workarounds: 1) manually restarting the service later will fix this issue. 2) changing TFTP_ADDRESS=":69" will fix the issue. 3) applying my patch and omitting the --address option works too I strongly believe it doesnt matter when you un/replug the wire after tftpd was successfully started but I would have to test this >> Is changing to TFTP_ADDRESS=":69" cause any issues, or a if-up.d >> script still the best option? > > As we discussed earlier in this bug, if that's what you *want* it > is fine, but if there is some other bug that is still causing this > problem, that won't help people who do want or need to restrict > this to just a subset of the available network addresses - so we > probably need to identify the real bug that you've hit so that we > can fix it for them too. > > (which is an independent question from your patch to allow running > this with just the tftpd default options for people who choose that > too, which seems like it's probably a reasonable idea as well). So In short, hope you dont take any offense but to me its clear that TFTP_ADDRESS="0.0.0.0:69" should mean the same as TFTP_ADDRESS=":69" should mean use any IP. Conversely if we ignore common socket rules, and TFTP_ADDRESS="0.0.0.0:69" would mean bind to one fixed IP "0.0.0.0" then the defaults would need to be adjusted. Under this perspective I don`t understand many of the arguments above > Cheers, > Ron > > Kind Regards, Norbert -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
