ASUS DSL-N17U as xDSL Modem (Bridge Mode)?

[A.D.]

Dear all,

I'm trying to figure whether or not the ASUS DSL-N17U is suitable as an xDSL modem in bridge mode, meaning that PPPoE will be done by another device behind it.

I came across a video indicating that the standard GUI allows to set certain ports as "bridged", but the use case for that seems to be IPTV and I presume that the term "bridge" refers to the router functionality here and that PPPoE will still be done by the N17U in this case.

However, maybe PPPoE can be disabled elsewhere without disabling the "bridge" settings, or maybe one can do some magic on the command line.

Any experience, hints or reference greatly welcomed.

 

[Riaan Burger]

Hello A.D.,

I answered in the linked thread (explaining what I did to get things to work), but in hindsight I should have probably answered in this one. It being in a more appropriate forum.

Just wanted to follow up. I now have my PCs, using Asus PCE-AC68 Wireless NICs connecting to the Asus AC-RT5300 (asuswrt-merlin) which use the DSL-N17U over PPPoE to connect to the internet. So far, so good.

Cheers,
Riaan

 

[A.D.]

I now have my PCs, using Asus PCE-AC68 Wireless NICs connecting to the Asus AC-RT5300 (asuswrt-merlin) which use the DSL-N17U over PPPoE to connect to the internet.

Thank you Riaan!

Where is PPPoE set up in your scenario? Not in the DSL-N17U, but in your RT-AC53000, yes?

One more point. Older DSL modems in "bridge" mode were sometimes reported to kill VLAN IDs (which brings us back to your question what people think a "bridge" is). Some newer DSL modems in "bridge" mode seem to be able to inject VLAN IDs (again not exactly a bridge but pretty useful in some cases).

Is your scenario one where you rely on VLAN IDs on the WAN side?

To clarify; in my case, my router is going to handle the VLAN ID(s). I'm more asking whether you can confirm that they're not being killed by the DSL-N17U.

 

[charlie2alpha]

I am also using the the N17U as a bridge, the actual connection is handled by my RT-AC56U that's behind it, of course by using PPPoE. There is a checkbox on the N17U to preserve the VLAN ID instead of stripping it but I am not sure how well it works, I can't test it anyway since it does not concern my use case.

 

[Riaan Burger]

Hello A.D.,

Some of this reply is also on your reply in http://www.snbforums.com/threads/asus-dsl-n17u-tp-link-td-vg5612-as-vdsl-modem-bridge.32126

The new network still needs to take over from my current one. Currently I'm using an Asus AC1900 router (with tomato) and an Asus DSL-N55U modem. This is what is in operation right now as I'm typing this and Tomato firmware exposes VLAN functionality, which I use right now, in the GUI. That was my first and only exposure to VLANs, I'm a networking novice but only use Linux in general (just stuck my Windows 10 in a VM somewhere and only run it when the moon is full), so find the command line stuff easy enough.

So, right now I can't really test the new network for you to see how the ports behave, but I'm definitely willing and will test what you need as soon as I get through the day's to-do list of work items and can mess with networking again.

PPPoE settings are being set in the router (AC-RT5300) and I can confirm they're not just the ones I may have entered into the modem as I can switch between ADSL service providers by changing credentials on the router GUI. For a little while there I had my doubts because I could get only wired links to the router to work, not wireless. Then I realised it was just my Ansible-managed shorewall that needed tweaking. I'm actually trying to work towards Ansible managing the router too as I'd really like the setup and LAN plan version controlled and portable to all the other guys working from home for our business (we're just a bunch of work-from-home web developers).

In my Googling I saw someone implement a VLAN with merlin, but not using the GUI. I'm not sure enough about such things to have that as a goal right now, but it would be nice. Maybe Tomato will become available for the new router some time soon, but I really like the stability of merlin (not that I had any problems with Tomato over the years, just that its website and such look a little more closed up and that the merlin stuff feels so accessible on GitHub with notes on how to compile it yourself).

Currently I'm thinking to set things up with 192.168.1.x/24 for one's own devices, but, since they will include things like printers and phones, the network will still be considered hostile, then 192.168.2.x/24 for guests and I made the modem 192.168.3.2 so I can still get to it - not terribly sure what's happaning network-wise with that ;-)

I'm thinking that anything I test for you will help me learn more, so ask away, but please also help me by stating how I should test (for example, if VLAN IDs are stripped). Maybe charlie2alpha can also point out where I can find the setting he mentioned. For now, as soon as I get through my work to-do list, I'll switch to testing the ports on the modem for you to see if they all behave the same.

Cheers,
Riaan

 

[A.D.]

I am also using the the N17U as a bridge, the actual connection is handled by my RT-AC56U that's behind it, of course by using PPPoE. There is a checkbox on the N17U to preserve the VLAN ID instead of stripping it but I am not sure how well it works, I can't test it anyway since it does not concern my use case.

Thank you!

One would assume that if the feature is there, it should work because it's needed in many scenarios and the firmware can be expected to have a certain maturity given the product launch date. (Also, it's more complicated to remove the tag than to leave it where it is... but you never know.)

However, Riaan says he's unaware of this setting. Maybe you can point him to the menu item.

 

[charlie2alpha]

Well, this is the setting:

That box, "Remove VLAN TAG from WAN" is supposed to do it. As I use VDSL, I have to use the generic bridge mode, like this:

The Internet/Automatic IP is dummy, my ISP uses PPPoE so the N17U will never get an IP via DHCP.

 

[A.D.]

[...] Currently I'm using an Asus AC1900 router (with tomato) and an Asus DSL-N55U modem. This is what is in operation right now as I'm typing this and Tomato firmware exposes VLAN functionality, which I use right now, in the GUI. [...] So, right now I can't really test the new network for you to see how the ports behave [...]

If you're using a VLAN ID on the WAN side, which originates from your RT-AC and is required by your DSL provider, then you wouldn't get any internet access if the DSL-N would not pass it through. So if these assumptions are true then the DSL-N passes the VLAN ID as it is supposed to.

PPPoE settings are being set in the router (AC-RT5300) [...]

Excellennt; as expected.

In my Googling I saw someone implement a VLAN with merlin, but not using the GUI [...]

I think that relates to VLAN IDs on the LAN side, not on the WAN side. See e.g. the asuswrt-merlin changelog for hints that it implements VALN IDs for ISPs (on the WAN side of things).

[...] how I should test (for example, if VLAN IDs are stripped) [...]

Set the "Remove VLAN tag from WAN" option and see whether you can still access the internet. If not, your ISP requires you to send the VLAN tag and we then know that the DSL-N is working.

[...] I'll switch to testing the ports on the modem for you to see if they all behave the same [...]

Yes, just plug the LAN cable into another port.

I think I saw LAN setting options in the DSL-N manual but I'm not sure they're available in modem bridge mode. So if they're not set to "bridged" (meaning all LAN ports behave the same) then they shouldn't behave identical. But if they're set to "bridged" (if the setting is available at all) then they should behave as if they're, well, bridged.

 

[A.D.]

Well, this is the setting: [...] That box, "Remove VLAN TAG from WAN" is supposed to do it. As I use VDSL, I have to use the generic bridge mode, like this: [...] The Internet/Automatic IP is dummy, my ISP uses PPPoE so the N17U will never get an IP via DHCP.

Thanks for posting the screenshots.

Actually I find them irritating. Looks like the DSL-N is treating "IPTV" separately and routing it to/from LAN 1.

So do you have a kind of set top box connected to LAN 1, and your router is connected to another port?

Is there no full bridge mode?

Presumably, "IPTV" really stands for "multicast" on technical level?

 

[charlie2alpha]

Thanks for posting the screenshots.

Actually I find them irritating. Looks like the DSL-N is treating "IPTV" separately and routing it to/from LAN 1.

So do you have a kind of set top box connected to LAN 1, and your router is connected to another port?

Is there no full bridge mode?

Presumably, "IPTV" really stands for "multicast" on technical level?

No, no setop boxes, I actually connect my RT-AC56U's WAN port to N17U's LAN 1. The N17U has a normal full bridge mode for plain DSL, but not for VDSL where I need to fool it and use the generic Bridge mode. Do not confuse with it with actual IPTV, it is an actual bridge and it passes everything it gets from the specified VLAN on the ethernet port specified.

The issue is that I am not sure it does the opposite, when I tried unchecking that box in order to preserve the VLAN tag, my RT-AC56U couldn't connect. But I never found out if it's the N17U's fault or the RT-AC56U's.

 

[Riaan Burger]

Hello Guys,

Pheew, well, that was a long day. Okay, I'm definitely going to have to learn a lot more before I know as much as the two of you.

For now I can report that yes, the setup works the same for whichever LAN port on the modem I connect to the WAN port on the router. Also, thank you charlie2alpha, I do have those settings on my modem.

Also, charlie2alpha, are you an Asus super-agent or something? I notice the latest firmware on their site for the DSL-N17U is version 1.1.0.4:

https://www.asus.com/Networking/DSLN17U/HelpDesk_Download/

But in the screenshots you have version 1.1.1.2. Do I just not have the right source for up to date firmware?

Let me know if you want me to check anything else for you A.D., but it sure looks like this may be on your purchase list soon.

Now I just have to go buy some cabling. Want to replace a lot of currently wired devices with the new setup, so the modem, router, NAS and switch will move off my desk and into a rack in the spare room.

Cheers,
Riaan

 

[Riaan Burger]

With my limited knowledge I assumed that the router-modem connection would become something used just for PPPoE, but since I gave the modem an IP of 192.168.3.2 and can access it, I realised that must not be the case.

So I was a little worried that the modem is still doing all its own things on the network too. I tried sudo dhclient -d -nw eth0 from a connected notebook and it would appear the modem's DHCP, which I didn't switch off explicitly yet, isn't served. Now I'm wondering if it wouldn't be simpler to then just assign an IP to the model on the local net like 192.168.1.2 to make it easier to reach / work with.

 

[charlie2alpha]

Lol, not an Asus agent, the version my N17U has its the latest beta firmware for it, I'm getting that from another forum I'm a member of.

 

[Riaan Burger]

;-) Does it look like it's worth tracking beta software for it?

 

[charlie2alpha]

I'm only interested in the DSL driver updates and the general stability updates since that's all I use. Used to be really crappy at that with random reboots and connection issues. With this latest beta all of these are resolved for me.

 

[Riaan Burger]

I haven't tested this for long connection times yet. Still on my old setup for day-to-day use, but if I do get things up and experience any such problems, would you mind referring me to the forum where I can get the firmware or is that sort of thing frowned upon in this forum?

 

[A.D.]

no setop boxes, I actually connect my RT-AC56U's WAN port to N17U's LAN 1. The N17U has a normal full bridge mode for plain DSL, but not for VDSL where I need to fool it and use the generic Bridge mode.

...seriously... one can enable a bridge mode but it doesn't work independently of the DSL modem connection mode? What's the problem with the bridge mode with VDSL?

Do not confuse with it with actual IPTV, it is an actual bridge and it passes everything it gets from the specified VLAN on the ethernet port specified. The issue is that I am not sure it does the opposite, when I tried unchecking that box in order to preserve the VLAN tag, my RT-AC56U couldn't connect. But I never found out if it's the N17U's fault or the RT-AC56U's.

I don't see how it could be the RT-AC's fault.

In other words, we're discussing that a vendor which offers a significant number of modemless routers doesn't have a single reasonably well working modem in its portfolio.

BTW, I contacted ASUS sales for a buying recommendation / details last week; no response yet.

 

[A.D.]

For now I can report that yes, the setup works the same for whichever LAN port on the modem I connect to the WAN port on the router.

Thank you for testing this! Referring to charlie2alpha's point (bridge mode needs different configurations in ADSL and VDSL mode), and given that charlie2alpha's VLAN setup relies on IPTV mode which is supposedly working only for LAN1, then

• either you're using ADSL,
• or you configured bridge mode for VDSL and it works (opposed to what charlie2alpha writes),
• or you configured IPTV for VDSL and it magically works also for other LAN ports

it sure looks like this may be on your purchase list soon

To be honest, even if you tell me that you're having a VDSL connection and plain bridge mode works for you, I'm really sceptical due to charlie2alpha's experience. To me, it sounds like ASUS should replace their chief software architect and product manager.

 

[A.D.]

I assumed that the router-modem connection would become something used just for PPPoE, but since I gave the modem an IP of 192.168.3.2 and can access it, I realised that must not be the case. So I was a little worried that the modem is still doing all its own things on the network too.

Don't draw false conclusions here. The device can distinguish between packets with itself as the destination, and packets which are sent to it to be forwarded to a different destination. That's necessary to make the UI accessible.

I tried sudo dhclient -d -nw eth0 from a connected notebook and it would appear the modem's DHCP, which I didn't switch off explicitly yet, isn't served.

Makes sense in bridge mode although I've seen ASUS devices behave in a surprising way in other scenarios.

Now I'm wondering if it wouldn't be simpler to then just assign an IP to the model on the local net like 192.168.1.2 to make it easier to reach / work with.

I'm not totally sure what you mean by "local net" but if you refer to your LAN behind your RT-AC, then please simply don't do that. Never. Ever. The RT-AC <-> DSL-N connection should be a dedicated subnet different from any LAN / subnet behind the RT-AC. I know it sounds tempting and seems to simplify things. Still.

 

[A.D.]

I'm only interested in the DSL driver updates and the general stability updates since that's all I use. Used to be really crappy at that with random reboots and connection issues. With this latest beta all of these are resolved for me.

Bad news. Makes me wonder. I can't imagine the DSL module in the DSL-N to be much different from DSL modules in other ASUS routers...

Looks like I should rather buy a device with a reputation instead.