If there's a way to specify the DSL firmware path in Network/Interfaces, then I'm not looking hard enough...
Obviously you won't be using ADSL settings on NBN
Okay... got that. I still need to copy it over to the DM200 in the first place.
The shown luci field will add this to /etc/config/network:
config dsl 'dsl' option xfer_mode 'ptm' option annex 'b' option tone 'bv' option line_mode 'vdsl' option firmware '/etc/config/dsl_vr9_firmware_xdsl-05.08.01.05.00.07_05.08.00.09.00.01.bin'
I opted to place the firmware file into /etc/config, so it is effortlessly preserved when using sysupgrade (without having to add it to the list of additional things to preserve) but that has some side-effects, so I do not want to recommend that.
WinSCP to copy the file onto the router/modem
Got it! Thanks! I'll keep tinkering and let you know how I go!
After going over OneArmedMan's am I right to assume, that the only real change that I need to make is the port number for vlan?
After going over the dmesg, it looks like port 4 reports link up and down.
Am I right to assume, that if I simply copy OneArmedMan's config and only change the ports for VLANs to port 4 everywhere?
That and apply my own DSL settings and subnets of course.
If you have a managed switch then I would say it would work, otherwise if you just directly connect the land of the DM200 to the WAN of your router, you wont be able to get access to LUCI interface, and that's from my personal experience
What I did was upload it on my server and wget it from there
No need for managed switch, my pfsense box allows me to create vlans on the nic itself and tag them.
It even allows for running router on a stick.
So to sum it up I need to tag port 4 (instead of whatever it is in the original config), and create virtual nics on my pfsense with vlan tag matching it.
The last thing I kind of don't understand is how the vlans are going to work anyway since swconfig doesn't seem to recognize there is a switch at all.
Am I missing some package that needs to be installed on openwrt because I am able to put the vlans in place?
After just having added the switch0 definition, Luci interface reports that it can't recognize the switch topology (makes sense since swconfig doesn't recognize it either).
Aaand, it works
As expected tagging all vlans on port 4 did the trick.
I am connected to the internet and also have access to LuCI
Here is my /etc/config/network for those who might find it useful:
config interface 'loopback' option ifname 'lo' option proto 'static' option ipaddr '127.0.0.1' option netmask '255.0.0.0' config globals 'globals' option ula_prefix 'fdbe:4494:9fdf::/48' config atm-bridge 'atm' option payload 'bridged' option nameprefix 'dsl' option vci '8' option vpi '48' option encaps 'vc' config dsl 'dsl' option ds_snr_offset '0' option annex 'b' option xfer_mode 'ptm' option line_mode 'vdsl' config interface 'lan' option type 'bridge' option ifname 'eth0.1' option proto 'static' option ipaddr '192.168.1.1' option netmask '255.255.255.0' option ip6assign '60' config device 'wan_dev' option name 'dsl0' option macaddr '8c:3b:ad:14:a4:7b' config switch option name 'switch0' option reset '1' option enable_vlan '1' config switch_vlan option device 'switch0' option vlan '1' option vid '1' option ports '4t' config switch_vlan option device 'switch0' option vlan '2' option vid '2' option ports '4t' config device 'lan_dev' option name 'eth0' option macaddr '8c:3b:ad:14:a4:7a' config interface 'ETHWAN' option proto 'none' option ifname 'eth0.2' config switch_vlan option device 'switch0' option vlan '3' option vid '3' option ports '4t' config interface 'WAN_BRIDGE' option type 'bridge' option proto 'none' option ifname 'eth0.3 dsl0' option auto '1' option delegate '0'
A few comments:
I have a hunch that the eth0.2 in this config is not really necessary.
Not sure what is its functionality in the original config too.
So two vlans shoud probably be enough (don't have the time to test that theory at this time, but might check that in the future).
Device doesn't have internet connectivity when used like that.
It reports not having any upstream connectivity.
I think this is actually a good thing as it ensures better security (not having to deal with fw rules, updates etc and only taking care of the actual fw appliance).
It should be possible to have internet back, by adding appropriate rules on the fw device for its vlan tagged interface (allowing incoming from ip of the fw), and specifying the ip of the fw as the gateway in openwrt's management interface config.
That setup (obviously) works only if you have managed switch or a firewall appliance which allows vlan configuration (such as Pfsense) and a network card that supports vlan on the firewall side (a plain gigabit realtek worked for me).
For those using Pfsense VM (like I do), I am not sure it would work with having a virtual interface bridged to a real one (vtnet for instance), in my case I am using a pcie network card that is using pci passthrough to a VM providing direct access to hardware for the virtual appliance.
I fell asleep waiting for my mate to stop using the Internet, otherwise I would have gotten to this sooner. Anyway...
I DO get physical line sync with "Annex A+L+M (all)" and "auto" settings on everything else. I am still on ADSL2+ for now but will be transitioned to VDSL2 (hopefully) sometime this week. The Annex setting will likely have to be changed (Annex B (all) doesn't currently work) so any hopes for a seamless automatic detection of an ADSL2+ or VDSL2 line are all but dashed pending firmware improvements. I plan on keeping my old combo unit as a backup anyway and probably will also hold onto a cheap standalone ADSL2+ modem so I can use it in conjunction with the Linksys router if/when necessary. The DM200 will therefore be dedicated for VDSL2 type connections.
PPPoE login is NOT working, therefore the Internet is NOT working. This may not be a big deal IF I can get the unit properly bridged. Of course that's another story altogether...
I found another used DM200 locally for $50. I may have to snag it as a backup and NOT TOUCH the stock firmware...
You are correct. fwiw, I recently reviewed the bridge mode setup for HH5A which was also based on triple VLAN configuration by JSamuel for the BT Openreach ECI modem (VG3503J)
This new two VLAN config for HH5A is inspired by posts I've seen appearing on OpenWRT forum in past 12 months, and seems to work fine when I tested it last week.
I've tested VDSL Bridge mode with LEDE 17.01.6.
External HH5A router was wired to LAN1 port of HH5A bridge modem.
LAN2 port of bridge modem wired to spare LAN port on external router for LuCI/SSH access.
config dsl 'dsl' option xfer_mode 'ptm' option annex 'b' option tone 'a' option line_mode 'vdsl' option ds_snr_offset '0' config interface 'lan' # for LAN2 to LAN4. eg. LuCI/SSH option type 'bridge' option ifname 'eth0.1' option proto 'static' option ipaddr '192.168.1.1' option netmask '255.255.255.0' option ip6assign '60' option gateway '192.168.1.254' # Point this to your main router option dns '18.104.22.168' config device 'lan_dev' option name 'eth0.1' option macaddr '02:xx:xx:xx:xx:xx' config interface 'wan' option proto 'none' option delegate '0' option type 'bridge' option ifname 'eth0.2 ptm0.101' # LEDE 17, VLAN tag 101 for use in UK. # option ifname 'eth0.2 dsl0.101' # OpenWRT 18, VLAN tag 101 config device 'wan_dev' option name 'ptm0' # option name 'dsl0' # OpenWRT 18 option macaddr '02:yy:yy:yy:yy:yy' config switch option name 'switch0' option reset '1' option enable_vlan '1' config switch_vlan option device 'switch0' option vlan '1' option ports '0 1 2 6t' # LAN2-4. eg. LuCI/SSH option vid '1' config switch_vlan option device 'switch0' option vlan '2' option ports '4 6t' # LAN1 to external router’s WAN port # option ports '5 6t' # red WAN option vid '2'
config zone option name 'lan' option input 'ACCEPT' option output 'ACCEPT' option forward 'ACCEPT' option network 'lan' config zone option name 'wan' option input 'REJECT' option output 'ACCEPT' option forward 'REJECT' option masq '1' option mtu_fix '1' option network ' ' # remove wan, wan6 interfaces # config forwarding # Removed # option src 'lan' # option dest 'wan'
above reproduced from:
Thanks for giving me the much needed courage to test out this theory
So I tried it and indeed vlan 2 and corresponding interface can be dropped.
Here is the updated network file for those who might be interested
config interface 'loopback' option ifname 'lo' option proto 'static' option ipaddr '127.0.0.1' option netmask '255.0.0.0' config globals 'globals' option ula_prefix 'fdbe:4494:9fdf::/48' config atm-bridge 'atm' option payload 'bridged' option nameprefix 'dsl' option vci '8' option vpi '48' option encaps 'vc' config dsl 'dsl' option ds_snr_offset '0' option annex 'b' option xfer_mode 'ptm' option line_mode 'vdsl' config interface 'lan' option type 'bridge' option ifname 'eth0.1' option proto 'static' option ipaddr '192.168.1.1' option netmask '255.255.255.0' option ip6assign '60' config device 'wan_dev' option name 'dsl0' option macaddr '8c:3b:ad:14:a4:7b' config switch option name 'switch0' option reset '1' option enable_vlan '1' config switch_vlan option device 'switch0' option vlan '1' option vid '1' option ports '4t' config switch_vlan option device 'switch0' option vlan '3' option vid '3' option ports '4t' config device 'lan_dev' option name 'eth0' option macaddr '8c:3b:ad:14:a4:7a' config interface 'WAN_BRIDGE' option type 'bridge' option proto 'none' option ifname 'eth0.3 dsl0' option auto '1' option delegate '0'
I left the wan interface as vlan3 because its already defined as such in my fw and I felt like its too much work to change it there
Another proposed change (I won't do it myself because its pointless in my setup), is not to use vlan1 for ethernet.
This is actually a very bad practice to use vlan 1 if used together with a managed switch (Pfsense manual mentions that).
Vlan1 is sometimes reserved by some managed switches for inner use and is not to be used by users.
Not an issue for me, because in my case there is a cable going directly from pfsense fw to the modem.
OAM from WP reporting in.
My previous posts in the WP thread for DM200 had details for vlan configuration on TPLink W8970 that I was using for testing.
The VLAN configuration for that router allows for a management port to to be configured on one vlan for easy access to LUCI GUI . I also had the DSL port and an ethernet port bridged to allow my EdgeRouter to handle all PPPoE and firewall duty.
The DSL bridge went to WAN interface on EdgeRouter, while the management port from W8970 went to management port on EdgeRouter on separate subnet.
Onto the DM200.
I have a slightly customized version of OpenWRT 18.06 running on my DM200 as of 1st Oct 2018 it has been online for less than 48 hours so time will tell how good this is.
The customization allow for
- Australian NBN FTTN using OpenWRT
- load firmware blob from Netgear GPL source that supports NBN FTTN
- switch the stock firmware Annex A configuration over to Annex B.
- hard code the VDSL / ADSL annex settings in the config to reduce the chance of locking the FTTN port.
- configure the DM200 in bridge mode allowing for EdgeRouter to handle PPPoE and firewall
- adjust the dsl stats on the status page to give a few more details.
To allow the router to work in bridge mode and keep access to the web UI i am using vlan configuration on a managed switch and a management port on the EdgeRouter.
DM200 --> Switch VLAN 10
VLAN 10 Switch --> EdgeRouter WAN Port
VLAN10 Switch --> EdgeRouter MGMT port
EdgeRouter Lan Port --> Switch VLAN20
VLAN20 Switch ---> Reset of network.
Not exactly ideal - but currently functional.
Current settings in /etc/config/network
root@OpenWrt:~# cat /etc/config/network config interface 'loopback' option ifname 'lo' option proto 'static' option ipaddr '127.0.0.1' option netmask '255.0.0.0' config atm-bridge 'atm' option vpi '1' option vci '32' option encaps 'llc' option payload 'bridged' option nameprefix 'dsl' config dsl 'dsl' option annex 'b' option tone 'bv' option xfer_mode 'ptm' option line_mode 'vdsl' option firmware '/lib/firmware/nbn_firmware.bin' option ds_snr_offset '10' config interface 'lan' option type 'bridge' option proto 'static' option ipaddr '172.16.18.1' option netmask '255.255.255.0' option ifname 'dsl0 eth0' config device 'lan_dev' option name 'eth0' option macaddr 'XXX' config interface 'wan' option ifname 'dsl0' option proto 'none' option auto '1' config device 'wan_dev' option name 'dsl0' option macaddr 'XXX'
A few people would be interested on the details of this step
Now you got my attention ;), what did you do here?
To clarify for those that don't already know (since I only found this out recently myself) this applies to FTTN; an FTTC setup REQUIRES the NetComm Connection Device (NDD-0300) as this has something to do with injecting power back to the fibre interface in the curb, therefore a normal VDSL2 modem will NOT work with FTTC.
This effectively means I bought the DM200 for nothing... kind of. I'm always happy to have spare networking equipment just the same and it is certainly possible I may be at an address that uses FTTN in the future, and I certainly want to be able to continue using my Linksys router either way.
I'm glad I'm getting the opportunity to get under the hood with OpenWRT, and need to do so now more than ever, as I can use the DM200 while I am still on ADSL2+; for the most part I hope this won't be for too much longer, as 17.5 Mbps just isn't cutting it in 2018, however this does mean that if I want my DM200 "ready to go" if and when I have the misfortune to be stuck with FTTN rather than HFC or FTTP, I need to have it properly configured and demonstrated working NOW... or at the very least within the next few days or so.
I'll definitely be an astute student amongst this group for the time being.
War and Peace posted below.
To start with I'll leave this here:
I am no expert on GPL license restrictions or the license that the Lantiq VDSL binary blobs are released under however the VDSL blob I am using is readily available as part of the DM200 GPL source released by Netgear or extract from DM200 firmware download from the Netgear website.
As long as its being used on a DM200 that you own - I can't see the harm in it.
I mean it is the official Netgear supplied blob for that device.
On to the OpenWRT firmware
To make the changes simple to test, easy to fix / update and easy to back out of I basically did
- git clone of the Openwrt source
- created a new directory structure for including custom files
As per this page : https://wiki.openwrt.org/doc/howto/build#custom_files
- put in the files that I wanted into the appropriate directory tree
- make defconfig
- make menuconfig
- setup the build settings for DM200 with a couple of minor includes / excludes of extra stuff I did and didn't want
- build firmware
- upload to DM200
As stated in previous post the file changes were mostly related to hard coding the VDSL mode settings to avoid accidentally locking my FTTN port ( See note below ) , loading the DM200 firmware into my personal build, and the line stats settings.
As the changes for the line stats have been blatantly stolen from someone else the details can be found on this WP post https://whrl.pl/RfegoE
As per the WP post - something isn't quite right as the default xDSL stats no longer display correctly, but the extra details do when the link is selected.
I have also made a very minor change to code taken from the Kitz forum stats page to also pull out the modem version details - jsamuel https://forum.kitz.co.uk/index.php?action=profile;u=8531 code appeared to have hard coded modem version details
I haven't investigated further as this stage as it is a low priority for me.
For the non-Australians playing today the Australian Government version of modern Internet access is called the NBN - National Broadband Network - it
has been well thought out and designed by experts in the field is a complete and utter shit fight that has been abused by those in political power and a gross waste of tax payer funds.
those lucky few most of us that have FTTN as opposed to FTTP if you connect an ADSL / VDSL modem that is not configured correctly the VDSL DSLAM will detect the settings that are used ( G.INP, Trellis, VDSL Profile etc ) and possibly lock your port ( no access at all ) until you contact your RSP to have the port unlocked and you fix or replace your router.
For extra points when you are on FTTN there is no copper phone line service so a VoIP call ( oh wait no internet access ) or call from mobile is required, in Australia mobile service tends to range from Zero coverage to hideously expensive.
Note 2 : to be fair its probably hard to provide FTTP to the population when you have a country about the same size as continental USA with a population of approx 25 Mill ( less than 10% of USA )
Thank you for that brutally honest review of Australian NBN. You, sir, just made my day!