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 un
Thanks! The change to oxm_serialize_header helped immensely.
I'm working on adjusting the tablefeatures test packet_data. I'll
also test experimenter oxm id's.
-Bill
On Tue, Apr 4, 2017 at 9:59 PM, Iwase Yusuke wrote:
> Instead, I guess we need to extend ofproto.oxm_serialize_header() to
> i
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:0x0
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:
>>> data='\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00\x02\x08\x00E\x10\x00D\x84u@\x00@\x06\xa2,\n\x00\x
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
tried multithreading, and
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 pat
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日 15:44, William Fisher
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: https://github.com/faucetsdn/faucet/issues/1665
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.
Yes, this change looks goo
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 co
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 RuleBase(object
11 matches
Mail list logo
