Upgrade nginx to 1.0.14.
Changelog: http://nginx.org/en/CHANGES-1.0
This upgrade includes a fix for a major security vulnerability,
CVE-2012-1180.
Signed-off-by: Mark Mentovai m...@moxienet.com
---
Index: packages/net/nginx/Makefile
Changelog: http://nginx.org/en/CHANGES-1.0
This upgrade includes a fix for a security vulnerability, CVE-2012-2089.
Signed-off-by: Mark Mentovai m...@moxienet.com
---
Index: packages/net/nginx/Makefile
===
--- packages/net/nginx
.
Local hostnames will remain available for lookup using fully-qualified names.
Signed-off-by: Mark Mentovai m...@moxienet.com
Index: package/dnsmasq/files/dnsmasq.init
===
--- package/dnsmasq/files/dnsmasq.init (revision 31782
.
The default, on, produces the current behavior. Setting it to off avoids
adding a search line to resolv.conf. option domain still retains its other
functions such as providing the value for the --domain option to dnsmasq.
Signed-off-by: Mark Mentovai m...@moxienet.com
Index: package/dnsmasq/files
, it is obsolete and should be removed from the dnsmasq package.
Signed-off-by: Mark Mentovai m...@moxienet.com
---
Index: package/dnsmasq/Makefile
===
--- package/dnsmasq/Makefile(revision 31782)
+++ package/dnsmasq/Makefile
Very well, I'll drop this. I missed the conf-file=/etc/dnsmasq.conf at
the top of /var/etc/dnsmasq.conf.
I'm still proposing the other four dnsmasq patches I sent to the list
in a series earlier today.
___
openwrt-devel mailing list
.
Signed-off-by: Mark Mentovai m...@moxienet.com
---
Index: include/image.mk
===
--- include/image.mk(revision 31782)
+++ include/image.mk(working copy)
@@ -142,7 +142,7 @@
define Image/mkfs/prepare/default
# Use
On the off chance that the root filesystem's /tmp is used directly as a
temporary directory instead of having a tmpfs mounted over it, it should have
the sticky bit set.
Signed-off-by: Mark Mentovai m...@moxienet.com
---
Index: include/image.mk
the sticky bit set.
Signed-off-by: Mark Mentovai m...@moxienet.com
---
Index: include/image.mk
===
--- include/image.mk (revision 31782)
+++ include/image.mk (working copy)
@@ -146,7 +146,7 @@
- $(FIND) $(TARGET_DIR
Are you sure this is universally correct for all WNDRMAC units? It's
possible that the N there is actually variable, and part of something
else that shows up at that location in flash. `hexdump -C /dev/mtd5`
(assuming mtd5 is art in /proc/mtd) should help identify what that N is
actually
||
My guess is that this should work on all WNDRMACs, although I only have one
device to test this.
15.06.2012 20:19, Mark Mentovai пишет:
Are you sure this is universally correct for all WNDRMAC units? It's
possible that the N there is actually variable, and part of something
else
I suspect that the netifd changes are related, since that looks like the
only relevant area of major activity in the past month when this began
happening. Then again, the timing-sensitive nature means that the
underlying problem may have been present for a while, and only exposed
with the
Philip Prindeville wrote:
On 6/26/12 11:02 AM, Jo-Philipp Wich wrote:
That is nothing netifd or OpenWrt does, it is the behaviour of Linux
bridges - they'll assume the lowest MAC address of all their member ifaces.
Imo that should be changed in the Kernel, it shoud fix the bridge MAC to
Felix Fietkau wrote:
I did add code to netifd to take care of this a while ago, but there was
a bug that prevented it from working. This bug is fixed in the latest
version, committed in r32506
Great, I confirmed that this is working as it used to now. Thanks!
Changelog: http://nginx.org/en/CHANGES-1.2
Signed-off-by: Mark Mentovai m...@moxienet.com
---
Index: packages/net/nginx/Makefile
===
--- packages/net/nginx/Makefile (revision 33213)
+++ packages/net/nginx/Makefile (working copy
Signed-off-by: Mark Mentovai m...@moxienet.com
---
Index: packages/net/nginx/Makefile
===
--- packages/net/nginx/Makefile (revision 33213)
+++ packages/net/nginx/Makefile (working copy)
@@ -103,6 +103,8 @@
$(INSTALL_DATA
Jo-Philipp Wich wrote:
Hi.
You do not need to ship a keep file, it is enough to add /etc/nginx to
the conffiles define.
It looks like conffiles can only save files, not entire directories.
/etc/nginx is a directory. Should conffiles be fixed to work with
directories too?
Jo-Philipp Wich wrote:
It looks like conffiles can only save files, not entire directories.
/etc/nginx is a directory. Should conffiles be fixed to work with
directories too?
It works fine with directories, see include/package-ipkg.mk, the code
below ifneq ($$(KEEP_$(1)),)
I see. The
Jo-Philipp Wich wrote:
But they will get recorded by opkg, which is another source sysupgrade
uses to assemble the list of files to get backed up.
This is the part I was missing. Thanks for the explanation. I've submitted
a v2 patch in case it's thought to be generally useful, otherwise I'll
This allows additional files in /etc/nginx/, such as SSL certificates,
tobe saved on sysupgrade.
Signed-off-by: Mark Mentovai m...@moxienet.com
---
Index:
packages/net/nginx/Makefile
===
--- packages/net/nginx/Makefile (revision
John Crispin wrote:
On 24/08/12 15:14, Mark Mentovai wrote:
This allows additional files in /etc/nginx/, such as SSL certificates,
tobe saved on sysupgrade.
Signed-off-by: Mark Mentovai m...@moxienet.com
after not reading the 100 mails leading up to this patch i expected
something
Is there a way to make the link state drop on an ag71xx interface, so that
it appears to whatever equipment is connected to the port that the cable
has been disconnected?
I've got a WNDR3700-family device and I need to make it appear to the
equipment connected to its eth1 interface that the
John Crispin wrote:
not merging any new stuff and/or updates atm ...
--
https://lists.openwrt.org/pipermail/openwrt-devel/2012-August/016411.html
is there a specific reason, such as a security fix or is it just a
feature update ?
No security fixes here, just bug fixes. It's OK to hold
Gabor Juhos wrote:
The problem is that PHYLIB in Linux does not fully stops the PHY device when a
driver issues a phy_stop call.
Copy the attached patches into 'target/linux/ar71xx/patches-3.3', then do a
'make target/linux/clean world'. With these patches, the PHY of the WAN port
will be
Adam Gensler wrote:
I recently acquired a Netgear WNDR3800. To date I've been playing
exclusively on an alix 2D13 platform so I have a few new things to learn.
In any case, I've been tinkering with the LEDs and I'm having some trouble
getting my head around a few things. Specifically:
1.
)
@@ -0,0 +1,54 @@
+include $(TOPDIR)/rules.mk
+
+PKG_NAME:=ifplugd_support
+PKG_VERSION:=0.1
+PKG_RELEASE:=1
+
+include $(INCLUDE_DIR)/package.mk
+
+define Package/ifplugd_support
+ SECTION:=base
+ CATEGORY:=Custom
+ TITLE:=ifplugd support
+ MAINTAINER:=Mark Mentovai m...@moxienet.com
+ DEPENDS
Weedy weedy2...@gmail.com wrote:
On 27/08/12 07:34 AM, Gabor Juhos wrote:
The problem is that PHYLIB in Linux does not fully stops the PHY device
when a
driver issues a phy_stop call.
Copy the attached patches into 'target/linux/ar71xx/patches-3.3', then
do a
'make target/linux/clean
Florian Fainelli wrote:
On Tuesday 21 August 2012 12:32:17 Mark Mentovai wrote:
Changelog: http://nginx.org/en/CHANGES-1.2
Signed-off-by: Mark Mentovai m...@moxienet.com
Applied in r34495, thanks Mark!
Thanks, Florian. They’re up to 1.2.5 now, so I’ve moved on to using this.
Signed-off
Since the recent enhancements to NAT reflection were made, I found
that reflection stopped working on my networks. I was unable to
connect from hosts on a LAN to its router’s WAN-side address and have
the port mappings from “config redirect” sections be effective.
Instead, I got “connection
It seems that at some point in the last three months (between r37989 and
r39097), something about the way network interfaces are brought up changed.
Interfaces that were formerly available at a certain point during startup
are no longer necessarily available at that point.
I first noticed this
I wrote:
Are you suggesting that dnsmasq should be started out of a hotplug
script?
I suppose the answer is “yes:” I see r39152.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
etienne.champet...@free.fr wrote:
zabbix-agentd select BUSYBOX_CONFIG_UNAME and BUSYBOX_CONFIG_HOSTNAME,
It's working ok in r39105 (419db8ef231eae6c0a514f32ff6c423c384900ca)(just
before busybox config changes),
but it's not in r39185 (13b222d757237eb7772eb7cf8433306ffd6b8ccd)(latest
deca1064 rps...@arcor.de wrote:
This patch adds platform machine support for the Netgear WNDR3700v4.
Signed-off-by: Ralph Perlich rps...@arcor.de
The WNDR3700v4 and WNDR4300 are almost identical, so much so that
nearly everything you’ve added here duplicates the definitions that
already exist
Has the source address used for NAT reflection changed with firewall3?
At r35938, I’m seeing that when I attempt to connect from a host on my LAN
to a redirected port on my main router’s WAN address, the router reflects
the request back in to my LAN using its own WAN address as the source
reflection_src_dip? That matches src_dip as used for SNAT rules, but makes
it clear that it’s for reflection. (src_dip has a matching function instead
of a rewriting function for DNAT rules.)
I’ve got a strong preference to allow an interface name argument (“lan”)
instead of requiring an IP
This would work just fine for me, although configuration’s meaning wouldn’t
be nearly as evident without consulting some reference documentation.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
the up/down state
of its interface.
[1] https://lists.openwrt.org/pipermail/openwrt-devel/2012-August/016540.html
[2] https://lists.openwrt.org/pipermail/openwrt-devel/2012-October/016996.html
Signed-off-by: Mark Mentovai m...@moxienet.com
---
Index:
target/linux/ar71xx/patches-3.8/910-phy-add
This works perfectly. Thanks, jow.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
the problem. This seems to be how compound conditions are generally
handled in OpenWrt Makefiles.
Signed-off-by: Mark Mentovai m...@moxienet.com
---
Index: feeds/packages/net/nginx/Makefile
===
--- feeds/packages/net/nginx/Makefile
Jo-Philipp Wich wrote:
Here's my proposal:
I like the outcome but I find the logic a bit confusing. ${country_ie}
starts out as the value of the country parameter on the wifi-device
(empty or a country string), but then becomes either 0 or 1, a boolean
that controls enabling the feature in
the discrepancy between the two places that
ieee80211d could be set.
Signed-off-by: Mark Mentovai m...@moxienet.com
ieee80211d.patch
Description: Binary data
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo
Gábor-
I’d like your thoughts (and others’) on my proposed patch at
https://dev.openwrt.org/ticket/8781
Currently, the WNDR3700 images reserve 1MB for the kernel, whether or
not the kernel is actually anywhere near that size. It can be smaller,
in which case space is wasted, or it can in theory
-NA and worldwide images, neither of
which are tagged with hd_id.
Signed-off-by: Mark Mentovai m...@moxienet.com
wndr3700v2_images.patch
Description: Binary data
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org
toolchain/gcc: upgrade Linaro GCC to 4.5-2011.05-0
Signed-off-by: Mark Mentovai m...@moxienet.com
linaro_4.5-2011.05-0.patch
Description: Binary data
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman
Signed-off-by: Mark Mentovai m...@moxienet.com
--
Index: toolchain/gcc/patches/linaro/860-fix_extension_elimination.patch
===
--- toolchain/gcc/patches/linaro/860-fix_extension_elimination.patch
(revision 27096)
+++ toolchain/gcc
/8781.
Signed-off-by: Mark Mentovai m...@moxienet.com
---
Index: target/linux/ar71xx/image/Makefile
===
--- target/linux/ar71xx/image/Makefile (revision 27926)
+++ target/linux/ar71xx/image/Makefile (working copy)
@@ -42,13 +42,13
Dave Taht wrote:
Awesome. However I'd like to somehow make for fully field-upgradable
kernels for this device (how to do that?), and reserving 64k strikes
me as too small to account for future growth.
It doesn't reserve 64kB. It doesn't really reserve anything at all.
There can be as little as
Gabor Juhos wrote:
2011.11.16. 21:20 keltezéssel, Petri Rosenström írta:
This fixes the machine name in /proc/cpuinfo and luci status page machine
name.
Signed-off-by: Petri Rosenström petri.rosenst...@gmail.com
Applied, thanks!
I don't think this patch is a great idea. There are no
Petri Rosenström wrote:
I think it is useful because it adds the specific board information
about WNDR3800 (e.g. the name WNDR3800 on status page or /proc/cpuinfo
show correct board name). I think that this information is important
and it should be available.
Since you can flash a WNDR3700v2
Jonathan Bennett wrote:
This patch seems like a really good idea for the ar71xx family. What
sorts of problems are preventing this from being implemented? As small
as it sounds, an extra 192k would be really useful on quite a few
routers.
I don't know of any actual problems with the patch.
I just had a chance to flash a WNDR3800 with an image that contains
this “machine name” patch (post-r29326). It's broken in two ways that
I can see so far. These are regressions. The WNDR3800 images that used
board=WNDR3700v2 worked properly in these cases. It remains my
recommendation that this
Jonathan McCrohan wrote:
Is there even a need to produce an oversize image warning? I'm not aware
of any other architecture that refuses to build over a certain size. x86
being the obvious exception, but that is different because it doesn't
target any particular device, but a whole
. It also will not mis-detect
units on which people install more memory.
I have tested this patch on WNDR3700 (v1), WNDR3700v2, and WNDR3800.
Signed-off-by: Mark Mentovai m...@moxienet.com
---
Index: target/linux/ar71xx/base-files/lib/ar71xx.sh
to set the device: field. In r29434, this was
erroneously changed to be WNDR3700 for all models. The tools to flash
factory images (U-Boot's TFTP server and the factory software's upgrade
utility) may refuse to honor images with incorrect device: fields in their
DNI tags.
Signed-off-by: Mark Mentovai
I concur that there's something wrong with mtd -j jffs write, as
used by sysupgrade when preserving configuration. The CRC in the TRX
header is computed before all writes that the CRC protects have
completed. I've worked around this problem in my brcm47xx builds by
running mtd fixtrx as part of
Dave Taht wrote:
[PATCH 4/4] Add local mac support to wndr3700 so as to be able to
route not bridge
The wndr3700 at least has no eth0 mac address and usually leverages
the first wireless device's mac when in a bridged scenario. If,
however, you want to route, and not bridge the interfaces,
://dev.openwrt.org/ticket/8103
Signed-off-by: Mark Mentovai m...@moxienet.com
---
Index: target/linux/ar71xx/base-files/etc/defconfig/wndr3700/network
===
--- target/linux/ar71xx/base-files/etc/defconfig/wndr3700/network
(revision 23538
Make the WiFi LEDs blink for activity on the WNDR3700, matching the
stock firmware and user expectations. The green 2.4GHz and blue 5GHz
LEDs will illuminate with the radio on, and will blink to indicate
transmission and reception.
https://dev.openwrt.org/ticket/7984
Signed-off-by: Mark Mentovai
Always set auth_algs in hostapd.conf. For WEP, auth_algs is configurable
using a new UCI parameter, auth_algs, which may contain open,
shared, or both. For other encryption types, auth_algs is always set
to 1 (open).
https://dev.openwrt.org/ticket/8120
Signed-off-by: Mark Mentovai m
Philip Prindeville wrote:
+[ -n $auth_alg_shared ] \
+auth_alg_val=$(expr $auth_alg_val + 2)
Just curious: why not use:
let -i auth_alg_val+=2
here instead?
let is Kornish. Straight Bourne needs to rely on expr for arithmetic. I wasn’t
. The default is default is open as it is more
secure than shared (although WEP is pretty weak regardless.) For
non-WEP, open is always used.
https://dev.openwrt.org/ticket/8120
Signed-off-by: Mark Mentovai m...@moxienet.com
---
Index: package/hostapd/files/hostapd.sh
identically-configured OpenWrt and the stock
firmware.
https://dev.openwrt.org/ticket/6533
Signed-off-by: Mark Mentovai m...@moxienet.com
---
Index: package/mac80211/files/lib/wifi/mac80211.sh
===
--- package/mac80211/files/lib/wifi
Jo-Philipp Wich wrote:
Good work on the patch and I agree with the approach, however there's one
detail. The fixed_antenna_group uci option would be the fourth variable for
antenna related stuff after rxantenna, txantenna and antenna.
The antenna option is already used for Ubiquiti devices
/ticket/6533
Signed-off-by: Mark Mentovai m...@moxienet.com
---
Index: package/mac80211/files/lib/wifi/mac80211.sh
===
--- package/mac80211/files/lib/wifi/mac80211.sh (revision 23587)
+++ package/mac80211/files/lib/wifi/mac80211.sh
-compiler.
Signed-off-by: Mark Mentovai m...@moxienet.com
---
Index: feeds/packages/utils/lsof/patches/005-lsof_ccv.patch
===
--- feeds/packages/utils/lsof/patches/005-lsof_ccv.patch(revision 0)
+++ feeds/packages/utils/lsof/patches
Philip Prindeville wrote:
+AR=$(TARGET_CROSS)ar cr \
Is this safe? I've seen config scripts do things like:
if [ -x $RANLIB ]; then
in which case having args be part of the string (or spaces, for that matter)
could be bad.
This is unfortunately how the lsof Makefile
sequential anyway.)
Signed-off-by: Mark Mentovai m...@moxienet.com
---
Index: target/linux/ar71xx/files/arch/mips/ar71xx/mach-wndr3700.c
===
--- target/linux/ar71xx/files/arch/mips/ar71xx/mach-wndr3700.c (revision 23587)
+++ target
This GCC 4.4.1 typo slipped in at r18113.
Signed-off-by: Mark Mentovai m...@moxienet.com
Index: toolchain/gcc/common.mk
===
--- toolchain/gcc/common.mk (revision 23700)
+++ toolchain/gcc/common.mk (working copy)
@@ -54,7
nbd asked me earlier today what sort of txpower I was seeing from ath9k on
ar71xx/WNDR3700. Even with CONFIG_ATH_USER_REGD set, I see 20dBm on both
radios. This is at trunk r23883 (current).
The intersection stuff is still clamping everything to 20dBm. Ignoring DFS
channels, the expected
, this
resulted in no calls to set the GPIOs, an improperly-configured radio,
and reduced RSSI on other systems listening to the radio.
Signed-off-by: Mark Mentovai m...@moxienet.com
---
Index: package/mac80211/patches/310-ath9k_gpio_settings.patch
I wrote:
nbd asked me earlier today what sort of txpower I was seeing from ath9k on
ar71xx/WNDR3700. Even with CONFIG_ATH_USER_REGD set, I see 20dBm on both
radios. This is at trunk r23883 (current).
The intersection stuff is still clamping everything to 20dBm.
I figured out why I’m
r24132 (https://dev.openwrt.org/ticket/8308) introduced the -n flag for
mtd, which is supposed to bypass the erase step. It appears that the
logic used to do this is backwards, and that erasing will actually be
bypassed unless -n is given. Lots and lots of things will break.
(no_erase) needs to
the
*_PASSIVE_SCAN and *_NO_IBSS flags set. This was done by breaking
ATH9K_5GHZ_5150_5350 into two REG_RULES. The various struct
ieee80211_regdomains that reference these rules in their reg_rules
fields need to have their n_reg_rules fields updated accordingly.
Signed-off-by: Mark Mentovai m...@moxienet.com
Vasilis Tsiligiannis wrote:
It's not so safe, as user home dir can be overriden in a shell by setting
the $HOME environment variable.
This is at least an explicit declaration that something else ought to
be treated as ${HOME}; if someone sets it badly, all sorts of things
are subject to
base-files: librt should depend on libpthread, not the other way around
In uClibc 0.9.32 as well as recent versions of glibc and eglibc, librt
depends on libpthread.
Signed-off-by: Mark Mentovai m...@moxienet.com
---
Index: package/base-files/Makefile
with this compiler, I'm not sending this patch
upstream to hostapd at this point.
Signed-off-by: Mark Mentovai m...@moxienet.com
---
Index: package/hostapd/patches/001-mips_linaro_gcc45_codegen.patch
===
--- package/hostapd/patches/001
Felix Fietkau wrote:
Scratch that, got confused by the delay slot for a second there :)
I see the code that adds the wrong bits now, I wonder if there's
something wrong with signed vs unsigned type propagation...
I'll let you know when I find out more about this.
I agree that signed/unsigned
Felix Fietkau wrote:
Actually, it emits -16384 in both the working and non-working case,
I think what makes the difference of working vs non-working is this:
Broken: (0xc000 is in v0)
- e8:00021a02srl v1,v0,0x8
- ec:00021200sll v0,v0,0x8
documented in the UCI
wireless configuration page on the wiki. When this change is
committed, I'll update the documentation as needed.
Signed-off-by: Mark Mentovai m...@moxienet.com
---
Index: package/mac80211/files/lib/wifi/mac80211.sh
I received a request for more information, so in case anyone else is
interested, here’s what was happening.
The problem occurs in hostapd src/ap/ieee802_11.c’s send_assoc_resp.
The C statement that triggers the compiler bug is
reply-u.assoc_resp.aid = host_to_le16((sta ? sta-aid : 0)
bjorn.smed...@venatech.se:
Wouldn't it make more sense to configure beacon interval per
wifi-iface? This is how mac80211 does it and there is at least talk
about supporting different beacon intervals for different ap vifs with
ath9k.
It’s configured via hostapd, which only supports the beacon
This applies Richard Sandiford's patch for Linaro GCC as an
alternative to disabling the Linaro-specific extension elimination
optimization altogether.
Original patch: https://bugs.launchpad.net/gcc-linaro/+bug/728315
Signed-off-by: Mark Mentovai m...@moxienet.com
---
Index: toolchain/gcc
-by: Mark Mentovai m...@moxienet.com
---
Index: toolchain/gcc/patches/linaro/860-fix_extension_elimination.patch
===
--- toolchain/gcc/patches/linaro/860-fix_extension_elimination.patch
(revision 0)
+++ toolchain/gcc/patches/linaro/860
(Third time's the charm? Sorry for the spam.)
This applies Richard Sandiford's patch for Linaro GCC as an alternative to
disabling the Linaro-specific extension elimination optimization altogether.
Original patch: https://bugs.launchpad.net/gcc-linaro/+bug/728315
Signed-off-by: Mark Mentovai m
In the latest OpenWrt trunk, I found that config_get has stopped loading
uncommitted uci changes from /tmp/.uci. I rely on this behavior, which had
worked well for years.
I found a change[1] in uci that’s responsible.
The uci change makes uci_add_delta_path() reject any attempt to add
Yousong Zhou wrote:
I just sent a patch for this with you in the cc list. Could you give it a
try and tell if it can work for you?
Thanks, Yousong. Your patch fixes this for me.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
Felix, is this patch acceptable?
The v2 that made it to Patchwork applies cleanly to the trunk without any
whitespace problems.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
ikely, all of OpenWrt’s busybox Config.in files need
to be updated in this way after a Busybox update.
Signed-off-by: Mark Mentovai <m...@moxienet.com>
diff --git a/package/utils/busybox/config/coreutils/Config.in
b/package/utils/busybox/config/coreutils/Config.in
index f50823f012de..e25
John Crispin wrote:
patch does not apply to current trunk
Sorry, the tabs got swallowed. I re-sent it.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Signed-off-by: Mark Mentovai <m...@moxienet.com>
---
package/utils/busybox/Config-defaults.in | 159 +++---
package/utils/busybox/config/archival/Config.in | 10 ++
package/utils/busybox/config/coreutils/Config.in | 116 +++--
package/utils/busybox/conf
rc. Likely, all of OpenWrt’s busybox Config.in files
need to be updated in this way after a Busybox update.
Signed-off-by: Mark Mentovai <m...@moxienet.com>
diff --git a/package/utils/busybox/config/coreutils/Config.in
b/package/utils/busybox/config/coreutils/Config.in
index f50823f012de..e25
I wrote:
OpenWrt’s busybox/config/coreutils/Config.in needs to mirror Busybox’ own
coreutils/Config.src. Likely, all of OpenWrt’s busybox Config.in files need
to be updated in this way after a Busybox update.
I posted this as an alternative, more complete patch, under the title
[PATCH]
Felix Fietkau wrote:
> On 2015-11-21 22:43, Mark Mentovai wrote:
> > r47288 updated to Busybox 1.24.1 but did not update the configuration.
> >
> > The configuration is updated by running
> >
> > cd config
> > ../convert_menuconfig.pl .../b
Signed-off-by: Mark Mentovai <m...@moxienet.com>
---
package/utils/busybox/Config-defaults.in | 159 +++---
package/utils/busybox/config/archival/Config.in | 10 ++
package/utils/busybox/config/coreutils/Config.in | 116 +++--
package/utils/busybox/conf
User-space firmware loading is handled by hotplug in procd. It’s directed
by /etc/hotplug.json. Paraphrasing:
[
[ "case", "ACTION", {
"add": [
[ "if",
[ "has", "FIRMWARE" ],
[
[ "exec", "/sbin/hotplug-call", "%SUBSYSTEM%" ],
[ "load-firmware", "/lib/firmware" ],
[ "return" ]
]
]
],
} ],
]
Ansuel Smith wrote:
Tested-by: Ansuel Smith
I also tested this with the qca8k driver on 5.10. Also can you include
this with kernel 5.10
Yes, thanks. The broken fa731838c524 hasn't made it into patches-5.10 yet,
so I'm going to merge this patch, that one, and 75ca641f1b84 into an
update
Signed-off-by: Mark Mentovai
Run-tested: ipq806x/ubnt,unifi-ac-hd
Cc: Ansuel Smith
---
.../ipq806x/patches-5.10/0069-arm-boot-add-dts-files.patch | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git
a/target/linux/ipq806x/patches-5.10/0069-arm-boot-add-dts-files.patch
b
2825dd77b3 ipq806x: dwmac: set forced speed when using fixed-link
Signed-off-by: Mark Mentovai
Run-tested: ipq806x/ubnt,unifi-ac-hd
Cc: Ansuel Smith
---
.../082-ipq8064-dtsi-tweaks.patch | 36
...-dwmac-ipq806x-qsgmii-pcs-all-ch-ctl.patch | 83 +++
2 files ch
d, setting the speed as directed by
fixed-link if present, and otherwise clearing it as was done previously.
Fixes: fa731838c524 ("ipq806x: dwmac: clear forced speed during probe")
Signed-off-by: Mark Mentovai
Tested-by: Hannu Nyman
Run-tested: ipq806x/ubnt,unifi-ac-hd, ipq806x/netgear,r7800
:
- correctly configures that register,
- properly configures the on-board PHYs for both interfaces, and
- reorders eth0 and eth1 so that gmac2/MAIN is eth0 and gmac1/SECONDARY
is eth1.
Mark Mentovai (3):
ipq806x: dwmac: clear forced speed during probe
ipq806x: ubnt,unifi-ac-hd: use on-board PHYs
1 - 100 of 118 matches
Mail list logo