I recently subscribed to Fusion ADSL, replacing an old AT&T DSL system. I figured I'd just replace the old modem with a new one, and I'd be all set.
Not quite. When it didn't work, I talked to a pleasant knowlegable gentleman in your customer support. I'm sorry I didn't get his name. We worked through one issue, but didn't quite get the other one...
First, my modem wasn't configured with the proper static IP. I'm not sure whether I should have caught that originally, but in any case, that was easy to fix when customer support gave me the proper IP address.
The second issue was a bit trickier. The modem wouldn't sync at all while I was talking to customer support. I was using my landline phone, the same landline that was being used for the DSL connection. The support person said the problem was probably that I was re-using the same DSL filters from my old AT&T DSL installation.
I hung up, switched the filters over, and everything worked great, for awhile. But as soon as I used the phone again, the DSL modem lost sync. It would never get or maintain sync while the phone was off-hook. It seemed to work OK when the phone was on-hook.
Background: With the old AT&T DSL service, the line would lose sync briefly any time the phone switched betweeen off-hook and on-hook, either direction. It would then regain sync after awhile. I installed a quality whole-house DSL filter in the NID, I ran a separate home-run CAT5 cable directly to the modem, moved the modem location to within 6 feet of the NID, and nothing fixed this annoyance, but things worked well otherwise, so I just thought it was as good as it gets.
Well, I was willing to put up with a brief interruption of service when the phone was off-hook, but I wouldn't put up with a complete loss of DSL for the entire time the phone was in use. So I dug around a bit on the web and found the problem. My phone line had a MTU (Maintenance Test Unit) buried in the network box.
My network box and the hidden MTU looked almost exactly like what is described here
http://rdist.root.org/2009/02/04/fixing ... c-problem/
I removed it, and the DSL sync is rock-solid during phone calls now. I wish I had discovered the problem years ago!
In retrospect, I think the filter issue was probably a red herring -- the real reason for the sync failure while I was on the phone with customer support was the MTU, which was upstream of the demarcation point, and upstream of any place I could install filters. The support rep said it looked like the modem had been syncing properly earlier in the day. At that time, the IP address wasn't configured properly, which kept me from using Internet properly, but at least the sync was working right using the old filters, as long as the phone stayed on-hook.
Anyway, I don't have a question. I just wanted to report this to add to the knowledge base of customer support issues. I don't know how common those MTU devices are, and I would hope nobody with an existing DSL account would still have one. I shouldn't have had one. I don't know if this is a reasonable possibility, but if your team could have checked for the presence of an MTU when provisioning my line, it would have made the troubleshooting a lot quicker.
Not quite. When it didn't work, I talked to a pleasant knowlegable gentleman in your customer support. I'm sorry I didn't get his name. We worked through one issue, but didn't quite get the other one...
First, my modem wasn't configured with the proper static IP. I'm not sure whether I should have caught that originally, but in any case, that was easy to fix when customer support gave me the proper IP address.
The second issue was a bit trickier. The modem wouldn't sync at all while I was talking to customer support. I was using my landline phone, the same landline that was being used for the DSL connection. The support person said the problem was probably that I was re-using the same DSL filters from my old AT&T DSL installation.
I hung up, switched the filters over, and everything worked great, for awhile. But as soon as I used the phone again, the DSL modem lost sync. It would never get or maintain sync while the phone was off-hook. It seemed to work OK when the phone was on-hook.
Background: With the old AT&T DSL service, the line would lose sync briefly any time the phone switched betweeen off-hook and on-hook, either direction. It would then regain sync after awhile. I installed a quality whole-house DSL filter in the NID, I ran a separate home-run CAT5 cable directly to the modem, moved the modem location to within 6 feet of the NID, and nothing fixed this annoyance, but things worked well otherwise, so I just thought it was as good as it gets.
Well, I was willing to put up with a brief interruption of service when the phone was off-hook, but I wouldn't put up with a complete loss of DSL for the entire time the phone was in use. So I dug around a bit on the web and found the problem. My phone line had a MTU (Maintenance Test Unit) buried in the network box.
My network box and the hidden MTU looked almost exactly like what is described here
http://rdist.root.org/2009/02/04/fixing ... c-problem/
I removed it, and the DSL sync is rock-solid during phone calls now. I wish I had discovered the problem years ago!
In retrospect, I think the filter issue was probably a red herring -- the real reason for the sync failure while I was on the phone with customer support was the MTU, which was upstream of the demarcation point, and upstream of any place I could install filters. The support rep said it looked like the modem had been syncing properly earlier in the day. At that time, the IP address wasn't configured properly, which kept me from using Internet properly, but at least the sync was working right using the old filters, as long as the phone stayed on-hook.
Anyway, I don't have a question. I just wanted to report this to add to the knowledge base of customer support issues. I don't know how common those MTU devices are, and I would hope nobody with an existing DSL account would still have one. I shouldn't have had one. I don't know if this is a reasonable possibility, but if your team could have checked for the presence of an MTU when provisioning my line, it would have made the troubleshooting a lot quicker.
