This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/ripe-atlas@ripe.net/
[atlas] Request for RIPE Atlas probe DHCP change.
- Previous message (by thread): [atlas] Request for RIPE Atlas probe DHCP change.
- Next message (by thread): [atlas] ATLAS as mechanism for route policy discovery
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Leo Bicknell
bicknell at ufp.org
Mon Apr 23 15:59:15 CEST 2012
In a message written on Mon, Apr 23, 2012 at 03:31:48PM +0200, Philip Homburg wrote:
> Looking into it. Client ID or Vendor Class? You are not supposed to set
> Client ID to something generic because it has to unique identify the
> device. Vendor Class is safe.
Client ID is what most of the home gateways present. I can think of
three ways it could be done:
1) Just use "ripeatlas" or a similar fixed string, and yes, there will
be "collisions". Plenty of other devices use this method and they
seem to work, although it's not the most RFC-complaint way to do
things.
2) Use a fixed string and part of the MAC. I've seen a number of
embedded devices use this method. "atlas-12:AB:56" or similar.
3) Actually set it based on the probe ID. I think this would be the
coolest option. "atlas-1234" or similar. I would think this could
be super-useful for folks setting up and testing more than one
probe, since all of the UI references them by probe ID.
I've never seen a home gateway display vendor class, but setting it
properly would also be a nice thing to do. :)
--
Leo Bicknell - bicknell at ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: </ripe/mail/archives/ripe-atlas/attachments/20120423/53996b9f/attachment.sig>
- Previous message (by thread): [atlas] Request for RIPE Atlas probe DHCP change.
- Next message (by thread): [atlas] ATLAS as mechanism for route policy discovery
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]