|
web
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
At a loss figuring out if an IP is on LAN or INETI'm writing an app that communicates with computers both inside and outside
my router. So I need to determine by the remote host's IP address if I need to send them my LAN IP or my Internet IP. Someone suggested AND'ing the IP and my Subnet Mask but I come up with this: My IP: 192.168.0.14 Mask: 255.255.255.0 Result: 192.168.0.0 Should I just compare the first two octets? Or are there situations where this would provide incorrect results? Terry,
AFAIK are there three ranges reserved for internal use 10.x.x.x 150.x.x.x 192.168.x.x If I am not completely wrong than the first two should therefore be enough. Cor Show quoteHide quote "Terry Olsen" <tolse***@hotmail.com> schreef in bericht news:ug3WninaGHA.4116@TK2MSFTNGP05.phx.gbl... > I'm writing an app that communicates with computers both inside and > outside my router. So I need to determine by the remote host's IP address > if I need to send them my LAN IP or my Internet IP. Someone suggested > AND'ing the IP and my Subnet Mask but I come up with this: > > My IP: 192.168.0.14 > Mask: 255.255.255.0 > > Result: 192.168.0.0 > > Should I just compare the first two octets? Or are there situations where > this would provide incorrect results? > > Terry,
Sorry when I had sent it I realized me that it was not the 150 so I searched for it in Google. 10.x.x.x 172.16.x.x - 172.31.x.x 192.168.x.x Cor corrrect you are.
Testing against the forst two octets should be sufficient to determine routable vs. non routable.... aka internal/external. NOW, if an internal network is configured to have an IP scheme with ROUTABLE IPs ( which CAN be done --- WHY? I wouldn't know)... that would make it a bit touchy. -- Show quoteHide quoteGrumpy Aero Guy "Cor Ligthert [MVP]" <notmyfirstn***@planet.nl> wrote in message news:%23HCKc6naGHA.5088@TK2MSFTNGP03.phx.gbl... > Terry, > > AFAIK are there three ranges reserved for internal use > > 10.x.x.x > 150.x.x.x > 192.168.x.x > > If I am not completely wrong than the first two should therefore be > enough. > > Cor > > "Terry Olsen" <tolse***@hotmail.com> schreef in bericht > news:ug3WninaGHA.4116@TK2MSFTNGP05.phx.gbl... >> I'm writing an app that communicates with computers both inside and >> outside my router. So I need to determine by the remote host's IP address >> if I need to send them my LAN IP or my Internet IP. Someone suggested >> AND'ing the IP and my Subnet Mask but I come up with this: >> >> My IP: 192.168.0.14 >> Mask: 255.255.255.0 >> >> Result: 192.168.0.0 >> >> Should I just compare the first two octets? Or are there situations where >> this would provide incorrect results? >> >> > > The correct way is to AND both the PC's own IP address and the destination
IP address each with the subnet mask... If the result is the same, then they are on the same subnet of the network. Out of interest the result of AND'ing the ip address against the subnet mask produces what is called the "Network Address". For class B addresses (such as your example) this is simply the same as the first two octects followed by 2 zeros, but this may not always be the case... HTH Simon -- Show quoteHide quote================================ Simon Verona Dealer Management Service Ltd Stewart House Centurion Business Park Julian Way Sheffield S9 1GD Tel: 0870 080 2300 Fax: 0870 735 0011 "Grumpy Aero Guy" <f*@beerme.org> wrote in message news:UZm4g.23735$P2.7486@tornado.ohiordc.rr.com... > corrrect you are. > > Testing against the forst two octets should be sufficient to determine > routable vs. non routable.... aka internal/external. > > NOW, if an internal network is configured to have an IP scheme with > ROUTABLE IPs ( which CAN be done --- WHY? I wouldn't know)... that would > make it a bit touchy. > > -- > Grumpy Aero Guy > > > > "Cor Ligthert [MVP]" <notmyfirstn***@planet.nl> wrote in message > news:%23HCKc6naGHA.5088@TK2MSFTNGP03.phx.gbl... >> Terry, >> >> AFAIK are there three ranges reserved for internal use >> >> 10.x.x.x >> 150.x.x.x >> 192.168.x.x >> >> If I am not completely wrong than the first two should therefore be >> enough. >> >> Cor >> >> "Terry Olsen" <tolse***@hotmail.com> schreef in bericht >> news:ug3WninaGHA.4116@TK2MSFTNGP05.phx.gbl... >>> I'm writing an app that communicates with computers both inside and >>> outside my router. So I need to determine by the remote host's IP >>> address if I need to send them my LAN IP or my Internet IP. Someone >>> suggested AND'ing the IP and my Subnet Mask but I come up with this: >>> >>> My IP: 192.168.0.14 >>> Mask: 255.255.255.0 >>> >>> Result: 192.168.0.0 >>> >>> Should I just compare the first two octets? Or are there situations >>> where this would provide incorrect results? >>> >>> >> >> > > Ok, take an example of a pc with an ip address of 192.168.1.1 and a sub net
mask of 255.255.255.128 if you do an AND of the ip address and the subnet mask, you get 192.168.1.0 which is the network address for this subnet. Take another PC with an IP address of 192.168.1.129 with the subnet mask of 255.255.255.128. Do an AND of these two and you get 192.168.1.128 as the network address. These two addresses are on different subnets. There needs to be a router somewhere in the network to route between these networks. The two pc's may be at different locations seperated by a WAN (perhaps the internet). Whilst we normally see subnet masks of 255.255.0.0 or 255.255.255.0 it should not be assumed that it's always a zero at the end of the netmask. This explain better? Regards Simon -- Show quoteHide quote================================ Simon Verona Dealer Management Service Ltd Stewart House Centurion Business Park Julian Way Sheffield S9 1GD Tel: 0870 080 2300 Fax: 0870 735 0011 <aaron.ke***@gmail.com> wrote in message news:1146239215.477739.210290@u72g2000cwu.googlegroups.com... > no please-- give more detail > On 2006-04-29, Simon Verona <nom***@nomail.zzz> wrote:
> Ok, take an example of a pc with an ip address of 192.168.1.1 and a sub net Well, probably not the internet, since these addresses are in the> mask of 255.255.255.128 > > if you do an AND of the ip address and the subnet mask, you get 192.168.1.0 > which is the network address for this subnet. > > Take another PC with an IP address of 192.168.1.129 with the subnet mask of > 255.255.255.128. Do an AND of these two and you get 192.168.1.128 as the > network address. > > These two addresses are on different subnets. There needs to be a router > somewhere in the network to route between these networks. The two pc's may > be at different locations seperated by a WAN (perhaps the internet). private IP range. Show quoteHide quote > Whilst we normally see subnet masks of 255.255.0.0 or 255.255.255.0 it > should not be assumed that it's always a zero at the end of the netmask. > > This explain better? > > Regards > Simon On Fri, 28 Apr 2006 11:26:44 GMT, "Grumpy Aero Guy" <f*@beerme.org> wrote: The computers could have external static IPs that all lie on the same subnet. This most likely a few servers beloning to>corrrect you are. > >Testing against the forst two octets should be sufficient to determine >routable vs. non routable.... aka internal/external. > >NOW, if an internal network is configured to have an IP scheme with ROUTABLE >IPs ( which CAN be done --- WHY? I wouldn't know)... that would make it a >bit touchy. one company that have brought a block of ips, etc. They now can have both their 'internal' network between each other (internal being that they all lie on the same side of a gateway) but at the same time they are external (probaly have a firewall though, at least I'd hope they do). On 2006-04-28, Terry Olsen <tolse***@hotmail.com> wrote:
> I'm writing an app that communicates with computers both inside and outside I'm curious, why do you need to do this? The remote host should already> my router. So I need to determine by the remote host's IP address if I need > to send them my LAN IP or my Internet IP. Someone suggested AND'ing the IP > and my Subnet Mask but I come up with this: > > My IP: 192.168.0.14 > Mask: 255.255.255.0 > > Result: 192.168.0.0 > > Should I just compare the first two octets? Or are there situations where > this would provide incorrect results? know how to respond to you. If you're sending an IP to a third host that distributes the IP (like many P2P networks), then using the IP address to determine local vs. remote isn't going to help you, because you'll have conflicts with identical addresses. > I'm curious, why do you need to do this? The remote host should already There should not be any identical addresses. I am writing a P2P application > know how to respond to you. If you're sending an IP to a third host > that distributes the IP (like many P2P networks), then using the IP > address to determine local vs. remote isn't going to help you, because > you'll have conflicts with identical addresses. that communicates via UDP (as an experiment, I know UDP isn't reliable for a chat application). I want to be able to communicate with other peers both inside and outside my router. Since there is no TCP connection from which to read the remote IP address, when one peer sends a message to another, it also sends the return IP address. So I need to be able to determine if the peer is inside or outside my router so I know which IP address to send as the return address. I won't be sending my "192.168.x.x" address to anyone outside my router, and I should not received a private IP from anyone outside my router. I believe I understand now how to get the "network address" by AND'ing the Subnet Mask with with each IP and comparing the results. I'm going to try that. On 2006-04-29, Terry Olsen <tolse***@hotmail.com> wrote:
>> I'm curious, why do you need to do this? The remote host should already I don't see where the TCP vs. UDP issue comes in. Both have the source>> know how to respond to you. If you're sending an IP to a third host >> that distributes the IP (like many P2P networks), then using the IP >> address to determine local vs. remote isn't going to help you, because >> you'll have conflicts with identical addresses. > > There should not be any identical addresses. I am writing a P2P application > that communicates via UDP (as an experiment, I know UDP isn't reliable for a > chat application). I want to be able to communicate with other peers both > inside and outside my router. Since there is no TCP connection from which to > read the remote IP address, when one peer sends a message to another, it > also sends the return IP address. address in the packet. > So I need to be able to determine if the Maybe I just don't understand the problem. I can sorta see issue in> peer is inside or outside my router so I know which IP address to send as > the return address. I won't be sending my "192.168.x.x" address to anyone > outside my router, and I should not received a private IP from anyone > outside my router. p2p swarming apps like BitTorrent or Kazaa where a third server needs to keep lists of distributable IP addresses and the sender address might not match the distributable address. In this case though, it doesn't look like that's happening. So why can't a node receiving a packet simply reply to the sender, without the issue of embedding a user-defined IP address in the data. > I believe I understand now how to get the "network address" by AND'ing the That's going to break on any internal network with routing. In other> Subnet Mask with with each IP and comparing the results. I'm going to try > that. words, on anything larger than a very trivial home network. This is kinda what I'm getting at. Checking the subnet mask will answer the question you asked, i.e., whether a transmission went through a router. But the question you want seems to be whether a tranmission went through a NAT router, which is a completely different question. Of course, I'm not sure why you need the second question either... > I don't see where the TCP vs. UDP issue comes in. Both have the source What source address is in the packet? The local, private IP? or the public > address in the packet. internet IP? > Maybe I just don't understand the problem. I can sorta see issue in Ok. I'm talking to multiple peers, some inside and some outside my router. > p2p swarming apps like BitTorrent or Kazaa where a third server needs > to keep lists of distributable IP addresses and the sender address might > not match the distributable address. > > In this case though, it doesn't look like that's happening. So why > can't a node receiving a packet simply reply to the sender, without the > issue of embedding a user-defined IP address in the data. > If I send out my private IP (192.168.0.14) to all peers as a return address, then only those INSIDE my router will be able to respond. If I send out my public internet IP to all peers, only those OUTSIDE my router will be able to respond. I need to send the appropriate return IP address to each peer determined by their location relative to my router. >> I believe I understand now how to get the "network address" by AND'ing I don't think I have to worry about this at all. Since I don't control the >> the >> Subnet Mask with with each IP and comparing the results. I'm going to try >> that. > > That's going to break on any internal network with routing. In other > words, on anything larger than a very trivial home network. corporate firewall at work (port forwarding & such), I wouldn't be able to communicate outside the company boundaries anyway. I would simply send my local IP (10.x.x.x) to all other peers. On Sat, 29 Apr 2006 08:22:57 -0600, "Terry Olsen" <tolse***@hotmail.com> Why do you have to send 'your ip' to the server. Can the server not justwrote: >I don't think I have to worry about this at all. Since I don't control the >corporate firewall at work (port forwarding & such), I wouldn't be able to >communicate outside the company boundaries anyway. I would simply send my >local IP (10.x.x.x) to all other peers. > look at the IP and port it sees from the incomming tcp connection? If you need a new connection between the two clients: * client A could tells the server it is ready to accept a connection on port X. * The server can now tell client A to expect a connection from client B * The server now tells client B, client A's ip address (from the tcp connection) and port X * Client B now trys to connect to client A on the give IP and port This could fail if there is a firewall / NAT, but no way to solve this unless you can change the NAT settings to forward your chosen port. To make it easier you could let the client's set what port rages they use for these connection in a config somewhere. Not knowing the particular problem I just thought you may be trying this
as some sort of speed optimisation. If the two computers are on the same subnet try sending using internal ip's (like MSN). For this you could: * query both clients for internal ip/subnet, and client A for port X to connect to * mask ips and compare. If equal you can now send to each client, internal ip and external ip (and to client B, port X from A) * the sever tells client A to expect a connection from A's internal or external ip (probaly want to have A send some sort of random key to the server that can be sent to B) * client B can now try to connect on the internal ip, if that fails it could retry the external ip (and the first thing it needs to send is that secrect key or A or A will close the connection) Along with all this automatic discovery you could allow power users to decide they really do know better and have a config somewhere, where they can set what IP address to send to the server. This gives us two types of IP sent from the client to the server; internal IP/subnet, and forced IP (no subnet as we're now telling the server to always use this IP, should disregard the external IP unless this is some sort of automate regular connection which could result in a DDOS if misused) On 2006-04-29, Chris Chilvers <kee***@dynafus.com> wrote:
This gets into what I mentioned before, the complications of adding a server host to the two clients. I'm not entirely sure the OP needs this, although it's an interesting problem. > Not knowing the particular problem I just thought you may be trying this I still don't see how using the subnet mask helps anything here. The> as some sort of speed optimisation. If the two computers are on the same > subnet try sending using internal ip's (like MSN). For this you could: > * query both clients for internal ip/subnet, and client A for port X to > connect to > * mask ips and compare. If equal you can now send to each client, > internal ip and external ip (and to client B, port X from A) fact that two ip addresses are on different subnets doesn't tell you whether to use the internal IP or the external IP. What the server probably wants to check here is whether the IP in the packet header matched the IP in the packet data. That would tell you whether the packet was NATted, which is what you really want to know. You might also want to check whether hosts A and B had the same external IP both in the packet data and the packet header, which would let you identify situations where A and B are local to each other but remote from the server. Show quoteHide quote > * the sever tells client A to expect a connection from A's internal or > external ip (probaly want to have A send some sort of random key to the > server that can be sent to B) > * client B can now try to connect on the internal ip, if that fails it > could retry the external ip (and the first thing it needs to send is > that secrect key or A or A will close the connection) > > Along with all this automatic discovery you could allow power users to > decide they really do know better and have a config somewhere, where > they can set what IP address to send to the server. This gives us two > types of IP sent from the client to the server; internal IP/subnet, and > forced IP (no subnet as we're now telling the server to always use this > IP, should disregard the external IP unless this is some sort of > automate regular connection which could result in a DDOS if misused) On Sat, 29 Apr 2006 09:25:55 -0700, david <da***@woofix.local.dom>
wrote: >I still don't see how using the subnet mask helps anything here. The I originaly thought about that, but then I thought about the fact that>fact that two ip addresses are on different subnets doesn't tell you >whether to use the internal IP or the external IP. > >What the server probably wants to check here is whether the IP in the >packet header matched the IP in the packet data. That would tell you >whether the packet was NATted, which is what you really want to know. > >You might also want to check whether hosts A and B had the same external >IP both in the packet data and the packet header, which would let you >identify situations where A and B are local to each other but remote >from the server. > the NAT we think about of multiple machines sharing the same IP is in fact NAPT, whilst true NAT means that each machine could have a different external IP whilst all being on the same internal network. The only work around I could see was to have one client try to talk to the other client internaly first to see if a connection could be found, hence the use of the shared secrect. Think about it you probaly want two shared secrects, one from A and one from B so that they both know they are talking to the right machine, whilst in my first idea only A knew it had the right computer, B does not (B could have connected to a random computer that just accepted the connection). On 2006-04-30, Chris Chilvers <kee***@dynafus.com> wrote:
Show quoteHide quote > On Sat, 29 Apr 2006 09:25:55 -0700, david <da***@woofix.local.dom> True, though in practice I think it would be awfully rare to have> wrote: > >>I still don't see how using the subnet mask helps anything here. The >>fact that two ip addresses are on different subnets doesn't tell you >>whether to use the internal IP or the external IP. >> >>What the server probably wants to check here is whether the IP in the >>packet header matched the IP in the packet data. That would tell you >>whether the packet was NATted, which is what you really want to know. >> >>You might also want to check whether hosts A and B had the same external >>IP both in the packet data and the packet header, which would let you >>identify situations where A and B are local to each other but remote >>from the server. >> > > I originaly thought about that, but then I thought about the fact that > the NAT we think about of multiple machines sharing the same IP is in > fact NAPT, whilst true NAT means that each machine could have a > different external IP whilst all being on the same internal network. multiple desktop machines behind "true NAT" firewalls. The > only work around I could see was to have one client try to talk to the Agreed. > other client internaly first to see if a connection could be found, > hence the use of the shared secrect. Think about it you probaly want two > shared secrects, one from A and one from B so that they both know they > are talking to the right machine, whilst in my first idea only A knew it > had the right computer, B does not (B could have connected to a random > computer that just accepted the connection). Ideally you'd also want to handle situations where A can initiate a connection with B, but B can't initiate a connection with A. But I suspect this is all getting pretty far afield from the OP's needs, which I don't think included server registration at all. On 2006-04-29, Terry Olsen <tolse***@hotmail.com> wrote:
>> I don't see where the TCP vs. UDP issue comes in. Both have the source The IP address from which the packet arrived. In other words, for>> address in the packet. > > What source address is in the packet? The local, private IP? or the public > internet IP? internet hosts, the packet will contain the external public address, for internal network hosts, the packet will contain the internal address. This seems to be the information you're trying to handle yourself, when in fact the network layer is already handling it for you. More importantly, for external internet hosts what you really want is the NATted address, and that's what the packet will contain, since a NAT firewall will replace the source address in the header. Show quoteHide quote > What I'm suggesting is don't send any IP address in your data packet.>> Maybe I just don't understand the problem. I can sorta see issue in >> p2p swarming apps like BitTorrent or Kazaa where a third server needs >> to keep lists of distributable IP addresses and the sender address >> might not match the distributable address. >> >> In this case though, it doesn't look like that's happening. So why >> can't a node receiving a packet simply reply to the sender, without >> the issue of embedding a user-defined IP address in the data. >> > > Ok. I'm talking to multiple peers, some inside and some outside my > router. If I send out my private IP (192.168.0.14) to all peers as a > return address, then only those INSIDE my router will be able to > respond. If I send out my public internet IP to all peers, only those > OUTSIDE my router will be able to respond. I need to send the > appropriate return IP address to each peer determined by their > location relative to my router. Let the IP stack worry about putting the correct address in the header. Unless you have special needs, this isn't something the application layer should be worrying about. > Host 1 has address 10.0.0.1/255.255.255.0 (address/subnet) >>> I believe I understand now how to get the "network address" by >>> AND'ing the Subnet Mask with with each IP and comparing the results. >>> I'm going to try that. >> >> That's going to break on any internal network with routing. In other >> words, on anything larger than a very trivial home network. > > I don't think I have to worry about this at all. Since I don't control > the corporate firewall at work (port forwarding & such), I wouldn't be > able to communicate outside the company boundaries anyway. I would > simply send my local IP (10.x.x.x) to all other peers. Host 2 has address 10.0.1.1/255.255.255.0 Now these two hosts are NOT on the same subnet, in fact they must be routed, and your algorithm will correctly identify that. But in reality both hosts are probably behind the firewall, and you'd have to use the internal IP addresses to communicate between them. IAW, routed != NAT. > What I'm suggesting is don't send any IP address in your data packet. Here's the code I'm using to receive the packets:> Let the IP stack worry about putting the correct address in the > header. Unless you have special needs, this isn't something the > application layer should be worrying about. Private Sub RcvCallback(ByVal ar As IAsyncResult) Dim _UdpState As UdpState = ar.AsyncState Dim _UdpClient As UdpClient = _UdpState.cl Dim IPE As IPEndPoint = _UdpState.ep Dim rcvd As String = ASCII.GetString(_UdpClient.EndReceive(ar, IPE)) ThreadPool.QueueUserWorkItem(New WaitCallback(AddressOf ProcessIncoming), rcvd) _UdpClient.BeginReceive(New AsyncCallback(AddressOf RcvCallback), _UdpState) End Sub How would I go about getting the source IP (and port?) ? I tried looking at the Address from IPE but it just shows "0.0.0.0". Nevermind. I got it. Check IPE.Address _AFTER_ the _UdpClient.EndReceive,
not before :) Can't use the port property, because I need to know what port the peer is listening on, no the port used to send. Show quoteHide quote > Here's the code I'm using to receive the packets: > > Private Sub RcvCallback(ByVal ar As IAsyncResult) > Dim _UdpState As UdpState = ar.AsyncState > Dim _UdpClient As UdpClient = _UdpState.cl > Dim IPE As IPEndPoint = _UdpState.ep > Dim rcvd As String = ASCII.GetString(_UdpClient.EndReceive(ar, IPE)) > ThreadPool.QueueUserWorkItem(New WaitCallback(AddressOf > ProcessIncoming), rcvd) > _UdpClient.BeginReceive(New AsyncCallback(AddressOf RcvCallback), > _UdpState) > End Sub 
Other interesting topics
update form background color
DLL does not load Dynamically DWORDS ? LONG? - I need to create constants for the following Datagrid, binded columns and unbinded columns Can't open a project by iteself? Solution opens every time! Stepping between .Net IDE into a VB6 dll call Invoking apps within VB is this possible... Format Function Textbox, how to detect enter "key" event. |
|||||||||||||||||||||||
