I have an odd problem I'm hoping to solve.
Is it possible to get a CM to forward the config file (it gets via tftp) to the PC sitting behind the CM?
Logged into the CM, I see that I can 'tftp put' files, so that would work. But it looks like CMs don't save their tftp config
files anywhere. Do CMs typically just parse the config file without saving it anywhere?
Thanks.
I know that an Arris shell can provide plenty of information; same with Moto. However, I'm not familiar with modems that have a shell that includes a full TFTP client that can get/put files... It might be vendor specific so you might have to ask them directly.
since you know the modem file was taken from the tftp server by snmp to the modem, why would you want to look at it again after it got to the modem unless it was to hack the file once you got it on the pc?
am I wrong? before giving out any kind of information like that, would need to know reason why it's needed.
you created the file, put it on your tftp server. modem registered. why the need to see the file after it got there, unless you need the see the shared secret or other information
To my understanding, the config file received via tftp doesn't contain any secret information (keys, etc)
Like I said above, I have login access to the modem already. If I wanted to "hack" something, or get some secret information
from the file, I would be able to do it from the modem itself.
I'm not sure I follow this statement:
"modem file was taken from the tftp server by snmp to the modem".
snmp isn't used to pull config files from the tftp server.
The idea is for the cmts to forward specific configuration information for the PC behind the modem. If the PC was using dhcp, then we could
include a tftp server info to the pc during the dhcp offer (just like the cm). But if the PC isn't using dhcp, then we still want the cmts to pass some config info to it.
Post from kwesibrunee :
Perhaps, if you could state which problem you are trying to solve and why you are trying to solve it this way, this group could be more helpful. I am not trying to be judgmental, or anything, but the way you phrased the question and the subject matter seem out of place for a cable operator.
cpe's are not suppose to get modem file info., so I thought unless the docsis spec changed along the way.
only reason I would see is if I wanted to change it back on the modem from the pc side. give myself more ip's or faster speed.
so I say Hacker. don't like it. I don't care
If you have some time, please take a look at my above message "Major clarification - using eCMs rather then CM" ... I had no malicious intent and my question is based straight from a DOCSIS specification.
thanks.
I've looked at a couple of modems. I'm not too sure what modems we will be going with yet.
The modems I've looked at tend to have a tftp client that can be used to push their flash device config files for backup purposes.
What is the reasoning behind "backing up" the modem config file to the PC behind the modem? Most, if not all manufacturers do not allow modems to tftp from the Ethernet or USB port and a single command on the CMTS (in cisco world cable tftp-enforce) won't allow modems to come online unless it saw the tftp transaction on the cable interface.
If you are interested in backing up config files, why not do it at the tftp server rather than the tftp endpoint?
"Do CMs typically just parse the config file without saving it anywhere?"
As for your original question, in an attempt to foil would be uncappers most modems, with current firmware, don't store the modem config file after registering with the CMTS. Some modems, notably Motorola's have gone as far as masking the file name of the config.
Perhaps, if you could state which problem you are trying to solve and why you are trying to solve it this way, this group could be more helpful. I am not trying to be judgmental, or anything, but the way you phrased the question and the subject matter seem out of place for a cable operator.
I guess I prematurely asked a question on this forum.
I read somewhere about a cable modem configuring a device behind it (i.e. behind the cable modem) by using
instructions in the cable modem's configuration file.
From this I assumed it meant that the cable modem forwarded it's config file to a device (which I called a PC
in my above posts). I thought this was a cool idea, so I posted my above message. Apparently my above message
wasn't taken too well by a certain forum member who decided to resort to name calling. I guess I can understand why.
However, I was somewhat correct about CMs configuring devices via their configuration file. It is called
"eCM Config File Encapsulation". eCMs (embedded CM) can use their config files to configure eSAFE
devices (devices behind the eCM). This is outlined in the eDOCSIS Specification.
(Please see the eDOCSIS Specification sections 5.2.8 at http://www.cablelabs.com/specifications/CM-SP-eDOCSIS-I14-080215.pdf)
After reading this, I still have some question regarding how an eCM actually forwards it's config file sections (TLVs)
to the eSAFE device. Does anybody have any experience with this?
Hopefully this clears up any thoughts of malicious intent and sorry for posting prematurely.
Thanks.
After a quick run through the specified doc, this paragraph sums it up bolded for emphasis.
Upon successful validation of the CM MIC, the eCM MUST pass the contents of the appropriate eCM eSAFE Configuration File TLVs to each eSAFE that supports eCM Config File Encapsulation.
111 Added this section per eDOCSIS-N-06.0279-3 by GO on 10/4/06. Last sentence in section added per eDOCSIS-N-07.0457-2, #2 on 7/20/07 by KN.
CM-SP-eDOCSIS-I14-080215 Data-Over-Cable Service Interface Specifications
The eCM MUST silently ignore eCM eSAFE Configuration File TLVs for eSAFEs that do not exist or that do not support eCM Config File Encapsulation.
The mechanism used to pass eCM eSAFE Configuration File TLVs to the eSAFE is vendor specific. It is in the scope of each eSAFE specification to define the encoding of configuration parameters within the corresponding eSAFE TLV and the rules in case the contents are longer than the 254-octet maximum length of each eCM configuration file TLV instance.
So how it passes the data from cm to eSafe device varies from vendor to vendor, which would explain your confusion, you would need to ask the appropriate vendors how they do it.
I suspect you are not likely to run into many people with experience with eDocsis here as this list is viewed by mostly cable operators rather than cablemodem + MTA/STB/router/etc developers which eDOCSIS seems directed towards. I am not aware of any groups for such a thing perhaps try an Electrical Engineering group?
Yeah, you're right, the bold line is where my confusion is.
I was hoping someone here may have had experience with this situation.
One more question for this forum: The spec says the mechanism is vendor specific. The particular device I'm working with ( of which I cannot say for NDA purposes ) uses one vendor for the eCM and another vendor for the eSAFE device (i.e. the device behind the eCM). Can anyone offer insight into which vendor would more likely define the mechanism? I.E. Is it the eCM that defines the mechanism to pass on the TLVs or is it the eSAFE device that defines the how it would grab the TLV from the eCM?
I would guess it would have to be the eCM as it's the one parsing the CM config file in the first place.
Thoughts?