Authentication inheritance consistency when importing a reactor in a federated execution

[ChadliaJerad]

In a federated program that does not enable authentication (using auth C target property), importing a reactor from a file where authentication is required will cause the program to fail.

To reproduce, consider the following 2 lf programs:
R1.lf:

target C {
  auth: true
}
reactor R1 {
  input in: int
  reaction(in) {=
    lf_print("R1 reacted to input %d", in->value);
  =}
}

And IssueAuth.lf:

target C
import R1 from "R1.lf"
reactor R0 {
  output out: int
  state s: int = 0
  timer t(0, 100 ms)
  reaction(t) -> out {=
    self->s ++ ;
    lf_set(out, self->s);
    lf_print("R0 is sending %d.", self->s);
  =}
}

federated reactor {
  r1 = new R1()
  r0 = new R0()
  r0.out -> r1.in
}

Executing IssueAuth says:

DEBUG: RTI sending MSG_TYPE_REJECT.
ERROR: RTI expected a MSG_TYPE_FED_IDS message. Got 100 (see net_common.h).
Fed 0 (r1): WARNING: Failed to read RTI response.
Fed 0 (r1): Trying RTI again on port 15046.
Fed 0 (r1): Trying RTI again on port 15047.
Fed 0 (r1): Trying RTI again on port 15048.
Fed 0 (r1): Trying RTI again on port 15049.
...

The reason is that r1 wants to proceed with authentication (Message id 100), while the RTI is not expecting such a message, but rather the neighborhood structure.

[edwardalee]

It seems to me correct for this to fail, though I suppose it could generate a better error message.

[lhstrh]

@Jakio815 what should be the expected behavior here? I think that with the latest this will "just work," enabling auth automatically. But let me verify.

[lhstrh]

Indeed, it works now, but I'm pretty sure it won't work if, say, the main file imports two different files, one that does support auth and one that does not. Either way, let's consider this fixed for now.

[Jakio815]

Yeah, it seems to need to fail with a better error message. However, the federate does not know if the RTI is compiled with the -a option. So first, RTI should fail with sending a reject signal. I'll make a PR for this.

However, I'm not sure what happens to R0. R1 will start send a HMAC authentication, however, I don't know what will R0 will do. Will it inherit the target properties of the imported reactor?

[lhstrh]

However, I'm not sure what happens to R0. R1 will start send a HMAC authentication, however, I don't know what will R0 will do. Will it inherit the target properties of the imported reactor?

Now, yes.

[Jakio815]

Now, yes.

Great. Then I'll make the RTI send a failed signal.

[Jakio815]

It already seems to do send a failed signal. I'll just fix the error message.

[lhstrh]

It already seems to do send a failed signal. I'll just fix the error message.

I'm not sure I understand. The example as given compiles and runs in master.

[Jakio815]

Oh, I'll clarify the total thing.

So, no problems in compilation. The situation happens when federates are compiled using the auth:true option, and the RTI is 'not' executed using the -a or --auth option.

The federate will start sending MSG_TYPE_FED_NONCE, however the RTI will not expect it since the -a option is not on.

So, as Dr. Lee suggested to produce better error codes, I'll just add some better error messages, to turn on the -a option to make this work.

[lhstrh]

But is the given example expected to fail? Right now it just executes.

[Jakio815]

The example itself should not fail if the RTI was executed properly with the -a option.