Error "missing Origin-State-Id" whilst using diam/sm. about go-diameter

[fiorix]

Sounds like the error you get is because the server you're connecting to does not respond with a CEA containing Origin-State-Id. Can you confirm that with a pcap?

[micrypt]

@fiorix You're absolutely correct. It's sending back an error message (3099).

   DIAMETER_INVALID_AVP_BITS          3009
      A request was received that included an AVP whose flag bits are
      set to an unrecognized value, or that is inconsistent with the
      AVP's definition.

Might it be worthwhile to override the CER within the state machine's handshake(), and is there a way to do this?

[micrypt]

@fiorix Curiously, the only way I've managed to get a valid CEA response thus far has been to completely remove the FirmwareRevision AVP.

https://github.com/fiorix/go-diameter/blob/master/diam/sm/client.go#L179

Would you be open to swapping out that line for the following, which also appears to work?
m.NewAVP(avp.FirmwareRevision, 0, 0, cli.Handler.cfg.FirmwareRevision)

[fiorix]

I see, the Firmware-Revision AVP is not mandatory but the state machine will always include it. We have to patch it and make this optional somehow. Not sure how I want this implemented, need to think about it. Can't do for e.g. if revision=0 does not include, but also don't want to add a boolean field to that struct. Ideas are welcome.

[fiorix]

Closing this in favor of #44.

[micrypt]

@fiorix Would you mind reopening this as it's not quite a fit with #44. It turns out the CEA truly doesn't include the Origin-State-Id AVP even when it is present in the CER. It responds with DIAMETER_SUCCESS but skips returning Origin-State-Id, at which point the state machine freaks outs. I suspect one ought to avoid throwing an error when it's not present in the answer. BTW, it does the same with the DWR/DWA cycle.

[fiorix]

Sure

[fiorix]

Could you please try this dev branch?