Thread: mac.c
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
> 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
> > 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
> > 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, Pennsylvania19026
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
> 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, Pennsylvania19026
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. >
> 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, Pennsylvania19026
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
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