From scott@zorch.sf-bay.org  Wed Jul 18 16:51:08 2001
Return-Path: <scott@zorch.sf-bay.org>
Received: from zorch.sf-bay.org (zorch.dial.idiom.com [216.240.37.73])
	by hub.freebsd.org (Postfix) with ESMTP id 4581C37B401
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 18 Jul 2001 16:51:07 -0700 (PDT)
	(envelope-from scott@zorch.sf-bay.org)
Received: (from uucp@localhost) by zorch.sf-bay.org (8.11.1/8.8.2) with UUCP id f6INp5068852 for FreeBSD-gnats-submit@freebsd.org; Wed, 18 Jul 2001 16:51:05 -0700 (PDT)
Received: (from scott@localhost)
	by zorba.sf-bay.org (8.11.3/8.8.8) id f6INmd709715;
	Wed, 18 Jul 2001 16:48:39 -0700 (PDT)
	(envelope-from scott)
Message-Id: <200107182348.f6INmd709715@zorba.sf-bay.org>
Date: Wed, 18 Jul 2001 16:48:39 -0700 (PDT)
From: Scott Hazen Mueller <scott@zorch.sf-bay.org>
Reply-To: scott@zorch.sf-bay.org
To: FreeBSD-gnats-submit@freebsd.org
Subject: a little hack to rwhod
X-Send-Pr-Version: 3.113

>Number:         29071
>Category:       bin
>Synopsis:       relay patch for rwhod
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    ceri
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Wed Jul 18 17:00:02 PDT 2001
>Closed-Date:    Sun Jun 08 11:01:55 PDT 2003
>Last-Modified:  Sun Jun 08 11:01:55 PDT 2003
>Originator:     Scott Hazen Mueller
>Release:        FreeBSD 4.3-RELEASE i386
>Organization:
>Environment:
System: FreeBSD zorba.sf-bay.org 4.3-RELEASE FreeBSD 4.3-RELEASE #0: Wed Jul 18 14:01:18 PDT 2001 scott@zorba.sf-bay.org:/export/obj/export/src/sys/ZORBA i386


	
>Description:

Enclosed please find a small patch to add a '-r' flag (and underlying support)
to rwhod.  Enabling '-r' turns the daemon into a relay so that it repeats
broadcasts it receives on all interfaces.  This allows a FreeBSD router to
relay rwho packets across multiple subnets w/o using multicast support.  Only
the relay needs to run the modified rwhod and enable relaying; the leaf nodes
need no changes.

Please note that this patch writes a byte of foo into the 'wd_pad' area of the
whod structure so that it can identify packets that it has already touched and
refrain from relaying them again...

>How-To-Repeat:

First, admit to using rwho.

"Hi, my name is Scott, and I use rwho."

Second, decide you'd like machines on different nets, tunneled together over
PPP tunnels, to exchange rwhod data.

Third, find yourself unable to get multicasting and rwhod -m to work.

>Fix:

*** rwhod.c	Wed Jul 18 16:32:56 2001
--- rwhod.c.relay	Wed Jul 18 16:28:57 2001
***************
*** 122,127 ****
--- 122,128 ----
  int			multicast_mode  = NO_MULTICAST;
  int			multicast_scope;
  struct sockaddr_in	multicast_addr  = { sizeof multicast_addr, AF_INET };
+ int			mode_relay = 0;
  
  /*
   * Alarm interval. Don't forget to change the down time check in ruptime
***************
*** 179,184 ****
--- 180,186 ----
  	struct sockaddr_in sin;
  	uid_t unpriv_uid;
  	gid_t unpriv_gid;
+ 	struct	neighbor *np;
  
  	if (getuid())
  		errx(1, "not super user");
***************
*** 204,209 ****
--- 206,213 ----
  			quiet_mode = 1;
  		else if (strcmp(*argv, "-p") == 0)
  			iff_flag = 0;
+ 		else if (strcmp(*argv, "-r") == 0)
+ 			mode_relay = 1;
  		else
  			usage();
  		argv++, argc--;
***************
*** 296,301 ****
--- 300,311 ----
  			    inet_ntoa(from.sin_addr));
  			continue;
  		}
+ 		if ( mode_relay && ( wd.wd_hostname != myname ) && ( wd.wd_pad[1] != 'X' ) ) {
+ 			wd.wd_pad[1] = 'X';
+ 			for (np = neighbors; np != NULL; np = np->n_next)
+   				(void) sendto(s, (char *)&wd, cc, 0,
+ 					np->n_addr, np->n_addrlen);
+ 		}
  		(void) snprintf(path, sizeof path, "whod.%s", wd.wd_hostname);
  		/*
  		 * Rather than truncating and growing the file each time,

>Release-Note:
>Audit-Trail:

From: Brian Somers <brian@Awfulhak.org>
To: scott@zorch.sf-bay.org
Cc: FreeBSD-gnats-submit@FreeBSD.ORG, brian@Awfulhak.org
Subject: Re: bin/29071: a little hack to rwhod 
Date: Thu, 19 Jul 2001 01:23:17 +0100

 > >Number:         29071
 > >Category:       bin
 > >Synopsis:       relay patch for rwhod
 
 I like this idea -- I've thought of doing likewise myself before.
 
 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:
 
   rwhod -r 172.17.10.255 -r 10.0.0.255 etc
 
 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....
 -- 
 Brian <brian@freebsd-services.com>                <brian@Awfulhak.org>
       http://www.freebsd-services.com/        <brian@[uk.]FreeBSD.org>
 Don't _EVER_ lose your sense of humour !      <brian@[uk.]OpenBSD.org>
 
 

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
 
State-Changed-From-To: open->feedback 
State-Changed-By: schweikh 
State-Changed-When: Mon Aug 12 13:55:19 PDT 2002 
State-Changed-Why:  
I think we would need a patch against a recent -current. This patch must 
also include an updated manpage before it could be committed. The C part 
should as much as possible conform to style(9). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=29071 
State-Changed-From-To: feedback->closed 
State-Changed-By: ceri 
State-Changed-When: Sun Jun 8 11:01:53 PDT 2003 
State-Changed-Why:  
Feedback timeout (6 months or more). 
I will handle any feedback that this closure generates. 


Responsible-Changed-From-To: freebsd-bugs->ceri 
Responsible-Changed-By: ceri 
Responsible-Changed-When: Sun Jun 8 11:01:53 PDT 2003 
Responsible-Changed-Why:  
Feedback timeout (6 months or more). 
I will handle any feedback that this closure generates. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=29071 
>Unformatted:
