dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
3915
vikingisson
join:2010-01-22
Mississauga, ON

vikingisson

Member

Sagemcom VDSL in bridge mode?

I have an office on the 10/7 service in Montreal. Been through a cellipe and now a Sagemcom. The default is a Bell login that takes you to a Bell signup page. I use a router and have no trouble doing PPPoE which then shows on the sagemcom as a "passthrough". So basically it is working but I'm wondering if there is a way to make it fully bridge, I don't see any other options. From behind the router it works right, speeds are good, and I get a proper TSI IP but the random disconnects are driving me crazy. It might go days without a reconnect or it might reconnect several times in a day. All stats etc are fine.

HiVolt
Premium Member
join:2000-12-28
Toronto, ON

HiVolt

Premium Member

It works as a PPPoE bridge simultaneously, as you've discovered. I just disable the DHCP as well as wireless to be sure.
vikingisson
join:2010-01-22
Mississauga, ON

vikingisson

Member

That's what it seems. I did turn off wireless. All I want is a dumb modem and not this pedestrian all in one crap that we're forced to rent. Oh well, let's see if it can stay online this time.

HiVolt
Premium Member
join:2000-12-28
Toronto, ON

HiVolt

Premium Member

said by vikingisson:

That's what it seems. I did turn off wireless. All I want is a dumb modem and not this pedestrian all in one crap that we're forced to rent. Oh well, let's see if it can stay online this time.

Unfortunately this is what we're stuck with. It works fine in bridge mode with the router initiating PPPoE.
vikingisson
join:2010-01-22
Mississauga, ON

vikingisson

Member

That's the way it is. The problem is probably not related to the modem. It is funny however that the modem doesn't have a proper clock, it always starts out like a dead unix box until it gets online. It does however remember the MAC of previously connected devices, but not the time. Not a business class device.
vikingisson

vikingisson to HiVolt

Member

to HiVolt
It's now been 8 hours since the new reset and so far there hasn't been a new log entry on the sagemcom. That's a good thing.

The nerve racking but fun part was doing it all remotely this time. Hoping that I'd get back in to make the final settings. Modem reboots to default, router behind it gets back online and sets up the VPN, I get back in to look back at the modem. Make final changes and hope I get back again.
It went very well so now we wait. I'll start feeling better if it is stable for 7 days in a row.

Inssomniak
The Glitch
Premium Member
join:2005-04-06
Cayuga, ON

Inssomniak

Premium Member

Yea I have a business with this modem in passthru mode, for a long time now, and its never missed a beat, I would know if it was resetting.
vikingisson
join:2010-01-22
Mississauga, ON

vikingisson

Member

said by Inssomniak:

Yea I have a business with this modem in passthru mode, for a long time now, and its never missed a beat, I would know if it was resetting.

Then you're lucky. I don't think the modem is the problem at this location but the modem is still a poor business device. The issues I'm having are somewhere upstream and after trying every DSL option there I don't think it will ever be stable. The next change will be something other than DSL. I just have to wait for the boss to want to pay one more time for a line. Or have it fail a few more times during business hours. It failed about 9 times in the last 24 hours but fortunately not during business hours. It's only a one minute cycle when it happens but that's enough to disrupt.

TSI Support2
TSI Support
Premium Member
join:2009-09-28
Chatham, ON

TSI Support2 to vikingisson

Premium Member

to vikingisson
Hello,

As previously mentioned most modems that do not give the option to be bridged can be worked around by disabling the DHCP service (depending on the model). The modem will have to be configured into routed mode for the time log to be accurate. If you are still experiencing disconnects please post in the direct forum so we can look into this for you.

Thanks.

TSI-ChadZ
vikingisson
join:2010-01-22
Mississauga, ON

vikingisson

Member

TSI should have these (two) modems in their hands so they know what works and what doesn't. There is no "routed" mode that I can find. But yes, everything is turned off including DHCP. The clock is still stupid but there's nothing left to do about that.

There should be an option at least for business accounts to use a simple bridged modem. This is the last VDSL account I'll ever have in the meantime. If this is reasonably stable for a week straight I'll be happy enough.
vikingisson

vikingisson to TSI Support2

Member

to TSI Support2
Things aren't getting any better. Here's what's good:
Speeds are right on target: 10/7
Stats as reported by TSI are always good. We can't see much from the modem end so I can only trust TSI on that. Speeds being fine tell me that stats are probably excellent.

Here's what is bad:
The connection will randomly drop sometimes 10 times in one day. Yesterday it was perfect but so far today it has happened twice. On Monday it happened 10 times. It reconnects right away.

Swapped out the Cellpipe for a Sagemcom. Modem was factory reset more than once. All options including DHCP have been turned off. The router will notice and reconnect right away but all sessions will be dropped. Even a one minute outage over and over again is driving the users and me crazy.

Here's a typical log entry from the modem:

Nov 14 09:59:31 NTP [581]: Got new time: Nov 14 09:58:04 2012
Nov 14 10:08:50 PPP [581]: Connection terminated.
Nov 14 10:08:51 PPP [581]: Exit.
Nov 14 10:09:46 PPP [581]: ppp1 started
Nov 14 10:09:49 PPP [581]: Connecting: ppp1
Nov 14 10:09:52 [290.7]PPPoE Passthrough session opened: server=00:90:1a:a2:43:f9(eth2.35:4374), client=84:1b:5e:df:9a:e1(eth0:2)
Nov 14 10:09:52 PPP [581]: local IP address 184.145.208.129
Nov 14 10:09:52 PPP [581]: remote IP address 64.230.200.60
Nov 14 10:09:52 PPP [581]: primary DNS address 206.47.199.71
Nov 14 10:09:52 PPP [581]: secondary DNS address 67.69.240.9
Nov 14 10:09:53 dnsmasq[21682]: compile time options: IPv6 GNU-getopt no-DBus no-I18N DHCP TFTP no-IDN
Nov 14 10:10:30 [290.7]PPPoE Passthrough session closed: server=00:90:1a:a2:43:f9(eth2.35:3917), client=84:1b:5e:df:9a:e1(eth0:3): Received PADT

That routable IP is from the default PPPoE session the modem uses, it isn't the public IP I get from the router. There's no way to avoid that. It all works fine except for the random reconnects.
vikingisson

vikingisson

Member

Third time so far today. Confidence is now zero.

Nov 14 10:45:58 PPP [581]: Connection terminated.
Nov 14 10:45:59 PPP [581]: Exit.
Nov 14 10:46:51 PPP [581]: ppp1 started
Nov 14 10:46:55 PPP [581]: Connecting: ppp1
Nov 14 10:46:57 PPP [581]: local IP address 70.53.202.49
Nov 14 10:46:57 PPP [581]: remote IP address 64.230.200.60
Nov 14 10:46:57 PPP [581]: primary DNS address 206.47.199.71
Nov 14 10:46:57 PPP [581]: secondary DNS address 67.69.240.9
Nov 14 10:46:58 dnsmasq[21892]: compile time options: IPv6 GNU-getopt no-DBus no-I18N DHCP TFTP no-IDN
Nov 14 10:47:02 [290.7]PPPoE Passthrough session opened: server=00:90:1a:a2:43:f9(eth2.35:4871), client=84:1b:5e:df:9a:e1(eth0:3)
Nov 14 10:47:39 [290.7]PPPoE Passthrough session closed: server=00:90:1a:a2:43:f9(eth2.35:4374), client=84:1b:5e:df:9a:e1(eth0:2): Received PADT

HiVolt
Premium Member
join:2000-12-28
Toronto, ON

HiVolt

Premium Member

here's a thought, try entering username test@test, password test in the modem's internal login field.

This gives it a non-routable IP, making the internet led turn RED. Perhaps its some pinging from Bell's management servers that's affecting it. This non routable login will make impossible for that to happen.
vikingisson
join:2010-01-22
Mississauga, ON

vikingisson

Member

and again. I could keep doing this but it gets boring.

Anyone in the St Laurent area of Montreal with DSL have anything to share?
vikingisson

vikingisson to HiVolt

Member

to HiVolt
said by HiVolt:

here's a thought, try entering username test@test, password test in the modem's internal login field.

This gives it a non-routable IP, making the internet led turn RED. Perhaps its some pinging from Bell's management servers that's affecting it. This non routable login will make impossible for that to happen.

interesting. I thought of something like that but haven't tried it. I'm remote so this is a nerve racking thing to try. On the other hand I did the factory reset remotely so why not...

lemme try that and I'll ding back.
vikingisson

vikingisson

Member

I'm just waiting for the users to find a quiet time so I can do it. After that rash of reconnects this morning it's been a whole hour without a problem. it won't last...
vikingisson

vikingisson to HiVolt

Member

to HiVolt
I got my chance and I now have a non routable IP on the Bell side. The existing PPPoE from my router didn't go down. Now we'll see what happens.

Nov 14 12:37:33 PPP [581]: Exit.
Nov 14 12:37:33 PPP [581]: ppp1 started
Nov 14 12:37:34 PPP [581]: Connecting: ppp1
Nov 14 12:37:36 PPP [581]: local IP address 10.6.223.137
Nov 14 12:37:36 PPP [581]: remote IP address 10.6.223.1

JenSuisUn
Premium Member
join:2006-02-23
Chatham, ON

JenSuisUn

Premium Member

So although the test@test is connected on the modem side, your router is still connected with your TSI login?

Does it seem like it's working right now?
vikingisson
join:2010-01-22
Mississauga, ON

vikingisson

Member

said by JenSuisUn:

So although the test@test is connected on the modem side, your router is still connected with your TSI login?

Does it seem like it's working right now?

Yes and the connection from the router didn't even drop when I did it (remotely). The VPN stayed up and so far it's working. I was always uncomfortable with the modem keeping a Bell connection. I expected it to endlessly keep trying but so far it hasn't.

JenSuisUn
Premium Member
join:2006-02-23
Chatham, ON

JenSuisUn

Premium Member

test@test only connects to the BAS. It won't allow anything else then connecting to the BAS.
vikingisson
join:2010-01-22
Mississauga, ON

vikingisson

Member

said by JenSuisUn:

test@test only connects to the BAS. It won't allow anything else then connecting to the BAS.

Does it need to be specifically test@test? This needs to be in the docs or mentioned much earlier in the service requests. My unsavvy users and angry boss have lost all faith in me so this is likely my last days with them. All the friends and family I've setup know that my skills are good but they don't pay me.

It's too early to call it fixed but this is where it's at:
factory reset modem. turn off all features such as DHCP, wireless, and make sure the services are only internet and not IPTV. Set the PPPoE to test@test and a random password. Router setup normally.

HiVolt
Premium Member
join:2000-12-28
Toronto, ON

HiVolt

Premium Member

said by vikingisson:

Does it need to be specifically test@test?

This is the only way that I know to make the sagemcom not be able to contact bell's management server. It will not update the time (if you reboot it) and it will not update firmware either.

The Cellpipe had a built in bell management login too, but you were actually able to erase it and leave the field blank. In the Sagemcom you can't leave the field blank, it auto-populates the field...
vikingisson
join:2010-01-22
Mississauga, ON

vikingisson

Member

said by HiVolt:

said by vikingisson:

Does it need to be specifically test@test?

This is the only way that I know to make the sagemcom not be able to contact bell's management server. It will not update the time (if you reboot it) and it will not update firmware either.

The Cellpipe had a built in bell management login too, but you were actually able to erase it and leave the field blank. In the Sagemcom you can't leave the field blank, it auto-populates the field...

That's exactly what I've discovered with those modems. Thanks for the test@test tip. Usually I'm really peeved at not having a proper clock but if it stops acting like 1980 tech I'll be happy enough.

I know one thing, I'll never buy VDSL again. even knowing the tricks this is subpar technology especially for a business.

HiVolt
Premium Member
join:2000-12-28
Toronto, ON

HiVolt

Premium Member

There's nothing wrong with VDSL. It's just that Bell's early implementation of VDSL was on crappy hardware (Lucent Stingers) and requires the use of proprietary modems...

Not sure if by being in MIssissauga you're on an Alcatel 7330 remote, but if you are, you can get yourself a Zyxel modem without all the bullshit of dealing with Bell's proprietary locked down hardware.
vikingisson
join:2010-01-22
Mississauga, ON

vikingisson

Member

My problem isn't so much the technology but the insane way that Bell is using it. It's unacceptable.

This particular issue is about a remote site in Montreal. Just two users but they have been a major pain in the side and soon I'm out of a job because of it. Nope, not touching VDSL until Bell plays nicely. Not for me and not for anyone else since I'll be the one to take the heat.

HiVolt
Premium Member
join:2000-12-28
Toronto, ON

HiVolt

Premium Member

said by vikingisson:

My problem isn't so much the technology but the insane way that Bell is using it. It's unacceptable.

This particular issue is about a remote site in Montreal. Just two users but they have been a major pain in the side and soon I'm out of a job because of it. Nope, not touching VDSL until Bell plays nicely. Not for me and not for anyone else since I'll be the one to take the heat.

It's about having control... Rogers just sells/rents all in one routers which are a pain in the ass, and they've been known to push firmware updates that reset the users wireless settings, leaving the wifi wide open.
vikingisson
join:2010-01-22
Mississauga, ON

vikingisson

Member

said by HiVolt:

It's about having control... Rogers just sells/rents all in one routers which are a pain in the ass, and they've been known to push firmware updates that reset the users wireless settings, leaving the wifi wide open.

yipes. At least with cable I still have the choice to buy my own modem and whatever router I choose. I'm lucky where I currently have cable modems but I know that isn't always the case.

The customer pays and should be entitled to some control. Not all businesses even small ones are clueless so deserve to control their side of the demarc. I don't have a problem with offering the all in one crap as long as I have the option to do it the right way. That's not happening with VDSL so for now it's off my option list.

If this current issue settles down I'll be happy but I'm afraid it's too late for me to save face.
vikingisson

vikingisson

Member

Well 48 hours uptime ain't bad I suppose. No, actually that sucks.

Nov 16 10:21:31 PPP [581]: Connection terminated.
Nov 16 10:21:32 PPP [581]: Exit.
Nov 16 10:22:26 PPP [581]: ppp1 started
Nov 16 10:22:27 PPP [581]: Connecting: ppp1
Nov 16 10:22:29 PPP [581]: local IP address 10.6.223.173
Nov 16 10:22:29 PPP [581]: remote IP address 10.6.223.1
Nov 16 10:22:30 [290.7]PPPoE Passthrough session opened: server=00:90:1a:a2:43:f9(eth2.35:9959), client=84:1b:5e:df:9a:e1(eth0:2)
Nov 16 10:23:05 [290.7]PPPoE Passthrough session closed: server=00:90:1a:a2:43:f9(eth2.35:4951), client=84:1b:5e:df:9a:e1(eth0:3): Received PADT
vikingisson

vikingisson

Member

Number two for the day. That does it, VDSL will be cancelled. (side note, clock is drifting. This is apparently from the future)

Nov 16 10:56:16 PPP [581]: Connection terminated.
Nov 16 10:56:17 PPP [581]: Exit.
Nov 16 10:57:12 PPP [581]: ppp1 started
Nov 16 10:57:16 PPP [581]: Connecting: ppp1
Nov 16 10:57:18 PPP [581]: local IP address 10.6.223.175
Nov 16 10:57:18 PPP [581]: remote IP address 10.6.223.1
Nov 16 10:57:23 [290.7]PPPoE Passthrough session opened: server=00:90:1a:a2:43:f9(eth2.35:10529), client=84:1b:5e:df:9a:e1(eth0:3)
Nov 16 10:57:46 [290.7]PPPoE Passthrough session closed: server=00:90:1a:a2:43:f9(eth2.35:9959), client=84:1b:5e:df:9a:e1(eth0:2): Received PADT
vikingisson

vikingisson

Member

3 times and it's not even noon yet.

Nov 16 11:48:40 PPP [581]: Connection terminated.
Nov 16 11:48:41 PPP [581]: Exit.
Nov 16 11:49:31 PPP [581]: ppp1 started
Nov 16 11:49:34 PPP [581]: Connecting: ppp1
Nov 16 11:49:37 PPP [581]: local IP address 10.6.223.177
Nov 16 11:49:37 PPP [581]: remote IP address 10.6.223.1
Nov 16 11:49:45 [290.7]PPPoE Passthrough session opened: server=00:90:1a:a2:43:f9(eth2.35:11356), client=84:1b:5e:df:9a:e1(eth0:2)