dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
18302

AthlGrond
Premium Member
join:2002-04-25
Aurora, CO

1 recommendation

AthlGrond

Premium Member

DHCP Spoofing / Half Bridging

Since the topic of dhcp spoofing / Half Bridging comes up quite a bit I thought I'd start a resource topic on it.

Here is what I know about dhcp spoofing / Half Bridging:

1) It is a feature supported by a few modems
2) It allows the modem to act as if it is bridged without the assistance of your ISP
3) It works with PPPoA

A list of modems that work with dhcp spoofing / Half Bridging and Qwest DSL:
SpeedTouch 510, 530, (570?)
Zoom ADSL X4 (with some issues)

Linkage:
»Speedtouch and real IP address
»Re: Public IP on the inside: dhcp spoofing for Tho
»modem alternatives
»www.skidmark.net/spoofing.htm
»www.petri.co.il/configur ··· fing.htm

Please add any modems or references that you know of that support dhcp spoofing / Half Bridging, or would help people set up dhcp spoofing / Half Bridging on their modems.

msj
Premium Member
join:2004-05-21
Fort Collins, CO

1 recommendation

msj

Premium Member

Well, I would just note that "dhcp spoofing" and "Half Bridging" are marketing terms, and aren't very accurate in describing how this is done.

I don't have one of these modems (I have the Actiontec GT701WG) but I was interested in finding out how these modems do what they do (and possibly adding the feature to the Actiontec in the future).

So, from reading as much as I can find, I believe I understand how this works. The "dhcp spoofing" part describes the process in which you get the external IP address on your machine. This process is the same as what has been done in the past with dumb (non routing) cable modems. When you first connect to the modem (or after power is cycled on the modem) the modem first delivers a local IP address to your machine, however the lease is very short). This allows you to connect to the modem and possibly do configuration, etc. Meanwhile the modem is establishing a connection via PPPoA to your ISP. Once it gets the external IP address to use it waits for the lease to expire. When your machines lease expires it makes a new request for an IP address via dhcp, and this time the modem gives you the external address with a normal lease. I assume that if the connection fails or doesn't complete before the first short lease expires the modem will just reissue the internal IP with another short lease.

Anyway, there is nothing new about that part of the feature, in fact it was the norm for older cable modems that didn't have a router built into the modem. I don't think it was called "dhcp spoofing" in the past. I have a hard time with describing this as spoofing.

The second part of making this work is "Half Bridging". I don't like this name either. There is nothing "half" about it. It is just a different type of bridging. Normally when you use bridging you are bridging the ethernet (local LAN) device with the ATM device. The bridging support in Linux just passes the ethernet packets between the drivers. The ATM driver handles encapsulating/splitting the ethernet packets within ATM packets (Ethernet over ATM).

When you are not bridging the modem starts a PPPoA connection over the ATM device. It creates a virtual lan device (ppp0 on Linux) that is the local endpoint for the connection. It is this ppp0 device that gets the external IP address. The modem then routes packets between the local lan device (eth0 on Linux) and the ppp device.

In the "Half Bridging" scenario eth0 is not bridged to the ATM device. Instead the ppp daemon starts a normal PPPoA connection as before, creating the ppp0 device. However the external IP address is not assigned to that device. Instead the ppp0 device is bridged with eth0. Note that on Linux the bridging control command, brctl is used in both bridging cases. In one case it is used to bridge the ethernet device with the ATM device. In the other case it is used to bridge the ethernet device with the ppp device. If I had to choose a name for this feature I would probably call it "PPP bridging"

So, you might ask whether you could log into the Actiontec modem and use brctl to bridge eth0 with ppp0 after the connection is established. I wondered that also. However, the standard 2.4 kernel doesn't have support in the ppp lan device to support bridging. However, there is a patch available for that support. I'm currently playing around with OpenWRT on the Actiontec modem, and I may try to add that feature at some point (which of course would kind of defeat the purpose of having OpenWRT running on the modem ).

Anyway, hopefully this has been informative and you will forgive me for the small rant!

AthlGrond
Premium Member
join:2002-04-25
Aurora, CO

AthlGrond

Premium Member

said by msj:

In the other case it is used to bridge the ethernet device with the ppp device. If I had to choose a name for this feature I would probably call it "PPP bridging"
I've seen "PPP Half Bridge" on some modem spec sheets.

I think part of the problem with this technology is that is isn't very well described (lack of standard terminology) or supported by the hardware manufacturers.

I imagine that its usefulness will eventually lead to it being a standard feature/option at some point.

NormanS
I gave her time to steal my mind away
MVM
join:2001-02-14
San Jose, CA
TP-Link TD-8616
Asus RT-AC66U B1
Netgear FR114P

3 edits

NormanS to msj

MVM

to msj
said by msj:

I don't have one of these modems (I have the Actiontec GT701WG) but I was interested in finding out how these modems do what they do (and possibly adding the feature to the Actiontec in the future).

So, from reading as much as I can find, I believe I understand how this works. The "dhcp spoofing" part describes the process in which you get the external IP address on your machine. This process is the same as what has been done in the past with dumb (non routing) cable modems. When you first connect to the modem (or after power is cycled on the modem) the modem first delivers a local IP address to your machine, however the lease is very short). This allows you to connect to the modem and possibly do configuration, etc. Meanwhile the modem is establishing a connection via PPPoA to your ISP. Once it gets the external IP address to use it waits for the lease to expire. When your machines lease expires it makes a new request for an IP address via dhcp, and this time the modem gives you the external address with a normal lease. I assume that if the connection fails or doesn't complete before the first short lease expires the modem will just reissue the internal IP with another short lease.
Something like this?
2005/08/25 11:05:21 GMT E |System       |=============== SYSTEM UP ===============
2005/08/25 11:05:21 GMT E |System |Current Mode: PPP on the modem (Public IP for LAN device)
2005/08/25 11:05:22 GMT E |DSL |DataPump Version 01.01.00.00
2005/08/25 11:05:22 GMT E |DSL |State: WAITING
2005/08/25 11:05:24 GMT E |Ethernet |Link 1 Up - 100Base-TX Full Duplex
2005/08/25 11:05:26 GMT E |DSL |State: INITIALIZING
2005/08/25 11:05:34 GMT E |DSL |HYBRID 1
2005/08/25 11:05:34 GMT E |DSL |Link up 1 US 384 DS 1536 (FAST:G.dmt)
2005/08/25 11:06:02 GMT E |dhcp Server |Smarttimeout invoked, lease timeout
2005/08/25 11:06:31 GMT E |dhcp Server |Address 192.168.1.64 given out to 00:09:5b:2c: f2:3b
2005/08/25 11:06:31 GMT E |PPPoE |tx PADI, id: 0000, ac: (NULL), sn: (NULL)
2005/08/25 11:06:31 GMT E |PPPoE |rx AC Name: 62011030047564-rback2.sntc01
2005/08/25 11:06:31 GMT E |PPPoE |tx PADR, id: 0000, ac: (NULL), sn: (NULL)
2005/08/25 11:06:31 GMT E |PPPoE |rx PADS id: C644
2005/08/25 11:06:31 GMT E |PPP |LCP neg PAP
2005/08/25 11:06:31 GMT E |PPP |LCP up
2005/08/25 11:06:33 GMT E |PPP |IPCP nak option: 3
2005/08/25 11:06:33 GMT E |PPP |IPCP nak option: 129
2005/08/25 11:06:33 GMT E |PPP |IPCP nak option: 131
2005/08/25 11:06:33 GMT E |PPP |IPCP up ip: 64.161.28.158,
gw: 64.161.31.254,
dns: 206.13.31.12, 20 6.13.28.12
2005/08/25 11:06:46 GMT E |dhcp Server |Address 64.161.28.158 given out to 00:09:5b:2c :f2:3b
2005/08/25 11:07:10 GMT E |SNTP Client |Updated time from Primary server 132.163.4.102
2005/08/25 11:26:36 GMT E |Ethernet |Link 1 Down
2005/08/25 11:26:37 GMT E |Ethernet |Link 1 Up - 100Base-TX Full Duplex
2005/08/25 12:13:09 GMT E |Ethernet |Link 1 Down
2005/08/25 12:13:11 GMT E |Ethernet |Link 1 Up - 100Base-TX Full Duplex
The modem calls it, "PPP on the modem (Public IP for LAN device)".
VikingStorm
join:2002-06-25
Omaha, NE

VikingStorm to AthlGrond

Member

to AthlGrond
I have a Westell Ultraline 7401 that is suppose to be able to do that. (Assign the WAN IP internally), they call it IP Passthrough, or something more vague (the feature was labeled as static ip something) in the generic firmware. But haven't had the time to fully play with it. I was able to get the router to get the WAN IP, but couldn't get the connection to work correctly through the router.

Bink007
@qwest.net

Bink007 to AthlGrond

Anon

to AthlGrond
Does anyone know if the planned 2wire modems will support this feature?
bigjoesmith
join:2000-11-21
Peoria, IL

1 recommendation

bigjoesmith to AthlGrond

Member

to AthlGrond
A dhcp spoofing topic and I have not chimed in yet. Well...I have been away, unconnected for the last few weeks.

I agree that the dhcp spoofing/Half Bridging monikers are half baked and not entirely accurate. What is important is the capabilities being provided by these technologies, which is a PPPoA-based DSL connection where the public IP is not consumed by the modem itself but is instead passed to the inside LAN. The public IP is available to the end-user's computer and the end user has a direct connection to the Internet, without any interferring NAT server in the modem.

In other words, the end user enjoys a connection that is very similar to the standard dial-up connection or cable modem connection: a public IP and no NAT and easy configuration via dhcp on the end-user's computer.

The public mechanism of how this is achieved is similar: the modem makes available, via a dhcp server, the IP configuration information that it received itself upon making the PPPoA connection to the ISP. The end-user's computer (or router, or whatever), just works as a normal dhcp client...it has no idea that anything different is happening under the covers.

I suspect the implementation mechanism (under the covers) varies from modem to modem.

In my case, using an Speedtouch 510v4 modem, here's some details on how it works:

1) I'm not sure if the modem provides a very short initial IP address to the local computer while the PPPoA connection is being established (as described above) I've never checked. However, the modem is still accessible to local computers (for configuration, etc) as descibed below.

2) The modem establishes a PPPoA connection to the ISP, obtaining a public IP address and other configuration information.

3) This public IP address is made available to local computers by a dhcp server that listens for dhcp configuration requests on the modem's ethernet interface. Only the first request to the server will get the public IP address.

4) The local computer will configure according to the information received from the modem's dhcp server. This will include assigning the public IP to the computer's ethernet interface that is connected to the modem. The computer's default gateway will be the default gateway at the ISP, as specified when the PPPoA connection is established. In other words, the computer's routing table will include a default route as illustrated below by my specific situation (acutal IPs will vary).
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 63.231.10.204 168.103.152.x 20
where 168.103.152.x is the public IP assigned to the computer's ethernet interface that is connected to the modem and 63.231.10.204 is the default gateway at the ISP.

5) When the local computer tries to communicate with a remote host on the Internet (say cs.washington.edu, 128.208.3.200), it generates a packet addressed to the remote host and passes the packet off to the default gateway.

6) A tracert to cs.washington.edu reveals the following (only the first 3 lines of the trace route included):
Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.

C:\>tracert cs.washington.edu

Tracing route to cs.washington.edu [128.208.3.200]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 169.254.141.11
2 215 ms 220 ms 230 ms tukw-dsl-gw12-204.tukw.qwest.net [63.231.10.204]

3 255 ms 253 ms 273 ms tukw-agw1.inet.qwest.net [63.231.10.125]
We see that the first visible hop is something at 169.254.141.11. What's this? It's the modem. The modem, as part of the dhcp-spoofing configuration (or whatever you want to call it) has assigned itself (out of the self-assignment IP pool) an IP address that is attached to the modem's ethernet interface. And indeed, the modem is available (for configuration, etc) on that IP address to the local computer. The modem received the packet for cs.washington.edu and then passed it off to the ISP's default gateway, the 63.231.10.204 host. So the modem is visible in the tracert as a normal layer 3 IP router.

7) How did the modem end up as the first hop when the local computer's routing table indicates that it would have sent the packet to the ISP's default gateway as the first hop? The local computer's ARP table shows what is happening:
C:\>arp -a

Interface: 168.103.152.x--- 0x10003
Internet Address Physical Address Type
63.231.10.204 00-90-d0-c4-86-e4 dynamic

00-90-d0-c4-86-e4 is the ethernet address of my modem. So what has happened is that the modem is answering arp reqests for the 63.231.10.204 (the ISP's default gateway) on the 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.

So, as implemented on the Speedtouch, dhcp-spoofing is not just a simple transparent layer 2 bridge. It functions more like a layer 3 IP router, but with some special characteristics thrown in. I hope this provides some insight into what dhcp-spoofing provides the end-user and how it's implemented on one modem.

Bink007
@rockynet.com

Bink007

Anon

Nice write-up Joe...

NormanS
I gave her time to steal my mind away
MVM
join:2001-02-14
San Jose, CA
TP-Link TD-8616
Asus RT-AC66U B1
Netgear FR114P

NormanS to bigjoesmith

MVM

to bigjoesmith
said by bigjoesmith:

So, as implemented on the Speedtouch, dhcp-spoofing is not just a simple transparent layer 2 bridge. It functions more like a layer 3 IP router, but with some special characteristics thrown in. I hope this provides some insight into what dhcp-spoofing provides the end-user and how it's implemented on one modem.
Interesting...based on my SpeedStream 4100, as connected to my Netgear FR114P, and pushing a public IP address from the SS4100 to the Netgear FR114P:

Item 4:
Diagnostic - Routing Table (from Netgear FR114P connected to SpeedStream 4100)

Destination Mask Gateway Metric Active
Default -- 64.174.90.97 -- Yes
64.174.90.0 255.255.255.0 64.174.90.97 1 Yes
64.174.90.97 255.255.255.255 64.174.90.97 1 Yes
192.168.102.0 255.255.255.0 192.168.102.1 1 Yes
192.168.102.1 255.255.255.255 192.168.102.1 1 Yes
Item 6:
C:\WINDOWS>tracert cs.washington.edu

Tracing route to cs.washington.edu [128.208.3.200]
over a maximum of 30 hops:

1 41 ms 55 ms 55 ms Suzuka [192.168.0.1]
2 69 ms 55 ms 27 ms adsl-64-174-91-254.dsl.sntc01.pacbell.net [64.174.91.254]
3 14 ms 14 ms 14 ms dist2-vlan50.sntc01.pbi.net [63.203.35.66]
Item 7:
C:\WINDOWS>arp -a

Interface: 192.168.102.100 on Interface 0x4
Internet Address Physical Address Type
192.168.102.1 00-09-5b-2c-f2-3a dynamic
I would have to change the physical connection to show the arp table for the modem connection; alas, the Netgear doesn't seem to let me see its arp table.
bigjoesmith
join:2000-11-21
Peoria, IL

bigjoesmith

Member

said by NormanS See Profile
Interesting...based on my SpeedStream 4100, as connected to my Netgear FR114P, and pushing a public IP address from the SS4100 to the Netgear FR114P:
C:\WINDOWS>tracert cs.washington.edu

Tracing route to cs.washington.edu [128.208.3.200]
over a maximum of 30 hops:

1 41 ms 55 ms 55 ms Suzuka [192.168.0.1]
2 69 ms 55 ms 27 ms adsl-64-174-91-254.dsl.sntc01.pacbell.net [64.174.91.254]
3 14 ms 14 ms 14 ms dist2-vlan50.sntc01.pbi.net [63.203.35.66]

[/BQUOTE :


In this case, it would appear that the SpeedStream is using a different implementation technique. If I'm understanding your network correctly, it seems that the first hop is your netgear router at 192.168.0.1, then the next hop is a pacbell router at 64.174.91.254. On the other hand, perhaps 64.174.91.254 is your public IP. I admit I'm little confused about your network.

If your netgear is at 192.168.0.1, why is the ping time taking on the order of 55ms? That seems rather high for a locally connected host over Ethernet.
bigjoesmith

bigjoesmith

Member

said by bigjoesmith:

6) A tracert to cs.washington.edu reveals the following (only the first 3 lines of the trace route included):
Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.

C:\>tracert cs.washington.edu

Tracing route to cs.washington.edu [128.208.3.200]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 169.254.141.11
2 215 ms 220 ms 230 ms tukw-dsl-gw12-204.tukw.qwest.net [63.231.10.204]

3 255 ms 253 ms 273 ms tukw-agw1.inet.qwest.net [63.231.10.125]
I just noticed from this that the ping times on my DSL loop are showing as very high (230ms) in this example. This is not my normal first hop ping time. I normally have a first hop (first hop from the modem) of about 40ms. I just re-tested, and I'm getting my normal 40ms (more or less). So the example is fine, but the first hop ping times shown are not typical. (I've no idea why they were so high when I gathered the data for the write-up.)

NormanS
I gave her time to steal my mind away
MVM
join:2001-02-14
San Jose, CA
TP-Link TD-8616
Asus RT-AC66U B1
Netgear FR114P

2 edits

NormanS to bigjoesmith

MVM

to bigjoesmith
My Netgear is at 192.168.102.1. I do not know why it doesn't show in tracerts; it never did, though my old SMC Barricade does when I use it with a dial-up modem. If I doctor the tracert with the Netgear so it looked like the Barricade; well...SMC Barricade 7004BR:
C:\WINDOWS>tracert cs.washington.edu

Tracing route to cs.washington.edu [128.208.3.200]
over a maximum of 30 hops:

1 <10 ms <10 ms <10 ms Shizuku [192.168.102.3]
2 165 ms 206 ms 192 ms nas93.SanJose1.Level3.net [209.247.21.227]
3 165 ms 192 ms 206 ms ge-7-0-1.core2.SanJose1.Level3.net [63.215.14.3]
Doctored Netgear trace (adding the Netgear line as it would appear if the Netgear behaved the same as the SMC Barricade):
C:\WINDOWS>tracert cs.washington.edu

Tracing route to cs.washington.edu [128.208.3.200]
over a maximum of 30 hops:

1 <10 ms <10 ms 14 ms Chihiro [192.168.102.1]
2 41 ms 55 ms 55 ms Suzuka [192.168.0.1]
3 69 ms 55 ms 27 ms adsl-64-174-91-254.dsl.sntc01.pacbell.net [64.174.91.254]
4 14 ms 14 ms 14 ms dist2-vlan50.sntc01.pbi.net [63.203.35.66]
I don't know why the Netgear behaves this way, it just does. I am puzzled by that hop to the modem, as well; 55 ms from the WAN port of the router to the CPE Ethernet port of the modem, over a 1 ft. CAT5e patch cord!

BTW, I did not "invent" that first line out of whole cloth; I can trace it from the computer, thus:
C:\WINDOWS>tracert chihiro

Tracing route to Chihiro [192.168.102.1]
over a maximum of 30 hops:

1 <10 ms <10 ms <10 ms Chihiro [192.168.102.1]

Trace complete.
192.168.0.1 is the SpeedStream 4100; the WAN IP address here is: 64.174.90.97.

SS4100 Routing Table:
Routing Table
Destination Netmask Gateway Interface
127.0.0.0 255.0.0.0 127.0.0.1 lo0
192.168.0.0 255.255.0.0 192.168.0.1 LAN
Default Gateway - 64.174.91.254 PPPoE
64.174.90.97 255.255.255.255 64.174.90.97 LAN
FR114P Routing Table:
Diagnostic - Routing Table

Destination Mask Gateway Metric Active
Default -- 64.174.90.97 -- Yes
172.29.61.0 255.255.0.0 192.168.102.100 2 Yes
64.174.90.0 255.255.255.0 64.174.90.97 1 Yes
64.174.90.97 255.255.255.255 64.174.90.97 1 Yes
192.168.102.0 255.255.255.0 192.168.102.1 1 Yes
192.168.102.1 255.255.255.255 192.168.102.1 1 Yes
P.S. Sam Spade shows a different ping time result than the Windows Me tracert:
09/08/05 21:58:02 Slow traceroute chihiro
Trace chihiro (192.168.102.1) ...
192.168.102.1 RTT: 0ms TTL: 64 (Chihiro ok)

09/08/05 21:57:02 Slow traceroute cs.washington.edu
Trace cs.washington.edu (128.208.3.200) ...
192.168.0.1 RTT: 14ms TTL:170 (Suzuka ok)
64.174.91.254 RTT: 27ms TTL:170 (adsl-64-174-91-254.dsl.sntc01.pacbell.net ok)
63.203.35.66 RTT: 28ms TTL:170 (dist2-vlan50.sntc01.pbi.net ok)
P.P.S. If you had some kind of upload running at a third of your upload capacity, or so, that could have an impact on your ping times. I see my times go to hell in a hurry during a BitTorrent session.

msj
Premium Member
join:2004-05-21
Fort Collins, CO

msj to bigjoesmith

Premium Member

to bigjoesmith
said by bigjoesmith:

So, as implemented on the Speedtouch, dhcp-spoofing is not just a simple transparent layer 2 bridge. It functions more like a layer 3 IP router, but with some special characteristics thrown in. I hope this provides some insight into what dhcp-spoofing provides the end-user and how it's implemented on one modem.
Thanks, that showed me a different way of doing it. I simulated this alternate method (used on the Speedtouch) with some manual configuration on my Actiontec running OpenWRT and got it to work.

I'm curious what netmask you obtain via dhcp from the modem. My guess is 255.255.255.255. What is the output from running ipconfig on your PC?
bigjoesmith
join:2000-11-21
Peoria, IL

1 edit

bigjoesmith

Member

said by msj:

I'm curious what netmask you obtain via dhcp from the modem. My guess is 255.255.255.255. What is the output from running ipconfig on your PC?
The netmask that my computer obtains from the dhcp-spoofing modem is 255.255.0.0. So, you ask, how does my computer talk to any host with the same network, since it will think it's directly accessible? It works the same way that the default gateway is accessed, as descibed above. Basically, the modem will answer any arp request for any host on that network. In other words, the modem will answer an arp request for any 168.103.x.y request. (In this case, my local computer has gotten a 168.103.x.y IP address from the modem, so the network portion is 168.103 in this case.) The computer will send the packet to the modem, and the modem will send it on to the ISP's gateway.

So the modem will answer arps for any address in the computer's network (other than the computer's specific address, I suppose) and will also answer arps for the default gateway's specific address (which may not be in the same network as the computer's network). It will not answer arps for any other hosts in the default gateway's network, if that network is different from the computer's network.

msj
Premium Member
join:2004-05-21
Fort Collins, CO

msj to bigjoesmith

Premium Member

to bigjoesmith
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).
bigjoesmith
join:2000-11-21
Peoria, IL

bigjoesmith

Member

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 ··· oof1.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.
bigjoesmith

bigjoesmith to msj

Member

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 ··· 3.0.html

msj
Premium Member
join:2004-05-21
Fort Collins, CO

msj to bigjoesmith

Premium Member

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 ··· oof1.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.
bigjoesmith
join:2000-11-21
Peoria, IL

bigjoesmith

Member

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.

NormanS
I gave her time to steal my mind away
MVM
join:2001-02-14
San Jose, CA
TP-Link TD-8616
Asus RT-AC66U B1
Netgear FR114P

NormanS to msj

MVM

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.

msj
Premium Member
join:2004-05-21
Fort Collins, CO

msj to bigjoesmith

Premium Member

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.