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 RuleBase(object): > > def __init__(self, dp: Datapath, *args, **kwargs): > > self.dp = dp > > self.ofproto = self.dp.ofproto > > self.parser = self.dp.ofproto_parser > > self.match = kwargs > > self.inst = [] > > > > def add_flow(self): > > match = self.parser.OFPMatch(**self.match) > > msg = self.parser.OFPFlowMod( > > table_id=FIREWALL_TABLE_ID, > > datapath=self.dp, > > priority=10, > > command=self.ofproto.OFPFC_ADD, > > match=match, > > instructions=self.inst > > ) > > self.dp.send_msg(msg) > > > > > > class DenyRule(RuleBase): > > def __init__(self, *args, **kwargs): > > super(DenyRule, self).__init__(*args, **kwargs) > > self.inst = [ > > > > self.parser.OFPInstructionActions(self.ofproto.OFPIT_APPLY_ACTIONS, []) > > ] > > > I'm using it in switch_features_handler as follows: > > msg = ev.msg > > dp = msg.datapath > > d_rule = DenyRule(dp=dp, ipv6_dst='2001:db8:bd05:1d2:288a:1fc0:1:10ee') > > d_rule.add_flow() > > > > But, I get the following output: > > move onto main mode > EventOFPErrorMsg received. > version=0x4, msg_type=0x1, msg_len=0x4c, xid=0xa6de76ce > `-- msg_type: OFPT_ERROR(1) > OFPErrorMsg(type=0x4, code=0x9, > data=b'\x04\x0e\x00\x50\xa6\xde\x76\xce\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0a\xff\xff\xff\xff\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x00\x18\x80\x00\x36\x10\x20\x01\x0d\xb8\xbd\x05\x01\xd2') > |-- type: OFPET_BAD_MATCH(4) > |-- code: OFPBMC_BAD_PREREQ(9) > `-- data: version=0x4, msg_type=0xe, msg_len=0x50, xid=0xa6de76ce > `-- msg_type: OFPT_FLOW_MOD(14) > > > > Best Regards, > Maged > ___ > Ryu-devel mailing list > Ryu-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/ryu-devel ___ Ryu-devel mailing list Ryu-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ryu-devel
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 convention that encodes the datapath_id in the switch certificate's subject CN? This could be plaintext (exposing the datapath_id in the clear during TLS handshake) or an HMAC of the datapath_id using a secret that only the controller knows. Or, does the controller have to maintain the complete datapath_id to peer cert blob mapping? (Assume that the controller already does whitelist by datapath_id.) On Thu, May 17, 2018 at 2:54 AM Kashyap Thimmaraju < kashyap.thimmar...@sect.tu-berlin.de> wrote: > Dear Ryu Developers, > I hope that you are aware of the OpenFlow CVE that was recently made > public [1]. Have there been any discussions on this? Do you plan to > provide a fix or announce a security advisory on this matter? We believe > it is important to spread the awareness to people using OpenFlow > controllers that such an attack is possible. > [1] http://www.openwall.com/lists/oss-security/2018/05/09/4 > -- > Thanks, > Kashyap Thimmaraju > Security in Telecommunications > Technische Universität Berlin > Ernst-Reuter-Platz 7, Sekr TEL 17 > 10587 Berlin, Germany > Phone: +49 30 8353 58351 -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Ryu-devel mailing list > Ryu-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/ryu-devel -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Ryu-devel mailing list Ryu-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ryu-devel
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. Yes, this change looks good to me. It makes sense to handle the ascii encoding in the OFPErrorMsg class. >> Also: Ryu leaves the OF connection open after responding to the hello >> failed message. The connection appears to remain in the >> HANDSHAKE_DISPATCHER state. What is the best way to close the >> connection? > > Thanks for your pointing out. > I found that Ryu does not automatically close the OF connection when the > failure > of the version negotiation, so Ryu application need to close it manually. > I think it can be often overlooked and dangerous. > > What do you think about adding "close_socket" option to > "Datapath.send_msg()" > method, which will close socket after sending the given message? The send_msg api looks okay. I guess there is no easier way to close and flush the connection. > +if close_socket: > +# Forces to call _deactivate() > +raise CloseSocketRequest > +except CloseSocketRequest: > +pass I didn't understand this part of your change. You throw a CloseSocketRequest exception but immediately catch it. This seems like the same operation as a "break" or "return" which will drop you down to the finally clause. I see that _deactivate is a decorator that calls shutdown() on the socket for wrapped methods, but I don't see how it can ever be called in this case. _send_loop() is not protected by _deactivate. Regards, -Bill -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Ryu-devel mailing list Ryu-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ryu-devel
[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: https://github.com/faucetsdn/faucet/issues/1665 I've attached a patch that fixes the uncaught exception issue. Also: Ryu leaves the OF connection open after responding to the hello failed message. The connection appears to remain in the HANDSHAKE_DISPATCHER state. What is the best way to close the connection? Regards, -Bill ryu_hello_failed.patch Description: Binary data -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Ryu-devel mailing list Ryu-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ryu-devel
Re: [Ryu-devel] Error parsing ICMPv4 fragments
Iwase, Yes, your patch works for me. Thanks, -Bill On Tue, Nov 7, 2017 at 8:59 PM, Iwase Yusuke wrote: > Hi Bill, > > Thank you for reporting issue, but sorry for the delay! > > Well, packet library for ICPMv6 seems to be fixed for the same issue. > I guess the same fix should be back-ported to ICMPv4. > > https://github.com/osrg/ryu/blob/8185637767f870b5887a369dc569cc2933aeec34/ryu/lib/packet/icmpv6.py#L151-L155 > > Any way, your patch looks more concise for me. > If we don't expect "self.data = None", how about changing the default value > to "data=b''" > in __init__() method? > The following should fix this problem? > > $ git diff > diff --git a/ryu/lib/packet/icmp.py b/ryu/lib/packet/icmp.py > index 1a6cd76..f5358b1 100644 > --- a/ryu/lib/packet/icmp.py > +++ b/ryu/lib/packet/icmp.py > @@ -77,7 +77,7 @@ class icmp(packet_base.PacketBase): > return cls > return _register_icmp_type > > -def __init__(self, type_=ICMP_ECHO_REQUEST, code=0, csum=0, data=None): > +def __init__(self, type_=ICMP_ECHO_REQUEST, code=0, csum=0, data=b''): > super(icmp, self).__init__() > self.type = type_ > self.code = code > @@ -103,7 +103,7 @@ class icmp(packet_base.PacketBase): > hdr = bytearray(struct.pack(icmp._PACK_STR, self.type, > 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 wrote: >> >> 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 patch for this issue. >> >> It looks like Ryu attempts to parse the higher layers of an IPv4 >> packet even when the IP fragment offset is > 0. This is a separate >> issue that I did not change. >> >> Regards, >> -Bill >> >> >> >> >> -- >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> >> >> >> ___ >> Ryu-devel mailing list >> Ryu-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/ryu-devel >> > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Ryu-devel mailing list Ryu-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ryu-devel
[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 patch for this issue. It looks like Ryu attempts to parse the higher layers of an IPv4 packet even when the IP fragment offset is > 0. This is a separate issue that I did not change. Regards, -Bill import binascii from ryu.lib.packet.packet import Packet data = '0e010ac2bb02429681640800451803c000b94001610a0a010a6400fec0c1c2c3' result = Packet(binascii.unhexlify(data)) print(result) ryu_icmpv4.patch Description: Binary data -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Ryu-devel mailing list Ryu-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ryu-devel
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 tried multithreading, and the flows do get added but because of GIL, it isn't truly happening in parallel). > What are you ultimately testing, the controller or the switch? If you are optimizing, what is the performance benchmark you are trying to reach? If you are testing the ability of a switch to process multiple simultaneous OpenFlow messages, you should use two separate connections to the switch. Perhaps by running two ryu processes listening on different ports. If you are testing the controller, be aware that ryu has one connection to the switch and isn't designed to share it between processes. (Even if it is possible to share the connection, you may still run into atomicity issues where openflow message bytes get interleaved.) If you tried multithreading in a single process and that worked for you, that's probably the best you can expect. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Ryu-devel mailing list Ryu-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ryu-devel
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: >>> data='\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00\x02\x08\x00E\x10\x00D\x84u@\x00@\x06\xa2,\n\x00\x00\x02\n\x00\x00\x01\xb8\xfd\x00P\x19\xb9\\\xe6\xa1^+U\x80\x18\x00:\xd6\x9d\x00\x00\x01\x01\x08\n\x00U\xe4J\x00U\xd8\x9fGET >>> / HTTP/1.0\r\n' >>> import binascii >>> binascii.hexlify(data) '00010002080045100044847540004006a22c0a020a01b8fd005019b95ce6a15e2b558018003ad69d0101080a0055e44a0055d89f474554202f20485454502f312e300d0a' -Bill On Sun, Apr 9, 2017 at 11:53 AM, Jibran Ahmed wrote: > Hello Bill, > > Thank you for your response! The output is very similar to our requirement! > Could you please tell me how the data field was populated? > > Thanks once again! > Jibran -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Ryu-devel mailing list Ryu-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ryu-devel
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:0x
reason: APPLY_ACTION
table_id:0x00
cookie: 0x
match:
- field: IN_PORT
value: 0x0002
data:
00010002080045100044847540004006A22C0A020A01B8FD005019B95CE6A15E2B558018003AD69D0101080A0055E44A0055D89F474554202F20485454502F312E300D0A
_pkt_decode:
- field: ETH_DST
value: '00:00:00:00:00:01'
- field: ETH_SRC
value: '00:00:00:00:00:02'
- field: ETH_TYPE
value: 0x0800
- field: IP_DSCP
value: 0x04
- field: IP_ECN
value: 0x00
- field: IP_PROTO
value: 0x06
- field: IPV4_SRC
value: 10.0.0.2
- field: IPV4_DST
value: 10.0.0.1
- field: NX_IP_TTL
value: 0x40
- field: TCP_SRC
value: 0xB8FD
- field: TCP_DST
value: 0x0050
- field: NX_TCP_FLAGS
value: 0x0018
- field: X_PKT_POS
value: 0x0036
You can use the oftr tool to do this. It converts OpenFlow message to YAML
(or JSON) and back again. Easiest way to install is from launchpad:
https://launchpad.net/~byllyfish/+archive/ubuntu/oftr
The github repository is https://github.com/byllyfish/oftr
I translated your example to YAML below, then ran `oftr encode
packet_in.yml | oftr decode --pkt-decode` to get the above output.
Contents of packet_in.yml:
version: 0x4
type: PACKET_IN
xid: 0x0
msg:
in_port: 2
in_phy_port: 2
buffer_id: 4294967295
metadata: 0
cookie: 0
data:
00010002080045100044847540004006a22c0a020a01b8fd005019b95ce6a15e2b558018003ad69d0101080a0055e44a0055d89f474554202f20485454502f312e300d0a
reason: 1
table_id: 0
total_len: 82
-Bill
On Sat, Apr 8, 2017 at 7:32 PM, Jibran Ahmed wrote:
>
> Hi RYU-DEV team,
>
> I would like to decode the following message without using the commands
in the RYU Controller. I am failing to do so and was wondering if there was
any lib or script available to do the translation for us. Here the message
is being transferred to a higher layer application and will do the
processing based on message contents. I would ultimately like to have this
message in plain text.
>
> The message example:
> version: 0x4 msg_type 0xa xid 0x0
OFPPacketIn(buffer_id=4294967295,cookie=0,data='\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00\x02\x08\x00E\x10\x00D\x84u@
\x00@\x06\xa2,\n\x00\x00\x02\n\x00\x00\x01\xb8\xfd\x00P\x19\xb9\\\xe6\xa1^+U\x80\x18\x00:\xd6\x9d\x00\x00\x01\x01\x08\n\x00U\xe4J\x00U\xd8\x9fGET
/ HTTP/1.0\r\n',match=OFPMatch(oxm_fields={'in_port':
2}),reason=1,table_id=0,total_len=82)
>
> I would NOT like to use the following in the controller:
> self.pcap_writer = pcaplib.Writer(open('mypcap.pcap', 'wb'))
> self.pcap_writer.write_pkt(ev.msg.data)
>
> When I use this library (pcaplib) in my python script in the application
server, I am failing to decode it appropriately,
>
> Could you advice! Thanks in advance!
>
> Regards,
> Jibran Ahmed
> Northeastern University, Boston MA
> Telecommunications Department
>
>
>
--
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Ryu-devel mailing list
> Ryu-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ryu-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Ryu-devel mailing list
Ryu-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ryu-devel
Re: [Ryu-devel] OFPOxmId in Table Features Request
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
> include the "hasmask" field.
> Just an idea, how about the following?
>
> $ git diff
> diff --git a/ryu/ofproto/oxx_fields.py b/ryu/ofproto/oxx_fields.py
> index e9c1fb9..a3cc1d3 100644
> --- a/ryu/ofproto/oxx_fields.py
> +++ b/ryu/ofproto/oxx_fields.py
> @@ -228,7 +228,7 @@ def _make_exp_hdr(oxx, mod, n):
> return n, exp_hdr
>
>
> -def _serialize_header(oxx, mod, n, buf, offset):
> +def _serialize_header(oxx, mod, n, buf, offset, hasmask=False):
> try:
> get_desc = getattr(mod, '_' + oxx + '_field_desc')
> desc = get_desc(n)
> @@ -238,8 +238,10 @@ def _serialize_header(oxx, mod, n, buf, offset):
> n, exp_hdr = _make_exp_hdr(oxx, mod, n)
> exp_hdr_len = len(exp_hdr)
> pack_str = "!I%ds" % (exp_hdr_len,)
> +if hasmask:
> +value_len *= 2
> msg_pack_into(pack_str, buf, offset,
> - (n << 9) | (0 << 8) | (exp_hdr_len + value_len),
> + (n << 9) | (hasmask << 8) | (exp_hdr_len + value_len),
>bytes(exp_hdr))
> return struct.calcsize(pack_str)
>
>
> With this change, we can serialize oxm header field as following.
>
from ryu.ofproto import ofproto_v1_3 as ofproto
n = ofproto.oxm_from_user_header('ipv4_src')
buf = bytearray()
ofproto.oxm_serialize_header(n, buf, offset=0, hasmask=True)
> 4
buf
> bytearray(b'\x80\x00\x17\x08')
ofproto.oxm_serialize_header(n, buf, offset=0, hasmask=False)
> 4
buf
> bytearray(b'\x80\x00\x16\x04')
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Ryu-devel mailing list
Ryu-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ryu-devel
[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 unclear in
2014. (ofproto_v1_3_parser, ofproto_v1_4_parser, ofproto_v1_5_parser)
The 1.3.5 OF spec states, "The oxm_length field in OXM headers must be
the length value defined for the OXM field, i.e. the payload length if
the OXM field had a payload." (7.3.5.5.2 Table Features properties)
OVS appears to set the oxm_length to the payload length. If the mask
bit is set, the payload length is double the usual size.
I am trying to change the OFPOxmId serialization code so I can submit
a patch. Is there an API like:
ofproto.oxm_from_user('eth_dst', None)
that will return the length information for a field?
The ryu parsing code for an OXM ID ignores the oxm_length. This patch
would only break things if the receiving OpenFlow implementation
expects the oxm_length's to be zero in the TableFeatures message
OXMID's. Such an implementation would be broken IMO.
-Bill
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Ryu-devel mailing list
Ryu-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ryu-devel
