18-10-2010, 08:07 PM
Did some testing.
I wanted to pinpoint when the CMTS decides to switch to a BPI enabled tftp config file. I polled and md5sumed a tftp config file every second that was verified NoBPI. Plugged in the modem, and traced when the md5sum changed in the other window. My suspicions were correct in thinking that it happened during the DHCP Discover of the modem. What happens is that the DHCP Discover is broadcasted, the a timeout occurs while the file is changed, and when the Discover retry happens, it gets the right config.
This is not just exclusive to Haxorware. I also tried all builds of Sigma X2 in my testing, and it's all the same. I really believe that Charter is inspecting our DHCP Discover request's option 60 for which docsis version and features the modem is capable of. Since I'm trying to emulate a DOCSIS 1.0 modem not capable of BPI, this is pretty much a dead giveaway to Charter, and I think that's why my mac is getting banned every day.
I wanted to pinpoint when the CMTS decides to switch to a BPI enabled tftp config file. I polled and md5sumed a tftp config file every second that was verified NoBPI. Plugged in the modem, and traced when the md5sum changed in the other window. My suspicions were correct in thinking that it happened during the DHCP Discover of the modem. What happens is that the DHCP Discover is broadcasted, the a timeout occurs while the file is changed, and when the Discover retry happens, it gets the right config.
This is not just exclusive to Haxorware. I also tried all builds of Sigma X2 in my testing, and it's all the same. I really believe that Charter is inspecting our DHCP Discover request's option 60 for which docsis version and features the modem is capable of. Since I'm trying to emulate a DOCSIS 1.0 modem not capable of BPI, this is pretty much a dead giveaway to Charter, and I think that's why my mac is getting banned every day.