how-to block ads
|
|
Share Topic
 |
 |
|
 msjPremium
join:2004-05-21
Fort Collins, CO
kudos:1 | reply to bigjoesmith
Re: DHCP Spoofing / Half Bridging said by bigjoesmith:... local LAN with it's own ethernet address. So the local computer, which thinks the default gateway is locally accessable, arps for the default gateway and the modem replies that it is the default gateway's IP (63.231.10.204). The local computer sends the tracert off to the modem's ethernet address, thinking it's the default gateway. Actually your machine doesn't think it's locally accessible since the address of the gateway is not within the subnet of any of its connected networks. But since you have a default route for it that says it can get to it via the local interface it arps for it anyway.
I spent some time trying to get a route like that installed via the route command. It can't be done. Windows will complain that the address is not local and refuse to install the route. I tried first installing a static route to the remote gateway, which allows you to ping the remote gateway (note I also turned on proxy-arp in the modem so that it does respond to arps for the remote gateway). At that point an arp -a shows that it has a mapping from the remote gateway IP address to the ethernet address of the modem. But the route command still won't let you install a default route that uses the remote gateway.
However, if you specify the remote gateway in the IP properties for the interface THEN it will bypass the route command and install the default route (and this is also how DHCP succeeds in doing it on Windows).
This presents a slight problem on a Linux system. The standard dhclient software uses the route command to install routes, and the route command on Linux also complains about the gateway not being local. However, contrary to Windows, you can workaround this by installing a static route to the remote gateway. Linux will then allow you to install a default route to the gateway. The problem is that dhclient won't do this for you by default, so the Speedtouch modem is not going to work for a Linux system by default (you would need to add an exit hook for the dhclient-script). I wonder if this will also prevent it from working with some ethernet routers, since many of them are running Linux (although since they are embedded systems, they typically run alternate, smaller versions of things like dhclient, so perhaps they work differently). I'll have to try this experiment with my Linksys WRT54g and see what happens.
If it doesn't work with a Linux based router most customers are not going to know how to log into the router and fix the problem (and if it fails there won't be any indication of why it fails). | | |
|
Reviews:
 ·Future Nine Corp..
| Interesting comments about Linux and the Speedtouch. I don't run Linux here right now, but I have heard of people using a Speedtouch, DHCP-spoofing, and Linux. For example, see here: »gyrene.com/survival/dhcp_spoof1.htm In that case, he's talking about a Speedtouch Home Pro modem, and not the 510, but I think they are similar in their behavior. The 510 can be flashed to a Home Pro, which I believe is an earlier model. | |
Reviews:
·Future Nine Corp..
| reply to msj
Here's another site where the person reaches a conclusion very similar to yours about the problems of DHCP-spoofing under Linux as implemented on the 510.
»www.stonki.de/Speedtouch_510.13.0.html | |
msjPremium
join:2004-05-21
Fort Collins, CO
kudos:1 | reply to bigjoesmith
said by bigjoesmith:Interesting comments about Linux and the Speedtouch. I don't run Linux here right now, but I have heard of people using a Speedtouch, DHCP-spoofing, and Linux. For example, see here: » gyrene.com/survival/dhcp_spoof1.htm In that case, he's talking about a Speedtouch Home Pro modem, and not the 510, but I think they are similar in their behavior. The 510 can be flashed to a Home Pro, which I believe is an earlier model. He only makes a short reference regarding having it working under Linux. Perhaps he figured out the problem and manually installed the appropriate static route. But it's also possible that he was using a different dhcp client. There are at least four of them, probably more.
I did try a simulation with the Linksys WRT54g. It had the same problem. You can't easily get into a Linksys because it doesn't run a telnetd or sshd. I'm able to log into it because I have a serial port attached to mine. This means that most people would not be able to use this Speedtouch feature with the Linksys getting the external address via "DHCP Spoofing".
said by bigjoesmith:Here's another site where the person reaches a conclusion very similar to yours about the problems of DHCP-spoofing under Linux as implemented on the 510. It looks like that person didn't figure out the workaround. He made the silly claim that "DHCP Spoofing" violated "all kinds of ethernet standards". It certainly doesn't violate any ethernet standards, and I don't believe it violates any IP standards. It does perhaps violate some IP conventions though. Still, it's a useful feature.
said by bigjoesmith:The netmask that my computer obtains from the DHCP-spoofing modem is 255.255.0.0. Now this surprises me a little. I tested using a netmask of 255.255.255.255 and it worked just fine with Windows (although you can't manually enter it even in the network IP properties box, you have to provide it via DHCP). It doesn't make any sense to use a bogus netmask. 255.255.0.0 is certainly not the correct netmask, in fact PPP does not provide the remote netmask at all, so it was fabricated. There is some old code in pppd that still uses the old ClassA,ClassB,ClassC stuff to create a netmask, so I bet that is where it came from (newer versions of pppd override that code, and also any netmask passed in via the command line, and hardwires the netmask to 255.255.255.255).
Using too large a netmask isn't going to cause a real problem if the modem arps for everything in the same range. It just causes uneccessary arp table entries on your PC (rather than the single arp entry that would be required for the remote gateway address). Now if the netmask was too small (not very likely, but possible) then it may prevent you from reaching a legitimate IP address ending in 255.255, because the PC would think that was the broadcast address for the network. | |
Reviews:
·Future Nine Corp..
| said by msj:said by bigjoesmith:The netmask that my computer obtains from the DHCP-spoofing modem is 255.255.0.0. Now this surprises me a little. I tested using a netmask of 255.255.255.255 and it worked just fine with Windows (although you can't manually enter it even in the network IP properties box, you have to provide it via DHCP). It doesn't make any sense to use a bogus netmask. 255.255.0.0 is certainly not the correct netmask, in fact PPP does not provide the remote netmask at all, so it was fabricated. There is some old code in pppd that still uses the old ClassA,ClassB,ClassC stuff to create a netmask, so I bet that is where it came from (newer versions of pppd override that code, and also any netmask passed in via the command line, and hardwires the netmask to 255.255.255.255). The problem you identified where the address of the gateway is not within the subnet of any connected networks is just that...it's only a problem when the gateway is outside the network of the public IP given to the local host. I suspect the "bogus" netmask is used to minimize the cases where the address of the gateway in not within the subnet of any of the connected networks. If I had to guess, that's what I would advance as their reason for cremudging up a 255.255.0.0 netmask as opposed to a 255.255.255.255 netmask. | |
NormanSPremium,MVM
join:2001-02-14
San Jose, CA
kudos:4 Reviews:
 ·SONIC.NET
·Pacific Bell - SBC
| reply to msj
said by msj:Now this surprises me a little. I tested using a netmask of 255.255.255.255 and it worked just fine with Windows (although you can't manually enter it even in the network IP properties box, you have to provide it via DHCP). It doesn't make any sense to use a bogus netmask. 255.255.0.0 is certainly not the correct netmask, in fact PPP does not provide the remote netmask at all, so it was fabricated. There is some old code in pppd that still uses the old ClassA,ClassB,ClassC stuff to create a netmask, so I bet that is where it came from (newer versions of pppd override that code, and also any netmask passed in via the command line, and hardwires the netmask to 255.255.255.255). Using too large a netmask isn't going to cause a real problem if the modem arps for everything in the same range. It just causes uneccessary arp table entries on your PC (rather than the single arp entry that would be required for the remote gateway address). Now if the netmask was too small (not very likely, but possible) then it may prevent you from reaching a legitimate IP address ending in 255.255, because the PC would think that was the broadcast address for the network. What makes 255.255.0.0 an "incorrect" netmask? All the netmask does is define the number of devices which can be connected to a network.
I expect that the netmask is configured by the device which creates the network. I have a SpeedStream 4100 DSL modem which sets up the modem as the gateway, and it assigns a netmask of 255.255.0.0. Presumably, as bigjoesmith states, this allows the gateway to be accessed from a different LAN network address; i.e., I can route packet to the gateway IP address from 192.168.102.100.
BTW, this is not the generic SS4100 that you would get off the shelf at a retailer direct from Siemens; this is modified to order for SBC. There is no way to change any of the IP address configurations. In the absence of an Internet connection, or by choice of pushing a private IP address to the computer/router, instead of a public IP address, this version of the SS4100 always assigns IP address 192.168.1.64 to the computer/router. This, also, can't be configured. I expect that having both a 192.168.0.x and a 192.168.1.x address on the same LAN requires a larger subnet than 255.255.255.255; maybe a 255.255.254.0 would be the smallest netmask that would work? But, as I said, the SBC modified SS4100 does not allow for a configuration change of any of the IP addresses, subnet masks.
I will have to put a sniffer on the wire between the SS4100 and the Netgear FR114P someday, I guess.
--
Norman
~A deam, dream, no dream
~Voices of the night go across the forest
~A dream, dream, no dream
~Good night my good child | |
msjPremium
join:2004-05-21
Fort Collins, CO
kudos:1 | reply to bigjoesmith
said by bigjoesmith:The problem you identified where the address of the gateway is not within the subnet of any connected networks is just that...it's only a problem when the gateway is outside the network of the public IP given to the local host. I suspect the "bogus" netmask is used to minimize the cases where the address of the gateway in not within the subnet of any of the connected networks. If I had to guess, that's what I would advance as their reason for cremudging up a 255.255.0.0 netmask as opposed to a 255.255.255.255 netmask. I guess that is a possibility. But since there is some code in pppd that chooses a netmask based on the old network class system, it could just be a side effect of that also. It would be interesting to see what would happen if someone with a static IP used such a modem, since Qwest's static addresses are mostly allocated from the 207.224.0.0 network. That address is in the old class C region. So it would be interesting to see if the modem would assign a 255.255.255.0 address instead, or if it still used 255.255.0.0.
But you are right that if the gateway address was within the netmask range then Linux wouldn't have the problem I noticed. Perhaps that explains why some people haven't seen a problem using the modem with Linux. | |
|
