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: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. | |
|
