[OPNFLWPLUG-66] Netty Decode Exception Created: 31/Jan/14  Updated: 27/Sep/21  Resolved: 21/Apr/14

Status: Resolved
Project: OpenFlowPlugin
Component/s: General
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Brent Salisbury Assignee: Brent Salisbury
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: Other


External issue ID: 398

 Description   

Figured I would open a case on this Netty decode exception. Mainly to see if there is anything I can assist with in data collection for you guys or if we are implementing something improperly on the OVSDB end. We also use Netty for socket IO. The OVSDB socket stays up but the OF ports go down. That said we have a similar issue lurking ourselves but have not had time to debug in the past couple of days w/ docs and everything else.

Here is a quick output of the logs. Just let me know if I can help with more information or jump on a Webex for a screenshare of the scenario which is pretty simple. OVS 2.0.9 running on a single host. That host is also running the vanilla virtualization distribution distributions-virtualization-0.1.0-SNAPSHOT-osgipackage.zip

Gist w/ the error snippets.
https://gist.github.com/38715b32bfd8a2dbe2d1

Cheers,
-Brent



 Comments   
Comment by Michal Rehak [ 10/Mar/14 ]

Hi Brent,
could you provide more detail? Can I replicate the scenario locally?

Reading logs I got feeling like the messages got shifted or something and suddenly there is rubbish instead of version negotiation. This could be caused by bug in netty, where sliced buffer is getting overwritten as the next message is shifted to beginning of buffer. Similar issue is being solved at OPNFLWJAVA-15. That behavior by slicing should be fixed in netty-4.0.12.Final.

By the way - in logs there is warning that there are 2 ports assigned to packetIn: one is in inPort field and the other in match entry (or both are in match entries). And then plugin can not decide which port is the right one if 2 different port numbers are extracted.

Regards,
Michal

Comment by Abhijit Kumbhare [ 24/Mar/14 ]

Any update Brent?

Comment by Abhijit Kumbhare [ 14/Apr/14 ]

As per Michal's comment above - the behavior by slicing should be fixed in netty-4.0.12.Final.

Please check.

Comment by Abhijit Kumbhare [ 14/Apr/14 ]

Brent - can you confirm if still occurs?

Comment by Brent Salisbury [ 21/Apr/14 ]

(In reply to Abhijit Kumbhare from comment #4)
> Brent - can you confirm if still occurs?

Sorry I missed the request last week. I am still seeing it. Here were some logs I gave posted to the ODL-OF irc channel.

https://www.dropbox.com/s/oj4js8v3vhmnh71/OF13-Netty.io.DeserializationError.zip

https://www.dropbox.com/s/1t2g36ekv4m0epi/OF13-Netty.io.DeserializationError-mar25-%28See-Packet-Number-113649%29.pcapng

https://lists.opendaylight.org/pipermail/controller-dev/2014-April/003891.html

Comment by Brent Salisbury [ 21/Apr/14 ]

(In reply to Brent Salisbury from comment #5)
> (In reply to Abhijit Kumbhare from comment #4)
> > Brent - can you confirm if still occurs?
>
> Sorry I missed the request last week. I am still seeing it. Here were some
> logs I gave posted to the ODL-OF irc channel.
>
> https://www.dropbox.com/s/oj4js8v3vhmnh71/OF13-Netty.io.DeserializationError.
> zip
>
> https://www.dropbox.com/s/1t2g36ekv4m0epi/OF13-Netty.io.DeserializationError-
> mar25-%28See-Packet-Number-113649%29.pcapng
>
> https://lists.opendaylight.org/pipermail/controller-dev/2014-April/003891.
> html <-ignore this, I thought it was another thread regarding the multiple port complaints.

Argh, that was the wrong thread I pasted. I will verify and also look at Michals helpful comment on the multiple port information. I spent the weekend digging into the OFPlugin and OFJava bundles for extensions and have a understanding of the patterns now so hopefully will be able to assist with patches rather then bug reports in the future.

Appreciate the help guys,
Brent

Generated at Wed Feb 07 20:31:29 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.