Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Local Unit TUN Testing With Monitor Class Fails #48

Open
kb1lqc opened this issue Feb 28, 2018 · 0 comments
Open

Local Unit TUN Testing With Monitor Class Fails #48

kb1lqc opened this issue Feb 28, 2018 · 0 comments

Comments

@kb1lqc
Copy link
Member

kb1lqc commented Feb 28, 2018

Likely due to threading, the unit testing fails when run locally but apparently passes both on Travis-CI builds as well as when I run each TUN test case individually. See below:

Pytest Failures

(.venv) bryce@bryce-ubuntu:~/Documents/git/faradayio$ sudo .venv/bin/python3 -m pytest
============================= test session starts ==============================
platform linux -- Python 3.5.2, pytest-3.3.2, py-1.5.2, pluggy-0.6.0
rootdir: /home/bryce/Documents/git/faradayio, inifile:
plugins: cov-2.5.1
collected 37 items                                                             

tests/test_serial.py .................................                   [ 89%]
tests/test_tun.py ...F                                                   [100%]

=================================== FAILURES ===================================
_______________________________ test_serialToTUN _______________________________

    def test_serialToTUN():
        """
        Test serial port to TUN link. Don't need a serial port but just assume that
        an IP packet was received from the serial port and properly decoded with
        SLIP. Send it to the TUN and verify that the IP:PORT receives the message.
        """
        # Create a test serial port for TUN Monitor class. Won't be used.
        serialInstance = faraday.SerialTestClass()
        serialPort = serialInstance.serialPort
    
        # Configure TUN IP:PORT and IP Packet source IP:PORT parameters for test
        sourceAddress = '10.0.0.2'
        sourcePort = 9998
        destPort = 9999
    
        # Start a TUN Monitor class
        isRunning = threading.Event()
        isRunning.set()
        TUNMonitor = faraday.Monitor(serialPort=serialPort,
>                                    isRunning=isRunning)

tests/test_tun.py:163: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
faradayio/faraday.py:146: in __init__
    mtu=mtu)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

self = <faradayio.faraday.TunnelServer object at 0x7fb688fe04a8>
addr = '10.0.0.1', netmask = '255.255.255.0', mtu = 1500, name = 'Faraday'

    def __init__(self, addr,
                 netmask,
                 mtu,
                 name):
>       self._tun = pytun.TunTapDevice(name=name)
E       pytun.Error: [Errno 16] Device or resource busy

faradayio/faraday.py:99: Error
===================== 1 failed, 36 passed in 0.51 seconds ======================
TUN brought down...
Exception ignored in: <bound method TunnelServer.__del__ of <faradayio.faraday.TunnelServer object at 0x7fb688fe04a8>>
Traceback (most recent call last):
  File "/home/bryce/Documents/git/faradayio/faradayio/faraday.py", line 112, in __del__
AttributeError: 'TunnelServer' object has no attribute '_tun'

Individual Test Cases

(.venv) bryce@bryce-ubuntu:~/Documents/git/faradayio$ sudo .venv/bin/python3 -m pytest -k serialToTUN
============================= test session starts ==============================
platform linux -- Python 3.5.2, pytest-3.3.2, py-1.5.2, pluggy-0.6.0
rootdir: /home/bryce/Documents/git/faradayio, inifile:
plugins: cov-2.5.1
collected 37 items                                                             

tests/test_tun.py .                                                      [100%]

============================= 36 tests deselected ==============================
=================== 1 passed, 36 deselected in 0.33 seconds ====================

@hdkmike @reillyeon @lqdev This is an interesting observation. Any thoughts? Am I correct in suspecting the Monitor class (which inherits Threading.Thread) is suspect?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant