So again, to answer my own question. PacketReceived basically IS PacketInMessage. The translators pull off various bits and add them to PacketReceived. The “payload” of the PacketReceived is effectively the inner packet payload. This reminds me a bit of how an SSL termination proxy works. This unfortunately for me was not clear in any of the documentation I read. But I figured it out.
One thing before I stop sending these emails (that nobody is reading/replying to anyway). Ipv4Packet doesn’t override the getPayload method. That is kind of rude. I expected my decoder for the TCP header to work just fine. Instead I had to print the raw packet as hex to realize that the getPayload method was returning the entire packet (starting with the ethernet frame). Oh it is also pretty annoying to have the OpenflowProtocolListener inherit from NotificationListener, implying that you can register an implementation with the NotificationServiceProvider, when in reality it will do literally nothing. I’m sure all of you know what can and can’t be registered, but for a “mere mortal” like me knowing what can and can’t be registered was literally grabbing random things in the dark and plugging them in to see if they did anything. The direction I was looking for was pretty simple. I wanted to know how to receive or create a PacketInMessage from a PacketReceived message. The reality is that I already had what I needed, but the nature of the data enclosed was at a different layer than I expected. -Ryan Dietrich > On May 9, 2016, at 2:11 PM, Ryan Dietrich <[email protected]> wrote: > > Alternative approaches to get a PacketInMessage into my southbound plugin. > > 1. Figure out how to add a second OpenflowProtocolListener to > “ConnectionManagerImpl”. (It appears this can only have a single value). > Also looked at ConnectionAdapterImpl, as that is where PacketInMessages are > dispatched from. > 2. Try to figure out how to transform a “PacketReceived” into a > “PacketInMessage”. There are plenty of classes that do the opposite > (openflowplugin/openflowplugin-impl/src/main/java/org/opendaylight/openflowplugin/impl/translator/PacketReceivedTranslator.java) > 3. Try to figure out how to access MDController from within my plugin, so I > can register an additional Translator for PacketInMessage. (The tests use the > getMessageTranslators function, but MDController doesn’t seem to be a > singleton that I can access from within my plugin, I looked in > OpenflowPluginProvider). > 4. Figure out how a PacketInMessage is instantiated, and work backwards from > there. I started with PacketInMessageBuilder, then to > PacketInMessageFactory, then to MessageDeserializerInitializer. (I got lost > while trying to figure out what is calling the > 5. See if “MessageSpy” lets me subscribe to PacketInMessages? > > I’m still digging. I’ve been reading the docs as well, the file below > confirmed the tracing I had done by hand, but didn’t show my any entry points > where a southbound plugin can access or the data as it is being processed. > (my primary goal is to not alter any source code of any of my dependencies, > just have my own little plugin off to the side) > > docs/manuals/developer-guide/src/main/asciidoc/openflowjava/odl-openflowjava-protocol-dev.adoc > > Again, any direction on how to receive PacketInMessages in a southbound > plugin, or how to transform a “PacketReceived” into a “PacketInMessage” would > be appreciated. > > -Ryan Dietrich > > >> On May 6, 2016, at 3:13 PM, Luis Gomez <[email protected] >> <mailto:[email protected]>> wrote: >> >> cc-ing openflow people. >> >>> On May 6, 2016, at 1:41 PM, Ryan Dietrich <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> So, I have a working southbound plugin using the PacketProcessingListener. >>> My goal is to read the payload of the OpenFlow 1.3 “PacketIn” message. >>> This “per packet” approach seems unwieldy, as I am parsing both the >>> Ethernet header as well as the IP and TCP headers. Is there a “shortcut” ? >>> >>> I went searching for a simpler approach and found this file: >>> >>> controller/opendaylight/md-sal/sal-binding-broker/src/main/java/org/opendaylight/controller/md/sal/binding/impl/BindingDOMNotificationServiceAdapter.java >>> >>> This is what my plugin calls when it registers itself as a packet handler >>> (implementing the “onPacketReceived”). >>> >>> 1. I tried to create another listener using the “OpenflowProtocolListener”, >>> and used the same approach to register it, but it is never called (I have >>> an OVS pointed to my controller, and the PacketProcessingListener is >>> logging like crazy). Do I need to add anything to my yang file beyond the >>> notification service? Or some other configuration that is not immediately >>> apparent? >>> >>> 2. Can you even listen to PacketInMessage using the notification service? >>> Or are they considered RPC, and do you implement that differently (similar >>> to how Toaster implements RPC)? >>> >>> … >>> >>> Long story short, I’m currently using the PacketProcessingListener, and I >>> tried to use OpenflowProtocolListener the same way, to get the >>> “onPacketInMessage” to fire, but it is not working, and I’m not sure if it >>> is configuration related, or me doing something totally incorrect. >>> >>> Thanks to anyone who can give me a pointer in the right direction. >>> >>> -Ryan Dietrich >>> _______________________________________________ >>> controller-dev mailing list >>> [email protected] >>> <mailto:[email protected]> >>> https://lists.opendaylight.org/mailman/listinfo/controller-dev >>> <https://lists.opendaylight.org/mailman/listinfo/controller-dev> >> > > _______________________________________________ > openflowplugin-dev mailing list > [email protected] > https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
