trex_emu_conversions.py is not python3 compatible

[mickopp]

Hi together,

trex_emu_conversions.py in /automation/trex_control_plane/interactive/trex/emu seems to be not python3 compatible.

load_profile -
Emu profile loading failed! Traceback:
  File "/opt/trex/v2.84/automation/trex_control_plane/interactive/trex/emu/trex_emu_profile.py", line 564, in load_py
    profile = module.register().get_profile(tunables)
  File "emu/test_ipfix3.py", line 289, in get_profile
    return self.create_profile(args.is_ipv6, args.mac, args.ipv4, args.ipv6, args.dg_4, args.dst_4, args.dst_6, args.dst_port)
  File "emu/test_ipfix3.py", line 251, in create_profile
    host_port = HostPort(dst_ipv6, dst_port) if is_ipv6 else HostPort(dst_ipv4, dst_port)
  File "/opt/trex/v2.84/automation/trex_control_plane/interactive/trex/emu/trex_emu_conversions.py", line 514, in __init__
    HostPort._verify_port(port)
  File "/opt/trex/v2.84/automation/trex_control_plane/interactive/trex/emu/trex_emu_conversions.py", line 529, in _verify_port
    if not unicode(port, 'utf-8').isnumeric():
NameError: name 'unicode' is not defined

here is a suggested quick fix - works for me. sorry I am not a real good coder.

@@` -3,6 +3,7 @@
 from trex.utils.common import compress_ipv6, mac_str_to_num, int2mac, ip2int, int2ip, ipv62int, int2ipv6
 from scapy.utils import mac2str

+import sys
 import copy
 import socket
 import struct
@@ -526,8 +527,13 @@
             :raises:
                 + :exe:'TRexError': If port is not a valid port
         """
-        if not unicode(port, 'utf-8').isnumeric():
-            raise TRexError("{} is not a numeric value.".format(port))
+
+        if sys.version_info[0] == 3:
+            if not str(port).isnumeric():
+                raise TRexError("{} is not a numeric value.".format(port))
+        else:
+           if not unicode(port, 'utf-8').isnumeric():
+                raise TRexError("{} is not a numeric value.".format(port))
         port_int = int(port)
         if port_int < 0 or port_int > 0xFFFF:
             raise TRexError("{} is not a valid port. Port must be in [0-65535].".format(port_int))

Hope this helps

regards Michael

[hhaim]

@mickopp this is a trap to find the users of EMU + NetFlow plugin, am I right?

[mickopp]

@hhaim - nice one ;-) - yeah tried the EMU / NetFlow Plugin to do some regression testing of netflow collector

[hhaim]

@mickopp nice, @bdollma that wrote it will be happy to hear a feedback and your use-case.

[mickopp]

Hi @hhaim , hi @bdollma again thanks for this great project ! I dont know what is the best way to sent feedback ? Google Groups List ? Just one questing, is there a reason why you didnt expose the template sent rate in the json file and have it as a const in the plugin ? Did a short test and altered it to 0.01667 (which is from point of view a realisitc value in real live (1 template/minute) - the go tests fail, but trex-emu is working fine with the set template rate. I have almost zero experience with golang but can look into it, if you want.

[bdollma]

Hi @mickopp , First, very glad to hear you are enjoying TRex, and very glad to hear there is a user to our Netflow/IPFix plugin so fast. You can send feedback here, or by mail at bdollma@cisco.com. Now to your questions: There is a reason why we didn't expose the template rate and this is because it is not something interesting, something we though you would want to play with. The idea is that the template packet teaches the collector about the templates and then its job is done. In our case the template doesn't change, the only thing that changes is the data, through out the engines. For that matter, even sending 1 single template packet would be enough. Hence we decided on sending them at a relatively slow rate of 1 pps.

Now about changing/exposing the value of TemplateRate:

1. Part of the tests will fail, as they compare the generated output of the test to some golden file. In that golden file the rate is set to 1. You can update the golden files in your private repo if you want.
2. If there is some widely accepted value of 1 template/minute or if this is defined somewhere, please point us to it.
3. You can very easily expose the template rate to the init json.
4. You can set the template rate live through RPC calls. For the last 2 points follow the data rate variable and try to do the same. If you need help implementing it, let us know. Thanks, Bes