Re: perl and network addresses
Kevin D. Clark wrote: Another thing to be aware of (but which hasn't come up...yet...in this thread) is that all of the test code that I see here uses signed integers for the bit operations (~ << etc.). The C spec. specifically states that the results of such expressions is system dependent (and hence unportable). FWIW, I also changed my test program to use unsigned integers, and got the same results.--The sall instruction is working as advertised on my Pentium III. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
Stephen Ryan writes: > Ooh, here's something interesting. I first tried a test with constants, > and got the warning: left shift count >= width of type" out of gcc. > Then I rewrote the thing to use a loop, and I got correct results out of > it. (This is all on an Athlon64X2.) > > When you described getting the same results for 0 and 32, I tried it > again on my wife's laptop, a Celeron M, and got the same results you > did; just out of curiosity, I looked it up, and gcc generates a 'sall' > instruction to do the actual bit-shift, which on the 80386, PIII and > Celeron M (according to Intel's documentation, your test, and my test, > respectively) all ignore everything but the low 5 bits on the shift > count. The 64-bit Athlon64 apparently doesn't, though, even though I'm > supposedly running in 32-bit compatibility mode. Huh. > > Yet another demonstration of the dangers of of assuming specific > bit-sizes for int, I suppose. Another thing to be aware of (but which hasn't come up...yet...in this thread) is that all of the test code that I see here uses signed integers for the bit operations (~ << etc.). The C spec. specifically states that the results of such expressions is system dependent (and hence unportable). That warning message you saw was gcc doing an OK job warning you of a possible problem. When you added the loop you bamboozled the compiler, but the underlying issue (however small) still remained. Just another compiler guy... --kevin -- GnuPG ID: B280F24E And the madness of the crowd alumni.unh.edu!kdc Is an epileptic fit -- Tom Waits ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
On Fri, 2006-03-31 at 21:00 -0500, Jason Stephenson wrote: > Stephen Ryan wrote: > > hostmask = (1 << (32 - n)) - 1 > > netmask = ~ hostmask > > Doh! That's so obvious, so obviously, I overlooked it. ;) Well, yes, of course :-) > > > > 1 << (32 - n) in binary is (n-1) '0' bits, a '1', then (32 - n) '0' > > bits. Subtracting 1 from that gives n '0' bits followed by (32 - n) '1' > > bits. The 'not' operator flips all the bits for the netmask. > > > > This works for /1 through /32 networks, even though some of those are > > nonsensical. A /0 might break this because of overflow (1 << (32 -n) > > overflows a 32-bit integer); theoretically, it should work even for /0 > > so long as 1 << (32-n) returns 0 (32-bit gcc 4.0 on my Athlon64 desktop > > computes this correctly, but complains 'warning: left shift count >= > > width of type' while compiling. Anyway, if you're running a /0, you've > > got other, bigger problems. > > Using gcc 3.4.4 on a 32-bit Pentium III, I get no warnings when > compiling your test program, even with -Wall. When it runs, 0 gives the > same result as 32, so it overflows (silently) on my machine. Ooh, here's something interesting. I first tried a test with constants, and got the warning: left shift count >= width of type" out of gcc. Then I rewrote the thing to use a loop, and I got correct results out of it. (This is all on an Athlon64X2.) When you described getting the same results for 0 and 32, I tried it again on my wife's laptop, a Celeron M, and got the same results you did; just out of curiosity, I looked it up, and gcc generates a 'sall' instruction to do the actual bit-shift, which on the 80386, PIII and Celeron M (according to Intel's documentation, your test, and my test, respectively) all ignore everything but the low 5 bits on the shift count. The 64-bit Athlon64 apparently doesn't, though, even though I'm supposedly running in 32-bit compatibility mode. Huh. Yet another demonstration of the dangers of of assuming specific bit-sizes for int, I suppose. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
Stephen Ryan wrote: Can anyone think of a better way to blit an arbitrary number of bits from 0 to 1? Well, let's see Taking advantage of the fact that all of the '1' bits are at the end of the hostmask, you've actually almost gotten it already. hostmask = (1 << (32 - n)) - 1 netmask = ~ hostmask Doh! That's so obvious, so obviously, I overlooked it. ;) 1 << (32 - n) in binary is (n-1) '0' bits, a '1', then (32 - n) '0' bits. Subtracting 1 from that gives n '0' bits followed by (32 - n) '1' bits. The 'not' operator flips all the bits for the netmask. This works for /1 through /32 networks, even though some of those are nonsensical. A /0 might break this because of overflow (1 << (32 -n) overflows a 32-bit integer); theoretically, it should work even for /0 so long as 1 << (32-n) returns 0 (32-bit gcc 4.0 on my Athlon64 desktop computes this correctly, but complains 'warning: left shift count >= width of type' while compiling. Anyway, if you're running a /0, you've got other, bigger problems. Using gcc 3.4.4 on a 32-bit Pentium III, I get no warnings when compiling your test program, even with -Wall. When it runs, 0 gives the same result as 32, so it overflows (silently) on my machine. If you're running a /0, you really must be Root. ;) I'm going to limit the input on my network calculator and throw an error on IPv4 net masks that are not between /8 and /30 inclusive. The reason being that < /8 and > /30 don't really give valid IPv4 networks. Cheers and thanks, Jason ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
On Thu, 2006-03-30 at 20:35 -0500, Jason Stephenson wrote: > Paul Lussier wrote: > > > Yes, more or less. Between you and Jason I've been able to come up > > with exactly what I need. Thanks a lot for all your help. Why I > > couldn't see this for myself is beyond me. Of course, this week has > > been full of me "missing the details" to the point where I somehow > > managed to mail my taxes to myself from work the other day rather than > > to my accountant :) So, just in case you wondered, the USPS system is > > working at peak efficiency ! > > You're very welcome to the help, and we all have those weeks. It took me > a while to realize what your real question was. > > Once I figured out your question, it was actually rather interesting: > adding network addresses to interpolate between different networks. > Trying to answer it allowed me to discover some facts about IPv4 > addresses and masks, so I got to learn something, too. > > The thing that I found most interesting is if you use the one or two > digit kind of "mask," i.e. /19, you can determine how many addresses are > on the network via the following C code: addresses = 1 << (32 - n). > Where n is the part of the mask after the /. > > I wish I could find a faster way to blit the bits to make the "real" > mask from the /N style than using a for loop. Only alternative I can > think of is to use a switch on the 33 possibilities (0-32).--Of course, > anything < /8 and > /30 doesn't make a "real" network. > > Can anyone think of a better way to blit an arbitrary number of bits > from 0 to 1? Well, let's see Taking advantage of the fact that all of the '1' bits are at the end of the hostmask, you've actually almost gotten it already. hostmask = (1 << (32 - n)) - 1 netmask = ~ hostmask 1 << (32 - n) in binary is (n-1) '0' bits, a '1', then (32 - n) '0' bits. Subtracting 1 from that gives n '0' bits followed by (32 - n) '1' bits. The 'not' operator flips all the bits for the netmask. This works for /1 through /32 networks, even though some of those are nonsensical. A /0 might break this because of overflow (1 << (32 -n) overflows a 32-bit integer); theoretically, it should work even for /0 so long as 1 << (32-n) returns 0 (32-bit gcc 4.0 on my Athlon64 desktop computes this correctly, but complains 'warning: left shift count >= width of type' while compiling. Anyway, if you're running a /0, you've got other, bigger problems. > Now, I'm working on a network calculator application that will support > IPv6 as well. I should probably do it in JavaScript, uh, sorry, AJAX, so > that the "Web 2.0" people will notice. ;) > > Cheers, > Jason > ___ > gnhlug-discuss mailing list > gnhlug-discuss@mail.gnhlug.org > http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss #include int main() { int n; int netmask,hostmask; for (n=0;n<=32;n++) { hostmask = (1 << (32 -n)) - 1; netmask = ~hostmask; printf("n: %d netmask: 0x%08x hostmask: 0x%08x\n",n,netmask,hostmask); } return 0; }
Re: perl and network addresses
Paul Lussier wrote: Yes, more or less. Between you and Jason I've been able to come up with exactly what I need. Thanks a lot for all your help. Why I couldn't see this for myself is beyond me. Of course, this week has been full of me "missing the details" to the point where I somehow managed to mail my taxes to myself from work the other day rather than to my accountant :) So, just in case you wondered, the USPS system is working at peak efficiency ! You're very welcome to the help, and we all have those weeks. It took me a while to realize what your real question was. Once I figured out your question, it was actually rather interesting: adding network addresses to interpolate between different networks. Trying to answer it allowed me to discover some facts about IPv4 addresses and masks, so I got to learn something, too. The thing that I found most interesting is if you use the one or two digit kind of "mask," i.e. /19, you can determine how many addresses are on the network via the following C code: addresses = 1 << (32 - n). Where n is the part of the mask after the /. I wish I could find a faster way to blit the bits to make the "real" mask from the /N style than using a for loop. Only alternative I can think of is to use a switch on the 33 possibilities (0-32).--Of course, anything < /8 and > /30 doesn't make a "real" network. Can anyone think of a better way to blit an arbitrary number of bits from 0 to 1? Now, I'm working on a network calculator application that will support IPv6 as well. I should probably do it in JavaScript, uh, sorry, AJAX, so that the "Web 2.0" people will notice. ;) Cheers, Jason ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
"Ben Scott" <[EMAIL PROTECTED]> writes: >> The 10.0.32/19 is an interesting beast. The systems which live on it >> have 2 NICs, the primary eth0, which *always* have a 10.0.32/19 >> based address (currently restricted to 10.0.33/24 for some reason?!), > > > As far as that restriction goes, I've read of crufty old code which > assume everything follows the old classful model, with strict > boundaries even for subnets. It might be that. To be honest, I think it's more that we just don't have more 255 hosts on that network... yet. We're about to get 50 more systems in which will bring us up to 251. After that, things may well get interesting :) > As for the rest... wow... funky. I do hope all that multi-homing to > the same network is for test/simulation procedures. :) Pretty much. It's to simulate how our product actually works. Though, our product uses this type of setup in a very restricted and controlled manner on a "backend", completely separate and private network. In theory, one installation of our product could approach 255+ hosts in a single installation, in practice, the number of hosts in a single install is rarely more than 10. > Okay, in return for taking the time and effort to explain all that, > I took the time to figure out how to get Perl to convert IP addresses. > Hopefully the following sample code will help you out: [ code elided ] > Is that even close to what you were thinking of? Yes, more or less. Between you and Jason I've been able to come up with exactly what I need. Thanks a lot for all your help. Why I couldn't see this for myself is beyond me. Of course, this week has been full of me "missing the details" to the point where I somehow managed to mail my taxes to myself from work the other day rather than to my accountant :) So, just in case you wondered, the USPS system is working at peak efficiency ! -- Seeya, Paul ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
On 3/28/06, Paul Lussier <[EMAIL PROTECTED]> wrote: > It's confusing. Sure is! Wow, that's one wacky setup. :) > The 10.0.32/19 is an interesting beast. The systems which live on it > have 2 NICs, the primary eth0, which *always* have a 10.0.32/19 > based address (currently restricted to 10.0.33/24 for some reason?!), As far as that restriction goes, I've read of crufty old code which assume everything follows the old classful model, with strict boundaries even for subnets. It might be that. As for the rest... wow... funky. I do hope all that multi-homing to the same network is for test/simulation procedures. :) Okay, in return for taking the time and effort to explain all that, I took the time to figure out how to get Perl to convert IP addresses. Hopefully the following sample code will help you out: !/usr/bin/perl -w use Socket qw(inet_aton inet_ntoa); # address and mask in ASCII decimal dotted-quad notation $addr = '10.0.32.42'; $mask = '255.255.224.0'; # 19 print ("addr: $addr/$mask\n"); # convert to "string" (which is really the four bytes of a 32-bit int) $addr = inet_aton($addr); $mask = inet_aton($mask); # convert to native integers # the 'N' tells unpack the string is 32-bit int, network order) $addr = unpack('N', $addr); $mask = unpack('N', $mask); # use binary math to mask out net and host parts $net = $addr & $mask; $host = $addr & ~$mask; # ~$m = complement of mask (binary NOT) # convert to "string" form $net = pack('N', $net); $host = pack('N', $host); # convert to ASCII dotted-quad notation $host = inet_ntoa($host); $net = inet_ntoa($net); # survey says... print ("net : $net\n"); print ("host: $host\n"); Is that even close to what you were thinking of? -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
Jason Stephenson <[EMAIL PROTECTED]> writes: > I'd suggest looking up how to configure VLANs on whatever you're > using for a router.--I know you mentioned a FreeBSD firewall > earlier. You must have missed the part where I said "we don't have a router", "we're migrating to a comletely new network", and, most importantly: "Ultimately, the ability to support "network addition" using something wacky like a /19 is entirely my own intellectual curiosity" :) -- Seeya, Paul ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
Paul Lussier wrote: Errr, no, just the opposite actually. Trying to *prevent* routing from a very existent router :) Sounds to me like what you really need is a router with VLAN capability. If I understand correctly, it sounds like you're trying to implement VLANs. Your setup actually sounds very similar to something that we're designing for all the libraries in our consortium. Right now, each site has a Class C (/24) on a 10.10.*. In the near future, we plan to implement each site having a Class B (/16) with different class Cs for each VLAN. For example, if a site is now on 10.10.32.0, it will move to 10.32.0.0 with something like 10.32.0.0/24 reserved for network equipment, 10.32.10.0/24 for the staff, 10.32.20.0/24 for the public, 10.32.30.0/24 for staff wireless, 10.32.40.0/24 for public wireless, etc.--The Dracut Public Library will be our first test case, since they're moving (back) into their renovated building next month. Without VLANs setup in the router, I can't imagine how that would work to prevent traffic among the various 10.32.0.0 "subnets." I suppose you could simulate it with some really complicated routing rules. At this point, my knowledge on the matter of networking begins to recede into nothingness. I can set up a simple Linux or *BSD router/firewall. I can do the math (poorly, but that's what computers are for). I can even use the socket() interface, but configuring fancy-shmancy, complicated network topologies is beyond my current abilities. I didn't design the above mentioned topology, nor did I figure out the configuration in the Cisco routers that we buy. However, I'm promised by our contractor that they'll show me enough so I can break things. ;) Long story made slightly longer, I'd suggest looking up how to configure VLANs on whatever you're using for a router.--I know you mentioned a FreeBSD firewall earlier. Cheers, Jason "Can't-the-network-for-the-wires" Stephenson ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
Paul Lussier wrote: Jason Stephenson <[EMAIL PROTECTED]> writes: It seems to me that the answer is that your IP addresses are limited to the range of 10.0.32.0 to 10.0.63.255 with 10.0.0.0 being the network address and 10.255.255.255 being the broadcast address, no? Err, you've got the IP addresses wrong. It's 10.32.0.0/16, but segmented on a /19 boundary. I need to be able to calculate the "next" network, which for 10.32.0.0/19, would be 10.64.0.0/19, then take the host portion and "add" it to this new network such that any given host has the same host portion on all networks it may exist on. Doesn't matter. I got the network address wrong, too. ;) You want to interpolate the address of one host to another network, is that it? ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
"Ben Scott" <[EMAIL PROTECTED]> writes: > On 3/28/06, Paul Lussier <[EMAIL PROTECTED]> wrote: >> If you really want the long convoluted discussion, I'll be glad to >> post it, I just figured no on would care. > > Well, everyone here knows *I* thrive on long, convoluted > discussions. I'm also curious if you're trying to route packets > through a non-existant gateway again. ;-) Errr, no, just the opposite actually. Trying to *prevent* routing from a very existent router :) -- Seeya, Paul ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
"Ben Scott" <[EMAIL PROTECTED]> writes: > Well... okay... but it's the *why* that makes me wonder. :) > > I hope it's something interesting, and not just that he's trying to > say that he's been assigned the addresses in the range 10.0.32.0/19 on > the 10.0.0.0/16 network. That would be *so* boring. :) Well, since you've asked, I'm sure you'll regret it :) I'll try to be as brief and concise, yet clear as possible. It's confusing. We have no internal router. Just a legacy BSD box acting as a firewall. The internal network, for there really is only one, is 10.0.0.0/16. When it was set up, the 10.0.0 space was allocated along CIDR boundaries on the premise that someday we would have a router to separate un-like network traffic. As a result, we have something like this: Address/CIDR block| Function | Address Range Defined -- 10.0.0/22 | Dev/infrastructure servers | 10.0.0.0 - 10.0.3.255 10.0.4/22 | Mgmt/admin desktops, Mac laptops | 10.0.4.0 - 10.0.7.255 10.0.8/22 | Dev desktops | 10.0.8.0 - 10.0.11.255 10.0.12/24| Network hardware | 10.0.12.0 - 10.0.12.255 10.0.13/24| Printers | 10.0.13.0 - 10.0.13.255 10.0.14/24| MS-OS systems| 10.0.14.0 - 10.0.14.255 10.0.32/19| Dev lab systems | 10.0.32.0 - 10.0.63.255 This allocates a generous portion of addresses to various uses, and, if need be, subdivide based on /24 boundaries if we wanted to. The 10.0.32/19 is an interesting beast. The systems which live on it have 2 NICs, the primary eth0, which *always* have a 10.0.32/19 based address (currently restricted to 10.0.33/24 for some reason?!), and a secondary eth1 which has a primary address of 10.106.XX.YY where XX.YY are the same as the 10.0.XX.YY, and where XX is currently always 33. i.e. host 10.0.33.124 has an eth1 IP of 10.106.33.124. Here's the *really* confusing part. Every system's eth1 *also* has 10 virtual/alias IPs of 10.[96-105].XX.YY. If you recall, I mentioned not having a router. Have I mentioned that the number of hosts in the 10.33/16 range is somewhere around 300, with another 50-100 being added in the next 2 months? :) Both NICs in all systems are essentially on one ethernet network! At any given time, these hosts can have both eth0 and eth1 up, plus any number of the 10 alias IPs up. We are actually about to cut over to a new network configuration this week. However, as the saying goes, "There's nothing more permanent than a temporary solution." and dev has basically evolved their testing infrastructure to *require* this flat network scheme. I'm currently testing things to make sure "nothing breaks" in the transition. One of the things our product does is look at the list of currently configured interfaces, take the "highest" IP and "add 1" to the network portion to obtain a new IP on a different network, but retaining the host portion of the IP. Basically, there's a multi-host negotiation which takes place and figures out a "back-channel" to communicate over. Since name resolution is not possible either via DNS, /etc/hosts, or other means, the only reliable means any two hosts have of reliably talking to each other is making sure that any given host keeps the same host portion of it's IP address on all networks. Does this help clarify things? Ultimately, the ability to support "network addition" using something wacky like a /19 is entirely my own intellectual curiosity, since in-house everything is on a /16 making it trivial. But it's one of those problems I can neither figure out, nor let go of :) As someone said to me yesterday, "IP addresses were never designed to be manipulated, merely assigned and used!" :) -- Seeya, Paul ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
Jason Stephenson <[EMAIL PROTECTED]> writes: > It seems to me that the answer is that your IP addresses are limited > to the range of 10.0.32.0 to 10.0.63.255 with 10.0.0.0 being the > network address and 10.255.255.255 being the broadcast address, no? Err, you've got the IP addresses wrong. It's 10.32.0.0/16, but segmented on a /19 boundary. I need to be able to calculate the "next" network, which for 10.32.0.0/19, would be 10.64.0.0/19, then take the host portion and "add" it to this new network such that any given host has the same host portion on all networks it may exist on. -- Seeya, Paul ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
On 3/28/06, Jason Stephenson <[EMAIL PROTECTED]> wrote: > Of course, after looking back through the thread, I see Ben has already > pretty much answered the above. ;) "Repetition is the very soul of the net." -- from alt.config > Paul is using a network that is restricted to using a /19 netmask for > addressing, but it is really using a /16 when configured. So, he wants > to limit address to 10.0.32.0/19 but needs to configure broadcast and > network addresses for 10.0.32.0/16. Why he needs to do that, I have no > idea and wouldn't need to know. ;) Well... okay... but it's the *why* that makes me wonder. :) I hope it's something interesting, and not just that he's trying to say that he's been assigned the addresses in the range 10.0.32.0/19 on the 10.0.0.0/16 network. That would be *so* boring. :) > It seems to me that the answer is that your IP addresses are limited to > the range of 10.0.32.0 to 10.0.63.255 with 10.0.0.0 being the network > address and 10.255.255.255 being the broadcast address, no? Well, /16 means the first two octets are the network portion and the last two octets are the host portion. So the broadcast address (with CIDR) would be 10.0.255.255. Of course, 10.0.32.0/16 would normally be written 10.0.0.0/16, because, again, the third octet is part of the host portion. The host portion is really irrelevant when talking about network numbers. Convention says we fill the host portion with zeros. -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
On 3/28/06, Paul Lussier <[EMAIL PROTECTED]> wrote: > If you really want the long convoluted discussion, I'll be glad to > post it, I just figured no on would care. Well, everyone here knows *I* thrive on long, convoluted discussions. I'm also curious if you're trying to route packets through a non-existant gateway again. ;-) >> perl -we '$a = inet_addr("192.0.2.42");' >> >> but it complained that inet_addr is not defined. > > You likely need to use -MSocket, and then figure out which of the > correct functions in there are analogous to inet_addr. The ones which > leap to mind are inet_ntoa and inet_aton. There doesn't seem to be an > inet_addr. Hmmm Well, I just tried that quickly, but it looks like Perl's inet_aton() function results in something that Perl thinks is a string, not a long integer. (Probably because inet_aton() is defined in terms of a pointer to character(s), in typical C fashion.) I don't know how to tell Perl to treat the result as the integer it is (so I can do binary operations on it). Or maybe I'm using it wrong. -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
Paul Lussier wrote: Python <[EMAIL PROTECTED]> writes: Would it help to convert to 32-bit integers? I might. I'll try that. It will definitely help. If you get the "netmask" and address both in 32-bit integers, then calculating the network and broadcast addresses is very straightforward. Here's some sample code: network = address & netmask; broadcast = address | ~netmask; The above is C, but should work in Perl, too. Of course, after looking back through the thread, I see Ben has already pretty much answered the above. ;) I think I understand the arithmetic. I do not really understand what you are trying to do. That's okay, neither do I ;) (If you really want the long convoluted discussion, I'll be glad to post it, I just figured no on would care. Of course, I also often misunderstimate the intellectual curiosity of fellow geeks :) I think Paul explained it pretty well in his first post. Let me explain to see if I really understand. Paul is using a network that is restricted to using a /19 netmask for addressing, but it is really using a /16 when configured. So, he wants to limit address to 10.0.32.0/19 but needs to configure broadcast and network addresses for 10.0.32.0/16. Why he needs to do that, I have no idea and wouldn't need to know. ;) Ben's previous message pretty much explains how to solve this. It seems to me that the answer is that your IP addresses are limited to the range of 10.0.32.0 to 10.0.63.255 with 10.0.0.0 being the network address and 10.255.255.255 being the broadcast address, no? Cheers, Jason ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
"Ben Scott" <[EMAIL PROTECTED]> writes: > I tried > > perl -we '$a = inet_addr("192.0.2.42");' > > but it complained that inet_addr is not defined. I suspect there's a > module somewhere you need to pull in. Hopefully this is enough to get > you started. You likely need to use -MSocket, and then figure out which of the correct functions in there are analogous to inet_addr. The ones which leap to mind are inet_ntoa and inet_aton. There doesn't seem to be an inet_addr. -- Seeya, Paul ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
Python <[EMAIL PROTECTED]> writes: > Would it help to convert to 32-bit integers? I might. I'll try that. > I think I understand the arithmetic. I do not really understand what > you are trying to do. That's okay, neither do I ;) (If you really want the long convoluted discussion, I'll be glad to post it, I just figured no on would care. Of course, I also often misunderstimate the intellectual curiosity of fellow geeks :) -- Seeya, Paul ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
On 3/27/06, Paul Lussier <[EMAIL PROTECTED]> wrote: > I'm stumped. I've got a network address space of 10.0.32/19. How > ever, this space is carved up using a /16 netmask. HUH? > Given an address, say 10.0.33.189, I want to get the "network" and > "host" portion of the address. (1) Red Hat provides a nifty utility called "ipcalc" that will do that for you. E.g.: $ ipcalc -b -m -n -p 10.0.33.189/19 NETMASK=255.255.224.0 PREFIX=19 BROADCAST=10.0.63.255 NETWORK=10.0.32.0 $ (2) I find it's a lot easier to conceptualize this stuff if you write it out in binary notation (view using a fixed-width font): /19 = 255.255.224.0 010.000.033.189 = 1010 0011 1001 255.255.224.000 = 1110 Net portion = 1010 0010 Node portion= 0001 1001 (3) You mentioned Perl, but this is the same in most programming languages: It's simple binary arithmetic and Boolean logic. All you need are AND and NOT (complement). The trickier part is usually converting from dotted-quad notation to binary storage. Fortunately, Unix provides a function for that: inet_addr(2). C code looks like this: /* includes */ #include #include #include #include /* main program */ int main() { /* variables */ unsigned int a; /* address */ unsigned int m; /* mask */ unsigned int n; /* node */ /* get address and mask, in network byte order */ a = inet_addr("192.0.2.42"); m = inet_addr("255.255.255.0"); /* find node portion by AND'ing with complement of net-mask */ n = a & (~m); /* convert to host byte order */ n = ntohl(n); /* print result as decimal integer */ printf("node=%d\n", n); } I tried perl -we '$a = inet_addr("192.0.2.42");' but it complained that inet_addr is not defined. I suspect there's a module somewhere you need to pull in. Hopefully this is enough to get you started. -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
On Mon, 2006-03-27 at 14:25 -0500, Paul Lussier wrote: > Hi all, > > I'm stumped. I've got a network address space of 10.0.32/19. How > ever, this space is carved up using a /16 netmask. In otherwords, the > /19 netmask was simply used to *allocate* the space from 10.0.32.0 to > 10.0.63.255, but we actually *use* the space with a /16 netmask (yes, > this means that 10.0.8.10 is in the *same* physical network as > 10.0.33.93!). > > Given an address, say 10.0.33.189, I want to get the "network" and > "host" portion of the address. given that I'm really on a /16, it's > fairly easy to split the IP at 10.0 and 33.189. However, I want to be > able to do the same thing on the /19 as well. Once I have the network > and host portions of the address, I need to increment the network > portion by 1 block, then re-apply the host portion. > > For example, given the address 10.0.33.189/16: > > Network = 10.0 Host = 33.189 >+ 1 > - > 10.1 + $HOST = 10.1.33.189 Would it help to convert to 32-bit integers? When you add 1 here, you are really adding 2 ** 17. Your host mask is int('1' * 16, 2) So newIP = oldIP + 2 ** 17 newhost = newIP & hostmask > > And, given the address 10.0.33.189/19: With a /19, you are adding 2**14 hostmask = int('1' * 13, 2) Converting a.b.c.d (base 256) to integer is left as an exercise for the reader. Perhaps you do not really care about the host mask. You can simply convert the newIP back to base-256 notation. I think I understand the arithmetic. I do not really understand what you are trying to do. > > Network = 10.0.32 Host = 1.189 > + 1 > - > 10.0.64 + $HOST = 10.1.65.189 > > And, given the address 10.0.35.189/19: > Network = 10.0.32 Host = 3.189 > + 1 > - > 10.0.64 + $HOST = 10.1.67.189 > > Getting the "next" network block isn't too tough, Net::Netmask does > that for me. What I can't quite figure out is how to get the host > portion, and then add it to the new network portion. For a classful > address it's fairly simple, for CIDR address, not so much... > > All ideas are welcome and appreciated :) > > Thanks, -- Lloyd Kvam Venix Corp ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
perl and network addresses
Hi all, I'm stumped. I've got a network address space of 10.0.32/19. How ever, this space is carved up using a /16 netmask. In otherwords, the /19 netmask was simply used to *allocate* the space from 10.0.32.0 to 10.0.63.255, but we actually *use* the space with a /16 netmask (yes, this means that 10.0.8.10 is in the *same* physical network as 10.0.33.93!). Given an address, say 10.0.33.189, I want to get the "network" and "host" portion of the address. given that I'm really on a /16, it's fairly easy to split the IP at 10.0 and 33.189. However, I want to be able to do the same thing on the /19 as well. Once I have the network and host portions of the address, I need to increment the network portion by 1 block, then re-apply the host portion. For example, given the address 10.0.33.189/16: Network = 10.0 Host = 33.189 + 1 - 10.1 + $HOST = 10.1.33.189 And, given the address 10.0.33.189/19: Network = 10.0.32 Host = 1.189 + 1 - 10.0.64 + $HOST = 10.1.65.189 And, given the address 10.0.35.189/19: Network = 10.0.32 Host = 3.189 + 1 - 10.0.64 + $HOST = 10.1.67.189 Getting the "next" network block isn't too tough, Net::Netmask does that for me. What I can't quite figure out is how to get the host portion, and then add it to the new network portion. For a classful address it's fairly simple, for CIDR address, not so much... All ideas are welcome and appreciated :) Thanks, -- Seeya, Paul ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss