Looks like there was some code loss when the driver came from an earlier kernel
series. Without this, my MT7621 board starts its GPIO offsets at 416 (why that
number, I don't know):
--- a/drivers/gpio/gpio-mt7621.c2022-10-18 15:03:42.596454871 -0400
+++ b/drivers/gpio/gpio-mt7621.c202
On 10/18/22 15:55, Martin Blumenstingl wrote:
Hello Peter,
On Tue, Oct 18, 2022 at 9:34 PM Peter Naulls wrote:
Looks like there was some code loss when the driver came from an earlier kernel
series. Without this, my MT7621 board starts its GPIO offsets at 416 (why that
number, I don't
On 10/18/22 17:10, Lukas Zeller wrote:
.
Just not any more - the mt7621 had this too. I currently patch it back into
22.03's gpio-mt7621.c for my builds and set base in the DTS, see [3]
I can follow the rationale to get rid of legacy GPIOs, but in the context
of experimenting platforms, where G
On 10/19/22 05:51, Lukas Zeller wrote:
Hi,
Lukas, thanks for this. I've read through everything and I agree with your
concerns. I'll note also that Linus W's commentary is from 2018.
On 19 Oct 2022, at 08:55, Petr Štetiar wrote:
IMO there should be `ugpiod` daemon available over ubus, prob
Yes, I know. Bear with me. Laugh if you must.
# ls -l /rom/
...
drwxr-xr-x4 root root98 Oct 20 13:53 www
I'd like to remove the writable bits from the squashfs image - /www is
particular concern because of security paranoia.
Now I realize that:
1. This is contrary to th
Apologies for the obtuseness of the previous email about the squashfs
permissions - that's related to the following, but a different topic. I can now
say that we're undergoing a security review for our system which is very much
based upon OpenWrt 22.03.
If you have ever done this, you'll pro
This is of course from ca-certificates 20211016
$ openssl x509 -enddate -noout -in
build_dir/target-mipsel_24kc_musl/root-ramips/etc/ssl/certs/Cybertrust_Global_Root.crt
notAfter=Dec 15 08:00:00 2021 GMT
$ openssl x509 -enddate -noout -in
build_dir/target-mipsel_24kc_musl/root-ramips/etc/s
I don't know if this is intentional, or some side effect of my build setup, but
the OpenWrt 22.03 libstdc++ library has some build strings in it.
$ strings
build_dir/target-mipsel_24kc_musl/root-ramips/usr/lib/libstdc++.so.6.0.29 | grep
home
... /gcc-11.2.0/libstdc++-v3/src/c++11/debug.cc
On 10/23/22 23:35, Phillip Lougher wrote:
On Thu, Oct 20, 2022 at 6:01 PM Peter Naulls wrote:
What you probably want is the following
% mksquashfs test test.sqsh -action "chmod(ugo-w)@perm(/ugo+w)"
It is, fantastic, thank you.
I added to include/image.mk:
--- a/include/imag
On 10/24/22 18:21, Hauke Mehrtens wrote:
Hauke, thanks for replying!
I also prefer if the CVE number is named in the patch. If this is missing
somewhere you could send a patch or pull request to rename the patch.
I'm afraid I don't have any explicit examples, but I'll let you know if
find a
The default uhttpd configuration has this:
# HTTP listen addresses, multiple allowed
list listen_http0.0.0.0:80
list listen_http[::]:80
Now, I know there's lots of practical reasons for this to be the case,
and I know also that the firewall setup in OpenWrt is r
On 10/25/22 14:53, Luiz Angelo Daros de Luca wrote:
is much easier to let the firewall zones deal with that.
As aside, they don't see the iptables tool in the system, and don't
understand that that's been deprecated (although I since did add it
for some unrelated legacy usage), and think there'
On 10/25/22 16:40, Karl Palsson wrote:
Peter Naulls wrote:
If they see what they want to see, then why should anyone else
get involved in their wish fulfilment?
Security review is fine, security should not be entertained, and
certainly foisted on other people?
Karl, not sure where you&#x
On 10/25/22 17:25, Reuben Dowle wrote:
I have myself gone through the process of getting an openwrt based product
through a security audit.
The issue of HTTP listening on all interfaces also came up in my audit, but the
auditors were happy with the explanation that the firewall prevented a
On 10/25/22 17:45, Michael Richardson wrote:
So, it needs to bound to *all* the IPv6 "LAN" IPs.
That means:
a) the ULA that is created.
b) the LL-IPv6 that are always present
c) the GUA IPv6 that is delegated
Sorry, I badly paraphrased. The requested change was for IPv4 only. I
don'
Lua 5.1.5 would appear to have CVEs below against it.
The patches to this in OpenWrt are significant, but dated, with the
last bug fix seeming to be from 2019, so it's hard to say if
these are addressed:
https://github.com/openwrt/openwrt/tree/openwrt-22.03/package/utils/lua/patches
https://
On 10/25/22 20:45, Reuben Dowle wrote:
My opinion is that openwrt should try and move to a newer version of lua. This
old 5.1.5 version appears to be unmaintained, and there does not seem to be the
resources within the openwrt community to change that.
So I naively adjusted the lua5.3 packa
On 10/25/22 18:20, openwrt-devel-requ...@lists.openwrt.org wrote:
From: Nathan Lutchansky
My hands are tied, we gotta do the dance.
I mean this as gently as possible, but I think what a lot of us are
missing is the benefit to the OpenWrt project to carry an increased
maintenance burden in
https://nvd.nist.gov/vuln/detail/CVE-2021-46848
Against openwrt-22.03
--- /dev/null
+++ b/libs/libtasn1/patches/099-CVE-2020-15888.patch
@@ -0,0 +1,11 @@
+--- a/lib/int.h2022-11-03 10:15:01.065656767 -0400
b/lib/int.h2022-11-03 10:15:39.333658083 -0400
+@@ -97,7 +97,7 @@
+
Another one from our security scan:
File: /usr/sbin/px5g
Issue: RET NOT ASSIGNED in function 'FUN_000281b0' at address 0x281c0 while
calling 'mbedtls_rsa_check_pub_priv'
Issue: RET NOT ASSIGNED in function 'FUN_000285e8' at address 0x285f8 while
calling 'mbedtls_ecp_check_pub_priv'
I'm not
On 11/3/22 12:01, Etienne Champetier wrote:
Hi Peter,
Can you resend this as a proper patch ready to be applied ?
Or as a PR on Github if this is easier for you ?
Sorry, retry. I wasn't 100% sure of the filename setup for submitted
patches. I've got a couple more to come.
As per:
https://nv
On 11/3/22 14:49, Peter Naulls wrote:
Another one from our security scan:
File: /usr/sbin/px5g
Issue: RET NOT ASSIGNED in function 'FUN_000281b0' at address 0x281c0 while
calling 'mbedtls_rsa_check_pub_priv'
Issue: RET NOT ASSIGNED in function 'FUN_000285e8' at
The 2.4.9 version of expat in OpenWrt 22.03 contains the following CVEs:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-43680
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-40674
Suggest either update to 2.5.0 (as per master) or application of the upstream
patches, etc:
ht
I needed to add this in my build:
diff --git a/package/boot/uboot-mediatek/Makefile
b/package/boot/uboot-mediatek/Makefile
index 9d823ec698..ac8e5dd0f3 100644
--- a/package/boot/uboot-mediatek/Makefile
+++ b/package/boot/uboot-mediatek/Makefile
@@ -3,7 +3,7 @@ include $(INCLUDE_DIR)/kernel.mk
On 11/17/22 14:33, Petr Štetiar wrote:
Daniel Golle [2022-11-17 17:01:43]:
Hi,
Add swig/host to build dependencies.
this doesn't looks like a cleanup as commit subject suggests, but rather
contrary :-)
Thanks all in any case for looking at this. We have a possible need to modify
our vendo
Our vendor has put calibration data into flash for the onboard WiFi. They've
made some changes which I have to their supplied 4.14.131 driver to read from
the "factory" flash partition to read calibration data.
As per my previous post on u-boot, getting exact details out of them
has proved tric
This backports the upstream label feature in block2mtd to the 5.10.x kernel in
22.03:
https://github.com/torvalds/linux/blob/master/drivers/mtd/devices/block2mtd.c
--- a/drivers/mtd/devices/block2mtd.c 2022-11-29 07:35:32.382695321 -0500
+++ b/drivers/mtd/devices/block2mtd.c 2022-11-29 08:0
On 11/29/22 10:32, Daniel Golle wrote:
On Tue, Nov 29, 2022 at 10:23:48AM -0500, Peter Naulls wrote:
This backports the upstream label feature in block2mtd to the 5.10.x kernel
in 22.03:
https://github.com/torvalds/linux/blob/master/drivers/mtd/devices/block2mtd.c
Where are we using
On 11/29/22 11:50, Daniel Golle wrote:
There is nothing wrong with that use-case, and it can even be
interesting for other downstream users. Encrypted rootfs_data is
generally a good idea, especially when rootfs_data is used to store
private key material (think: VPN keys) or other kind of crede
On 11/29/22 12:37, Daniel Golle wrote:
I thought you are on a device with actual block storage.
For your case I also can't come up with anything better which works
out-of-the-box for NOR flash. Supporting fscrypt in JFFS2 would be more
elegant, but that's a bit more demanding than just using wh
In 22.03, px5-mbedtls isn't bothering to check if the output was opened:
--- a/package/utils/px5g-mbedtls/px5g-mbedtls.c
+++ b/package/utils/px5g-mbedtls/px5g-mbedtls.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
@@ -70,6 +71,11 @@ static void write_fil
I've been experimenting with making the overlay encrypted as part of our
security requirements.
There are a couple of things needed to make this work - first, cryptsetup and
other kernel modules need to be brought in. This also needs the upstream kernel
patch to block2mtd that I posted last we
Some background. I have two versions of OpenWrt code:
One is legacy version based upon a mismash of versions, but is approximately
luci code from mid-2021. The webserver is http only. I'm able to change this
code for bug fixes, but don't want to pull in anything too large.
The other is bas
On 12/22/22 13:50, Oscar Hjelm wrote:
I’m not familiar with the luci interface, but to help you get started:
- One workaround would be to use a different cookie name on the new secure
cookies (or a new name on the older cookies, if that is preferred). The two
cookies could co-exist.
Yes, th
I see this warning in Firefox (OpenWrt 22.03):
Loading mixed (insecure) display content
“http://192.168.113.1/luci-static/resources/icons/loading.gif?0.046104145623280135”
on a secure page
This happens when the sysupgrade dialog is processing on an https luci. It
doesn't cause any real har
On 12/22/22 15:56, Peter Naulls wrote:
On 12/22/22 13:50, Oscar Hjelm wrote:
I’m not familiar with the luci interface, but to help you get started:
- One workaround would be to use a different cookie name on the new secure
cookies (or a new name on the older cookies, if that is preferred
On 12/30/22 15:42, Jo-Philipp Wich wrote:
Hi,
[...]
I renamed the new cookies to "http-sysauth" and "https-sysauth", to work
around this and it seems to do the right thing. But there is still a fault
here.
Already fixed with
https://github.com/jow-/lucihttp/commit/6e68a1065f3ed1889e5fa053b
I posted previously on GPIOs, which caused some debate; this may or may not
be relevant, but I'd be remiss to not mention it:
http://lists.openwrt.org/pipermail/openwrt-devel/2022-October/039593.html
I've been chasing an issue with GPIO mapping in for an mt7621 on the OpenWrt
5.10.161 etc ker
On 1/22/23 13:58, Daniel Santos wrote:
[snip]
Thanks Daniel and all the others (to many to mention). Yes, I should have read
the datasheet much earlier, so in the end I really have only myself to blame.
The fix was simply to add back in the "rgmii2" group back into the gpio group.
I beli
ed
as debug.
Signed-off-by: Peter Naulls
---
--- a/src/odhcpd.c 2023-01-24 13:29:56.080616097 -0500
+++ b/src/odhcpd.c 2023-01-24 13:30:19.284692423 -0500
@@ -207,7 +207,7 @@
ssize_t sent = sendmsg(socket, &msg, MSG_DONTWAIT);
if (sent < 0)
- syslog(LOG_ERR, "Failed to send
On 1/24/23 14:48, Nick wrote:
Hey,
We have testing-support for 5.15 in almost all targets, so we may be able to
release it shortly [0]? WIP 6.1 support is already underway in OpenWrt [1]. We
are using GCC 12 as our default compiler version[2]. Binutils has been updated
to version 2.40. Could w
This is elfutils-0.188 in master. No doubt I'm using a bad toolchain combo - I
brought the config over from my 22.03 build:
CONFIG_GCC_VERSION="11.3.0"
CONFIG_BINUTILS_VERSION_2_38=y
configure:3994: mipsel-openwrt-linux-musl-gcc -Os -pipe -mno-branch-likely
-mips32r2 -mtune=24kc -fno-caller
get right first.
Signed-off-by: Peter Naulls
diff --git a/target/linux/ramips/dts/mt7621_atel-ei.dts b/target/linux/ramips/dts/mt7621_atel-ei.dts
new file mode 100755
index 00..2dcbd7b932
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_atel-ei.dts
@@ -0,0 +1,177 @@
+/dts-v1/;
+
+#inclu
On 2/7/23 18:35, Eric Montellese wrote:
Hello all,
As I'm sure those on this list are aware, OpenWrt is used extensively in the
commercial router world.
That would be an understatement, we do for one.
At NETGEAR, I am working to find a satisfactory solution to an annoying little
corporate
This is the boot on the vendor legacy code - OpenWrt 18.06ish, with kernel
4.14.131, with probably a bunch of their customizations, but:
[9.398860] [NAND]select ecc bit:12, sparesize :112 spare_per_sector=28
[9.412077] nand: device found, Manufacturer ID: 0xc2, Chip ID: 0xf1
[9.42
On 2/10/23 22:41, Chuanhong Guo wrote:
Hi!
16.163318] 8 fixed-partitions partitions found on MTD device mt7621-nand
From the datasheet here:
https://www.mxic.com.tw/Lists/Datasheet/Attachments/8858/MX30LF1G28AD,%203V,%201Gb,%20v1.3.pdf
The MX30LF1G28AD actually have 2K+128 flash layout, so i
On 2/11/23 08:10, Chuanhong Guo wrote:
Hi!
# nanddump -a /dev/mtd2
ECC failed: 8
ECC corrected: 0
Number of bad blocks: 0
Number of bbt blocks: 0
Block size 131072, page size 2048, OOB size 128
Dumping data starting at 0x and ending at 0x0004...
libmtd: error!: MEMGETBADBLOCK ioc
On 2/13/23 15:01, Peter Naulls wrote:
ich might be the misreporting.
In our driver, it comes out as:
[ 16.091826] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB
size: 128
[ 16.107083] mt7621-nand 1e003000.nand: ECC strength adjusted to 12 bits
I tried adjusting in
I'm trying to track yet another vendor vs current OpenWrt driver mishandling.
In my vendor kernel:
[2.243263] i2c-mt7621 1e000900.i2c: clock 100KHz, re-start not support
Which is this driver:
* drivers/i2c/busses/i2c-mt7621.c
*
* Copyright (C) 2013 Steven Liu
* Copyright (C) 2016 Micha
On 2/15/23 13:31, Peter Naulls wrote:
I'm trying to track yet another vendor vs current OpenWrt driver mishandling.
x00
In particular, for the first read attempt, the value is always the first
value sent as part of the last write. i.e, 3 in this case. After, that,
it's always 0 (t
On 2/16/23 13:59, Jan Breuer wrote:
On 16. 2. 2023 16:21, Peter Naulls wrote:
On 2/15/23 13:31, Peter Naulls wrote:
I'm trying to track yet another vendor vs current OpenWrt driver mishandling.
x00
Can you please provide info about the exact SoC and hardware you are using?
H
On 2/16/23 17:17, Alexander Papazoglou wrote:
My first guess would be that your microcontroller code doesn't handle repeated
starts properly. All of the i2ctransfer commands you've shown involve at least
one repeated start with the new driver but perhaps not with the old one. To
verify, you ca
On 2/15/23 10:17, Chuanhong Guo wrote:
Hi!
What to try next, thanks!
It looks like the detected spare size and ECC strength matches between the
two drivers, according to the u-boot message and kernel log.
Maybe you can try dumping the nand controller setup registers and compare
the registe
Due to some missing flash values, I need to do a later user space lookup for
possible missing values stored "elsewhere" to fix up the MAC address.
According to:
https://openwrt.org/docs/guide-user/base-system/basic-networking
Something like this should work:
config device
option n
On 2/22/23 15:34, Robert Marko wrote:
option 'lan1'
option macaddr 34:BA:9A:CC:DD:EE
This should work as long as its in single quotes.
I corrected the quotes, but no joy.
Also, cant you fixup the MAC in 02_networking or in preinit?
Yes, I have a preinit script, but it
On 2/23/23 01:43, Rafał Miłecki wrote:
On 22.02.2023 21:02, Peter Naulls wrote:
config device
option 'lan1'
This line is clearly wrong. See how you specify device name in above section.
Perhaps it is "clear" but there's much in OpenWrt that isn'
On 2/20/23 09:48, Peter Naulls wrote:
On 2/16/23 17:17, Alexander Papazoglou wrote:
My first guess would be that your microcontroller code doesn't handle repeated
starts properly. All of the i2ctransfer commands you've shown involve at least
one repeated start with the new driver b
On 2/27/23 17:23, Hauke Mehrtens wrote:
Build firmware images for Ralink MT7621 based boards.
This will add uboot-envtools to all devices. uboot-envtools is not included in
all DEVICE_PACKAGES now, should we explicitly remove it from device definitions
which do not had it before?
The D
On 2/28/23 06:46, Bjørn Mork wrote:
Peter Naulls writes:
On 2/27/23 17:23, Hauke Mehrtens wrote:
This will add uboot-envtools to all devices. uboot-envtools is not
included in all DEVICE_PACKAGES now, should we explicitly remove it
from device definitions which do not had it before?
The
On 2/28/23 09:07, Felix Baumann wrote:
one issue I see here is that there are MT7621 devices like the Asus RT-AX53U
that don't save their environment to their u-boot-env partition by default.
You still need to execute saveenv while connected via serial.
Note: the device doesn't have a u-boot-en
On 2/21/23 11:02, Peter Naulls wrote:
On 2/15/23 10:17, Chuanhong Guo wrote:
Hi!
What to try next, thanks!
It looks like the detected spare size and ECC strength matches between the
two drivers, according to the u-boot message and kernel log.
Maybe you can try dumping the nand controller
For those of you who track the small but very real OpenWrt job market, you may
have seen there's a creep into Defense/Clearance jobs. Here's but one example:
https://careers-bluehalo.icims.com/jobs/3844/job
As a self-declared pacifist (and anyway, dual citizen which would limit my
ability to
On 5/1/23 16:42, Dave Taht wrote:
How a ragtag bunch of unincorporated (mostly?) peacenik hippie types
can co-exist with devices being built by militaries out of this stuff
I have few ideas. I prefer to shrink the world, and produce stable,
secure, software, for everyone that wants it, but I lo
On 5/2/23 07:26, Enrico Mioso wrote:
On Mon, May 01, 2023 at 04:56:36PM -0400, Peter Naulls wrote:
On 5/1/23 16:42, Dave Taht wrote:
one of the constraints OpenWrt has been placed under, historically, is the need
to fit in small flash memoris, so fitting some libraries and infrastructure
On 5/2/23 09:31, Enrico Mioso wrote:
On Tue, May 02, 2023 at 09:24:52AM -0400, Peter Naulls wrote:
On 5/2/23 07:26, Enrico Mioso wrote:
Another impression I have, is that the OpenWrt project is very important for
many yet under-resourced.
There are some important tasks that would help
On 5/7/23 13:19, Hauke Mehrtens wrote:
I check from time to time which companies in the US are looking for OpenWrt
experts [0] to get an overview who is using it. About 10% to 30% of these job
offers require clearance. It looks like the US military and US intelligence
community is using Open
I'm trying to track down a problem whereby using Windows VPN, some websites are
accessible and some aren't. The problem is 100% OpenWrt, since it works over
my regular WiFi router.
Here's what I know (or think I know):
All the VPN traffic uses UDP port 4500. This is (or should be) a pretty
On 5/30/23 18:16, Yousong Zhou wrote:
On Wednesday, 31 May 2023, Peter Naulls wrote:
]
I am afraid the above is still single direction traffic.
Sorry, quite so. I finished this email in the middle of something else. There
is return traffic:
To Google, which works.
16:57:11.936911
On 5/30/23 21:09, Yousong Zhou wrote:
On Wed, 31 May 2023 at 06:38, Peter Naulls wrote:
Is it that your dns traffic is not going through the tunnel? curl
-vvv should reveal the IP address it tries to connect. One
possibility is that maybe the resolv result does not work.
Yes, a DNS
On 5/31/23 10:20, Peter Naulls wrote:
On 5/30/23 21:09, Yousong Zhou wrote:
On Wed, 31 May 2023 at 06:38, Peter Naulls wrote:
Thanks for you patience, more:
I ran the connection instead over a wired WAN connection instead of the cell
WWAN link, and the problem is the same. This points
On 5/31/23 21:08, Yousong Zhou wrote:
Not that I got any clue, but this looks very suspicious that you saw
the supposed-to-go-through-tunnel packet at an intermediate router
(the openwrt device).
I don't know exactly what happened here, but I didn't see it again.
In any case, it turns out th
On 07/27/2012 04:00 PM, LEO Airwarosu Yoichi Shinoda wrote:
Folks,
Please ignore this particular (additional) patch.
I've started to learn how uci-defaults work.
Also, and unless I've missed some very recent patch, we're still sans
full support of all the LEDs on the AG300N. Anyone want to
On 07/27/2012 07:35 PM, LEO Airwarosu Yoichi Shinoda wrote:
On 2012/07/28, at 8:04, Peter Naulls wrote:
On 07/27/2012 04:00 PM, LEO Airwarosu Yoichi Shinoda wrote:
Folks,
Please ignore this particular (additional) patch.
I've started to learn how uci-defaults work.
Also, and u
On 07/30/2012 09:51 PM, LEO Airwarosu Yoichi Shinoda wrote:
Peter and folks,
I believe Peter meant WZR-HP-AG300H.
Last night, I did some research on behaviors of leds on WZR-HP-AG300H,
and located controls for all remaining leds on wmacs.
Awesome, seems to work fine. Thanks.
__
On 07/31/2012 11:45 PM, LEO Airwarosu Yoichi Shinoda wrote:
The problem of wmac based leds on WZR-HP-AG300H stimulated
some research on status of led support on other buffalo
units with wmac based leds.
The following results and observations are based on the
trunk revision r32910.
COMMON
- Wmac
On 08/01/2012 09:03 PM, LEO Airwarosu Yoichi Shinoda wrote:
On 2012/08/01, at 22:39, Peter Naulls wrote:
The problem here is that the LED handling is done in the wrong
order. I submitted a fix/patch(?) for this months ago, but
it seems to have been ignored or lost. I can dig it out
again
This is not strictly on topic for this list, so I'll keep this pretty short.
I'm after a developer to work in the Bay Area on OpenWrt stuff. You should
be a junior/mid level developer willing to learn new skills but who knows
the basics of embedded development. We do lots of other stuff, but t
On 02/11/2013 12:04 PM, Aleksander Morgado wrote:
Hey,
I'm trying to prepare an update of udev/libudev to latest upstream. As
you may already know, udev/libudev sources are now within systemd. I'm
not fully sure how to handle this issue; so I'm hoping to get some
advice here. Comments welcome!
I've been bugging a lot of people about this, with hopes to get my patches in,
so I apologize to those long-suffering on IRC.
The quick version:
glibc 2.13 (with my patches) works and I have tested it extensively (within the
confines of my work) on a71xx, ramips and kirkwood. None of the old v
Is anyone else seeing lockups on WZR-HP-G300NH flash?
I have an sqlite3 database that I am accessing, but it causes the file system to
eventually get "stuck". This is typically for example a "find /overlay"
stopping before getting to the file in question, and requiring a ctrl-C.
On reboot, th
On 08/13/2011 02:45 PM, Peter Naulls wrote:
So, I don't have much to go on. Suggestions on how to resolve
this welcome.
From echo t > /proc/sysrq-trigger
(functions copied manually from System.map, sorry for any errors)
rsync R running 0 2760 2759 0x001000
On 08/13/2011 05:31 PM, Peter Naulls wrote:
On 08/13/2011 02:45 PM, Peter Naulls wrote:
So, I don't have much to go on. Suggestions on how to resolve
this welcome.
From echo t > /proc/sysrq-trigger
(functions copied manually from System.map, sorry for any errors)
And from
On 08/13/2011 06:57 PM, Peter Naulls wrote:
On 08/13/2011 05:31 PM, Peter Naulls wrote:
On 08/13/2011 02:45 PM, Peter Naulls wrote:
So, I don't have much to go on. Suggestions on how to resolve
this welcome.
From echo t > /proc/sysrq-trigger
This appears to be a recurrence o
This adds the o11s cozybit authentication daemon fork of authsae (see o11s.org).
This requires forthcoming work on o11s in the
kernel/compat-wireless et al. but there are people interested in running
this under OpenWrt right now.
I have not added any init scripts, etc.
Signed-off-by: Peter
On 08/16/2011 02:28 PM, Felix Fietkau wrote:
On 2011-08-16 11:51 AM, Mark Deneen wrote:
Please let me know if there is anything which I have overlooked.
Looks mostly fine to me on a first quick look (aside from some whitespace vs tab
issues).
Before we accept this, I want to split out the mtd
On 08/30/2011 06:57 AM, Mark Deneen wrote:
On Tue, Aug 30, 2011 at 1:34 AM, LEO Airwarosu Yoichi Shinoda
wrote:
On 2011/08/30, at 6:13, Peter Naulls wrote:
I have an immediate need to support v1 and v2 hardware in one image. As
"products" they are essentially identical, as well
On 09/09/2011 08:42 AM, Manuel Munz wrote:
Hi
this patch fixes 3 things in the imagebuilder, one of them is literally big:
When running package_install the imagebuilder generates package list(s),
which are stored in $(TARGET_DIR)/usr/lib/opkg/lists/ and then copied
into the final image, which w
On 09/09/2011 10:02 AM, Manuel Munz wrote:
> But why is CLEAN_IPKG not
> selected by default? And can we have a backport of this to backfire?
Why should it be? If you want it on, select it. It's the same option
from menuconfig.
Thats not an option for me. I build the most generic profile and
Some of this is speculation. I wish I had more precise details. This is true
of all trunk versions in last few weeks, when I started using my G300H (v2)
as an AP. This includes upto version r28254, which includes yesterday's
mac80211 patches, but not today's spam fixes.
I have two Linux machin
On 09/16/2011 11:26 AM, Peter Naulls wrote:
* In one case where I saw it triggered, I restarted hostapd, and it seemed to
come back, although NetworkManager on Ubuntu become confused, so I'm
not certain.
* There is nothing of consequence in kernel logs, apart from regular messages
On 09/16/2011 12:53 PM, Jim Henderson wrote:
On Fri, 16 Sep 2011 15:08:15 -0400, Mark Deneen wrote:
In the end, I ended up reverting to build 27572, which I knew worked
prior to the upgrade.
I reverted the mac80211 package only to 27572 earlier today, and it seems to now
be working correctly.
On 09/17/2011 12:28 AM, Felix Fietkau wrote:
On 2011-09-17 8:50 AM, Felix Fietkau wrote:
On 2011-09-17 1:54 AM, Peter Naulls wrote:
On 09/16/2011 12:53 PM, Jim Henderson wrote:
On Fri, 16 Sep 2011 15:08:15 -0400, Mark Deneen wrote:
In the end, I ended up reverting to build 27572, which I
These are taken from the Debian PHP patches. Thanks to jow and mhei for
suggestions. I tested this with my eglibc setup/zoneinfo files.
I think the comments in the patches describe the intent here.
Signed-off-by: Peter Naulls
Index: patches/102-debian_patches_use_embedded_timezonedb.patch
mount.cifs, or other words, the cifs kernel modules requires a number of pieces
which are missing from its dependency. I spent a lot of time chasing
this, and don't have the energy to chase it all up and make dependency
patches etc, however if someone else does, I can say that it requires the
fo
On 11/08/2011 02:15 PM, Michael Geddes wrote:
Hi,
The x86 build of Kontron compiles.. as I said, the 64bit endeavour was
abandoned. A couple of years ago it compiled, but didn't really work. The
reason it's still there is because I thought it might be useful for somebody
to continue what I sta
On 11/09/2011 08:42 AM, Mirko Vogt wrote:
On 11/09/2011 01:20 AM, Peter Naulls wrote:
On 11/08/2011 02:15 PM, Michael Geddes wrote:
I don't know about the target hardware in question or the 64-bit builds,
but for any hope of having glibc/eglibc builds work
Building with eglibc should
On 11/10/2011 05:59 AM, Ben Pfountz wrote:
I would like to see support in trunk as well. In the meantime I have been using
the patch Mark Deneen created, which adds support for everything except some of
the LEDs and switches, see his email and thread for more info...
https://lists.openwrt.org/pi
On 11/10/2011 08:13 AM, Mark Deneen wrote:
On Thu, Nov 10, 2011 at 9:42 AM, Peter Naulls wrote:
On 11/10/2011 05:59 AM, Ben Pfountz wrote:
I would like to see support in trunk as well. In the meantime I have been
using
the patch Mark Deneen created, which adds support for everything except
On 11/10/2011 08:21 AM, Peter Naulls wrote:
I'll test any such patches of course. As an additional note, we're
going to need the same thing on a300gh, since I'm getting one of those
in next few days. I'll submit any work on that here, even if it's
Now done. It&#
On 11/17/2011 12:37 AM, Matt Redfearn wrote:
That's great Peter, any ideas when you would be able to get the patches into
trunk?
Did you read my previous posts? Probably never. The developers have
expressed a desire to not combine images. Why? I remain unsure.
There's an argument to be ha
1 - 100 of 135 matches
Mail list logo
