Connect via Net ID works without a problem.
I'm using meshctl with zephyr's mesh_shell (upstream version)
I provision the shell and turn on it's gatt-proxy. Then I exit meshctl,
run it again and issue a "connect 0". It reconnects to the mesh without
a problem.
If I turn off the shell's gatt-proxy, start meshctl, issue a
"connect 0" and then issue a shell "ident". I get no connection. The
ident command only transmits advertisements for a short period of time.
The CONN_TYPE_IDENTITY path in parse_mesh_service_data() seems broken.
The comparison of data[0] and connection.type fails. The value of
data[0] is 1 (CONN_TYPE_IDENTITY) and the value of connection.type is
0.
Below is sniffer output of the two advertisements.
Steve
Net ID Advertisement
systime=1512335672 freq=2402 addr=8e89bed6 delta_t=1000.969 ms rssi=-20
40 1a d0 59 81 b8 f1 cf 02 01 06 03 03 28 18 0c 16 28 18 00 d4 76 79 43 3f db 10 4a bf 47 10
Advertising / AA 8e89bed6 (valid)/ 26 bytes
Channel Index: 37
Type: ADV_IND
AdvA: cf:f1:b8:81:59:d0 (random)
AdvData: 02 01 06 03 03 28 18 0c 16 28 18 00 d4 76 79 43 3f db 10 4a
Type 01 (Flags)
00000110
LE General Discoverable Mode
BR/EDR Not Supported
Type 03 (16-bit Service UUIDs)
1828
Type 16 (Service Data)
UUID: 1828, Additional: 00 d4 76 79 43 3f db 10 4a
Data: d0 59 81 b8 f1 cf 02 01 06 03 03 28 18 0c 16 28 18 00 d4 76 79 43 3f db 10 4a
CRC: bf 47 10
Node Identity Advertisement
systime=1512335702 freq=2402 addr=8e89bed6 delta_t=30492.935 ms rssi=-19
40 22 d0 59 81 b8 f1 cf 02 01 06 03 03 28 18 14 16 28 18 01 cb 3b d5 82 b5 1f 32 00 c6 36 a1 be 9b 88 c5 b6 fd e1 b3
Advertising / AA 8e89bed6 (valid)/ 34 bytes
Channel Index: 37
Type: ADV_IND
AdvA: cf:f1:b8:81:59:d0 (random)
AdvData: 02 01 06 03 03 28 18 14 16 28 18 01 cb 3b d5 82 b5 1f 32 00 c6 36 a1 be 9b 88 c5 b6
Type 01 (Flags)
00000110
LE General Discoverable Mode
BR/EDR Not Supported
Type 03 (16-bit Service UUIDs)
1828
Type 16 (Service Data)
UUID: 1828, Additional: 01 cb 3b d5 82 b5 1f 32 00 c6 36 a1 be 9b 88 c5 b6
Data: d0 59 81 b8 f1 cf 02 01 06 03 03 28 18 14 16 28 18 01 cb 3b d5 82 b5 1f 32 00 c6 36 a1 be 9b 88 c5 b6
CRC: fd e1 b3
Hi Johan,
On Mon, 2017-12-04 at 17:05 +0200, Johan Hedberg wrote:
> Hi Steve,
>
> On Mon, Dec 04, 2017, Steve Brown wrote:
> > I added the command as you suggested.
> >
> > I had to change them to net-connect and node-connect because of
> > command
> > completion.
> >
> > If I issue a node-connect while the mesh-shell ident command is
> > active,
> > it connects.
> >
> > If you think there's interest, I'll post the patch.
>
> I think we should definitely add support for this upstream, but after
> thinking a bit more about it, maybe we could simply extend the
> existing
> connect command instead of adding a new one. Node Identity is always
> in
> the context of a given NetKey Index, so I think it'd be just as
> natural
> to have a second optional parameter to the existing connect command
> which would be the element address. If only one parameter is given
> then
> meshctl looks for Net ID, if two are given it looks for Node ID.
> Sounds
> reasonable?
>
> Johan
I'll do that. Saves lots of duplicated code.
Steve
Hi Steve,
On Mon, Dec 04, 2017, Steve Brown wrote:
> I added the command as you suggested.
>
> I had to change them to net-connect and node-connect because of command
> completion.
>
> If I issue a node-connect while the mesh-shell ident command is active,
> it connects.
>
> If you think there's interest, I'll post the patch.
I think we should definitely add support for this upstream, but after
thinking a bit more about it, maybe we could simply extend the existing
connect command instead of adding a new one. Node Identity is always in
the context of a given NetKey Index, so I think it'd be just as natural
to have a second optional parameter to the existing connect command
which would be the element address. If only one parameter is given then
meshctl looks for Net ID, if two are given it looks for Node ID. Sounds
reasonable?
Johan
Hi Johan,
On Mon, 2017-12-04 at 14:36 +0200, Johan Hedberg wrote:
> Hi Steve,
>
> On Sun, Dec 03, 2017, Steve Brown wrote:
> > Connect via Net ID works without a problem.
> >
> > I'm using meshctl with zephyr's mesh_shell (upstream version)
> >
> > I provision the shell and turn on it's gatt-proxy. Then I exit
> > meshctl,
> > run it again and issue a "connect 0". It reconnects to the mesh
> > without
> > a problem.
> >
> > If I turn off the shell's gatt-proxy, start meshctl, issue a
> > "connect 0" and then issue a shell "ident". I get no connection.
> > The
> > ident command only transmits advertisements for a short period of
> > time.
> >
> > The CONN_TYPE_IDENTITY path in parse_mesh_service_data() seems
> > broken.
> > The comparison of data[0] and connection.type fails. The value of
> > data[0] is 1 (CONN_TYPE_IDENTITY) and the value of connection.type
> > is
> > 0.
>
> Looking at mesh/main.c it seems to me like the connect command is
> currently only desgined for connecting to Network Identity
> advertisements (which is also implied by the fact that it takes a
> NetKey
> Index as an optional parameter value).
>
> What would be needed is some command which takes an element address
> rather than a NetKey Index as input. Just thinking out loud, but
> maybe
> "connect" should be renamed to "connect-net" and then a new
> "connect-node" command could be introduced that would look for Node
> Identity advertisements?
>
> Johan
I added the command as you suggested.
I had to change them to net-connect and node-connect because of command
completion.
If I issue a node-connect while the mesh-shell ident command is active,
it connects.
If you think there's interest, I'll post the patch.
Steve
Hi Johan,
On Mon, 2017-12-04 at 14:36 +0200, Johan Hedberg wrote:
> Hi Steve,
>
> On Sun, Dec 03, 2017, Steve Brown wrote:
> > Connect via Net ID works without a problem.
> >
> > I'm using meshctl with zephyr's mesh_shell (upstream version)
> >
> > I provision the shell and turn on it's gatt-proxy. Then I exit
> > meshctl,
> > run it again and issue a "connect 0". It reconnects to the mesh
> > without
> > a problem.
> >
> > If I turn off the shell's gatt-proxy, start meshctl, issue a
> > "connect 0" and then issue a shell "ident". I get no connection.
> > The
> > ident command only transmits advertisements for a short period of
> > time.
> >
> > The CONN_TYPE_IDENTITY path in parse_mesh_service_data() seems
> > broken.
> > The comparison of data[0] and connection.type fails. The value of
> > data[0] is 1 (CONN_TYPE_IDENTITY) and the value of connection.type
> > is
> > 0.
>
> Looking at mesh/main.c it seems to me like the connect command is
> currently only desgined for connecting to Network Identity
> advertisements (which is also implied by the fact that it takes a
> NetKey
> Index as an optional parameter value).
>
> What would be needed is some command which takes an element address
> rather than a NetKey Index as input. Just thinking out loud, but
> maybe
> "connect" should be renamed to "connect-net" and then a new
> "connect-node" command could be introduced that would look for Node
> Identity advertisements?
>
> Johan
It's obvious after you pointed it out. I hadn't appreciated the
distinction between the two types of advertisements. I'll try to do
what you suggest.
Steve
Hi Steve,
On Sun, Dec 03, 2017, Steve Brown wrote:
> Connect via Net ID works without a problem.
>
> I'm using meshctl with zephyr's mesh_shell (upstream version)
>
> I provision the shell and turn on it's gatt-proxy. Then I exit meshctl,
> run it again and issue a "connect 0". It reconnects to the mesh without
> a problem.
>
> If I turn off the shell's gatt-proxy, start meshctl, issue a
> "connect 0" and then issue a shell "ident". I get no connection. The
> ident command only transmits advertisements for a short period of time.
>
> The CONN_TYPE_IDENTITY path in parse_mesh_service_data() seems broken.
> The comparison of data[0] and connection.type fails. The value of
> data[0] is 1 (CONN_TYPE_IDENTITY) and the value of connection.type is
> 0.
Looking at mesh/main.c it seems to me like the connect command is
currently only desgined for connecting to Network Identity
advertisements (which is also implied by the fact that it takes a NetKey
Index as an optional parameter value).
What would be needed is some command which takes an element address
rather than a NetKey Index as input. Just thinking out loud, but maybe
"connect" should be renamed to "connect-net" and then a new
"connect-node" command could be introduced that would look for Node
Identity advertisements?
Johan