Can't get numap-scan to run

[will-caruana]

I get a number of errors when trying to run numap-scan. I get similar problems trying to run other Facedancer programs.

Below is one of the errors I received in running numap-scan.

[ALWAYS] Scanning host for supported devices [ALWAYS] Testing support: audio [INFO ] Loading USB device audio [ERROR ] Traceback (most recent call last): File "/usr/local/lib/python3.7/dist-packages/pygreat/comms.py", line 780, in execute_command result = self.unpack(out_format, raw_result) File "/usr/local/lib/python3.7/dist-packages/pygreat/comms.py", line 617, in unpack bytes_consumed, raw_bytes = cls._split_off_bytes_for_format(subformat, raw_bytes) File "/usr/local/lib/python3.7/dist-packages/pygreat/comms.py", line 425, in _split_off_bytes_for_format num_bytes_consumed = cls._get_bytes_consumed_by_format(format_string, raw_bytes) File "/usr/local/lib/python3.7/dist-packages/pygreat/comms.py", line 402, in _get_bytes_consumed_by_format return int(match.groups(1)) TypeError: int() argument must be a string, a bytes-like object or a number, not 'tuple'

During handling of the above exception, another exception occurred:

Traceback (most recent call last): File "/usr/local/lib/python3.7/dist-packages/numap-2.0.2-py3.7.egg/numap/apps/scan.py", line 50, in run device.run() File "/usr/local/lib/python3.7/dist-packages/Facedancer-2019.3.2-py3.7.egg/facedancer/USBDevice.py", line 166, in run self.scheduler.run() File "/usr/local/lib/python3.7/dist-packages/Facedancer-2019.3.2-py3.7.egg/facedancer/core.py", line 506, in run task() File "/usr/local/lib/python3.7/dist-packages/Facedancer-2019.3.2-py3.7.egg/facedancer/USBDevice.py", line 84, in self.scheduler.add_task(lambda : self.maxusb_app.service_irqs()) File "/usr/local/lib/python3.7/dist-packages/Facedancer-2019.3.2-py3.7.egg/facedancer/backends/GreatDancerApp.py", line 755, in service_irqs self._handle_setup_events() File "/usr/local/lib/python3.7/dist-packages/Facedancer-2019.3.2-py3.7.egg/facedancer/backends/GreatDancerApp.py", line 362, in _handle_setup_events self._handle_setup_event_on_endpoint(i) File "/usr/local/lib/python3.7/dist-packages/Facedancer-2019.3.2-py3.7.egg/facedancer/backends/GreatDancerApp.py", line 377, in _handle_setup_event_on_endpoint data = bytearray(self.api.read_setup(endpoint_number)) File "/usr/local/lib/python3.7/dist-packages/pygreat/comms.py", line 1107, in method timeout=timeout, max_response_length=max_response_length, encoding=encoding, arguments) File "/usr/local/lib/python3.7/dist-packages/pygreat/comms.py", line 1262, in execute_command out_format, arguments, **kwargs) File "/usr/local/lib/python3.7/dist-packages/pygreat/comms.py", line 787, in execute_command future_utils.raise_with_traceback(outer_exception, sys.exc_info()[2]) File "/usr/lib/python3/dist-packages/future/utils/init.py", line 420, in raise_with_traceback raise exc.with_traceback(traceback) File "/usr/local/lib/python3.7/dist-packages/pygreat/comms.py", line 780, in execute_command result = self.unpack(out_format, raw_result) File "/usr/local/lib/python3.7/dist-packages/pygreat/comms.py", line 617, in unpack bytes_consumed, raw_bytes = cls._split_off_bytes_for_format(subformat, raw_bytes) File "/usr/local/lib/python3.7/dist-packages/pygreat/comms.py", line 425, in _split_off_bytes_for_format num_bytes_consumed = cls._get_bytes_consumed_by_format(format_string, raw_bytes) File "/usr/local/lib/python3.7/dist-packages/pygreat/comms.py", line 402, in _get_bytes_consumed_by_format return int(match.groups(1)) TypeError: unexpected return RPC read_setup; innner message: int() argument must be a string, a bytes-like object or a number, not 'tuple'; format: <8X

[Exxerial]

Yep had the same problem, it's caused by a commit that resolved an issue for a guy in the libgreat library but that caused a bug in mine and I suppose also your case. Simple revert the correction that was proposed in this issue : https://github.com/greatscottgadgets/libgreat/issues/7

[sprout42]

I did some work to get numap python3 compatible, would that potentially help this issue? If so, can submit a PR, although I'm not sure I caught all of the necessary changes. https://github.com/sprout42/nu-map/tree/umap2_python3_updates

[bhass1]

@sprout42 can you issue a pull request to merge your python3 changes in? There are two duplicate pull requests now to fix a piece of python3 support, but yours is more comprehensive.

[ktemkin]

We're working on fixing some of the numap-scan issues, now. I thought you might appreciate the way I added this into an internal project tracker:

If everything goes to plan, numap-scan will be Very Not Broken™ soon.

[sprout42]

As noted in #8 I went a bit off the rails at the end of my attempt to get py3 fixes made and started working on functionality (sorry for how messy my branch got). I have two branches working on numap functionality:

• https://github.com/sprout42/nu-map/tree/numap_reorg
• https://github.com/sprout42/Facedancer/tree/numap_testing

I think it is close to working. numap-scan mostly runs without error using a greatfet, USB OTG cable, and a Raspberry Pi3 as a scanning target. However it gets hung up somewhere between the nu-map USBFtdiVendor device (https://github.com/sprout42/nu-map/blob/master/numap/dev/ftdi.py) and the host machine's USB stack.

[sprout42]

update, I think I just figured out the issue with the vendor requests that was causing things to hang. there was still a mixup between the local_handlers and request_handlers for vendor types. However there are still issues with the scan, I don't think the correct summary happens yet.

[straithe]

Are you still experiencing issues with the scan, @sprout42 ?

[straithe]

I'm going to close this as there hasn't been a response in a while, but please re-open this issue or open a new one if you still need assistance.

[sprout42]

oops, sorry that I forgot to respond, this feel off my radar during the holidays, I haven't had time to play with USB stuff in a while and closing this is probably for the best (which you already did). Thank you for all the help while I was working on it!

[will-caruana]

I finally got around to reinstalling this and testing it with the greatfet and I am still running into the same issue as I was originally. I have not tried to use @sprout42 branch I will test in hopes that it fixes it.