usr.sbin/wake removal

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

usr.sbin/wake removal

Thomas Pfaff-5
On Sun, 8 Feb 2009 15:53:01 -0700 (MST)
Marc Balmer <[hidden email]> wrote:

> CVSROOT: /cvs
> Module name: src
> Changes by: [hidden email] 2009/02/08 15:53:01
>
> Removed files:
> usr.sbin/wake  : Makefile wake.8 wake.c
>
> Log message:
> Remove wake(8).  The bin directories are full, no new commands to be added.

I think this could use some explaining for those of us that are not
intimately involved in development or have been around here for that
long.  Keeping it small and simple by saying no to adding one file
at 7.2K?  I'd really like to know the rationale on this one.

Thanks.

Reply | Threaded
Open this post in threaded view
|

Re: usr.sbin/wake removal

Richard Toohey
On 9/02/2009, at 6:31 PM, Thomas Pfaff wrote:

> I think this could use some explaining for those of us that are not
> intimately involved in development or have been around here for that
> long.  Keeping it small and simple by saying no to adding one file
> at 7.2K?  I'd really like to know the rationale on this one.
>
> Thanks.

My guess would be that I want this 10K util, you want that 7.2K util,
Fred wants that 20K util, and every Tom, Dick, and Harry wants
their n K ... who gets to make the rules, who gets to administer it,  
etc.?
(Who gets to listen to everyone arguing why this or that should go in?)

And guess there may be ramifications for install media?

Reply | Threaded
Open this post in threaded view
|

Re: usr.sbin/wake removal

Alexander Yurchenko-3
On Mon, Feb 09, 2009 at 09:05:13PM +1300, Richard Toohey wrote:

> On 9/02/2009, at 6:31 PM, Thomas Pfaff wrote:
>
> >I think this could use some explaining for those of us that are not
> >intimately involved in development or have been around here for that
> >long.  Keeping it small and simple by saying no to adding one file
> >at 7.2K?  I'd really like to know the rationale on this one.
> >
> >Thanks.
>
> My guess would be that I want this 10K util, you want that 7.2K util,
> Fred wants that 20K util, and every Tom, Dick, and Harry wants
> their n K ... who gets to make the rules, who gets to administer it,  
> etc.?
> (Who gets to listen to everyone arguing why this or that should go in?)
>
> And guess there may be ramifications for install media?

you need wake(8) on install media to wake up your local ftp mirror?

--
   Alexander Yurchenko

Reply | Threaded
Open this post in threaded view
|

Re: usr.sbin/wake removal

Daniel Ouellet
Alexander Yurchenko wrote:

> On Mon, Feb 09, 2009 at 09:05:13PM +1300, Richard Toohey wrote:
>> On 9/02/2009, at 6:31 PM, Thomas Pfaff wrote:
>>
>>> I think this could use some explaining for those of us that are not
>>> intimately involved in development or have been around here for that
>>> long.  Keeping it small and simple by saying no to adding one file
>>> at 7.2K?  I'd really like to know the rationale on this one.
>>>
>>> Thanks.
>> My guess would be that I want this 10K util, you want that 7.2K util,
>> Fred wants that 20K util, and every Tom, Dick, and Harry wants
>> their n K ... who gets to make the rules, who gets to administer it,  
>> etc.?
>> (Who gets to listen to everyone arguing why this or that should go in?)
>>
>> And guess there may be ramifications for install media?
>
> you need wake(8) on install media to wake up your local ftp mirror?

I can't say the rational for it. Judging by the reaction to the addition
and removal, I guess many would use it too. We can only plea to make the
removal reverse, that's all we can do. I can only say many times we are
told you can leave xbase for example as hard disk is cheap, well that
should apply to this very nice tool too. Looks to me that by the number
of quick changes done to it between the changes and the removal by a few
different developers and the original OK list of a few more and nice
comments about it, looks like many would welcome it too.

We can only plea to the power to be to change their mind, but that's
about it. What I find harsh is the comments made to Marc on undeadly
about his removal. He didn't deserved them by a long shut!

I have to say it's hard to understand when it's always about the right
tool for the job and this is right. However, be as it may. We can only
suggest to have it back, however, it's not up to us, nor do we have a
say in it in the end either.

We don't know the reason, nor do we need to know. The outcome is sad
however for sure and obviously many looks like would use it and welcomed it.

But I must admit, it's somewhat difficult to understand the statement
about "bin being full".

May be a security possible issue, but if it does only provide wake, then
what's the harm in turning up an already up server. (;>

Hopefully this could be reconsider?

If not, thanks anyway to may be review the removal.

Best,

Daniel

Reply | Threaded
Open this post in threaded view
|

Re: usr.sbin/wake removal

Emilio Perea
In reply to this post by Richard Toohey
On Mon, Feb 09, 2009 at 09:05:13PM +1300, Richard Toohey wrote:

> On 9/02/2009, at 6:31 PM, Thomas Pfaff wrote:
>
>> I think this could use some explaining for those of us that are not
>> intimately involved in development or have been around here for that
>> long.  Keeping it small and simple by saying no to adding one file
>> at 7.2K?  I'd really like to know the rationale on this one.
>>
>> Thanks.
>
> My guess would be that I want this 10K util, you want that 7.2K util,
> Fred wants that 20K util, and every Tom, Dick, and Harry wants
> their n K ... who gets to make the rules, who gets to administer it,
> etc.?
> (Who gets to listen to everyone arguing why this or that should go in?)
>
> And guess there may be ramifications for install media?

If there is no room in base, it would be nice to have it in ports.  Or
is there something else in ports already that does the same thing?  I've
found wake extremely useful for turning on remote desktop computers from
the Soekris firewall rather than leaving them on all the time.

Reply | Threaded
Open this post in threaded view
|

Re: usr.sbin/wake removal

Johan Beisser
I'd gladly trade look(1) for wake(8).

That's almost 8k right there.

On 2/9/09, Emilio Perea <[hidden email]> wrote:

> On Mon, Feb 09, 2009 at 09:05:13PM +1300, Richard Toohey wrote:
>> On 9/02/2009, at 6:31 PM, Thomas Pfaff wrote:
>>
>>> I think this could use some explaining for those of us that are not
>>> intimately involved in development or have been around here for that
>>> long.  Keeping it small and simple by saying no to adding one file
>>> at 7.2K?  I'd really like to know the rationale on this one.
>>>
>>> Thanks.
>>
>> My guess would be that I want this 10K util, you want that 7.2K util,
>> Fred wants that 20K util, and every Tom, Dick, and Harry wants
>> their n K ... who gets to make the rules, who gets to administer it,
>> etc.?
>> (Who gets to listen to everyone arguing why this or that should go in?)
>>
>> And guess there may be ramifications for install media?
>
> If there is no room in base, it would be nice to have it in ports.  Or
> is there something else in ports already that does the same thing?  I've
> found wake extremely useful for turning on remote desktop computers from
> the Soekris firewall rather than leaving them on all the time.

Reply | Threaded
Open this post in threaded view
|

Re: usr.sbin/wake removal

STeve Andre'
In reply to this post by Emilio Perea
On Monday 09 February 2009 11:15:25 Emilio Perea wrote:

> On Mon, Feb 09, 2009 at 09:05:13PM +1300, Richard Toohey wrote:
> > On 9/02/2009, at 6:31 PM, Thomas Pfaff wrote:
> >> I think this could use some explaining for those of us that are not
> >> intimately involved in development or have been around here for that
> >> long.  Keeping it small and simple by saying no to adding one file
> >> at 7.2K?  I'd really like to know the rationale on this one.
> >>
> >> Thanks.
> >
> > My guess would be that I want this 10K util, you want that 7.2K util,
> > Fred wants that 20K util, and every Tom, Dick, and Harry wants
> > their n K ... who gets to make the rules, who gets to administer it,
> > etc.?
> > (Who gets to listen to everyone arguing why this or that should go in?)
> >
> > And guess there may be ramifications for install media?
>
> If there is no room in base, it would be nice to have it in ports.  Or
> is there something else in ports already that does the same thing?  I've
> found wake extremely useful for turning on remote desktop computers from
> the Soekris firewall rather than leaving them on all the time.

/usr/ports/net/wol has existed for some time now.  I like the idea of
a builtin wake more though.

You can always keep a copy of it and build it yourself.  Thats what I've
done.

--STeve Andre'

Reply | Threaded
Open this post in threaded view
|

Re: usr.sbin/wake removal

Brian Keefer
In reply to this post by Thomas Pfaff-5
On Feb 8, 2009, at 9:31 PM, Thomas Pfaff wrote:

> On Sun, 8 Feb 2009 15:53:01 -0700 (MST)
> Marc Balmer <[hidden email]> wrote:
>
>> CVSROOT: /cvs
>> Module name: src
>> Changes by: [hidden email] 2009/02/08 15:53:01
>>
>> Removed files:
>> usr.sbin/wake  : Makefile wake.8 wake.c
>>
>> Log message:
>> Remove wake(8).  The bin directories are full, no new commands to  
>> be added.
>
> I think this could use some explaining for those of us that are not
> intimately involved in development or have been around here for that
> long.  Keeping it small and simple by saying no to adding one file
> at 7.2K?  I'd really like to know the rationale on this one.
>
> Thanks.
>

I'm curious about this as well.  What sort of resource limitation is  
being hit here?

--
bk

Reply | Threaded
Open this post in threaded view
|

Re: usr.sbin/wake removal

Tobias Ulmer
On Mon, Feb 09, 2009 at 11:00:03AM -0800, Brian Keefer wrote:

> On Feb 8, 2009, at 9:31 PM, Thomas Pfaff wrote:
>
>> On Sun, 8 Feb 2009 15:53:01 -0700 (MST)
>> Marc Balmer <[hidden email]> wrote:
>>
>>> CVSROOT: /cvs
>>> Module name: src
>>> Changes by: [hidden email] 2009/02/08 15:53:01
>>>
>>> Removed files:
>>> usr.sbin/wake  : Makefile wake.8 wake.c
>>>
>>> Log message:
>>> Remove wake(8).  The bin directories are full, no new commands to be
>>> added.
>>
>> I think this could use some explaining for those of us that are not
>> intimately involved in development or have been around here for that
>> long.  Keeping it small and simple by saying no to adding one file
>> at 7.2K?  I'd really like to know the rationale on this one.
>>
>> Thanks.
>>
>
> I'm curious about this as well.  What sort of resource limitation is  
> being hit here?

EINTERNALPOLITICS

>
> --
> bk

Reply | Threaded
Open this post in threaded view
|

Re: usr.sbin/wake removal

Landry Breuil-4
In reply to this post by Emilio Perea
On Mon, Feb 9, 2009 at 5:15 PM, Emilio Perea <[hidden email]> wrote:

> If there is no room in base, it would be nice to have it in ports.

There's no more room in ports either.

Landry

Reply | Threaded
Open this post in threaded view
|

Re: usr.sbin/wake removal

Ted Unangst-2
In reply to this post by Thomas Pfaff-5
On Mon, Feb 9, 2009 at 12:31 AM, Thomas Pfaff <[hidden email]> wrote:

> I think this could use some explaining for those of us that are not
> intimately involved in development or have been around here for that
> long.  Keeping it small and simple by saying no to adding one file
> at 7.2K?  I'd really like to know the rationale on this one.

I'm kinda amazed at the hoopla over this.  Last week a wake on lan
utility was like the only possible feature not being requested, you
didn't even know you wanted it, and now a week later it's like people
can't live without it.  Yeah, it's handy, but if you survived 10 years
without it, I think you can get by a little longer.

Things usually happen for a reason (though I've no idea what they are
here), but at least wait until the dust settles before starting the
inquisition.  Nothing speeds progress like a dozen "how come?"s at
every step.

Reply | Threaded
Open this post in threaded view
|

Re: usr.sbin/wake removal

Thomas Pfaff-5
On Mon, 9 Feb 2009 15:14:48 -0500
Ted Unangst <[hidden email]> wrote:

> On Mon, Feb 9, 2009 at 12:31 AM, Thomas Pfaff <[hidden email]> wrote:
>
> > I think this could use some explaining for those of us that are not
> > intimately involved in development or have been around here for that
> > long.  Keeping it small and simple by saying no to adding one file
> > at 7.2K?  I'd really like to know the rationale on this one.
>
> I'm kinda amazed at the hoopla over this.

Yes, a lot of hoopla; patches flying around, undeadly.org coverage,
and then zap for no apparent reason.  Not that it matters a great
deal, but it does make one raise an eyebrow or three.

> Last week a wake on lan utility was like the only possible feature
> not being requested, you didn't even know you wanted it, and now a
> week later it's like people can't live without it.  Yeah, it's handy,
> but if you survived 10 years without it, I think you can get by a
> little longer.

net/wol has been working for me just fine, so I'm in no need of
another utility (although I do like wake better).

Thanks.

Thomas

Reply | Threaded
Open this post in threaded view
|

Re: usr.sbin/wake removal

Bryan Steele-2
In reply to this post by Thomas Pfaff-5
Hey,

The removal of this utility is unfortunate, but not the end of the
world.. the ports database at openports.se didn't list net/wol but I
contacted them and they gratefully corrected it.

Still, having such functionality in the base system.. without
requiring devel/gettext.. would be nice. :-)

Could something like the following be considered? not as-is probably,
I'm not the best programmer on earth.. and maybe it should be part of
ping(1) instead?

Example: sudo ifconfig int wake 00:00:00:00:00:00

The code is respectfully copy & pasted from the old wake(8), written
by Marc Balmer/Eugene M. Kim.

-Brynet

[demime 1.01d removed an attachment of type application/octet-stream which had a name of ifconfig-wol.diff]

Reply | Threaded
Open this post in threaded view
|

Re: usr.sbin/wake removal

Bryan Steele-2
In reply to this post by Thomas Pfaff-5
I totally forgot about demime, shame on me.. :-)

Index: ifconfig.8
===================================================================
RCS file: /cvs/src/sbin/ifconfig/ifconfig.8,v
retrieving revision 1.173
diff -u -r1.173 ifconfig.8
--- ifconfig.8 12 Dec 2008 22:09:26 -0000 1.173
+++ ifconfig.8 10 Feb 2009 22:50:27 -0000
@@ -412,6 +412,15 @@
 It happens automatically when setting the first address on an interface.
 If the interface was reset when previously marked down,
 the hardware will be re-initialized.
+.It Cm wake Ar etheraddr
+Sends a Wake on LAN (WoL) frame over a local Ethernet network using a
+link-layer (hardware) address.
+.Ar etheraddr
+is the link layer address of the remote machine
+and can be specified as an actual hardware address
+(six hexadecimal numbers separated by colons)
+or as a hostname entry in
+.Pa /etc/ethers .
 .El
 .Pp
 .Nm
@@ -1237,6 +1246,7 @@
 .Xr hostname.if 5 ,
 .Xr hosts 5 ,
 .Xr networks 5 ,
+.Xr ethers 5 ,
 .Xr rc 8 ,
 .Xr tcpdump 8
 .Sh HISTORY
Index: ifconfig.c
===================================================================
RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
retrieving revision 1.211
diff -u -r1.211 ifconfig.c
--- ifconfig.c 6 Feb 2009 22:07:04 -0000 1.211
+++ ifconfig.c 10 Feb 2009 22:50:28 -0000
@@ -64,6 +64,9 @@
 #include <sys/socket.h>
 #include <sys/ioctl.h>

+#ifndef SMALL
+#include <net/bpf.h>
+#endif /* SMALL */
 #include <net/if.h>
 #include <net/if_dl.h>
 #include <net/if_media.h>
@@ -98,6 +101,9 @@
 #include <ctype.h>
 #include <err.h>
 #include <errno.h>
+#ifndef SMALL
+#include <fcntl.h>
+#endif /* SMALL */
 #include <stdio.h>
 #include <stdlib.h>
 #include <string.h>
@@ -240,7 +246,22 @@
 void unsetpflow_sender(const char *, int);
 void setpflow_receiver(const char *, int);
 void unsetpflow_receiver(const char *, int);
+
+#ifndef BPF_PATH_FORMAT
+#define BPF_PATH_FORMAT "/dev/bpf%u"
+#endif
+#ifndef SYNC_LEN
+#define SYNC_LEN 6
 #endif
+#ifndef DESTADDR_COUNT
+#define DESTADDR_COUNT 16
+#endif
+void wolhandler(const char *, int);
+int get_bpf(void);
+int bind_if_to_bpf(char const *, int);
+int get_ether(char const *, struct ether_addr *);
+int send_wakeup(int, struct ether_addr const *);
+#endif /* SMALL */

 /*
  * Media stuff.  Whenever a media command is first performed, the
@@ -409,7 +430,8 @@
  { "-flowsrc", 1, 0, unsetpflow_sender },
  { "flowdst", NEXTARG, 0, setpflow_receiver },
  { "-flowdst", 1, 0, unsetpflow_receiver },
-#endif
+ { "wake", NEXTARG, 0, wolhandler },
+#endif /* SMALL */
  { NULL, /*src*/ 0, 0, setifaddr },
  { NULL, /*dst*/ 0, 0, setifdstaddr },
  { NULL, /*illegal*/0, 0, NULL },
@@ -4572,3 +4594,104 @@
  warn("SIOCSIFLLADDR");
 }

+#ifndef SMALL
+void
+wolhandler(const char *addr, int param)
+{
+ int bpf;
+ struct ether_addr macaddr;
+
+ bpf = get_bpf();
+ if (bpf == -1 ||
+    bind_if_to_bpf(name, bpf) == -1 ||
+    get_ether(addr, &macaddr) == -1 ||
+    send_wakeup(bpf, &macaddr) == -1) {
+ warn("error sending Wake on LAN frame over %s to %s",
+    name, addr);
+ }
+ (void)close(bpf);
+ return;
+}
+
+int
+get_bpf(void)
+{
+ int i, fd;
+ char path[MAXPATHLEN];
+
+ for (i = 0;; i++) {
+ if (snprintf(path, sizeof(path), BPF_PATH_FORMAT, i) == -1)
+ return -1;
+
+ fd = open(path, O_RDWR);
+ if (fd != -1)
+ return fd;
+ if (errno == EBUSY)
+ continue;
+ break;
+ }
+ return -1;
+}
+
+int
+bind_if_to_bpf(char const *ifname, int bpf)
+{
+ struct ifreq ifr;
+ u_int dlt;
+
+ if (strlcpy(ifr.ifr_name, ifname, sizeof(ifr.ifr_name)) >=
+    sizeof(ifr.ifr_name))
+ return -1;
+ if (ioctl(bpf, BIOCSETIF, &ifr) == -1)
+ return -1;
+ if (ioctl(bpf, BIOCGDLT, &dlt) == -1)
+ return -1;
+ if (dlt != DLT_EN10MB)
+ return -1;
+ return 0;
+}
+
+int
+get_ether(char const *text, struct ether_addr *addr)
+{
+ struct ether_addr *paddr;
+ paddr = ether_aton(text);
+ if (paddr != NULL) {
+ *addr = *paddr;
+ return 0;
+ }
+ if (ether_hostton(text, addr))
+ return -1;
+ return 0;
+}
+
+int
+send_wakeup(int bpf, struct ether_addr const *addr)
+{
+ struct {
+ struct ether_header hdr;
+ u_char data[SYNC_LEN + ETHER_ADDR_LEN * DESTADDR_COUNT];
+ } pkt;
+ u_char *p;
+ int i;
+ ssize_t bw;
+ ssize_t len;
+
+ (void)memset(pkt.hdr.ether_dhost, 0xff, sizeof(pkt.hdr.ether_dhost));
+ pkt.hdr.ether_type = htons(0);
+ (void)memset(pkt.data, 0xff, SYNC_LEN);
+ for (p = pkt.data + SYNC_LEN, i = 0; i < DESTADDR_COUNT;
+    p += ETHER_ADDR_LEN, i++)
+ bcopy(addr->ether_addr_octet, p, ETHER_ADDR_LEN);
+ p = (u_char *)&pkt;
+ len = sizeof(pkt);
+ bw = 0;
+ while (len) {
+ if ((bw = write(bpf, &pkt, sizeof(pkt))) == -1)
+ return -1;
+ len -= bw;
+ p += bw;
+ }
+ return 0;
+}
+#endif /* SMALL */

Reply | Threaded
Open this post in threaded view
|

Re: usr.sbin/wake removal

Marc Balmer-2
In reply to this post by Bryan Steele-2
Am 10.02.2009 um 23:59 schrieb Brynet:

> Hey,
>
> The removal of this utility is unfortunate, but not the end of the
> world.. the ports database at openports.se didn't list net/wol but I
> contacted them and they gratefully corrected it.
>
> Still, having such functionality in the base system.. without
> requiring devel/gettext.. would be nice. :-)
>
> Could something like the following be considered? not as-is probably,
> I'm not the best programmer on earth.. and maybe it should be part of
> ping(1) instead?
>
> Example: sudo ifconfig int wake 00:00:00:00:00:00
>
> The code is respectfully copy & pasted from the old wake(8), written
> by Marc Balmer/Eugene M. Kim.

wake was added to the tree for some reason.
it was then removed for some reason.

now we look at what is the best place for this
functionality.

I'd honestly prefer if we could close the wake
discussion for now.  we will eventually come
up with a solution.

>
>
> -Brynet
>
> [demime 1.01d removed an attachment of type application/octet-stream  
> which had a name of ifconfig-wol.diff]