netdev - Re: [RFC v3 5/6] j1939: rename NAME to UUID?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110420071012.GA332@kurt.e-circ.dyndns.org>
Date:	Wed, 20 Apr 2011 09:10:12 +0200
From:	Kurt Van Dijck <kurt.van.dijck@....be>
To:	Oliver Hartkopp <socketcan@...tkopp.net>
Cc:	socketcan-core@...ts.berlios.de, netdev@...r.kernel.org
Subject: Re: [RFC v3 5/6] j1939: rename NAME to UUID?

On Fri, Apr 15, 2011 at 07:57:25PM +0200, Oliver Hartkopp wrote:
> On 13.04.2011 06:49, Kurt Van Dijck wrote:
> > Oliver et.al.,
> > 
> > On Sun, Mar 20, 2011 at 04:56:46PM +0100, Oliver Hartkopp wrote:
> >> On 14.03.2011 14:59, Kurt Van Dijck wrote:
> >>
> >> Then you suggest to attach static and/or dynamic addresses to the interface.
> >>
> >>> +  Assigning addresses is done via
> >>> +  $ ip addr add dev canX j1939 0xXX
> >>> +  statically or
> >>> +  $ ip addr add dev canX j1939 name 0xXX
> >>> +  dynamically. In the latter case, address claiming must take place
> >>> +  before other traffic can leave.
> >>
> >> like you would have using DHCP/DNS (adapted for j1939) ...
> >>
> > I suspect the confustion with DHCP/DNS comes free with the used terminology.
> > 
> > Specifications talk about a 64bit NAME, where is actually is a 64bit UUID.
> > Calling this number a UUID may clarify things, but leaves the spec in the
> > terminology.
> > 
> > one would then do:
> > $ ip addr add dev canX j1939 uuid XXXX
> > 
> > Would that be a good way to progress?
> 
> Hello Kurt,
> 
> i don't know if it helps - at least for j1939 users - to rename the NAME for
> j1939 address claiming to UUID which is usually 128 bit long an has a pretty
> different understanding than the J1939 NAME which stands for
> 
>    1. Arbitrary address bit
>    2. Industry group, length 3 bits
>    3. Vehicle system instance, length 4 bits
>    4. Vehicle system, length 7 bits
>    5. Reserved bit
>    6. Function, length 8 bits
>    7. Function instance, length 5 bits
>    8. ECU instance, length 3 bits
>    9. Manufacturer code, length 11 bits
>   10. Identity number, length 21 bits
> 
> (from http://www.kvaser.com/en/about-can/higher-layer-protocols/36.html)
> 
> This is not comparable to the ideas from RFC 4122 ...

please note that for address claiming, this interpretation should not be used
as such, and the whole 64bit NAME is regarded as a 'Unique Number' :-)

I was not aware of RFC 4122 :-)

Never mind this idea, I'll stick to 'NAME' as that is what j1939 users
are used to. I wanted to avoid people thinking on DNS, but I should not
introduce other misunderstandings.

Kurt
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html