Date: Wed, 18 Jul 2001 18:20:00 -0700 (PDT) From: Scott Hazen Mueller <scott@zorch.sf-bay.org> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/29071: a little hack to rwhod Message-ID: <200107190120.f6J1K0D79273@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/29071; it has been noted by GNATS.
From: Scott Hazen Mueller <scott@zorch.sf-bay.org>
To: brian@Awfulhak.org, FreeBSD-gnats-submit@FreeBSD.ORG
Cc:
Subject: Re: bin/29071: a little hack to rwhod
Date: Wed, 18 Jul 2001 18:14:05 -0700 (PDT)
>> >Number: 29071
>> >Category: bin
>> >Synopsis: relay patch for rwhod
>However, I'm not sure I like the idea of sending the packet back out with a
>special X marker. I'd prefer if the target network(s) could be specified:
That part of it is inelegant, to say the least. I looked at trying to
identify the source address and using that for loop control...however, that's
harder than it appears. The send socket is (of course) bound with INADDR_ANY
(if anything, the structure is actually bzero'ed), so while we get an address
in the received packet, it's moderately hard(*) to correlate it back to our-
selves. The Right Thing, of course, is to maintain a list of our interface
addresses, and compare all of those against the address in the received
packet.
(*) Moderately hard here means well beyond my exceedingly rusty C programming
skills.
> rwhod -r 172.17.10.255 -r 10.0.0.255 etc
Assuming connected interfaces, this probably would work. rwhod builds a list
of "neighbors" when it starts up, so these -r addresses could just be inserted
into the neighbor list... Question, here, though - syntactically, is the
intent to relay packets from anywhere to 172.17.10.255 & 10.0.0.255, or
packets from 172.17.10.255 & 10.0.0.255 to all interfaces? Probably the
former, but just checking. My hack just does all to all...
>If rwhod kept a note of the payload it sends out, and simply makes sure it
>doesn't send the same thing out twice in a row within (say) 15 seconds, it
>may be better ? This could be implemented fairly easily by just maintaining
>a list of timestamped outbound packets and expiring them when it notices
>they're out of date....
I think looking for it's own interface address(es) as the source would be the
cleaner solution, but I'm not 100% confident it's easily implementable. This
would be the next best thing.
\scott
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200107190120.f6J1K0D79273>