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, 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, Pennsylvania 19026

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, Pennsylvania 19026

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), and
does macaddr support like xx:xx:xx% lookups? if so, give them
the tool to make their own DB.).

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.).

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