On 2011-01-31, Didi <dp@tgi-sci.com> wrote:> > It is an option of desperation, of course, but adding another box > only because windows cannot do the correct lookup in its ARP table > is what it is... :-) . Actually I could make the DPS machine > behave as a router and all that - will do it before too long - but > there should be a way devices on the same wire to communicate with > each other... > > Then I prefer that window machine to be with a real IP address, > it keeps a listening VNC viewer to accept support connections > from customers etc. Port forwarding will do most if not all > of what my current needs are but I still cannot accept that > a purely software issue - a very simple to solve one - will > force me to add hardware etc.It can do most of what you want by playing with the routing tables. At an administrative command prompt: route add <IP address> mask <network mask> 0.0.0.0 if <interface number> I would hope IP address and network mask are self explanatory. The interface number is an internal Windows thing - perhaps the easiest way to find it is with a "route print", and the interface number will be the leftmost number by the physical NIC. For example, on the Windows machine here: C:\Users\Administrator>route print =========================================================================== Interface List 11...00 25 22 82 0e 1f ......NVIDIA nForce Networking Controller 1...........................Software Loopback Interface 1 12...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter 13...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface =========================================================================== <snip> The "11" by the NVidia controller is the correct number here, yours may well vary. After the "route add" you should be able to ping the device in question, assuming that _it_ is configured to recognise the Windows machine (still using its original IP address) as being on the local network. Simply setting an entry in the ARP cache probably won't work - who uses proxy ARP anymore? However if the ping is unsuccessful an "arp -a" may help with diagnosis - if there is an entry then the route and ARP are working so presumably the ping got through and the problem is at the other end. -- Andrew Smallshaw andrews@sdf.lonestar.org
Ethernet routing to a second subnet from a wintel machine
Started by ●January 31, 2011
Reply by ●January 31, 20112011-01-31
Reply by ●February 1, 20112011-02-01
On 31/01/2011 21:53, Didi wrote:> On Jan 31, 10:39 pm, David Brown<david.br...@removethis.hesbynett.no> > wrote: >> On 31/01/11 18:53, Didi wrote: >> >> >> >>> On Jan 31, 7:40 pm, Philip Paeps<philip+use...@paeps.cx> wrote: >>>> Didi<d...@tgi-sci.com> wrote: >>>>> The problem I have is that while the wintel pc (xp) has acquired >>>>> its IP& subnet via dhcp from my ISP it won't route packets to >>>>> another subnet (e.g. 192.168.100.xx). >> >>>> Does your 'wintel' machine have an address on that network, or an >>>> interface route to it through the correct interface? >> >>> I don't think it has, it only has the IP address acquired via dhcp >>> from my ISP. I am not familiar with wintel systems, this is why I >>> ask if there is a way - although if there were one I would expect it >>> to be obvious enough to me. >> >>>>> I set manually an ARP entry to the (DPS) machine it has to route >>>>> to but no banana, it still wastes the packets down the gateway of >>>>> the ISP-s subnet. >> >>>> I'm not sure why you need a static ARP entry. >> >>> Well that is straight forward enough. On my DPS machines, outbound >>> packets will route according to an entry (or "subnet", ARP table >>> entries are maskable) in the ARP table; if no routing entry is found >>> in the ARP table, the packet will go down its respective subnet >>> gateway if it belongs there; if it is on the same subnet and there >>> was no ARP entry for it, a network ARP query will be initiated. I >>> expected similar behaviour from windows; but no, the manually set >>> ARP entry is ignored. >> >> I am not entirely sure of the rules involved, but I believe this is >> incorrect behaviour for IP routing. >> >> If your PC interface has an address 192.168.0.20 with a /24 mask, then >> any packets addressed to IP addresses outside that range should be sent >> according to the routing table - which will send them to the default >> gateway if nothing else is defined. I think that if you have an ARP >> table entry for an IP address that is not on the network of the >> interface, then that entry is invalid. Windows is correct here in not >> sending the packet on. > > Nothing invalid about it, as it takes a specific (perhaps > manual) intervention to define an ARP route. Just tried it out, > the DPS machine has no problem reaching the wintel pc either > at its 192.168.100.xx or at it 85.130.xx.xx address. Just some > additional functionality which is in no ones way. Would have > worked without adding the second IP address to the wintel pc > if they also had that functionality, but I am fine and happy > now anyway :-). >I don't know what a "DPS" is, but just because it supports such manual ARP entries is no indication whatsoever that such techniques are valid and follow the RFCs. It could easily be that you have found a way to trick the DPS into doing something useful but non-standard. However, as I said, I don't know for sure that this is non-standard.
Reply by ●February 1, 20112011-02-01
On 31/01/2011 22:36, Char Jackson wrote:> On Mon, 31 Jan 2011 21:39:54 +0100, David Brown > <david.brown@removethis.hesbynett.no> wrote: > >> The ideal arrangement is if Windows had something equivalent to Linux >> interface aliases, which allow you to put more than one IP address on >> the same network interface. However, as is usual in network issues, >> Windows is far less flexible than Linux. > > Windows (XP, at least, not sure about others) is perfectly happy with > multiple IP's on a single NIC. I don't know what the max number is, > but I've successfully run 4 IPs, which was all I needed at the time. > By default, when configuring multiple IP's on a NIC, one of them > cannot be acquired via DHCP, but others have posted a Registry hack > that will change that behavior. > > <http://www.petri.co.il/configure_tcp_ip_to_use_dhcp_and_a_static_ip_address_at_the_same_time.htm> >It's nice to know that it is possible, but it's not exactly intuitive or easy to configure... But thanks for the info - I will remember that it is possible to do it this way. I occasionally have need of more than one IP on the same interface, but I have done that by using VirtualBox machines and choosing to bridge the virtual machine's network card to the host's main physical interface. The extra IP is then the main IP in the virtual machine (Linux, Windows, whatever).
Reply by ●February 1, 20112011-02-01
On Tue, 01 Feb 2011 10:29:57 +0100, David Brown <david@westcontrol.removethisbit.com> wrote:>On 31/01/2011 22:36, Char Jackson wrote: >> On Mon, 31 Jan 2011 21:39:54 +0100, David Brown >> <david.brown@removethis.hesbynett.no> wrote: >> >>> The ideal arrangement is if Windows had something equivalent to Linux >>> interface aliases, which allow you to put more than one IP address on >>> the same network interface. However, as is usual in network issues, >>> Windows is far less flexible than Linux. >> >> Windows (XP, at least, not sure about others) is perfectly happy with >> multiple IP's on a single NIC. I don't know what the max number is, >> but I've successfully run 4 IPs, which was all I needed at the time. >> By default, when configuring multiple IP's on a NIC, one of them >> cannot be acquired via DHCP, but others have posted a Registry hack >> that will change that behavior. >> >> <http://www.petri.co.il/configure_tcp_ip_to_use_dhcp_and_a_static_ip_address_at_the_same_time.htm> >> > >It's nice to know that it is possible, but it's not exactly intuitive or >easy to configure... But thanks for the info - I will remember that it >is possible to do it this way.I assume you mean the Registry hack is not intuitive because the standard method of assigning multiple static IP's is both easy and intuitive. Open the network connectoid that you wish to modify, click on Internet Protocol, click on Properties, enter the first IP and related parameters, then click Advanced and enter as many additional IP addresses as you need. When done, OK your way out.>I occasionally have need of more than one IP on the same interface, but >I have done that by using VirtualBox machines and choosing to bridge the >virtual machine's network card to the host's main physical interface. >The extra IP is then the main IP in the virtual machine (Linux, Windows, >whatever).That works too, but IMHO is overkill for such a simple task.
Reply by ●February 1, 20112011-02-01
On 01/02/2011 12:03, Char Jackson wrote:> On Tue, 01 Feb 2011 10:29:57 +0100, David Brown > <david@westcontrol.removethisbit.com> wrote: > >> On 31/01/2011 22:36, Char Jackson wrote: >>> On Mon, 31 Jan 2011 21:39:54 +0100, David Brown >>> <david.brown@removethis.hesbynett.no> wrote: >>> >>>> The ideal arrangement is if Windows had something equivalent to Linux >>>> interface aliases, which allow you to put more than one IP address on >>>> the same network interface. However, as is usual in network issues, >>>> Windows is far less flexible than Linux. >>> >>> Windows (XP, at least, not sure about others) is perfectly happy with >>> multiple IP's on a single NIC. I don't know what the max number is, >>> but I've successfully run 4 IPs, which was all I needed at the time. >>> By default, when configuring multiple IP's on a NIC, one of them >>> cannot be acquired via DHCP, but others have posted a Registry hack >>> that will change that behavior. >>> >>> <http://www.petri.co.il/configure_tcp_ip_to_use_dhcp_and_a_static_ip_address_at_the_same_time.htm> >>> >> >> It's nice to know that it is possible, but it's not exactly intuitive or >> easy to configure... But thanks for the info - I will remember that it >> is possible to do it this way. > > I assume you mean the Registry hack is not intuitive because the > standard method of assigning multiple static IP's is both easy and > intuitive. > > Open the network connectoid that you wish to modify, click on Internet > Protocol, click on Properties, enter the first IP and related > parameters, then click Advanced and enter as many additional IP > addresses as you need. When done, OK your way out. >Now I've learned two things today - thanks again. Did you read the TAP-Win32 suggestion I made in an earlier post? If my theory is correct, it should give you a way to get a DHCP address and a static address without a registry hack - it should also let you have multiple DHCP addresses, if that is something you want. I'll give it a shot sometime from within a virtual machine.>> I occasionally have need of more than one IP on the same interface, but >> I have done that by using VirtualBox machines and choosing to bridge the >> virtual machine's network card to the host's main physical interface. >> The extra IP is then the main IP in the virtual machine (Linux, Windows, >> whatever). > > That works too, but IMHO is overkill for such a simple task. >For the OP's case, then yes it is overkill, which is why I didn't suggest it. Usually when I am doing some sort of fiddling on the network for which this kind of thing is useful, I prefer to work within a virtual machine anyway. It saves the risk of mucking things up on my main system, and lets me use whatever OS is most suitable for the job in hand (which is typically Linux for these sorts of things).
Reply by ●February 1, 20112011-02-01
On Feb 1, 11:15=A0am, David Brown <da...@westcontrol.removethisbit.com> wrote:> On 31/01/2011 21:53, Didi wrote: > > > > > On Jan 31, 10:39 pm, David Brown<david.br...@removethis.hesbynett.no> > > wrote: > >> On 31/01/11 18:53, Didi wrote: > > >>> On Jan 31, 7:40 pm, Philip Paeps<philip+use...@paeps.cx> =A0 =A0wrote=:> >>>> Didi<d...@tgi-sci.com> =A0 =A0wrote: > >>>>> The problem I have is that while the wintel pc (xp) has acquired > >>>>> its IP& =A0 =A0subnet via dhcp from my ISP it won't route packets t=o> >>>>> another subnet (e.g. 192.168.100.xx). > > >>>> Does your 'wintel' machine have an address on that network, or an > >>>> interface route to it through the correct interface? > > >>> I don't think it has, it only has the IP address acquired via dhcp > >>> from my ISP. I am not familiar with wintel systems, this is why I > >>> ask if there is a way - although if there were one I would expect it > >>> to be obvious enough to me. > > >>>>> I set manually an ARP entry to the (DPS) machine it has to route > >>>>> to but no banana, it still wastes the packets down the gateway of > >>>>> the ISP-s subnet. > > >>>> I'm not sure why you need a static ARP entry. > > >>> Well that is straight forward enough. On my DPS machines, outbound > >>> packets will route according to an entry (or "subnet", ARP table > >>> entries are maskable) in the ARP table; if no routing entry is found > >>> in the ARP table, the packet will go down its respective subnet > >>> gateway if it belongs there; if it is on the same subnet and there > >>> was no ARP entry for it, a network ARP query will be initiated. I > >>> expected similar behaviour from windows; but no, the manually set > >>> ARP entry is ignored. > > >> I am not entirely sure of the rules involved, but I believe this is > >> incorrect behaviour for IP routing. > > >> If your PC interface has an address 192.168.0.20 with a /24 mask, then > >> any packets addressed to IP addresses outside that range should be sen=t> >> according to the routing table - which will send them to the default > >> gateway if nothing else is defined. =A0I think that if you have an ARP > >> table entry for an IP address that is not on the network of the > >> interface, then that entry is invalid. =A0Windows is correct here in n=ot> >> sending the packet on. > > > Nothing invalid about it, as it takes a specific (perhaps > > manual) intervention to define an ARP route. Just tried it out, > > the DPS machine has no problem reaching the wintel pc either > > at its 192.168.100.xx or at it 85.130.xx.xx address. Just some > > additional functionality which is in no ones way. Would have > > worked without adding the second IP address to the wintel pc > > if they also had that functionality, but I am fine and happy > > now anyway :-). > > I don't know what a "DPS" is,DPS (Data Processing System) is the OS running on our products.> but just because it supports such manual > ARP entries is no indication whatsoever that such techniques are valid > and follow the RFCs. =A0It could easily be that you have found a way to > trick the DPS into doing something useful but non-standard. =A0However, a=s> I said, I don't know for sure that this is non-standard.When claiming incompatibility to an RFC you have to quote which one and perhaps give some details. I have "tricked" it (if implementing the thing can be called that) when the need arose, at the beginning it had - can still have - the same behaviour as windows, it was just a little easier to do - and p[erhaps beneficial on huge broadcast domains where searching the cached ARP table for each outbound packet may be not such a good idea. But for the vast majority of cases most of us face in everyday life this is just some additional functionality. Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
Reply by ●February 1, 20112011-02-01
On Tue, 01 Feb 2011 12:33:13 +0100, David Brown <david@westcontrol.removethisbit.com> wrote:>Did you read the TAP-Win32 suggestion I made in an earlier post? If my >theory is correct, it should give you a way to get a DHCP address and a >static address without a registry hack - it should also let you have >multiple DHCP addresses, if that is something you want. I'll give it a >shot sometime from within a virtual machine.I saw that, thanks. I haven't had a need to try it myself, but it looks like it should work.
Reply by ●February 1, 20112011-02-01
On 01/02/11 18:05, Didi wrote:> On Feb 1, 11:15 am, David Brown<da...@westcontrol.removethisbit.com> > wrote: >> On 31/01/2011 21:53, Didi wrote: >> >> >> >>> On Jan 31, 10:39 pm, David Brown<david.br...@removethis.hesbynett.no> >>> wrote: >>>> On 31/01/11 18:53, Didi wrote: >> >>>>> On Jan 31, 7:40 pm, Philip Paeps<philip+use...@paeps.cx> wrote: >>>>>> Didi<d...@tgi-sci.com> wrote: >>>>>>> The problem I have is that while the wintel pc (xp) has acquired >>>>>>> its IP& subnet via dhcp from my ISP it won't route packets to >>>>>>> another subnet (e.g. 192.168.100.xx). >> >>>>>> Does your 'wintel' machine have an address on that network, or an >>>>>> interface route to it through the correct interface? >> >>>>> I don't think it has, it only has the IP address acquired via dhcp >>>>> from my ISP. I am not familiar with wintel systems, this is why I >>>>> ask if there is a way - although if there were one I would expect it >>>>> to be obvious enough to me. >> >>>>>>> I set manually an ARP entry to the (DPS) machine it has to route >>>>>>> to but no banana, it still wastes the packets down the gateway of >>>>>>> the ISP-s subnet. >> >>>>>> I'm not sure why you need a static ARP entry. >> >>>>> Well that is straight forward enough. On my DPS machines, outbound >>>>> packets will route according to an entry (or "subnet", ARP table >>>>> entries are maskable) in the ARP table; if no routing entry is found >>>>> in the ARP table, the packet will go down its respective subnet >>>>> gateway if it belongs there; if it is on the same subnet and there >>>>> was no ARP entry for it, a network ARP query will be initiated. I >>>>> expected similar behaviour from windows; but no, the manually set >>>>> ARP entry is ignored. >> >>>> I am not entirely sure of the rules involved, but I believe this is >>>> incorrect behaviour for IP routing. >> >>>> If your PC interface has an address 192.168.0.20 with a /24 mask, then >>>> any packets addressed to IP addresses outside that range should be sent >>>> according to the routing table - which will send them to the default >>>> gateway if nothing else is defined. I think that if you have an ARP >>>> table entry for an IP address that is not on the network of the >>>> interface, then that entry is invalid. Windows is correct here in not >>>> sending the packet on. >> >>> Nothing invalid about it, as it takes a specific (perhaps >>> manual) intervention to define an ARP route. Just tried it out, >>> the DPS machine has no problem reaching the wintel pc either >>> at its 192.168.100.xx or at it 85.130.xx.xx address. Just some >>> additional functionality which is in no ones way. Would have >>> worked without adding the second IP address to the wintel pc >>> if they also had that functionality, but I am fine and happy >>> now anyway :-). >> >> I don't know what a "DPS" is, > > DPS (Data Processing System) is the OS running on our products. > >> but just because it supports such manual >> ARP entries is no indication whatsoever that such techniques are valid >> and follow the RFCs. It could easily be that you have found a way to >> trick the DPS into doing something useful but non-standard. However, as >> I said, I don't know for sure that this is non-standard. > > When claiming incompatibility to an RFC you have to quote which one > and perhaps give some details. I have "tricked" it (if implementingI am /not/ claiming that it is incompatible with an RFC. I am merely saying that I suspect it might be, and that the fact that the manual ARP method works on one particular system is no indication that it is allowed by the RFCs or that it should be implemented in other systems. I am not even saying that if it against the RFCs then it's a bad idea - just that if it is against the RFCs, then you can't expect other systems to support this method. I haven't read the relevant RFCs, or even looked up their numbers, and I am quite happy to be told that I'm wrong here. I'm just suggesting ideas to consider.> the thing can be called that) when the need arose, at the beginning > it had - can still have - the same behaviour as windows, it was > just a little easier to do - and p[erhaps beneficial on huge > broadcast domains where searching the cached ARP table for each > outbound packet may be not such a good idea. But for the vast majority > of cases most of us face in everyday life this is just > some additional functionality. > > Dimiter > > ------------------------------------------------------ > Dimiter Popoff Transgalactic Instruments > > http://www.tgi-sci.com > ------------------------------------------------------ > http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/ > >
Reply by ●February 1, 20112011-02-01
On Tue, 01 Feb 2011 22:04:25 +0100, David Brown wrote:>>> but just because it supports such manual ARP entries is no indication >>> whatsoever that such techniques are valid and follow the RFCs. It >>> could easily be that you have found a way to trick the DPS into doing >>> something useful but non-standard. However, as I said, I don't know >>> for sure that this is non-standard. >> >> When claiming incompatibility to an RFC you have to quote which one and >> perhaps give some details. I have "tricked" it (if implementing > > I am /not/ claiming that it is incompatible with an RFC. I am merely > saying that I suspect it might be, and that the fact that the manual ARP > method works on one particular system is no indication that it is > allowed by the RFCs or that it should be implemented in other systems. > > I am not even saying that if it against the RFCs then it's a bad idea - > just that if it is against the RFCs, then you can't expect other systems > to support this method. > > I haven't read the relevant RFCs, or even looked up their numbers, and I > am quite happy to be told that I'm wrong here. I'm just suggesting > ideas to consider.I'm not sure RFCs forbid this behavior, but I'm darn sure the RFCs don't require this behavior. It's a well known trick for not fully implemented tcp/ip stacks to behave this way. Any serious implementation does *not* behave this way. Again, I do not know what the RFCs actually require, but I do know that this 'trick' does not work on most ip stacks. HTH, M4
Reply by ●February 1, 20112011-02-01
On Feb 2, 1:35=A0am, Martijn Lievaart <m...@rtij.nl.invlalid> wrote:> ... > I'm not sure RFCs forbid this behavior, but I'm darn sure the RFCs don't > require this behavior.You claim you know that?> It's a well known trick for not fully implemented tcp/ip stacks to behave > this way. Any serious implementation does *not* behave this way.So how many not fully implemented stacks do you know which behave this way. Can you give us some examples.> Again, I do not know what the RFCs actually require, but I do know that > this 'trick' does not work on most ip stacks.It is not a trick. Just a routing policy which may be set this or that way. On the DPS stack it can, that is. Not on the ones you know, I already got that. Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/