Incorrect XID handling

[chgrivas]

Hi all,

It seems that there might be a problem with the way that the CPqD handles the XID of its RPC responses when it is first connected to a controller.

Here are two links from OpenDaylight and ONOS discussions which seem to have the same root problem caused by CPqD: OpenDaylight discussion ONOS discussion

In the above links it is mentioned that:

"The XID (see the change) wasn't used because CPqD switch didn't fully behave according to the specification (didn't reply with correct XID) - and as it turns out, it still doesn't. The first connection usually replies with random generated XID in features-reply, after we close the connection (approx. 30 seconds), the device connects successfully."

and

"The reason the connection failed the first time is that the switch sends an unsolicited STATS_REPLY when ONOS is expecting a CONFIG_REPLY. I'm not sure if this is something that ONOS should be able to handle, or if it is a bug that should be fixed in the CPqD switch. It's certainly different than the way all other switches behave."

Is the above an already known issue?

[ederlf]

Honestly I do not know about this issues. I remember seeing issues related to connection with ODL here, but never had proper time to test.

Since I'm not actively supporting the switch development, it is more and more likely that I will not be in touch with eventual errors, if they are not reported here.

I will take a look on that. Indeed, these problems seem to be connected. I believe it is caused by a message replied to the secchan (asked for the port-watcher) module. That message should not arrive the controllers, but looks like it is happening.

[disideriss]

Hello there,

Having the same issue. Is there any progress?

Thanks in advance!

[ederlf]

I have tested with the last version of ODL, and I could not detect the wrong behavior. I am closing this issue for now.