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

iptools.ipv4.validate_netmask() seems to be auto-filling 0's #18

Open
DarthOpto opened this issue Aug 17, 2016 · 4 comments
Open

iptools.ipv4.validate_netmask() seems to be auto-filling 0's #18

DarthOpto opened this issue Aug 17, 2016 · 4 comments
Labels

Comments

@DarthOpto
Copy link

DarthOpto commented Aug 17, 2016

import iptools netmask = '255' valid = iptools.ipv4.validate_netmask(netmask)
This returns True. 255 is not a valid netmask. It seems that this is auto-filling the 0's to make it a full netmask. We were using this tool to check and see if our users are entering valid IP addresses, netmasks, and gateways. Since it is auto-filling if you only have the first octet and nothing else this is not a valid tool which we can use.

Also, we tried inputting '0.255.255.0' and this method returned True.

bd808 added a commit that referenced this issue Aug 21, 2016
Ensure that the bit string representation of a netmask is the full 32
bits before validating the left most bits are 1s.

See #18
@bd808
Copy link
Owner

bd808 commented Aug 21, 2016

Right now it does autofill using the ip2network logic. It then asserts that all of the leftmost bits are 1 and the right most bits are 0. Your report about 0.255.255.0 led me to find a bug in that validation however. I wasn't ensuring that the bit string was fully expanded to 32 bits. That should be fixed by 285fe5c.

I looked around a bit for an RFC or other canonical documentation about what a "valid" netmask actually is and came up empty. @DarthOpto can you point me to some docs that you consider to be canonical?

@bd808 bd808 added the question label Aug 21, 2016
@DarthOpto
Copy link
Author

I am not sure about canonical documentation and I am sure that your implementation is correct. I simply wanted to point out that our use case was someone fat fingering a network mask and hitting ENTER instead of the period, they are right next to each other on the number pad, so it is possible. Returning True for only a 255 in my mind doesn't make a lot of sense. That being said thank you for correcting the other defect.

@jellonek
Copy link
Contributor

255 is correct value, as is 65535 for example. Why do you think that this is not valid value?
It's unusable for netmasking, but still looks like correct representation of 32bit value which should be interpreted as valid net mask.

@DarthOpto
Copy link
Author

We were using iptools for validating user input into a system as it was being setup to make sure that they were entering in a valid netmask. If the user does not enter in a valid netmask their system will have to be reconfigured. Our hope was that iptools would validate that the user had entered in a correct netmask. It does not. By auto-filling with 0's we cannot accurately validate whether or not a user has "fat-fingered" and possibly made a mistake when entering their netmask.

255 may be a valid value for short-hand notation, however simply checking whether or not the value entered is a valid netmask would seem to me to be better suited to not having it auto-fill with zeros.

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

No branches or pull requests

3 participants