Re: [Ryu-devel] dropping packets error (OFPET_BAD_MATCH)

The error code is OFPBMC_BAD_PREREQ; you are missing a pre-requisite for ipv6_dst. Include eth_type = 0x86dd in your match. On Sun, Feb 10, 2019 at 7:36 AM Maged Motawea wrote: > > Dear Sir/Madam, > > I'm trying to drop packets that match an IP address using this code > > > class

Re: [Ryu-devel] CVE-2018-1000155: Denial of Service, Improper Authentication and, Authorization, and Covert Channel in the OpenFlow 1.0+ handshake

It sounds like a single compromised switch peer certificate can be used to impersonate other datapath_id's. From the advisory, it appears the controller-side fix is to verify the datapath_id received in the FeaturesReply against the peer cert before trusting it. Is it possible to use a naming

Re: [Ryu-devel] Uncaught exception in hello_failed (Python3)

Hi Iwase, On Mon, Feb 26, 2018 at 10:55 PM, Iwase Yusuke wrote: > > A little difference though, how about doing "encode" in parser classes as > the > following? If encoding is done in parser, the differences of Python2 and > Python3 > can be obscured against Ryu users.

[Ryu-devel] Uncaught exception in hello_failed (Python3)

Hi, There is an uncaught exception (Python3 only) when Ryu responds to a HELLO message because the OF version is incompatible. The Ryu app specifies that it is interested in OF 1.3 only, and the exception occurs when an OF 1.0 switch connects. Ref:

Re: [Ryu-devel] Error parsing ICMPv4 fragments

self.code, self.csum)) > > -if self.data is not None: > +if self.data: > if self.type in icmp._ICMP_TYPES: > hdr += self.data.serialize() > else: > > > Thanks, > Iwase > > > > On 2017年11月04日

[Ryu-devel] Error parsing ICMPv4 fragments

Hi, There is a TypeError exception with Ryu parsing fragmented ICMPv4 packets of a certain length. The attached program "ryu_icmpv4_test.py" demonstrates the failure. Note that the packet data is for the second fragment of a large ICMP echo. The file "ryu_icmpv4.patch" contains a superficial

Re: [Ryu-devel] Using multiprocessing to modify flows

On Mon, Apr 24, 2017 at 3:46 PM, Yiwen Shen wrote: > > If I just do add_flow(..) by itself the flows will get added properly onto the switch, but if I do multiprocessing it doesn't appear. However, multiprocessing is the only way I know to do this stuff in parallel. (I've

Re: [Ryu-devel] Decoding explicitly RYU messages

The data field is the packet data for the Packet-In message in hex. I took the data snippet from your message (with python string escapes) and entered the following in a python 2.7 interpreter: >>>

Re: [Ryu-devel] Decoding explicitly RYU messages

I'm not completely sure what you want to do. Do you want output like this? type:PACKET_IN xid: 0x version: 0x04 msg: buffer_id: NO_BUFFER total_len: 0x0052 in_port: 0x0002 in_phy_port: 0x0002 metadata:

[Ryu-devel] OFPOxmId in Table Features Request

When an OXM id is serialized in a table features request, the OXM header that is serialized sets the oxm_length to 0. That is, the OXM id for "eth_dst" is sent as 8600 instead of 8606 (the last byte is the length of the value). There's a comment in the code that explains the issue was