odhcp6c logs messages related to its activity when invoked with -v, but
there is no way to configure this from within OpenWrt. This adds a UCI
option to turn on odhcp6c logging, disabled by default. To enable, set,
for example, network.wan6.verbose = 1.
Signed-off-by: Mark Mentovai
---
package
properly.
Note that the kernel's objtool and related configuration have seen a
major overhaul since kernel 5.15, and may need more attention again
after 22922deae13f, in kernel 5.19.
Signed-off-by: Mark Mentovai
---
include/kernel.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
di
Thibaut wrote:
I’m experiencing a strange bug on Yuncore AX820 (mt7621/mt7905/mt7975,
DSA-enabled) when using a bridge-vlan setup. This bug affects at least
OpenWRT 22.03.0-rc6.
I’m not sure whether this bug is related to this particular SoC or only
to DSA as I was unable to test with another
st the last-defined one). It sets a hostname of
"OpenWrt-failsafe" in failsafe mode which is rendered in the shell's
prompt as a reminder of the mode during interactive failsafe use.
Previously, no hostname was set, which resulted in the kernel-default
hostname, "(none)", appear
aring at
package/kernel/mac80211/patches/build/001-fix_build.patch.
Signed-off-by: Mark Mentovai
---
package/libs/libmnl/patches/001-fix_build.patch | 11 +++
1 file changed, 11 insertions(+)
create mode 100644 package/libs/libmnl/patches/001-fix_build.patch
diff --git a/package/libs/l
Hauke Mehrtens wrote:
On 6/21/22 16:38, Mark Mentovai wrote:
From: Mark Mentovai
This fixes the libmnl build on macOS, which ships with an outdated bash
at /bin/bash. During the OpenWrt build, a modern host bash is built and
made available at staging_dir/host/bin/bash, which is present before
t; on all
consoles (not just the last-defined one). It sets a hostname of
"OpenWrt-failsafe" in failsafe mode which is rendered in the shell's
prompt as a reminder of the mode during interactive failsafe use.
Previously, no hostname was set, which resulted in the kernel-defaul
From: Mark Mentovai
This fixes the libmnl build on macOS, which ships with an outdated bash
at /bin/bash. During the OpenWrt build, a modern host bash is built and
made available at staging_dir/host/bin/bash, which is present before
/bin/bash in the build's PATH.
This is similar to 8f7ce3a
nder of the mode during interactive failsafe use.
Previously, no hostname was set, which resulted in the kernel-default
hostname, "(none)", appearing in failsafe shell prompts.
Signed-off-by: Mark Mentovai
---
.../files/lib/preinit/10_indicate_failsafe | 7 ++-
.../files/lib/pr
util-linux getopt (such as one provided by an
OS) shadows the util-linux getopt in the PATH.
Signed-off-by: Mark Mentovai
---
include/prereq-build.mk | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/include/prereq-build.mk b/include/prereq-build.mk
index e1918f002787..1b
h multiple console= arguments,
including x86 and bcm27xx (Raspberry Pi).
Signed-off-by: Mark Mentovai
---
.../files/lib/preinit/30_failsafe_wait| 60 ++-
.../files/lib/preinit/99_10_failsafe_login| 15 ++---
2 files changed, 40 insertions(+), 35 deletions(-)
diff --git
ithout any need for reconfiguration can be shared by
devices with the more traditional (for x86) VGA console.
Signed-off-by: Mark Mentovai
---
.../files/lib/preinit/99_10_failsafe_login| 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/package/base-files
r and group are statically allocated
uid 101 and gid 101, respectively, per
package/base-files/files/etc/passwd and USERID in
package/network/services/hostapd/Makefile, this patch also uses a
constant 101 for the uid and gid.
Cc: Daniel Golle
Signed-off-by: Mark Mentovai
---
.../610-hostapd_cli_ujai
There's no such thing as ucidef_set_interfaces_lan. It's
ucidef_set_interface_lan.
Cc: David Bauer
Signed-off-by: Mark Mentovai
---
target/linux/mediatek/mt7622/base-files/etc/board.d/02_network | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/linux/media
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
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
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 for
ld, 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,r
s/net/ethernet/stmicro/stmmac/stmmac_platform.c
stmmac_probe_config_dt.
Signed-off-by: Mark Mentovai
Build-tested: ipq806x/ubnt,unifi-ac-hd
Run-tested: ipq806x/ubnt,unifi-ac-hd
---
.../ipq806x/patches-5.4/083-ipq8064-dtsi-additions.patch | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
during dwmac initialization when
SGMII is in use, this port becomes usable.
This patch is upstreamable, and will be sent upstream after successful
testing in OpenWrt.
Signed-off-by: Mark Mentovai
Build-tested: ipq806x/ubnt,unifi-ac-hd
Run-tested: ipq806x/ubnt,unifi-ac-hd
---
...-dwmac-ipq806x
the at803x driver to load.
Signed-off-by: Mark Mentovai
Build-tested: ipq806x/ubnt,unifi-ac-hd
Run-tested: ipq806x/ubnt,unifi-ac-hd
---
.../arm/boot/dts/qcom-ipq8064-unifi-ac-hd.dts | 38 +--
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git
a/target/linux/ipq806x/files
switch on board, so there's no possibility
to remap ports via switch configuration. "ip link set $interface name"
is used instead, during preinit before networking is configured.
Signed-off-by: Mark Mentovai
Build-tested: ipq806x/ubnt,unifi-ac-hd
Run-tested: ipq806x/ubnt,unifi-ac-hd
-
:
- 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
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" ]
]
]
],
} ],
]
hotplug
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
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-deve
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
---
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/config/miscutils/Config.in
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] busybo
Signed-off-by: Mark Mentovai
---
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/config/miscutils/Config.in
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
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
diff --git a/package/utils/busybox/config/coreutils/Config.in
b/package/utils/busybox/config/coreutils/Config.in
index f50823f012de..e25da6519f2b 100644
---
ly, all of OpenWrt’s busybox Config.in files need
to be updated in this way after a Busybox update.
Signed-off-by: Mark Mentovai
diff --git a/package/utils/busybox/config/coreutils/Config.in
b/package/utils/busybox/config/coreutils/Config.in
index f50823f012de..e25da6519f2b 100644
--- a/package/uti
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
https
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
ctx->savedi
deca1064 wrote:
> This patch adds platform machine support for the Netgear WNDR3700v4.
> Signed-off-by: Ralph Perlich
The WNDR3700v4 and WNDR4300 are almost identical, so much so that
nearly everything you’ve added here duplicates the definitions that
already exist for WNDR4300. I think it would
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
> com
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
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt
Weedy wrote:
> On 16 Dec 2013 12:54, "Mark Mentovai" wrote:
>>
>> Is this a new change with the ongoing netifd or procd work? In the new
>> procd/netifd world, is there a better way to start services that depend on
>> specific network interfaces?
>
&g
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 whe
s the problem. This seems to be how compound conditions are generally
handled in OpenWrt Makefiles.
Signed-off-by: Mark Mentovai
---
Index: feeds/packages/net/nginx/Makefile
===
--- feeds/packages/net/nginx/Makefile (revision
This works perfectly. Thanks, jow.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
k 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
---
Index:
target/linux/ar71xx/patches-3.8/910-phy-add-phy_suspend-r
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
https://lists.openwrt.org/mailman/listinfo/ope
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 addres
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
address.
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 refused
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
>
> Applied in r34495, thanks Mark!
Thanks, Florian. They’re up to 1.2.5 now, so I’ve moved on to using
Weedy 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 world'
nv "action=${1}" hotplug-call dhcpc
+
exit 0
Index: package/ifplugd_support/Makefile
===
--- package/ifplugd_support/Makefile(revision 0)
+++ package/ifplugd_support/Makefile(revision 0)
@@ -0,0 +1,54 @@
+include $(TOPDI
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:
>
>
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
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
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 cab
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
>
> after not reading the 100 mails leading up to this
This allows additional files in /etc/nginx/, such as SSL certificates,
tobe saved on sysupgrade.
Signed-off-by: Mark Mentovai
---
Index:
packages/net/nginx/Makefile
===
--- packages/net/nginx/Makefile (revision 33213
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
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 s
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?
_
Signed-off-by: Mark Mentovai
---
Index: packages/net/nginx/Makefile
===
--- packages/net/nginx/Makefile (revision 33213)
+++ packages/net/nginx/Makefile (working copy)
@@ -103,6 +103,8 @@
$(INSTALL_DATA) $(addprefix
Changelog: http://nginx.org/en/CHANGES-1.2
Signed-off-by: Mark Mentovai
---
Index: packages/net/nginx/Makefile
===
--- packages/net/nginx/Makefile (revision 33213)
+++ packages/net/nginx/Makefile (working copy)
@@ -8,12 +8,12
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!
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
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 recen
f ff ff ff ff ff ff ff ff ff ff ff |P...|
> 0080 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ||
>
> 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 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 doin
er it, it should have
> the sticky bit set.
>
> Signed-off-by: Mark Mentovai
>
> ---
>
> Index: include/image.mk
> ===
> --- include/image.mk (revision 31782)
> +++ include/image.mk (working copy)
&
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
---
Index: include/ima
image.
Signed-off-by: Mark Mentovai
---
Index: include/image.mk
===
--- include/image.mk(revision 31782)
+++ include/image.mk(working copy)
@@ -142,7 +142,7 @@
define Image/mkfs/prepare/default
# Use symbolic permis
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
openwrt-devel@lists.o
d, it is obsolete and should be removed from the dnsmasq package.
Signed-off-by: Mark Mentovai
---
Index: package/dnsmasq/Makefile
===
--- package/dnsmasq/Makefile(revision 31782)
+++ package/dnsmasq/Makefile(working
"search_domain" boolean option.
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-b
asq" section of
/etc/config/dhcp can be used. The default is on, producing the current
behavior. Setting it to off prevents this automatic mapping from being
inserted into the dnsmasq configuration.
Signed-off-by: Mark Mentovai
Index: package/d
required when using "fqdn".
Local hostnames will remain available for lookup using fully-qualified names.
Signed-off-by: Mark Mentovai
Index: package/dnsmasq/files/dnsmasq.init
===
--- package/dnsmasq/files/dnsmasq.init (
dhcp_options that should apply globally in
the "config dnsmasq" section of /etc/config/dhcp. dhcp_option is a list option.
Signed-off-by: Mark Mentovai
Index: package/dnsmasq/files/dnsmasq.init
===
--- package/dnsmasq/files/dn
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
---
Index: packages/net/nginx/Makefile
===
--- packages/net/nginx/Makefile (revision
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
---
Index: packages/net/nginx/Makefile
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 interfac
I've tested the WNDRMACv2 image. I don't have a v1 WNDRMAC, but assume
that this is sufficient to build a fully-functional image.
Subsequently, I'd like to restructure image generation for the WNDR3700
family, so that sysupgrade images are shared using symbolic links among
al
I concur that there's something wrong with "mtd -j 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 the
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: Mar
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
---
Index: target/linux/ar71xx/base-files/lib/ar71xx.sh
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 architec
Jonathan McCrohan wrote:
> Would you mind having another look at this patch as a priority, as it
> causes images larger than 8MB to FTBFS.
>
> While this obviously is not a problem for the WNDR3700, it is a problem
> for the WNDR3700v2 and WNDR3800, both of which have 16MB of flash.
>
> Attached is
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 pa
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.
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 WNDR3700
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
>
> Applied, thanks!
I don't think this patch is a great idea. There are no differences
between t
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
icket/8781.
Signed-off-by: Mark Mentovai
---
Index: target/linux/ar71xx/image/Makefile
===
--- target/linux/ar71xx/image/Makefile (revision 27926)
+++ target/linux/ar71xx/image/Makefile (working copy)
@@ -42,13 +42,13 @@
d
.05-0
Signed-off-by: Mark Mentovai
--
Index: toolchain/gcc/patches/linaro/860-fix_extension_elimination.patch
===
--- toolchain/gcc/patches/linaro/860-fix_extension_elimination.patch
(revision 27096)
+++ toolchain/gcc/patches/linar
toolchain/gcc: upgrade Linaro GCC to 4.5-2011.05-0
Signed-off-by: Mark Mentovai
linaro_4.5-2011.05-0.patch
Description: Binary data
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt
s NETGEAR
continues to produce distinct -NA and worldwide images, neither of
which are tagged with hd_id.
Signed-off-by: Mark Mentovai
wndr3700v2_images.patch
Description: Binary data
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
htt
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
is resolves the discrepancy between the two places that
ieee80211d could be set.
Signed-off-by: Mark Mentovai
ieee80211d.patch
Description: Binary data
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
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 hosta
r26765 adds the ieee80211d hostapd option from mac80211.sh when a
country code is configured. However, hostapd.sh already adds the
ieee80211d hostapd option when the ieee80211d UCI parameter is set.
https://dev.openwrt.org/changeset/26765
https://dev.openwrt.org/browser/trunk/package/hostapd/files
when the resultant executable is
severely hamstrung.
Signed-off-by: Mark Mentovai
---
Index: package/dropbear/patches/120-openwrt_options.patch
===
--- package/dropbear/patches/120-openwrt_options.patch (revision 25918)
+++ pa
(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: Mar
ff-by: Mark Mentovai
---
Index: toolchain/gcc/patches/linaro/860-fix_extension_elimination.patch
===
--- toolchain/gcc/patches/linaro/860-fix_extension_elimination.patch
(revision 0)
+++ toolchain/gcc/patches/linar
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
---
Index: toolchain/gcc/patches/linar
1 - 100 of 127 matches
Mail list logo