[steeplechase] verify if signaling server URL is reachable

NEW
Unassigned

Status

defect
5 years ago
2 years ago

People

(Reporter: drno, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [webrtc-mochitest],[steeplechase])

Attachments

(1 attachment)

If you provide an incorrect client IP to steeplechase it starts and prints this message:
  steeplechase INFO | Pushing app to Client 1...
Although it is obviously not connected to Client 1 at all.

Steeplechase should detect that it can not connect to the wrong Client 1 and exit with an error instead.
What I get after trying to connect to the wrong IP:
mwargers@ubuntu:~$ /usr/bin/env python ~/steeplechase/steeplechase/runsteeplechase.py --binary ~/firefox/firefox --specialpowers-path ~/tests/steeplechase/specialpowers --prefs-file ~/tests/steeplechase/prefs_general.js --signalling-server 'http://xxx.xx.xx.xxx:8080/' --html-manifest steeplechase/sample_tests/manifest.ini --host1 xxx.xx.xx.xxx:20701 --host2 xxx.xx.xx.xxx:20701 --save-logs-to ~/logs/
Traceback (most recent call last):
  File "/home/mwargers/steeplechase/steeplechase/runsteeplechase.py", line 311, in <module>
    sys.exit(0 if main(sys.argv[1:]) else 1)
  File "/home/mwargers/steeplechase/steeplechase/runsteeplechase.py", line 238, in main
    dm1 = DeviceManagerSUT(host, port)
  File "/usr/local/lib/python2.7/dist-packages/mozdevice-0.37-py2.7.egg/mozdevice/devicemanagerSUT.py", line 49, in __init__
    self.getDeviceRoot()
  File "/usr/local/lib/python2.7/dist-packages/mozdevice-0.37-py2.7.egg/mozdevice/devicemanagerSUT.py", line 704, in getDeviceRoot
    data = self._runCmds([{ 'cmd': 'testroot' }])
  File "/usr/local/lib/python2.7/dist-packages/mozdevice-0.37-py2.7.egg/mozdevice/devicemanagerSUT.py", line 154, in _runCmds
    self._sendCmds(cmdlist, outputfile, timeout, retryLimit=retryLimit)
  File "/usr/local/lib/python2.7/dist-packages/mozdevice-0.37-py2.7.egg/mozdevice/devicemanagerSUT.py", line 145, in _sendCmds
    raise DMError("Remote Device Error: unable to connect to %s after %s attempts" % (self.host, retryLimit))
mozdevice.devicemanager.DMError: Remote Device Error: unable to connect to xxx.xx.xx.xxx after 5 attempts
mwargers@ubuntu:~$
Looks like in your case the "wrong" IP address was in use by some device. In my case the "wrong" IP address was not in use at all on the network.
I also get the result from comment 1 with complete bogus IP addresses for host1 and host2:
mwargers@ubuntu:~$ /usr/bin/env python ~/steeplechase/steeplechase/runsteeplechase.py --binary ~/firefox/firefox --specialpowers-path ~/tests/steeplechase/specialpowers --prefs-file ~/tests/steeplechase/prefs_general.js --signalling-server 'http://xxx.xx.xx.xxx:8080/' --html-manifest steeplechase/sample_tests/manifest.ini --host1 bogus --host2 bogus --save-logs-to ~/logs/
Posted patch 1037777.diffSplinter Review
This fixes a similar issue when it can't connect to the signalling server, but I guess this issue is about when it can't connect to the negatus clients.
Comment on attachment 8461146 [details] [diff] [review]
1037777.diff

Review of attachment 8461146 [details] [diff] [review]:
-----------------------------------------------------------------

This basically tries to connect to the simple signaling server before steeplechase actually starts running, right?
Looks good to me.
Attachment #8461146 - Flags: review+
If it is not reproducible lets close this ticket.
Comment on attachment 8461146 [details] [diff] [review]
1037777.diff

(In reply to Nils Ohlmeier [:drno] from comment #5)
> Review of attachment 8461146 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> This basically tries to connect to the simple signaling server before
> steeplechase actually starts running, right?
> Looks good to me.

Yes. The "pushing client" stuff takes a long time, so it would be nice to know beforehand if one can connect to the signalling server.
Ted, do you think this is ok? Can you then push it to your repo?
Attachment #8461146 - Flags: feedback?(ted)
(In reply to Nils Ohlmeier [:drno] from comment #6)
> If it is not reproducible lets close this ticket.

It's not reproducible to me, but I've know attached a patch to this bug that fixes something unrelated. I guess we could morph it to that issue.
Comment on attachment 8461146 [details] [diff] [review]
1037777.diff

Review of attachment 8461146 [details] [diff] [review]:
-----------------------------------------------------------------

This is fine, but I don't think it fixes the issue as reported, right? (Bad client IPs.)
Attachment #8461146 - Flags: feedback?(ted) → feedback+
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #9)
> This is fine, but I don't think it fixes the issue as reported, right? (Bad
> client IPs.)

That is correct, but I couldn't reproduce it and Nils was fine with closing this bug (I'm not sure he could still reproduce this).
As Syd ran into the problem the patch here solves I think it would make sense to land this. I guess we should convert this into a GitHub PR.
Summary: [steeplechase] wrong client IP results in no error → [steeplechase] verify if signaling server URL is reachable
Whiteboard: [webrtc-mochitest],[steeplechase]
Component: New Frameworks → General
You need to log in before you can comment on or make changes to this bug.