IPprefix referenced before assignment

[canselcik]

python LANs.py -u -n results in the following error on line 987 in main:

UnboundLocalError: local variable 'IPprefix' referenced before assignment

[ganye]

Can you provide the full traceback? Also, try running

$ ip route

and tell me the input.

Thanks

[DanMcInerney]

Are you using the latest version? I just tested it without a problem. I just cloned the repo and I see "for r in iprs:" on line 987. Two lines below that is "IPprefix = r.split()[0]" which is the first reference to the variable IPprefix. The first place that "referenced before assignment" error could happen is on line 1000 when calling the active users class with "au.users(IPprefix, routerIP)". What do you see on line 987?

On Wed, Apr 30, 2014 at 7:53 PM, Can Selcik notifications@github.comwrote:

python LANs.py -u -n results in the following error on line 987 in main:

UnboundLocalError: local variable 'IPprefix' referenced before assignment

— Reply to this email directly or view it on GitHubhttps://github.com/DanMcInerney/LANs.py/issues/38 .

[DanMcInerney]

Ah yes, ganye's right this is likely an issue with ip route. What operating system and version are you on? I'm thinking about adding an OS checker to account for the variations in ip route output on them (if that is in fact the problem here).

[canselcik]

ip route prints:

default dev venet0 scope link

I am running on Ubuntu 13.10 Saucy. I'll be providing the full stack-trace when I get back to the machine. I was sure I had the latest version but I'll check again.

[DanMcInerney]

Yup, definitely a problem with ip route. Your IP route isn't showing your local subnet in the form of 192.168.0.0/24 like it does on Kali. I really want to get rid of ip route but there's just so much good info in there that is difficult to get elsewhere. For this problem at least, I think this might work:

http://stackoverflow.com/questions/11453378/get-network-address-and-network-mask-in-python?rq=1

I'll test it out and look into other ways of eliminating the script's reliance on IP route.

On Thu, May 1, 2014 at 12:40 AM, Can Selcik notifications@github.comwrote:

ip route prints:

default dev venet0 scope link

I am running on Ubuntu 13.10 Saucy. I'll be providing the full stack-trace when I get back to the machine. I was sure I had the latest version but I'll check again.

— Reply to this email directly or view it on GitHubhttps://github.com/DanMcInerney/LANs.py/issues/38#issuecomment-41879538 .

[DanMcInerney]

Maybe I can just make this library a dependency and grab all the info using it:

https://github.com/rlisagor/pynetlinux

On Thu, May 1, 2014 at 1:34 AM, Dan McInerney dan.h.mcinerney@gmail.comwrote:

Yup, definitely a problem with ip route. Your IP route isn't showing your local subnet in the form of 192.168.0.0/24 like it does on Kali. I really want to get rid of ip route but there's just so much good info in there that is difficult to get elsewhere. For this problem at least, I think this might work:

http://stackoverflow.com/questions/11453378/get-network-address-and-network-mask-in-python?rq=1

I'll test it out and look into other ways of eliminating the script's reliance on IP route.

On Thu, May 1, 2014 at 12:40 AM, Can Selcik notifications@github.comwrote:

ip route prints:

default dev venet0 scope link

I am running on Ubuntu 13.10 Saucy. I'll be providing the full stack-trace when I get back to the machine. I was sure I had the latest version but I'll check again.

— Reply to this email directly or view it on GitHubhttps://github.com/DanMcInerney/LANs.py/issues/38#issuecomment-41879538 .

[DanMcInerney]

Are you on a virtual machine or something? Why doesn't your ip route show any details?

On Thu, May 1, 2014 at 1:36 AM, Dan McInerney dan.h.mcinerney@gmail.comwrote:

Maybe I can just make this library a dependency and grab all the info using it:

https://github.com/rlisagor/pynetlinux

On Thu, May 1, 2014 at 1:34 AM, Dan McInerney dan.h.mcinerney@gmail.comwrote:

Yup, definitely a problem with ip route. Your IP route isn't showing your local subnet in the form of 192.168.0.0/24 like it does on Kali. I really want to get rid of ip route but there's just so much good info in there that is difficult to get elsewhere. For this problem at least, I think this might work:

http://stackoverflow.com/questions/11453378/get-network-address-and-network-mask-in-python?rq=1

I'll test it out and look into other ways of eliminating the script's reliance on IP route.

On Thu, May 1, 2014 at 12:40 AM, Can Selcik notifications@github.comwrote:

ip route prints:

default dev venet0 scope link

I am running on Ubuntu 13.10 Saucy. I'll be providing the full stack-trace when I get back to the machine. I was sure I had the latest version but I'll check again.

— Reply to this email directly or view it on GitHubhttps://github.com/DanMcInerney/LANs.py/issues/38#issuecomment-41879538 .

[canselcik]

Yes, I am running this on a virtual machine, however, it seems like not relying on ip route seems like a good idea. I like the idea of adding pynetlinux as a dependency and using that to get the information needed.

[DanMcInerney]

Getting good VM support for the script will require a refactor to enable all the attacks to take place from a wired connection which it doesn't allow at the moment. That's not a trivial task seeing as I coded this when I didn't know as much about python and took some shitty shortcuts. For the record, I am not working on this at the moment and have no date set for when I'll start. I know the path though, basically need to refactor all the core snooping code to be written like creds.py amongst other stuff. Got some other more interesting projects I'm working on at the moment.

On Thu, May 1, 2014 at 7:02 PM, Can Selcik notifications@github.com wrote:

Yes, I am running this on a virtual machine, however, it seems like not relying on ip route seems like a good idea. I like the idea of adding pynetlinux as a dependency and using that to get the information needed.

— Reply to this email directly or view it on GitHubhttps://github.com/DanMcInerney/LANs.py/issues/38#issuecomment-41966893 .