Hi Nick, Thanks again for your work on this. That's extremely helpful and your verbose discussion of the patches convinced me to disable all Debian patches for the moment. I'm waiting for comments from the Debian maintainer who added these patches before.
Mats, please let me know what you think. All packaging code is updated in https://salsa.debian.org/debian/rarpd Your comments will be really appreciated. Kind regards and thank you for your cooperation Andreas. Am Sat, Sep 05, 2026 at 06:17:25PM -0400 schrieb Nick Bowler: > OK, I just pushed out rarpd-dx-1.1, which can be found at the > archive location on my web site: > > http://draconx.ca/projects/rarpd-dx/ > http://draconx.ca/archive/rarpd-dx/ > > Please let me know if there are any problems. > > Here is my summary of the Debian patch set. As a general note for this > release, I did not worry about changes which just add new log messages. > I may come back to these in a future update. > > 001_from_0.981107_4.diff: > > - I did not apply the changes to the internal stuctures as it is unclear > to me if these fix any real problem (I have some plans to rework > these but I decided to defer this for a future release). > > - The default tftpboot dir can now be controlled by a configure option, > so the effect of this patch can be achieved by configuring with > > --enable-default-tftpboot=/tftpboot > > - The changes related to ether_ntohost should no longer be required. > - The changes related to interface names should no longer be required. > > 002_from_0.981107_6.diff: > > - Nothing to do on my end; essentially just fixes an error in the > previous patch. > > 010_standard_conventions.diff: > > - Various changes to the documentation, I think the new version covers > all of this. > > 015_notsock_and_debugging.diff: > > - I did not apply the changes regarding -ENOTSOCK. More analysis is > needed, because I do not understand how this error is even possible, > and this fix seems incomplete (the socket gets removed from the > pollfds array, but nothing will ever bring it back). > > I do think rarpd should probably do _something_ in response to > obviously unrecoverable errors like -ENOTSOCK. But I think this is > going to happen as part of a more long-term rework of the protocol > handling, which I didn't want to hold up this release. > > - I did not change the behaviour of the -d option and I don't intend > to do so. > > For debug purposes, the new --log-file=stderr option is useful, which > writes all messages to standard error instead of syslog. For a > reasonable "debug" mode in this version, I suggest rarpd -dvl stderr > > If it is really desirable to have a single option as a shorthand > then we can add a new one. > > 017_respond_to_arp.diff:any > > - I believe this bug should be fixed now. > > 020_manual_page.diff: > > - I added a few more words to the explanation of the --arp option, > which I think should be sufficient. > > - As I did not implement the change to make -d automatically imply -v, > the related manual changes are also not taken. > > - On my end I don't feel that details of how any particular system > resolver maps hostnames to IP addresses (e.g., /etc/hosts) are very > relevant in the rarpd man page. But of course do feel free to make > any modifications to the installed manual which are relevant for > Debian systems. > -- https://fam-tille.de
