[OpenWrt-Devel] [PATCH] fstools: add ntfs support

2018-09-28 Thread Ansuel Smith 
This adds ntfs support to block-mount

Signed-off-by: Ansuel Smith 
---
 block.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/block.c b/block.c
index b377429..2e3841a 100644
--- a/block.c
+++ b/block.c
@@ -711,6 +711,7 @@ static void check_filesystem(struct probe_info *pr)
const char *f2fsck = "/usr/sbin/fsck.f2fs";
const char *dosfsck = "/usr/sbin/dosfsck";
const char *btrfsck = "/usr/bin/btrfsck";
+   const char *ntfsck = "/usr/bin/ntfsfix";
const char *ckfs;
 
/* UBIFS does not need stuff like fsck */
@@ -725,6 +726,8 @@ static void check_filesystem(struct probe_info *pr)
ckfs = e2fsck;
} else if (!strncmp(pr->type, "btrfs", 5)) {
ckfs = btrfsck;
+   } else if (!strncmp(pr->type, "ntfs", 4)) {
+   ckfs = ntfsck;
} else {
ULOG_ERR("check_filesystem: %s is not supported\n", pr->type);
return;
@@ -743,6 +746,9 @@ static void check_filesystem(struct probe_info *pr)
} else if(!strncmp(pr->type, "btrfs", 5)) {
execl(ckfs, ckfs, "--repair", pr->dev, NULL);
exit(-1);
+   } else if(!strncmp(pr->type, "ntfs", 4)) {
+   execl(ckfs, ckfs, "-b", pr->dev, NULL);
+   exit(-1);
} else {
execl(ckfs, ckfs, "-p", pr->dev, NULL);
exit(-1);
@@ -1437,8 +1443,9 @@ static int mount_extroot(char *cfg)
if (strncmp(pr->type, "ext", 3) &&
strncmp(pr->type, "f2fs", 4) &&
strncmp(pr->type, "btrfs", 5) &&
+   strncmp(pr->type, "ntfs", 4) &&
strncmp(pr->type, "ubifs", 5)) {
-   ULOG_ERR("extroot: unsupported filesystem %s, try ext4, 
f2fs, btrfs or ubifs\n", pr->type);
+   ULOG_ERR("extroot: unsupported filesystem %s, try ext4, 
f2fs, btrfs, ntfs or ubifs\n", pr->type);
return -1;
}
 
-- 
2.17.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] fstools: add ntfs support

2018-09-28 Thread Ansuel Smith 
This adds ntfs support to block-mount

Signed-off-by: Ansuel Smith 
---
 block.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/block.c b/block.c
index b377429..1e82a38 100644
--- a/block.c
+++ b/block.c
@@ -711,6 +711,7 @@ static void check_filesystem(struct probe_info *pr)
const char *f2fsck = "/usr/sbin/fsck.f2fs";
const char *dosfsck = "/usr/sbin/dosfsck";
const char *btrfsck = "/usr/bin/btrfsck";
+   const char *ntfsck = "/usr/bin/ntfsfix";
const char *ckfs;
 
/* UBIFS does not need stuff like fsck */
@@ -725,6 +726,8 @@ static void check_filesystem(struct probe_info *pr)
ckfs = e2fsck;
} else if (!strncmp(pr->type, "btrfs", 5)) {
ckfs = btrfsck;
+   } else if (!strncmp(pr->type, "ntfs", 5)) {
+   ckfs = ntfsck;
} else {
ULOG_ERR("check_filesystem: %s is not supported\n", pr->type);
return;
@@ -743,6 +746,9 @@ static void check_filesystem(struct probe_info *pr)
} else if(!strncmp(pr->type, "btrfs", 5)) {
execl(ckfs, ckfs, "--repair", pr->dev, NULL);
exit(-1);
+   } else if(!strncmp(pr->type, "ntfs", 5)) {
+   execl(ckfs, ckfs, "-b", pr->dev, NULL);
+   exit(-1);
} else {
execl(ckfs, ckfs, "-p", pr->dev, NULL);
exit(-1);
@@ -1437,8 +1443,9 @@ static int mount_extroot(char *cfg)
if (strncmp(pr->type, "ext", 3) &&
strncmp(pr->type, "f2fs", 4) &&
strncmp(pr->type, "btrfs", 5) &&
+   strncmp(pr->type, "ntfs", 5) &&
strncmp(pr->type, "ubifs", 5)) {
-   ULOG_ERR("extroot: unsupported filesystem %s, try ext4, 
f2fs, btrfs or ubifs\n", pr->type);
+   ULOG_ERR("extroot: unsupported filesystem %s, try ext4, 
f2fs, btrfs, ntfs or ubifs\n", pr->type);
return -1;
}
 
-- 
2.17.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] OpenWrt 19.01 plans

2018-09-28 Thread Rosen Penev 


> On Sep 28, 2018, at 07:20, Jerome BENOIT  wrote:
> 
> 
>>> Is there any work in OpenWRT targeted at integrating Linux forwarding
>>> fastpath in the official build ?
>>> There are out-of-tree patches and builds floating around and nowadays 1
>>> GB/s fiber internet access is very common is developed countries, and
>>> the router is then becoming the bottleneck in many case.
>> With my colleagues I have already started this effort and plan to
>> share patches to OpenWrt as soon as the work is ready. The plan is to
>> present this on OpenWrt summit in our talk "State of fast path
>> networking in Linux" as well [1]. Part of this activity is my pull
>> request for 4.19 inclusion [2]. If there are other activities around
>> this space please reach out to speed up the process.
> 
> Great. I do no have closely followed the Linux kernel development lately but 
> the need for the 4.19 version in OpenWRT for fastpath forwarding is because 
> the SFE code have been upstreamed is that version ?
> Or because the latest SFE patches are against that version ?
> 
> The only related work that I'm aware of is 
> https://github.com/gwlim/Fast-Path-LEDE-OpenWRT but I do not think the author 
> have tried to include it upstream.
So in kernel 4.17 I believe landed flow offloading support. This accomplishes 
something similar to SFE while being a proper upstream solution. This is 
already implemented in OpenWrt.

Is there something that I’m missing here?
> 
> Cheers.
> 
> -- 
> Jérôme Benoit aka fraggle
> Piment Noir - https://piment-noir.org
> OpenPGP Key ID : 27B535D3
> Key fingerprint : B799 BBF6 8EC8 911B B8D7 CDBC C3B1 92C6 27B5 35D3
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] OpenWrt 19.01 plans

2018-09-28 Thread Jerome BENOIT 



Is there any work in OpenWRT targeted at integrating Linux forwarding
fastpath in the official build ?
There are out-of-tree patches and builds floating around and nowadays 1
GB/s fiber internet access is very common is developed countries, and
the router is then becoming the bottleneck in many case.

With my colleagues I have already started this effort and plan to
share patches to OpenWrt as soon as the work is ready. The plan is to
present this on OpenWrt summit in our talk "State of fast path
networking in Linux" as well [1]. Part of this activity is my pull
request for 4.19 inclusion [2]. If there are other activities around
this space please reach out to speed up the process.


Great. I do no have closely followed the Linux kernel development lately 
but the need for the 4.19 version in OpenWRT for fastpath forwarding is 
because the SFE code have been upstreamed is that version ?

Or because the latest SFE patches are against that version ?

The only related work that I'm aware of is 
https://github.com/gwlim/Fast-Path-LEDE-OpenWRT but I do not think the 
author have tried to include it upstream.


Cheers.

--
Jérôme Benoit aka fraggle
Piment Noir - https://piment-noir.org
OpenPGP Key ID : 27B535D3
Key fingerprint : B799 BBF6 8EC8 911B B8D7 CDBC C3B1 92C6 27B5 35D3


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] OpenWrt 19.01 plans

2018-09-28 Thread Marko Ratkaj 
Hi all,

On Fri, Sep 28, 2018 at 3:14 PM Jerome BENOIT  wrote:
> > They may not be able to push lots of bandwidth, but if you have
> > <~100Mbps internet they don't need to. If you have >~200Mbps internet
> > for example with DOCSIS3.1 provider, then you probably need a newer
> > dual-core device to take advantage of it.
>
> Is there any work in OpenWRT targeted at integrating Linux forwarding
> fastpath in the official build ?
> There are out-of-tree patches and builds floating around and nowadays 1
> GB/s fiber internet access is very common is developed countries, and
> the router is then becoming the bottleneck in many case.

With my colleagues I have already started this effort and plan to
share patches to OpenWrt as soon as the work is ready. The plan is to
present this on OpenWrt summit in our talk "State of fast path
networking in Linux" as well [1]. Part of this activity is my pull
request for 4.19 inclusion [2]. If there are other activities around
this space please reach out to speed up the process.

Thanks,
Marko Ratkaj

[1] https://openwrtsummit.wordpress.com/schedule-2018/
[2] https://github.com/openwrt/openwrt/pull/1386

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] OpenWrt 19.01 plans

2018-09-28 Thread Jerome BENOIT 

Hello,


They may not be able to push lots of bandwidth, but if you have 
<~100Mbps internet they don't need to. If you have >~200Mbps internet 
for example with DOCSIS3.1 provider, then you probably need a newer 
dual-core device to take advantage of it.


Is there any work in OpenWRT targeted at integrating Linux forwarding 
fastpath in the official build ?
There are out-of-tree patches and builds floating around and nowadays 1 
GB/s fiber internet access is very common is developed countries, and 
the router is then becoming the bottleneck in many case.


--
Jérôme Benoit aka fraggle
Piment Noir - https://piment-noir.org
OpenPGP Key ID : 27B535D3
Key fingerprint : B799 BBF6 8EC8 911B B8D7 CDBC C3B1 92C6 27B5 35D3


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] coova-chilli: fix compilation error with --enable-redir

2018-09-28 Thread Xabier Oneca -- xOneca 
musl lacks `allocated` member on `struct re_pattern_buffer`
(https://fossies.org/dox/musl-1.1.20/structre__pattern__buffer.html).

Patch inspired by drkhosla @github.com/coova/coova-chilli issue #200
(https://github.com/coova/coova-chilli/issues/200#issuecomment-253497070)

Signed-off-by: Xabier Oneca 
---
 .../300-fix-compile-with-enable-redirurl.patch | 25 ++
 1 file changed, 25 insertions(+)
 create mode 100644
net/coova-chilli/patches/300-fix-compile-with-enable-redirurl.patch

diff --git a/net/coova-chilli/patches/300-fix-compile-with-enable-redirurl.patch
b/net/coova-chilli/patches/300-fix-compile-with-enable-redirurl.patch
new file mode 100644
index 000..b7ae041
--- /dev/null
+++ b/net/coova-chilli/patches/300-fix-compile-with-enable-redirurl.patch
@@ -0,0 +1,25 @@
+--- a/src/options.c
 b/src/options.c
+@@ -377,7 +377,7 @@ int options_fromfd(int fd, bstring bt) {
+
+ #ifdef ENABLE_CHILLIREDIR
+   for (i = 0; i < MAX_REGEX_PASS_THROUGHS; i++) {
+-#if defined (__FreeBSD__) || defined (__APPLE__) || defined
(__OpenBSD__) || defined (__NetBSD__)
++#if defined (__linux__) || defined (__FreeBSD__) || defined
(__APPLE__) || defined (__OpenBSD__) || defined (__NetBSD__)
+ regfree(&_options.regex_pass_throughs[i].re_host);
+ regfree(&_options.regex_pass_throughs[i].re_path);
+ regfree(&_options.regex_pass_throughs[i].re_qs);
+--- a/src/main-redir.c
 b/src/main-redir.c
+@@ -508,11 +508,6 @@ check_regex(regex_t *re, char *regex, ch
+   syslog(LOG_DEBUG, "Checking %s =~ %s", s, regex);
+ #endif
+
+-#if defined (__FreeBSD__) || defined (__APPLE__) || defined
(__OpenBSD__) || defined (__NetBSD__)
+-  if (!re->re_g)
+-#else
+-if (!re->allocated)
+-#endif
+ {
+   if ((ret = regcomp(re, regex, REG_EXTENDED | REG_NOSUB)) != 0) {
+ char error[512];
--
1.9.1
From 356a46491329eb9f6f743c5c567cb99c791a02a5 Mon Sep 17 00:00:00 2001
From: Xabier Oneca 
Date: Fri, 28 Sep 2018 11:16:57 +0200
Subject: [PATCH] coova-chilli: fix compilation error with --enable-redir

musl lacks `allocated` member on `struct re_pattern_buffer`
(https://fossies.org/dox/musl-1.1.20/structre__pattern__buffer.html).

Patch inspired by the one posted by drkhosla at github.com/coova/coova-chilli
issue #200
(https://github.com/coova/coova-chilli/issues/200#issuecomment-253497070).

Signed-off-by: Xabier Oneca 
---
 .../300-fix-compile-with-enable-redirurl.patch | 25 ++
 1 file changed, 25 insertions(+)
 create mode 100644 net/coova-chilli/patches/300-fix-compile-with-enable-redirurl.patch

diff --git a/net/coova-chilli/patches/300-fix-compile-with-enable-redirurl.patch b/net/coova-chilli/patches/300-fix-compile-with-enable-redirurl.patch
new file mode 100644
index 000..b7ae041
--- /dev/null
+++ b/net/coova-chilli/patches/300-fix-compile-with-enable-redirurl.patch
@@ -0,0 +1,25 @@
+--- a/src/options.c
 b/src/options.c
+@@ -377,7 +377,7 @@ int options_fromfd(int fd, bstring bt) {
+ 
+ #ifdef ENABLE_CHILLIREDIR
+   for (i = 0; i < MAX_REGEX_PASS_THROUGHS; i++) {
+-#if defined (__FreeBSD__) || defined (__APPLE__) || defined (__OpenBSD__) || defined (__NetBSD__)
++#if defined (__linux__) || defined (__FreeBSD__) || defined (__APPLE__) || defined (__OpenBSD__) || defined (__NetBSD__)
+ regfree(&_options.regex_pass_throughs[i].re_host);
+ regfree(&_options.regex_pass_throughs[i].re_path);
+ regfree(&_options.regex_pass_throughs[i].re_qs);
+--- a/src/main-redir.c
 b/src/main-redir.c
+@@ -508,11 +508,6 @@ check_regex(regex_t *re, char *regex, ch
+   syslog(LOG_DEBUG, "Checking %s =~ %s", s, regex);
+ #endif
+ 
+-#if defined (__FreeBSD__) || defined (__APPLE__) || defined (__OpenBSD__) || defined (__NetBSD__)
+-  if (!re->re_g)
+-#else
+-if (!re->allocated)
+-#endif
+ {
+   if ((ret = regcomp(re, regex, REG_EXTENDED | REG_NOSUB)) != 0) {
+ char error[512];
-- 
1.9.1

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] OpenWrt 19.01 plans

2018-09-28 Thread John Crispin 


On 28/09/2018 06:35, Eric Luehrsen wrote:

On 09/27/2018 04:22 PM, Hauke Mehrtens wrote:

On 09/26/2018 09:38 AM, Koen Vandeputte wrote:



On 2018-09-23 00:42, Hauke Mehrtens wrote:

Hi,

We talked about plans for the next OpenWrt releases in this mail 
thread:

http://lists.infradead.org/pipermail/openwrt-adm/2018-July/000849.html
This mail is more or less a summary of the conclusions, this is still
open for change especially the dates as this depends on people having
time to do the work.

The next release, lets call it OpenWrt 19.01, should happen in January
2019, we would branch off from master in December 2018. This is the
current plan, but based on past experience it could also happen later.

OpenWrt 19.01 will ship with kernel 4.14 only, we encourage 
everyone to
update the targets to kernel 4.14, support for kernel 4.19 will 
probably

be added to OpenWrt master soon, but we will not select it as the
default kernel for any target till OpenWrt 19.01 is branched off, 
to get

more testing on 4.14. The release after 19.01, which should happen in
late summer 2019, should then use kernel 4.19 only.

For OpenWrt 19.01 GCC will stay on the 7.X branch, binutils and musl
already got some upgrades after the 18.06 release and could get some
more updates.

We are currently working on updating the wireless drivers and getting
them closer to upstream. The wireless driver in OpenWrt 19.01 will be
taken from kernel 4.19 or later and we want to update them more
frequently in master.

Otherwise we will have the normal changes in all places like with 
every

release.

LEDE 17.01 will get security updates and occasional bug fixes till
OpenWrt 19.01 was released, but we encourage everyone to upgrade to
18.06 to get full security support already now, as especially some of
the packages are not well maintained any more.

Hauke



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Hi Hauke,
Hi All,

Some targets are still on (EOL) kernel 3.18 today.
This kernel also still exists by the grace of Greg K-H but could be
dropped any moment.

I've bumped it a few times (untested) just for the sake of security
updates.
But afaict, nobody attempted/requested to update these to a newer 
kernel

version.

These targets were also dropped in 18.06 branch.
Maybe we should also consider dropping support for these targets in 
master?



adm5120
xburst
mcs814x
au1000
ppc40x
adm8668
ppc44x


I vote for removing them if on one wants to take care of these targets.
If something breaks kernel < 4.9 I anyway do not care any more.

Hauke


Considering that OpenWrt is volunteer spare time and hobby support, it 
is probably prudent to aggressively drop old and less popular targets. 
Considering 802.11ax is around the corner and (ac) is well 
established, it won't be hard to find for example ath79 compatible 
devices in (ac) or (n) as either new-overstock or used. They may not 
be able to push lots of bandwidth, but if you have <~100Mbps internet 
they don't need to. If you have >~200Mbps internet for example with 
DOCSIS3.1 provider, then you probably need a newer dual-core device to 
take advantage of it. Bottom line is it probably won't hurt to drop 
many targets, because small budget users will still have plenty to 
chose from.


Eric

can we mark them as broken now and when we release move them to a target 
feed. that will allow people to still use them in custom builds for 6-12 
months without us having to worry about them.


    John




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel