Re: [OpenWrt-Devel] multiwan -- allocation of a port (i.e. vlan) for wan2
On 11-10-20 04:17 PM, Daniel A. Nagy wrote: Hi Brian, Hello once again my friend. No, unfortunately there isn't one yet. I didn't think so. But we need it too, Ahhh. You are doing multi-WAN in your project also? so if nobody implements it before us, we will contribute one before the end of the year. Very sweet. Looking forward to it. Cheers, b. signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] multiwan -- allocation of a port (i.e. vlan) for wan2
On 20.10.2011 22:17, Daniel A. Nagy wrote: On 10/20/2011 09:08 PM, Brian J. Murrell wrote: Taking notice of https://dev.openwrt.org/changeset/20925 that looks like the bits needs to manage the balancing and failover for multiple WAN ports, which is great. Is there any corresponding Luci component to manage the allocating of a new WAN port (i.e. creating of a new VLAN for a the new WAN port)? Currently I manually carve one of the LAN ports off into it's own VLAN to use as the second WAN port but having a Luci app for this would be great. Cheers, b. Hi Brian, No, unfortunately there isn't one yet. But we need it too, so if nobody implements it before us, we will contribute one before the end of the year. Wrong list for it, anyways: There is support for switch/vlan config in luci [1], but it is only shown when your switch is configurable. So the problem is not with luci but with openwrt-support on your device i think. [1] http://luci.subsignal.org/trac/browser/luci/trunk/modules/admin-full/luasrc/model/cbi/admin_network/vlan.lua Hth, soma signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] multiwan -- allocation of a port (i.e. vlan) for wan2
On 11-10-21 11:08 AM, Manuel Munz wrote: There is support for switch/vlan config in luci [1], but it is only shown when your switch is configurable. So the problem is not with luci but with openwrt-support on your device i think. Is that the Switch tab under the Network tab that has Enable VLAN functionality checkbox? If so, I have that. But that requires I understand way too much about VLANning. I was referring to a much more simple, add WAN port dedicated UI that basically went along the lines of Add WAN port-LAN port to become a WAN port. type of process. Cheers, b. signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] alix2 target in trunk
Hi all, I have a question on the updated alix2 target in trunk. It's great to see the alix platform getting some updates in trunk. However, I noticed the default inclusion of the ath5k and ath9k drivers. Alix boards don't come with wireless built in. While it is true that you can add wireless to it, some people do not, myself included. Most of the rest of the included drivers seem to be foundational alix2 platform pieces. Technically the ath5k and ath9k drivers aren't part of the base platform. The packages (kernel modules I guess), in question are: kmod-cfg80211 kmod-mac80211 kmod-ath kmod-ath5k kmod-ath9k hostapd I think it would be better to not include these by default. Presumably if someone is selecting the alix2 target form menuconfig they are already building them own image and can easily select them manually? If someone downloads a prebuilt image from openwrt.com they could always manually include the ath5k or ath9k drivers as necessary afterwards. Thoughts? Adam ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Netifd and ubus in trunk - Please provide some details
Hi Felix, What is this netifd and ubus business appearing in trunk? What is it implementing or replacing? Will it affect all platforms and be included firmware images by default or does it have to be specifically compiled into an image? How can we help you testing this new package, what should we be looking for in terms of regression testing? Please advise Kind Regards Hanno Schupp Connect Consulting Services Chillifire is a trademark owned by CCS ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Netifd and ubus in trunk - Please provide some details
On 2011-10-22 12:59 AM, Hanno Schupp wrote: Hi Felix, What is this netifd and ubus business appearing in trunk? What is it implementing or replacing? Will it affect all platforms and be included firmware images by default or does it have to be specifically compiled into an image? How can we help you testing this new package, what should we be looking for in terms of regression testing? ubus simply implements an RPC service, making it easy for C programs to export an API that can easily be accessed from other C code or even shell scripts. netifd is going to replace the network configuration scripts at some point. right now it's experimental and disabled by default, as not all network proto handlers have been converted yet (so far, static, ppp, pppoe, pppoa, dhcp are supported). What would be useful is not just testing what has been ported, but also review of the code and porting more of our protocol handler scripts. When all the existing features have been ported over, this will be enabled by default and the old scripts will be removed. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] busybox 1.19.2 update patch
Applied in [28513], with a minor modification (groups applet disabled)
and patches refreshed
Thanks!
--
-{Nico}
On Thu, Oct 13, 2011 at 8:13 PM, Peter Wagner tripo...@gmx.at wrote:
Hi Noco,
this is the updated patch.
/Peter
On Donnerstag, 13. Oktober 2011 19:59:41 Nico wrote:
Hi Peter,
I started working on an update too, but your patch seems really good
and comprehensive.
Some suggestions :
1. Can you rename upstream patches in the 000-*.patch serie to
000-upstream_*.patch ?
2. Can you change the following new options default to n (to remain
conservative)
- BUSYBOX_CONFIG_FEATURE_MESG_ENABLE_ONLY_GROUP
- BUSYBOX_CONFIG_FEATURE_SKIP_ROOTFS
- BUSYBOX_CONFIG_FEATURE_UDHCP_8021Q
- BUSYBOX_CONFIG_PSTREE
- BUSYBOX_CONFIG_PWDX
- BUSYBOX_CONFIG_SETSERIAL
Thanks,
--
-{Nico}
On Thu, Oct 13, 2011 at 6:21 PM, Peter Wagner tripo...@gmx.at wrote:
Hi,
this patch updates busybox to 1.19.2.
all patches are refreshed.
/Peter Wagner
Signed-off-by: Peter Wagner tripo...@gmx.at
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Netifd and ubus in trunk - Please provide some details
Thank you for the fast response. For sake of clarification: When you mention 'network configuration scripts' are you talking about scripts like the old brcm-2.4 init.d netconfig script and things like target profile specific network configuration defaults stored in target/linux/atheros/base-files/etc/uci-defaults/network and target/linux/ar71xx/base-files/etc/defconfig/* for example? Please advise Regards Hanno -Original Message- From: Felix Fietkau [mailto:n...@openwrt.org] Sent: Saturday, 22 October 2011 12:08 p.m. To: OpenWrt Development List Cc: Hanno Schupp Subject: Re: [OpenWrt-Devel] Netifd and ubus in trunk - Please provide some details On 2011-10-22 12:59 AM, Hanno Schupp wrote: Hi Felix, What is this netifd and ubus business appearing in trunk? What is it implementing or replacing? Will it affect all platforms and be included firmware images by default or does it have to be specifically compiled into an image? How can we help you testing this new package, what should we be looking for in terms of regression testing? ubus simply implements an RPC service, making it easy for C programs to export an API that can easily be accessed from other C code or even shell scripts. netifd is going to replace the network configuration scripts at some point. right now it's experimental and disabled by default, as not all network proto handlers have been converted yet (so far, static, ppp, pppoe, pppoa, dhcp are supported). What would be useful is not just testing what has been ported, but also review of the code and porting more of our protocol handler scripts. When all the existing features have been ported over, this will be enabled by default and the old scripts will be removed. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Netifd and ubus in trunk - Please provide some details
On 2011-10-22 1:30 AM, Hanno Schupp wrote: Thank you for the fast response. For sake of clarification: When you mention 'network configuration scripts' are you talking about scripts like the old brcm-2.4 init.d netconfig script and things like target profile specific network configuration defaults stored in target/linux/atheros/base-files/etc/uci-defaults/network and target/linux/ar71xx/base-files/etc/defconfig/* for example? I'm talking about the actual scripts that configure the network, e.g. /lib/network/*.sh, /sbin/ifup, some scripts in /etc/hotplug.d. netifd is intended to stay compatible with the existing format of /etc/config/network, the only exceptions being rare special cases like aliases or the overlay variables in /var/state, though even most of those can be easily emulated. One thing that netifd does much better is handling config changes. When /etc/config/network changes, you no longer have to restart all interfaces. Simply run /etc/init.d/netifd reload, which will issue an ubus call to netifd, telling it to figure out the difference between runtime state and the new config and apply only that. This works on a per-interface level, even with protocol handlers written as shell scripts. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] alix2 target in trunk
Adam == Adam Gensler open...@akapm.com writes: Adam Hi all, I have a question on the updated alix2 target in Adam trunk. It's great to see the alix platform getting some updates Adam in trunk. However, I noticed the default inclusion of the ath5k Adam and ath9k drivers. Alix boards don't come with wireless built Adam in. While it is true that you can add wireless to it, some Adam people do not, myself included. Most of the rest of the included Adam drivers seem to be foundational alix2 platform Adam pieces. Technically the ath5k and ath9k drivers aren't part of Adam the base platform. Adam The packages (kernel modules I guess), in question are: Adam kmod-cfg80211 kmod-mac80211 kmod-ath kmod-ath5k kmod-ath9k Adam hostapd Adam I think it would be better to not include these by Adam default. Presumably if someone is selecting the alix2 target Adam form menuconfig they are already building them own image and can Adam easily select them manually? If someone downloads a prebuilt Adam image from openwrt.com they could always manually include the Adam ath5k or ath9k drivers as necessary afterwards. Adam Thoughts? +1 -- Russell Senior, President russ...@personaltelco.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
