Connection Mgr issue

Luis Gomez

Hi ovsdb devs,

I am writing to you because since some time ago I am seeing some OSGI console errors when running the OVSDB test in Base edition:

And after some research I found out there is an issue in the connection manager the first time it connects to OVSDB server in mininet after controller starts. The issue is that the existing OF connections get bounced as you can see in this printout:

osgi> 2014-04-22 12:32:54.573 PDT [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - 00:00:00:00:00:00:00:02 is removed
2014-04-22 12:32:54.575 PDT [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch: is connected to the Controller
2014-04-22 12:32:54.765 PDT [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - 00:00:00:00:00:00:00:03 is removed
2014-04-22 12:32:54.770 PDT [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch: is connected to the Controller
2014-04-22 12:32:54.898 PDT [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - 00:00:00:00:00:00:00:01 is removed
2014-04-22 12:32:54.902 PDT [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch: is connected to the Controller

The steps to reproduce this are very simple:

- start controller base edition ./
- start mininet -tree,3
- Use connection mgr REST API to connect to OVS manager in mininet:, i.e.

Please let me know if you see this problem too and whether I should open a bug to ovsdb or controller project to fix it.


On Apr 22, 2014, at 7:59 AM, Brent Salisbury <brent.salisbury@...> wrote:

Thanks for the info Andre. Really appreciate you following up. Will get some better logging there. 


On Apr 21, 2014, at 7:20 PM, André Martins <aanm@...> wrote:

Hello Madhu,
sorry to bother you guys but I was around this for 2 days.
The fault is all mine, I thought you change the port of the controller from 6633 to 6640, but the 6640 is for the ovsdb.
I was running mininet as
$ sudo mn --switch ovsk --controller remote,ip=,port=6640 --topo single,3
So the openvswitch was trying to contact the ovsdb.
Thank you so much for the help.
André Martins

On 04/21/2014 02:51 PM, Madhu Venugopal wrote:
Hi Andre,

Thanks for the info. I see a potential issue in using the ByteSourceJsonBootstrapper for detecting the encoding.
This class looks for the BOM in the JSON stream to determine the encoding. But in addition, it also "auto-detects"
the encoding when BOM is absent. I think that auto-detection can cause issues with the way we are handling the
data stream. Since the OVSDB specification is strictly UTF-8 & there are no BOMs sent, am thinking of removing
the piece of code that checks for the encoding.

Can you please apply this patch : in your local repo and give it a try ?
Essentially, i have just commented out the piece of code that checks for the encoding in the decode() method of

BTW, the wireshark capture that you sent didnt capture the response to the "get_schema" RPC call. But I see the FIN
immediately after the get_schema call.

Please let us know if this patch works for you. We will continue to look into the issue.


On 4/21/14, 2:29 AM, André Martins wrote:
Hello Madhu,
I've tried with the netty 4.0.10 and the problem persists.
Inside the ovsdb/ovsdb/src/main/java/org/opendaylight/ovsdb/lib/jsonrpc/ line 82, I've put                 logger.trace("jsonEncoding.getJavaName() = {}", jsonEncoding.getJavaName());
Also, the buff content is 0x01, 0x0, 0x0, 0x08.
I'm using the 2.1.0 version of openvswith.
André Martins

On 04/21/2014 06:14 AM, Madhu Venugopal wrote:
Hi Andre,

As you notice in the Exception, we use Netty & we have a custom decoder : JsonRpcDecoder which handles the Initial
JSON decoding on the Netty pipeline before handing over to Jackson.

As per RFC 7047, OVSDB uses JSON-RPCv1.0 and only UTF-8 encoding is supported from the ovsdb server side.
Hence, the performs a strict check on the data format and throw an InvalidEncodingException
exception if it detects a non UTF-8 format. So, this is a deliberate exception and should be expected if the data format
is anything other than UTF-8.

Can you please help explain how you debugged the problem to spot the UTF-16LE and are you using stock OpenVSwitch
when you hit this problem ?

It could be unrelated, but in March timeframe there was a commit that bumped the Netty version to 4.0.17 in the controller
project (and persumably on integration as well).


On 4/20/14, 8:45 PM, André Martins wrote:
Thannk you for the response Brent,
I've just download the zip from that link with ./ -of13 -debug
I'm developing a bundle to opendaylight but I didn't pull the controller repo since around April 1st, before that everything worked.
I've tried to checkout the controller's repo to a commit before April 1st but after I do both controller and integration project
a mvn clean install, the problem doesn't go away.
$ sudo ovs-vsctl show
$ Sudo ovs-vsctl --version
ovs-vsctl (Open vSwitch) 2.1.0
Compiled Apr 20 2014 02:12:48

$ sudo ovsdb-client dump

Wireshark capture is attached in this email and the opendaylight.log
I could debug that where this exception is throw the data is UTF-16LE.
André Martins

On 04/21/2014 04:04 AM, Brent Salisbury wrote:
Hi Andre,
If you can provide some additional information about your environment we can figure out the root of the issue.

- QDescription how you are using the OVSDB plugin, e.g. API calls via Postman, the AD_SAL API,  Neutron (doubtful since you are using the base edition) etc.
$ sudo ovs-vsctl show  -- (Share command outputs via a public gist/pastebin/etc or attach as a text file)
$ sudo ovs-vsctl --version 
$ sudo ovsdb-client dump 
- if up to it, upload a packet capture to a public fileshare containing the unhandled transaction to see what is on the wire and not getting deserialized by Netty. In Wireshark filtering on " tcp.port == 6640 " without quotes and exporting only the filtered packets will give us the relevant information about the problematic method. 

I am adding the ovsdb-dev@... listserv as this will be an OVSDB plugin specific issue if you will drop controller-dev on your reply. Leaving it for this email to communicate the handoff. Also if more convenient for you we can work through this realtime on channel #opendaylight-ovsdb 

Thanks for the assistance and interest,

From: André Martins <aanm@...>
Date: Sunday, April 20, 2014 at 1:56 PM
To: <controller-dev@...>
Subject: [controller-dev] Huge problem - InvalidEncodingException: currently only UTF-8 is supported

I'm having a huge problem running opendaylight with openvswitch.
When openvswitch tries to connect opendaylight, this happens in opendaylight's terminal.

2014-04-20 07:06:14.161 WEST [nioEventLoopGroup-6-4] WARN - An exceptionCaught() event was fired, and it reached at the tail of the pipeline. It usually means the last handler in the pipeline did not handle the exception.
io.netty.handler.codec.DecoderException: org.opendaylight.ovsdb.lib.jsonrpc.InvalidEncodingException: currently only UTF-8 is supported
        at io.netty.handler.codec.ByteToMessageDecoder.callDecode( ~[na:na]
        at io.netty.handler.codec.ByteToMessageDecoder.channelInactive( ~[na:na]
        at [bundlefile:4.0.17.Final]
        at [bundlefile:4.0.17.Final]
        at [bundlefile:4.0.17.Final]
        at io.netty.handler.logging.LoggingHandler.channelInactive( [bundlefile:4.0.17.Final]
        at [bundlefile:4.0.17.Final]
        at [bundlefile:4.0.17.Final]
        at [bundlefile:4.0.17.Final]
        at$AbstractUnsafe$ [bundlefile:4.0.17.Final]
        at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks( [bundlefile:4.0.17.Final]
        at [bundlefile:4.0.17.Final]
        at io.netty.util.concurrent.SingleThreadEventExecutor$ [bundlefile:4.0.17.Final]
        at [na:1.7.0_51]
Caused by: org.opendaylight.ovsdb.lib.jsonrpc.InvalidEncodingException: currently only UTF-8 is supported
        at org.opendaylight.ovsdb.lib.jsonrpc.JsonRpcDecoder.decode( ~[na:na]
        at io.netty.handler.codec.ByteToMessageDecoder.callDecode( ~[na:na]
        ... 13 common frames omitted

I'm running the
with the ./ -of13 -debug options
André Martins
_______________________________________________ controller-dev mailing list controller-dev@...

ovsdb-dev mailing list

controller-dev mailing list

Join { to automatically receive all group messages.