What can I do to help get this resolved?

I've gotten some suggestions, but I'm still at a loss to 
get the functionality (and I sure as heck don't want to break
the backend...).

I think what we've come up with is to store the manufacturer information
in a table (my ouiparse.awk script can be hacked to create the table). 

My concern is what do we use to store the first 3 octets of the 
macaddr into the table or how to do the partial match on an existing
macaddr type.

Larry Rosenman
-- 
Larry Rosenman                      http://www.lerctr.org/~ler
Phone: +1 972-414-9812 (voice) Internet: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

Sun, 23 Jul 2000 09:03:25 -0500 (CDT)
Larry Rosenman <ler@lerctr.org>
mac.c
> My concern is what do we use to store the first 3 octets of the
> macaddr into the table or how to do the partial match on an existing
> macaddr type.

I had tried to respond to this earlier. For some reason, my new dial-in
drop "can not find" some, but not all, mail addresses. Yours is
apparently on the "can't find" list, as is Jan's (yahoo.com *is* pretty
obscure :/

Anyway, tables are good, and we can make a function/operator pair which
compares mac addresses on manufacturer only. Should be pretty easy.
Shall we get started?

                     - Thomas

Sun, 23 Jul 2000 20:23:03 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: mac.c
> > My concern is what do we use to store the first 3 octets of the
> > macaddr into the table or how to do the partial match on an existing
> > macaddr type.
> 
> I had tried to respond to this earlier. For some reason, my new dial-in
> drop "can not find" some, but not all, mail addresses. Yours is
> apparently on the "can't find" list, as is Jan's (yahoo.com *is* pretty
> obscure :/
Hmm.  What ISP?  (I work for mine, and may be able to help them...). 


> 
> Anyway, tables are good, and we can make a function/operator pair which
> compares mac addresses on manufacturer only. Should be pretty easy.
> Shall we get started?
OK, but what do we put into the table as the key?  just a 
3 octet version of the OUI, or a full 6 octet, and use the function?

Thanks for the help.  

> 
>                      - Thomas


-- 
Larry Rosenman                      http://www.lerctr.org/~ler
Phone: +1 972-414-9812 (voice) Internet: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

Sun, 23 Jul 2000 15:49:25 -0500 (CDT)
Larry Rosenman <ler@lerctr.org>
Re: mac.c
> > Anyway, tables are good, and we can make a function/operator pair which
> > compares mac addresses on manufacturer only. Should be pretty easy.
> > Shall we get started?
>
> OK, but what do we put into the table as the key?  just a 
> 3 octet version of the OUI, or a full 6 octet, and use the function?
> 
> Thanks for the help.  

I hate to pour cold water on this, but it seems the whole idea of
having a database function to find the manufacturer from an ethernet
address is of questionable value.

Not that it can't be done in /contrib, but it is really important enough
to do?   I recommend just removing the function.  I doubt anyone would
miss it.

I have added a TODO item:

* Update macaddr manufacturer numbers, or remove the function macaddr_manuf()

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Wed, 26 Jul 2000 21:13:41 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: mac.c
All I want to do now (given the size stuff), is to have a function and
possibly a type to compare the 24-bit OUI's, and give the tools
in /contrib to load a table using these from the IEEE's list.

No more hardcoded stuff in the db. 

Does this make more sense?

It's definately extensible, and frees code space.

Larry
> > > Anyway, tables are good, and we can make a function/operator pair which
> > > compares mac addresses on manufacturer only. Should be pretty easy.
> > > Shall we get started?
> >
> > OK, but what do we put into the table as the key?  just a 
> > 3 octet version of the OUI, or a full 6 octet, and use the function?
> > 
> > Thanks for the help.  
> 
> I hate to pour cold water on this, but it seems the whole idea of
> having a database function to find the manufacturer from an ethernet
> address is of questionable value.
> 
> Not that it can't be done in /contrib, but it is really important enough
> to do?   I recommend just removing the function.  I doubt anyone would
> miss it.
> 
> I have added a TODO item:
> 
> * Update macaddr manufacturer numbers, or remove the function macaddr_manuf()
> 
> -- 
>   Bruce Momjian                        |  http://candle.pha.pa.us
>   pgman@candle.pha.pa.us               |  (610) 853-3000
>   +  If your life is a hard drive,     |  830 Blythe Avenue
>   +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026


-- 
Larry Rosenman                      http://www.lerctr.org/~ler
Phone: +1 972-414-9812 (voice) Internet: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

Wed, 26 Jul 2000 21:31:08 -0500 (CDT)
Larry Rosenman <ler@lerctr.org>
Re: mac.c
> All I want to do now (given the size stuff), is to have a function and
> possibly a type to compare the 24-bit OUI's, and give the tools
> in /contrib to load a table using these from the IEEE's list.
> 
> No more hardcoded stuff in the db. 
> 
> Does this make more sense?
> 
> It's definately extensible, and frees code space.

I was just wondering if there was any real demand for this feature.
-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Wed, 26 Jul 2000 23:54:31 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: mac.c
It'd be nice (tm). I am using mac address types now, and certainly going
to be upset if they just disappear in next postgres version :P)

However, this is definitely a contrib feature, not a core postgres item.

Probably the macaddr type should be also moved to that contrib directory.

I suggest that the contrib would include a query that creates mac_manuf
table and a 'macaddr_manuf(macaddr) returns varchar' function which would
do a 'select name from mac_manuf m where m.mac=mac_trunc(macaddr)' and a
'mac_trunc(macaddr) returns macaddr' which would set the 3 lowest-order
nibbles to 0.

(I don't think macmanufacturer deserves a separate type).

-alex

On Wed, 26 Jul 2000, Bruce Momjian wrote:

> > All I want to do now (given the size stuff), is to have a function and
> > possibly a type to compare the 24-bit OUI's, and give the tools
> > in /contrib to load a table using these from the IEEE's list.
> > 
> > No more hardcoded stuff in the db. 
> > 
> > Does this make more sense?
> > 
> > It's definately extensible, and frees code space.
> 
> I was just wondering if there was any real demand for this feature.
> 


Thu, 27 Jul 2000 00:11:21 -0400 (EDT)
Alex Pilosov <alex@pilosoft.com>
Re: mac.c
> It'd be nice (tm). I am using mac address types now, and certainly going
> to be upset if they just disappear in next postgres version :P)

No, I don't recommend removing the macaddr type.  It is fine in the main
tree.  It is just the function that maps ethernet address to
manufacturer that I am questioning.

> 
> However, this is definitely a contrib feature, not a core postgres item.
> 
> Probably the macaddr type should be also moved to that contrib directory.
> 
> I suggest that the contrib would include a query that creates mac_manuf
> table and a 'macaddr_manuf(macaddr) returns varchar' function which would
> do a 'select name from mac_manuf m where m.mac=mac_trunc(macaddr)' and a
> 'mac_trunc(macaddr) returns macaddr' which would set the 3 lowest-order
> nibbles to 0.
> 
> (I don't think macmanufacturer deserves a separate type).

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Thu, 27 Jul 2000 09:00:25 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: mac.c
On Thu, 27 Jul 2000, Bruce Momjian wrote:

> > It'd be nice (tm). I am using mac address types now, and certainly going
> > to be upset if they just disappear in next postgres version :P)
> 
> No, I don't recommend removing the macaddr type.  It is fine in the main
> tree.  It is just the function that maps ethernet address to
> manufacturer that I am questioning.

sounds to me like a contrib item too ... 

> > However, this is definitely a contrib feature, not a core postgres item.
> > 
> > Probably the macaddr type should be also moved to that contrib directory.
> > 
> > I suggest that the contrib would include a query that creates mac_manuf
> > table and a 'macaddr_manuf(macaddr) returns varchar' function which would
> > do a 'select name from mac_manuf m where m.mac=mac_trunc(macaddr)' and a
> > 'mac_trunc(macaddr) returns macaddr' which would set the 3 lowest-order
> > nibbles to 0.
> > 
> > (I don't think macmanufacturer deserves a separate type).
> 
> -- 
>   Bruce Momjian                        |  http://candle.pha.pa.us
>   pgman@candle.pha.pa.us               |  (610) 853-3000
>   +  If your life is a hard drive,     |  830 Blythe Avenue
>   +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
> 

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 


Thu, 27 Jul 2000 12:40:41 -0300 (ADT)
The Hermit Hacker <scrappy@hub.org>
Re: mac.c
At 11:54 PM -0400 7/26/00, Bruce Momjian wrote:
> > All I want to do now (given the size stuff), is to have a function and
> > possibly a type to compare the 24-bit OUI's, and give the tools
> > in /contrib to load a table using these from the IEEE's list.
> >
> > No more hardcoded stuff in the db.
> >
> > Does this make more sense?
> >
> > It's definately extensible, and frees code space.
>
>I was just wondering if there was any real demand for this feature.

Seems to me that code to deal with 24/48 bit integers is core, and 
everything else is contrib.  The actual list of manufacturers is not 
even Postgres, but IEEE and should have a URL or cross reference in 
contrib.

Just my opinion.


Signature failed Preliminary Design Review.
Feasibility of a new signature is currently being evaluated.
h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu

Fri, 28 Jul 2000 11:39:27 -0700
"Henry B. Hotz" <hotz@jpl.nasa.gov>
Re: mac.c