Thread: Update: mac.c update, patch now on ftp
I'm not sure whether my long post made it to the list, so I created a tarball of the patch and the awk script: ftp://ftp.lerctr.org/postgresql-patches/macupdate.tar.gz This has the patch file for mac.c to update the manufacturer list with the current list from IEEE and the awk script I ran against the IEEE's oui.txt file. This patch is relative to 7.0.0, but the file is the same in 7.0.2 the MD5 checksums are identical). Let me know if I can do anything else to help integrate this. 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
I am getting connection refused. Can you just send over a context diff of the old and new files? > I'm not sure whether my long post made it to the list, so I created > a tarball of the patch and the awk script: > > ftp://ftp.lerctr.org/postgresql-patches/macupdate.tar.gz > > This has the patch file for mac.c to update the manufacturer list with > the current list from IEEE and the awk script I ran against the IEEE's > oui.txt file. > > This patch is relative to 7.0.0, but the file is the same in 7.0.2 > the MD5 checksums are identical). > > Let me know if I can do anything else to help integrate this. > > 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 > -- 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
I sent a private copy to Bruce. My Firewall doesn't like PASV FTP, for future reference. Larry Rosenman -----Original Message----- From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] Sent: Monday, July 17, 2000 1:13 PM To: Larry Rosenman Cc: pgsql-hackers@hub.org; pgsql-patches@hub.org Subject: Re: [HACKERS] Update: mac.c update, patch now on ftp I am getting connection refused. Can you just send over a context diff of the old and new files? > I'm not sure whether my long post made it to the list, so I created > a tarball of the patch and the awk script: > > ftp://ftp.lerctr.org/postgresql-patches/macupdate.tar.gz > > This has the patch file for mac.c to update the manufacturer list with > the current list from IEEE and the awk script I ran against the IEEE's > oui.txt file. > > This patch is relative to 7.0.0, but the file is the same in 7.0.2 > the MD5 checksums are identical). > > Let me know if I can do anything else to help integrate this. > > 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 > -- 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
> > > > I'm not sure whether my long post made it to the list, so I created > > > > a tarball of the patch and the awk script: > > > > > > > > ftp://ftp.lerctr.org/postgresql-patches/macupdate.tar.gz > > > > > > > > This has the patch file for mac.c to update the manufacturer list with > > > > the current list from IEEE and the awk script I ran against the IEEE's > > > > oui.txt file. > > > > > > > > This patch is relative to 7.0.0, but the file is the same in 7.0.2 > > > > the MD5 checksums are identical). > > In looking at this patch, it changes mac.c from: > > 8513 mac.c > 184323 mac.c.new > > > This seems like a major size increase. Is it worth it to get > card manufacturers? Given that our list is old, and the new list is large, does anyone really want this feature. It allows the lookup of an ethernet card manufacturer based on the ethernet MAC address. -- 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
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> In looking at this patch, it changes mac.c from:
>>
>> 8513 mac.c
>> 184323 mac.c.new
Yipes.
>> This seems like a major size increase. Is it worth it to get
>> card manufacturers?
> Given that our list is old, and the new list is large, does anyone
> really want this feature. It allows the lookup of an ethernet card
> manufacturer based on the ethernet MAC address.
Seems like hardwiring the lookup table in the server code is
fundamentally wrongheaded anyway. It should have been designed as
(wait for it...) a database table lookup.
I'd suggest maybe this feature should be offered as a contrib item
containing a database table dump and a simple lookup function
coded in SQL. Lots easier to maintain, and it doesn't bloat the
backend for people who don't need it.
regards, tom lane
I just don't have the smarts to do the code for the backend. (strange thought:include my ouiparse.awk (changed to generate SQL inserts), anddoes macaddr support like xx:xx:xx% lookups?if so, give themthe tool to make their own DB.). The code in mac.c does a LINEAR search, and the list is only going togrow. It's at 4110+ OUI's that are PUBLIC.). Larry > Bruce Momjian <pgman@candle.pha.pa.us> writes: > >> In looking at this patch, it changes mac.c from: > >> > >> 8513 mac.c > >> 184323 mac.c.new > > Yipes. > > >> This seems like a major size increase. Is it worth it to get > >> card manufacturers? > > > Given that our list is old, and the new list is large, does anyone > > really want this feature. It allows the lookup of an ethernet card > > manufacturer based on the ethernet MAC address. > > Seems like hardwiring the lookup table in the server code is > fundamentally wrongheaded anyway. It should have been designed as > (wait for it...) a database table lookup. > > I'd suggest maybe this feature should be offered as a contrib item > containing a database table dump and a simple lookup function > coded in SQL. Lots easier to maintain, and it doesn't bloat the > backend for people who don't need it. > > regards, tom lane -- 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
> The code in mac.c does a LINEAR search, and the list is only going to
> grow. It's at 4110+ OUI's that are PUBLIC.).
Yuck. Let's put it into a (user loadable) table. And rather than having
macaddr_manuf(), we should just have a "sametype()" (or whatever) which
can compare an arbitrary mac address with another one. Then
select brand from mactypes where '03:04:...' = macmask;
or at least
select brand from mactypes where sametype('03:04:...',macmask);
would get you the right thing.
I can help with these internals, if that is the right way to head.
- Thomas
I was thinking of making the following:
1) macaddr_manuf function that returns the first 3 octets of a macaddr
2) a macaddr_manuf TYPE that can be used for the table
3) supply the ouiparse.awk to generate a set of INSERT statements to load a table
4) allow the above table to be indexed.
What does the group think of this?
Larry Rosenman
> > The code in mac.c does a LINEAR search, and the list is only going to
> > grow. It's at 4110+ OUI's that are PUBLIC.).
>
> Yuck. Let's put it into a (user loadable) table. And rather than having
> macaddr_manuf(), we should just have a "sametype()" (or whatever) which
> can compare an arbitrary mac address with another one. Then
>
> select brand from mactypes where '03:04:...' = macmask;
>
> or at least
>
> select brand from mactypes where sametype('03:04:...',macmask);
>
> would get you the right thing.
>
> I can help with these internals, if that is the right way to head.
>
> - 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
> I was thinking of making the following:
> 1) macaddr_manuf function that returns the first 3 octets of a macaddr
> 2) a macaddr_manuf TYPE that can be used for the table
> 3) supply the ouiparse.awk to generate a set of INSERT statements
> to load a table
> 4) allow the above table to be indexed.
Why not use a comparison function which knows how to compare just the
manufacturer's id fields? Or define a function which masks a mac address
to return the id fields and zeros everywhere else (so you can then use
the "normal" comparison functions)?
Defining a new type to allow this masking and comparison seems more than
necessary (which, if this argument holds up, would make it undesirable).
We can still define functional indices so that a table lookup will be
fast in any case.
- Thomas
Ok, how would one set this up (I've NEVER programmed in PG's backend, so I'm a little skittish). The changes I did for mac.c were obvious, so I'm afraid of breaking PG's world. Anything I can do? Larry > > I was thinking of making the following: > > 1) macaddr_manuf function that returns the first 3 octets of a macaddr > > 2) a macaddr_manuf TYPE that can be used for the table > > 3) supply the ouiparse.awk to generate a set of INSERT statements > > to load a table > > 4) allow the above table to be indexed. > > Why not use a comparison function which knows how to compare just the > manufacturer's id fields? Or define a function which masks a mac address > to return the id fields and zeros everywhere else (so you can then use > the "normal" comparison functions)? > > Defining a new type to allow this masking and comparison seems more than > necessary (which, if this argument holds up, would make it undesirable). > We can still define functional indices so that a table lookup will be > fast in any case. > > - 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