Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FS#490 - BT Home Hub 5 Ethernet WAN Port configuration #5629

Closed
openwrt-bot opened this issue Feb 9, 2017 · 3 comments
Closed

FS#490 - BT Home Hub 5 Ethernet WAN Port configuration #5629

openwrt-bot opened this issue Feb 9, 2017 · 3 comments
Labels

Comments

@openwrt-bot
Copy link

ezplanet:

Supply the following if possible:

  • Device problem occurs on: BT Home Hub 5 Type A
  • Software versions of LEDE release, packages: all
  • Steps to reproduce

To configure the Red Ethernet WAN port /etc/board.json must be edited manually
We would like to have the port automatically configured
The patch included provides an example, although with more knowledge around the hardware this could be improved.

@openwrt-bot
Copy link
Author

mkresin:

Hey Mauro,

please don't add patches to the bugtracker. Send this patch according to [[https://lede-project.org/docs/guide-developer/the-source-code#submitting_patches|Submitting Patches]] to get your changes included.

If you want to discuss an idea, it would be the best to send a mail to the [[https://lede-project.org/contact#mailing_lists|lede-dev mailing list]].

I've already prepared something similar, which should workaround FS#390 as well. Please have a look at these commits

  • lantiq: use xwan network name for xdsl wan
  • lantiq: xrx200: use vlan for ethernet wan port

in my [[https://git.lede-project.org/?p=lede/mkresin/staging.git;a=summary|staging repository]].

My first idea was to rename the networks wan/wan6 to ewan/ewan6 and use wan for xdsl/3G/4G connections. But that idea was not that appreciated by the other devs.

It's not yet in master since I see the following problems with the implemention:

  • it might be confusing if you want to make a service listen on any wan interface (interface assigned to either wan or xwan)
  • the wan network name could be hardcoded somewhere (config_get interface "wan")

The other idea I had, was to use a single network "wan" with multiple interfaces (ucidef_set_interface_wan "$interface_wan" "pppoe eth0.2" ). But when doing it this way, it is not possible to assign individual mac addresses to wan interfaces, since ucidef_set_interface_macaddr "wan" "$wan_mac" would set the same mac address for all interfaces in that network. Furthermore, it wouldn't be possible any longer to bind a service only to one specific wan interface (opposite use case to all wan interfaces are doing the same).

Maybe we can discuss my approach via mail and finish/test what I've done. Would be great to hear your opinion about the corner cases I do see. Might be that I'm seeing issue where no issues are.

@openwrt-bot
Copy link
Author

mkresin:

With https://git.lede-project.org/cd8b20931ee40a5cdf008e6087b35e7770fc51a1 the wan port is member of the switch can be used as eth0.2 using the default configuration.

I've tried to add a default config for the ethernet wan port as well using a solution similar to yours. But I wasn't able to come up with a solution which all other devs were happy with.

But with the mentioned commit it is now way easier to use the wan port as wan interface, since it is available in LuCI. No need to edit /etc/board.json. To use the ethernet wan port as wan interface apply the following changes to your /e/c/network:

config interface 'wan' option ifname 'eth0.2' option proto 'dhcp'

config device 'wan_dev'
option name 'eth0.2'
option macaddr 'aa:bb:cc:dd:ee:ff'

config interface 'wan6'
option ifname 'eth0.2'
option proto 'dhcpv6'

If you are fine with the way it works now, please close the feature request.

@openwrt-bot
Copy link
Author

ezplanet:

Mathias,

thank you for posting the patches to get the red wan port as eth0.2. I have been using them for several weeks and the interface has been stable since your latest patches for the multicast leak.

With regards to naming the port I guess we can leave this to the choice of the user.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant