Re: [LEDE-DEV] [PATCH] uhttpd: add manifest support
Thanks Jow It seems I get this problems when sending thru Outlook. Will have to stick to Thunderbird... > El 19/08/2017, a las 07:54, Jo-Philipp Wich escribió: > > Hi Adrian, > > the patch was whitespace mangled and thus not detected by patchwork. > > Applied manually in 3fd58e9. > > ~ Jo > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] uhttpd: add manifest support
@Jow any comments to get this merged?
Rgds
-Original Message-
From 1acb092818842553c1c1e4d0cfcf4ae8744b732b Mon Sep 17 00:00:00 2001
From: Adrian Panella
Date: Fri, 21 Jul 2017 14:17:36 -0500
Subject: [PATCH] uhttpd: add manifest support
Add "text/cache-manifest" mimetype support to enable the possibility of using
Application Cache.
Signed-off-by: Adrian Panella
---
mimetypes.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/mimetypes.h b/mimetypes.h
index 0651486..f7a3963 100644
---a/mimetypes.h
+++b/mimetypes.h
@@-87,6 +87,9 @@static const struct mimetype uh_mime_types[] = {
{ "pac","application/x-ns-proxy-autoconfig" },
{ "wpad.dat", "application/x-ns-proxy-autoconfig" },
+ { "appcache", "text/cache-manifest" },
+ { "manifest", "text/cache-manifest" },
+
{ NULL, NULL }
};
--
2.7.4
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] uhttpd: add manifest support
From 1acb092818842553c1c1e4d0cfcf4ae8744b732b Mon Sep 17 00:00:00 2001
From: Adrian Panella
Date: Fri, 21 Jul 2017 14:17:36 -0500
Subject: [PATCH] uhttpd: add manifest support
Add "text/cache-manifest" mimetype support to enable the possibility of
using Application Cache.
Signed-off-by: Adrian Panella
---
mimetypes.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/mimetypes.h b/mimetypes.h
index 0651486..f7a3963 100644
---a/mimetypes.h
+++b/mimetypes.h
@@-87,6 +87,9 @@static const struct mimetype uh_mime_types[] = {
{ "pac","application/x-ns-proxy-autoconfig" },
{ "wpad.dat", "application/x-ns-proxy-autoconfig" },
+ { "appcache", "text/cache-manifest" },
+ { "manifest", "text/cache-manifest" },
+
{ NULL, NULL }
};
--
2.7.4
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] Remerge logo ideas
Keeping the name after remerge but with a new logo, helps convey the notion that there has been a change. An modernizing the look is great +1 > El 29/05/2017, a las 12:32, Jamie Stuart escribió: > > Tried that Moritz - it just wouldn’t work unfortunately. Neither does adding > the antenna afterwards > > All - see another set of designs. I’ve opted for Roboto Condensed as the logo > typeface. > Personal favorite is the green as OpenWrt is targeted towards low-power > devices. > > http://imgur.com/a/TfWxr > > What’s the next step here? John - could this be added to the remerge proposal > v3? > > > >> On 29 May 2017, at 19:12, Moritz Warning wrote: >> >> Looks nice. >> >> random idea, merge antenna with O of OpenWrt? >> >>> On 05/29/2017 01:10 PM, Jamie Stuart wrote: >>> See another iteration, with: >>> >>> - correct capitalisation >>> - antenna to the side (will not work with lowercase ’n’) >>> - open sans typeface (open source) >>> - mockups of website header >>> - accent colours >>> >>> http://i.imgur.com/ZKtcFXo.png >>> >>> On 29 May 2017, at 13:52, John Crispin wrote: > On 29/05/17 12:11, Jamie Stuart wrote: > Hi, > First of all, I’m glad to hear the process of remerging LEDE with OpenWrt > is moving forward. > For what it’s worth, if prefer the LEDE name (it’s friendlier - ‘leddy’ - > and not tied to the name of an old router!) > > However, it seems the consensus is that the OpenWrt name should remain. I > thought that maybe we should take this opportunity to at least give the > project an updated look? > Maybe a new logo? I’m personally not one for mascots, so I had a quick go > at a few simple text-based designs: > > http://i.imgur.com/9zyXSYR.png > > What are you thoughts? > > Jamie, onebillion Hi, the correct spelling is OpenWrt with a capital O and W. could you add that to the proposal aswell please ? ideally with and without the antenna feature John > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev >>> >>> >>> ___ >>> Lede-dev mailing list >>> Lede-dev@lists.infradead.org >>> http://lists.infradead.org/mailman/listinfo/lede-dev >> >> >> ___ >> Lede-dev mailing list >> Lede-dev@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/lede-dev > > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Setting packages in Image building config
Hi, I'm a bit confused by the image building options. Can anyone explain what is the difference of setting necessary packages in: - DEFAULT_PACKAGES := in target's makefile - PACKAGES := in Profile/Default, inside image/makefile aren't both applied to all devices? If it were working, what can be specified in: - DEVICE_PACKAGES := in Device/, inside image/makefile I believe that all devices in a target shared the same kernel, so no packages that select anything at kernel level? I couldn't find much documentation on the topic of the new image building options. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] adding luci to snapshot images
Totally agree with the observation. +1 for including LuCI as default. -Original Message- From: Lede-dev [mailto:lede-dev-boun...@lists.infradead.org] On Behalf Of Jo-Philipp Wich Sent: miércoles, 29 de junio de 2016 09:54 a.m. To: lede-dev@lists.infradead.org Subject: Re: [LEDE-DEV] adding luci to snapshot images Hi, it would certainly help to bridge the gap until the #1 release and it would give more testing exposure to the ui... My observation on the matter is this: People who do *not* want to have the ui included are either building from source or using the IB anyway and those users *requiring* a ui tend to be unable to spin their own builds (no Linux os at hand, too hard, ...) So personally I'd lean toward adding LuCI to the snapshots but would await further feedback on it. ~ Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] ath10k-ct: Update to latest 10.4.3 CT firmware for 9980 chipsets.
Hi Ben, >-Original Message- >From: Ben Greear > >This works around regressions added in the 4.7 kernel. Tried it but still have the recurrent stack trace warning we had after the last compat-wireless update. This was the most "visible" regression we were experiencing we the updated ath10k drivers. Which other problems are you addressing? I'm not exactly sure, but it seems that the trace is now a little less frequent. This is an extract of the console log (from Linksys EA8500 router): [ 11.427882] ath10k_pci :01:00.0: firmware ver 10.4.3-ct-fW-007-41d8756 api 5 features peer-flow-ctrl crc32 5451981c . [ 936.407284] [ cut here ] [ 936.407406] WARNING: CPU: 0 PID: 0 at compat-wireless-2016-05-12/net/mac80211/rx.c:4068 ieee80211_rx_napi+0x8c/0x8a4 [mac80211]() [ 936.410974] Modules linked in: pppoe ppp_async iptable_nat pppox ppp_generic nf_nat_ipv4 nf_conntrack_ipv6 nf_conntrack_ipv4 ipt_REJECT ipt_MASQUERADE xt_time xt_tcpudp xt_tcpmss xt_statisth [ 936.557402] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GW 4.4.13 #2 [ 936.557754] Hardware name: Qualcomm (Flattened Device Tree) [ 936.564889] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 936.570270] [] (show_stack) from [] (dump_stack+0x88/0x9c) [ 936.578252] [] (dump_stack) from [] (warn_slowpath_common+0x94/0xb0) [ 936.585282] [] (warn_slowpath_common) from [] (warn_slowpath_null+0x1c/0x24) [ 936.593565] [] (warn_slowpath_null) from [] (ieee80211_rx_napi+0x8c/0x8a4 [mac80211]) [ 936.602400] [] (ieee80211_rx_napi [mac80211]) from [] (ath10k_htt_t2h_msg_handler+0x930/0x98c [ath10k_core]) [ 936.611811] [] (ath10k_htt_t2h_msg_handler [ath10k_core]) from [] (ath10k_htt_txrx_compl_task+0x9bc/0x115c [ath10k_core]) [ 936.623422] [] (ath10k_htt_txrx_compl_task [ath10k_core]) from [] (tasklet_action+0xb8/0x144) [ 936.635978] [] (tasklet_action) from [] (__do_softirq+0xe0/0x21c) [ 936.646216] [] (__do_softirq) from [] (irq_exit+0x98/0xec) [ 936.654033] [] (irq_exit) from [] (__handle_domain_irq+0xbc/0xe4) [ 936.661149] [] (__handle_domain_irq) from [] (gic_handle_irq+0x54/0x94) [ 936.669048] [] (gic_handle_irq) from [] (__irq_svc+0x54/0x90) [ 936.677200] Exception stack(0xc0775f50 to 0xc0775f98) [ 936.684840] 5f40: 0001 c020b4a0 [ 936.689884] 5f60: c0774000 c0776480 c0682740 c07702e4 c0775fa8 c0776488 [ 936.698041] 5f80: c0776140 c0775fa0 c0219d54 c0219d58 6013 [ 936.706195] [] (__irq_svc) from [] (arch_cpu_idle+0x34/0x50) [ 936.712623] [] (arch_cpu_idle) from [] (cpu_startup_entry+0x178/0x24c) [ 936.720266] [] (cpu_startup_entry) from [] (start_kernel+0x434/0x440) [ 936.728400] ---[ end trace d771ca9672150ac3 ]--- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Linksys ea8500 switch configuration
> El 18/06/2016, a las 12:51 p.m., Josh Bendavid > escribió: > > Ok. If the configuration I am suspecting for the stock firmware is > correct, then port 6 is unused and it shouldn't matter how it's > configured. > > Actually it's possible that some of this is anyways dynamically > configurable through the switch registers. (ie even if the stock > firmware has the eth1 connected directly to the WAN phy as I suspect, > it might still be possible/preferable to configure the switch so that > it is more like AP148 with gmacX (eth1) -> rgmii -> switch port 6 Is there any way I can dump all registers from the switch? I could flash back stock FW and see how it is set up. > > Actually I don't think gmac2 even supports rgmii, so if both ethernet > interfaces are connected to the switch chip/PHY's with rgmii then they > would have to be gmac0 and gmac1... ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Linksys ea8500 switch configuration
> El 18/06/2016, a las 5:38 a.m., Josh Bendavid > escribió: > > Hi Adrian, > Thinking a bit more about the discussion we were having in > https://github.com/lede-project/source/pull/6 about the ethernet and > switch configuration on the ea8500. Thanks for your help on this! > > Given that the stock firmware apparently doesn't enable VLAN on the > switch, I suspect that this router actually has a different > configuration than AP148. > > AP148: gmac1 (eth0) -> rgmii -> switch port 0 > gmac2 (eth1) -> sgmii -> switch port 6 > switch ports 1-4-> PHYs on LAN ports > switch port 5 -> PHY on WAN port > > Suspected configuration of ea8500: > gmac1 (eth0) -> rgmii -> switch port 0 > gmac2 (eth1) -> rmgii -> PHY on WAN port (bypassing the > switch but using the PHY normally connected to swich port 5) > switch ports 1-4-> PHYs on LAN ports > (switch port 5 is then unused) > From what I saw in the Linksys GPL source, port 6 is in SGMII mode, and should be like AP148. But I will give your idea a try and will come back with the results. It is an intriguing matter. And more so, as eth0, the only working, seems to be somehow related to pcie2. That pcie theoretically is not connected to anything. But if I disable it I completely loose wired networking > In that case no vlans would be needed for the standard 1 WAN 1 LAN > configuration. > > A bit of a guess on what would be needed in the device tree to handle > this is attached for the gmac and switch parts (but note the ??? in > pinctrl-0 for gmac2, since I'm not sure what to put here, and possibly > an additional block needs to be defined in the pinmux.) > ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [RFC] rootfs_data on different MTD outside firmware image
Hi, some Linksys devices (i.e WRT1900AC, EA4500, EA8500,...) have two different partitions for dual boot, and an additional partition that Linksys uses for system config (sysconf). Each of these partitions is of a considerable size (23-37 mb, varying between devices). As far as I could see, the ports already in Owrt/LEDE (Kirkwook & Mvebu) use only one partition at a time for the overlayfs, so total 23-37mb shared among squashfs rom and ubifs overlay. In some cases the third partition (sysconf) is mounted, but in /mmt, not taking part in the overlay, and so not directly useful for installing additional packages. I believe that a way to better profit all this available space would be to leave one partition for the rom squashfs alone (23-37mb there) and share the 3rd partition between alternative boots as the ubifs overlay (another 23-37mb here). In total we double the space up to a full 74mb for packages, reducing the need for extroot. Have you found any serious disadvantage on this approach, and that's why it is not implemented in mvebu/kirkwood? If so, which one? If we leave ubifs outside the image, and only squash in one MTD, does it add any benefit to have squash image on top of an UBI layer? Erase counters would be lost between firmware flashes anyway and no other write would occur in between. On the other hand, in the third MTD (i.e. sysconf) the erase counters could be preserved between firmware updates, as the ubi block doesn't need to be recreated each time, and only a ubiformat could be performed on flash. I'm planning on switching ipq806x/EA8500 to this scheme, and would appreciate opinions first. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] looking for ar7 testers
-Original Message- From: Lede-dev [mailto:lede-dev-boun...@lists.infradead.org] On Behalf Of John Crispin Sent: jueves, 16 de junio de 2016 01:14 a.m. To: David Lang; Daniel Gimpelevich Cc: lede-dev@lists.infradead.org Subject: Re: [LEDE-DEV] looking for ar7 testers > talk to your local developer and support him as per need i guess. I don't think any of the core devs are local to my city, and anyway I believe nowadays we are all "local" to the world > personally i am right now looking for donations of ipq hardware that is not locked down. I'd like to help with that, but as I said, I'm a bit far away. I think there should be an "official" Lede paypal account, or something, so that it is easy for anyone willing to make a donation. Then LEDE should assign the money, (or in the donation one could state which target you wish to fund). Sending hw directly to a dev means that they have to disclose their address, and it is also more complicated to the donor, which in the end may discourage donations. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 1/2] Add some common packages for x86-64 target.
I agree with having somehow a full build available for new users. Now that "market" seems to be catered by custom images published by some in the Owrt forum and consumed by many who want a better router firmware but don't know how to build it, and most probably don't even want to know or take the time to set up all the environment to just build an image only once to flash the router and forget about it (for all this many end up using other "friendlier" projects, like I did myself for quite some time - without realizing what I was missing!). As I see it the "buildme" script doesn't address that problem, as you still need to build. I would take a different approach: + for the ones willing to actually build themselves I think than jow's idea of a good "how to" should do + for the rest (I'm assuming it's the majority) I would do a "full" or "moded" metapackage for each target with the most important extras (assuming a fair agreement can be reached on which are those). That way anyone can just flash a nightly build and with just one "opkg" upgrade to a full build, closer to an "out of the box" experience without sacrificing much of the spirit, and with much less need for maintenance, and very little code. The idea could be further elaborated - and perhaps it already was, and was discarded :). Factory images (the entry point to LEDE for newcomers) could have at least a basic LUCI so that the "full" opkg installation could be easily done without needing to ssh into the router (in Windows even for that you need to install additional software to your PC). For sysupgrade, once you are already with LEDE, I would add an option "download and reinstall currently installed packages" to complement the keep settings option. If one wants a really quick upgrade. Sorry for the long mail. I found Owrt/LEDE a great product and easing its adoption is really worth. > El 01/06/2016, a las 1:26 p.m., Dave Taht escribió: > > To fork this discussion mildly, I would like to see a fuller build, > including the luci gui, available, somehow, somewhere, so that newer > users can get a working config "out of the box" from the daily builds. > > Also, at least on the archer c7v2, the ath10k kmod and firmware were > not included in the default build. > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
