Closed loz-hurst closed 6 years ago
I had been having issues with this for a while.
My python side being weak I didn't have time to look into why i couldn't make any changes. Turned out the timeout was stopping me ( raspberry pi ) --- seams shane-kerr has a fork that includes timeout at .5 (which is what I set on mine) I could actually discover the switch but do nothing else with it.
Thanks for the tip!
Which firmware version is your switch running with? I read they changed the authentication mechanism to "encrypted" passwords so that may stop you from changing anything....
Mine's running whichever firmware they came with out of the box (it's brand new) - is there an easy way to tell which version it is without having to borrow a Windows machine to hook it up to, again?
What's Within the discovery reply? Isn't there a switch firmware version information?
Damn...just saw it isn't.... so you can do a discover but nothing else, right?
Yes, but I can't even do a discover until I've increased the timeout. Once I've done that I get told that my password is incorrect (which it's not) to everything I try and do.
I've had a look at one of my new ones with the Windows utility - it's running firmware revision 1.02.04 according to that.
Can you please try the following patch:
https://gist.github.com/Z3po/0cfa93d668bdef73ebfe
that should implement the "secure" Netscape masterpass-xor-thing. If that works for you I'll check how to have that implemented in a more clean way with backwards compatibility.
That works as far as the password error goes. Apart from dhcp, ip and netmask everything else raises NotImplementedError exceptions though. I guess a lot has changed in this firmware?
For what it is worth: I'm seeing errors on https://github.com/tabacha/ProSafeLinux.git (master branch) when I do a fresh git clone (before applying patches) and do a query all and I end up the same bool error (only on query I actually get a response on Discover from my switch because it is fast enough)
At that point I tried the timeout patch on master and great now I get an error "TypeError: unpack_py() takes exactly 2 arguments (3 given)" --- Well its progress diffrent error. Try the password the password patch (which doesn't actually seem to be checked by the switch on query lookups) and the error is still there.
I ended up on https://github.com/shane-kerr/ProSafeLinux.git (Master branch) which never went through the CLI/CMDLET change.
Stock it has a .5 second timeout AND the query works. It would query but wouldn't set information (but at least it would query because of the longer timeout if i dropped the timeout to 0.005 it would crash) put in your password patch (needed 1 small change from cmddict to cmd_arr) and I'm able to query all values (it even queries with wrong password so i don't think queries are password checked ) and now I'm able to SET values (Before the patch it would send the command but the switch would never change the value)
So just my personal opinion I think we may have some issues in issues going on here in Master. Maybe switch version or python version related if everyone else isn't seeing it.
My switch is GS108EV2 Running firmware 1.00.12
We are definitely having different issues here....
@cmlara: you should be fine with the unpatched version as you're running the old firmware version (as far as i can see). Which python version are you using? Possibly some python3 stuff we weren't aware off...will take a further look this evening. Can you supply me with a full stacktrace?
@loz-hurst: looks like they've possibly done some further changes...can you post the full stacktrace and.maybe run the thing in debug mode? Will then also take a look this evening...
@Z3po
If its a separate issue may be worth let me know if you want me to split off a different issue to keep it clean.
Of note my switch was bought in December 2013 so I think it is running the hash patch especial since It didn't respond to SETS until I applied your patch.
pi@raspberrypi /tmp/ProSafeLinux $ python --version Python 2.7.3
Note: looks like python3 is also on the system, but 2.7.3 is what is being referenced by /usr/bin/python. The script doesn't even make it into any reasonable set of running on python3.2 fails to even get to a help screen.
--- BEFORE SETTING TIMEOUT --- This was cloned from tabacha/ProSafeLinux just moments before running so it is a clean install --- pi@raspberrypi /tmp/ProSafeLinux $ ./psl-cli.py query --mac 28:c6:8e:fb:9c:a8 --passwd password all Query Values..
Traceback (most recent call last):
File "./psl-cli.py", line 191, in
pi@raspberrypi /tmp/ProSafeLinux $ nano -w psl_class.py (Set the timeout to .5)
--- After setting timeout ---- pi@raspberrypi /tmp/ProSafeLinux $ ./psl-cli.py query --mac 28:c6:8e:fb:9c:a8 --passwd password all Query Values..
Traceback (most recent call last):
File "./psl-cli.py", line 191, in
This same error occurs if i use the password patch as well so doesn't seem to be related there
Deployment Note I run from my Pi to a standard switch which feeds to my GS108E
@Z3po : Here you go: https://gist.github.com/loz-hurst/9206184
@cmlara : That's what I was seeing when the timeout was too small - have you tried increasing it further to, e.g., 1? The variable ended up as None (which is what the recv method is coded to return if it times out, iirc), which the unpack method doesn't catch. I think there's scope for some improved error handling somewhere but I'm more interested in getting it working than the niceties of make it more user-friendly ;)
@loz-hurst: I think i know what happens here...has to do with some cleanup.... Please try the following patch: https://gist.github.com/Z3po/da1356feff10947975a1
I'm actually in progress of doing a major cleanup on some stuff...hopefully I will be able to release some of it soon. I'll take care to improve the error-handling and stuff.
UPDATE: I updated the patch file...actually I think the patch is for you both. Please have a try @loz-hurst @cmlara
Will let @loz-hurst respond if it fixes his.
Funny enough it moves my branch to have the same error as @loz-hurst in his post (Line numbers match when the password patch and the latest cleanup patch are applied and of course I'm editing the timeout as well)
Traceback (most recent call last):
File "./psl-cli.py", line 191, in
BTW appreciate all the efor you are putting into this Sebastian.
Ok...i finally made my way through all of this. Its getting kind of interesting because the forks somehow moved away from each others so I'm trying to get this fixed for now via patches:
https://gist.github.com/Z3po/a1dac9cc7ccc2824a998
@cmlara, @loz-hurst: can you please do a fresh checkout on the tabacha/master repository and apply all the patches? That should get you a working copy of the whole thing. Timeouts should be fixed and the password-encrypt stuff is also in it. If that works for you, I'll try to fix my own fork of the repository and then will continue to work on the cleanup branch....so we get a new cleaned up version soon :)
@tabacha: if that works, can you please also apply the patches to your own version? That should fix some open bugs and your repository will then share a working copy :)
UPDATE: Sorry for all the comment updates...I think I got it now. all file updates are within the same gist...I somehow messed that up before....
I've pushed the changes into my repository in the "tabacha-master" branch (https://github.com/Z3po/ProSafeLinux/tree/tabacha-master). So you can fetch the version there. @tabacha: you can also fetch the latest commits there if you want to.
I'm still getting an exception thrown - I think that the timeout's not been increased far enough. I set it to 1, in the end, and that seemed to be reasonably reliable.
I've updated my Gist with an example: https://gist.github.com/loz-hurst/9206184
Please check out the new version from my tabacha-master branch. I've added a timeout parameter and fixed some internal behaviour so you shouldn't get any ugly stacktraces anymore. It's not perfect but better now :)
By default the timeout of 0.005 is too short for my laptop to talk to the switch (GS105E) even when directly connected (i.e. with no other network device between the laptop and the switch):
Changing the timeout to 0.05 by default, in recv_all, fixes the problem:
and now:
Could you add an option to specify the timeout as a command line argument? e.g. '--timeout 0.05'?
Many thanks,
Laurence