Re: [LEDE-DEV] [PATCHv2 3/4] kernel/4.4: add generic spi-nand framework
On 2017-09-06 18:24, Weijie Gao wrote: > Yes, I have to admit operations of GigaDevice's chips are the same. > All the chips have the same read/write/erase command sequences. > Differences are plane selection bits (Micron), die selection > (Micron/Winbond), buffered read/continuous read (Winbond) and ECC > status bits. > These differences can be abstracted to different functions chosen by > the flash id. So this won't be a problem. > > As for the patches, may be I can submit patches to both generic-4.4 > and generic-4.9, and remove patches from pistachio. > So this won't be a problem when ar71xx updates linux-4.9. I think it's a bad idea to integrate new code that is based on an old framework rejected by upstream. Even if it's more work, I strongly suggest using the new code by Micron. If there's no way around using the old code for now, it should definitely not be placed in generic/ because this could potentially lead to even more people picking it up, thus creating long term porting issues. - Felix ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] netifd-proto.sh: add ip4table & ip6table to `proto_add_dynamic_defaults()`
On 09-09-17, Baptiste Jonglez wrote:
> On 05-09-17, Alexandru Ardelean wrote:
> > The `proto_add_dynamic_defaults()` seems to be called mostly
> > in the context of LTE/3G modems (via wwan, qmi, etc) setup.
> >
> > When they get setup, these devices override default routes.
> >
> > However, depending on setup, we want these modems to
> > be part of a another routing table.
> > This change allows that.
> >
> > ip4table/ip6table are of string type in netifd to allow
> > for `default`, `local` routing table names to be specified.
>
> Just a remark on the names: "ip4table" and "ip6table" make it looks like
> it's related to firewall. But this has nothing to do with firewalls.
>
> Maybe use "routingtable" and "routingtablev6" instead? Or just
> "table"/"tablev6"?
It seems that "ip4table" and "ip6table" is already understood by other
protocols, so you can disregard my remark:
https://wiki.openwrt.org/doc/uci/network#options_valid_for_all_protocol_types
> > Signed-off-by: Alexandru Ardelean
> > ---
> > scripts/netifd-proto.sh | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/scripts/netifd-proto.sh b/scripts/netifd-proto.sh
> > index cc7031a..fd7b596 100644
> > --- a/scripts/netifd-proto.sh
> > +++ b/scripts/netifd-proto.sh
> > @@ -26,6 +26,8 @@ proto_add_dynamic_defaults() {
> > [ -n "$defaultroute" ] && json_add_boolean defaultroute "$defaultroute"
> > [ -n "$peerdns" ] && json_add_boolean peerdns "$peerdns"
> > [ -n "$metric" ] && json_add_int metric "$metric"
> > + [ -n "$ip4table" ] && json_add_string ip4table "$ip4table"
> > + [ -n "$ip6table" ] && json_add_string ip6table "$ip6table"
> > }
> >
> > _proto_do_teardown() {
signature.asc
Description: PGP signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] netifd-proto.sh: add ip4table & ip6table to `proto_add_dynamic_defaults()`
Hi,
On 05-09-17, Alexandru Ardelean wrote:
> The `proto_add_dynamic_defaults()` seems to be called mostly
> in the context of LTE/3G modems (via wwan, qmi, etc) setup.
>
> When they get setup, these devices override default routes.
>
> However, depending on setup, we want these modems to
> be part of a another routing table.
> This change allows that.
>
> ip4table/ip6table are of string type in netifd to allow
> for `default`, `local` routing table names to be specified.
Just a remark on the names: "ip4table" and "ip6table" make it looks like
it's related to firewall. But this has nothing to do with firewalls.
Maybe use "routingtable" and "routingtablev6" instead? Or just
"table"/"tablev6"?
> Signed-off-by: Alexandru Ardelean
> ---
> scripts/netifd-proto.sh | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/scripts/netifd-proto.sh b/scripts/netifd-proto.sh
> index cc7031a..fd7b596 100644
> --- a/scripts/netifd-proto.sh
> +++ b/scripts/netifd-proto.sh
> @@ -26,6 +26,8 @@ proto_add_dynamic_defaults() {
> [ -n "$defaultroute" ] && json_add_boolean defaultroute "$defaultroute"
> [ -n "$peerdns" ] && json_add_boolean peerdns "$peerdns"
> [ -n "$metric" ] && json_add_int metric "$metric"
> + [ -n "$ip4table" ] && json_add_string ip4table "$ip4table"
> + [ -n "$ip6table" ] && json_add_string ip6table "$ip6table"
> }
>
> _proto_do_teardown() {
signature.asc
Description: PGP signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] using 464XLAT in LEDE (or OpenWRT)
Ah even better, I thought 17.01.2 was not including the right CLAT (NAT46) stuff. So, I will try that then: http://downloads.lede-project.org/releases/17.01.2/targets/ramips/mt7621/lede-17.01.2-ramips-mt7621-sk-wb8-squashfs-sysupgrade.bin Right? Or do you mean I use the snapshot and then opkg install all the relevant packages? I will confirm if it works well, thanks a lot! Regard, Jordi -Mensaje original- De: Hans Dedecker Responder a: Fecha: sábado, 9 de septiembre de 2017, 15:36 Para: Jordi Palet Martinez CC: LEDE Development List Asunto: Re: using 464XLAT in LEDE (or OpenWRT) On Sat, Sep 9, 2017 at 3:45 AM, JORDI PALET MARTINEZ wrote: > Hi all, > > I just saw in github that 464xlat.sh has been modified on June 2. > > I’m not sure if that means that 464XLAT is already working if I use a snapshot, for example: > > http://downloads.lede-project.org/snapshots/targets/ramips/mt7621/lede-ramips-mt7621-sk-wb8-squashfs-sysupgrade.bin > > I’m doing a workshop this week and have one of those routers which I can reflash to demo it. There is no OpenWRT 15.05 support for this box, and 15.05.1 has 464XLAT broken as well as I can remember. > > Or alternatively maybe an OpenWRT snapshot has it working? > > Thanks in advance! Hi, The 464xlat package is working in Lede trunk; however the 464xlat package is not enabled by default and as such won't be present in a snapshot build Hans > > Regards, > Jordi > > > -Mensaje original- > De: Hans Dedecker > Responder a: > Fecha: martes, 14 de marzo de 2017, 1:47 > Para: Jordi Palet Martinez > CC: LEDE Development List > Asunto: Re: using 464XLAT in LEDE (or OpenWRT) > > On Sun, Mar 12, 2017 at 12:24 AM, JORDI PALET MARTINEZ > wrote: > > Hi Hans, > > > > Thanks for your response. > > > > I’m now a bit more confused with your comment that it doesn’t work in LEDE, because this afternoon, finally I got it working. > > > > Let me explain all the history. > > > > About a year ago, using OpenWRT 15.05, I tested 464XLAT and it worked fine. > > > > Last weekend, I was trying to replicate it again directly with LEDE … no success. > > > > Then I tried again with OpenWRT 15.05.1 and didn’t worked, but this may be related to the platform I was using. > > > > I reverted back to 15.05 and it worked. > > > > This has been a very slow process because I expected that simply adding at network: > > config interface 'clat' > > option proto '464xlat' > > will make it, but, I didn’t realize that it requires a reboot, for some reason, just ifdown/ifup, is not enough. > > > > I could ping/traceroute to both IPv4/IPv6, browse, use skype, etc., and only having in the WAN IPv6, which is for what is meant 464XLAT of course. > > > > Once I got it stable, tried again with LEDE (17.01.0 stable), and even having the same configuration didn't worked, or at least I was assuming that … > > > > In the packages info, it shows a dependency with libssp, so that confused me … I also saw that the out rule was removed from 15.05, so I even edited the 464xlat.sh to include that rule again, but no difference. > > > > Now … by chance instead of trying ping, which is the FIRST thing that you do (specially because it worked in 15.05) … my previous browsing window was still open and tried to reload it … and it worked! > > > > I tried it also with the trunk version from today, and also works. > > > > I tried with both a hardware router and also a VM under VirtualBox. > > > > So, I’m not sure to understand in which LEDE release is broken … > > > > What definitively is broken is the capability to issue a ping (IPv4). > 464xlat is definitely broken on LEDE as you need an ip rule which > checks the prelocal table before the local table is checked > > ip rule list > 0: from all lookup prelocal > 1: from all lookup local > > The rule to the prelocal table is required in order to route the > 464xlat traffic to the nat46 module via the xlat interface > > > > Also, there are other, probably simple to sort out (I’m not a programmer so I’m not able to contribute myself on this), issues that may be enhanced to have a good 464XLAT support: > > 1) option ipv4addr '192.168.0.1' seems to not work, I see in the 464xlat.sh is fixed to 192.0.0.1, but according to my reading of RFC6877/7915 (and all the related ones), it should be possible to select what address and not just one address but a prefix for the translation. I believe that using just
Re: [LEDE-DEV] using 464XLAT in LEDE (or OpenWRT)
On Sat, Sep 9, 2017 at 3:45 AM, JORDI PALET MARTINEZ wrote: > Hi all, > > I just saw in github that 464xlat.sh has been modified on June 2. > > I’m not sure if that means that 464XLAT is already working if I use a > snapshot, for example: > > http://downloads.lede-project.org/snapshots/targets/ramips/mt7621/lede-ramips-mt7621-sk-wb8-squashfs-sysupgrade.bin > > I’m doing a workshop this week and have one of those routers which I can > reflash to demo it. There is no OpenWRT 15.05 support for this box, and > 15.05.1 has 464XLAT broken as well as I can remember. > > Or alternatively maybe an OpenWRT snapshot has it working? > > Thanks in advance! Hi, The 464xlat package is working in Lede trunk; however the 464xlat package is not enabled by default and as such won't be present in a snapshot build Hans > > Regards, > Jordi > > > -Mensaje original- > De: Hans Dedecker > Responder a: > Fecha: martes, 14 de marzo de 2017, 1:47 > Para: Jordi Palet Martinez > CC: LEDE Development List > Asunto: Re: using 464XLAT in LEDE (or OpenWRT) > > On Sun, Mar 12, 2017 at 12:24 AM, JORDI PALET MARTINEZ > wrote: > > Hi Hans, > > > > Thanks for your response. > > > > I’m now a bit more confused with your comment that it doesn’t work in > LEDE, because this afternoon, finally I got it working. > > > > Let me explain all the history. > > > > About a year ago, using OpenWRT 15.05, I tested 464XLAT and it worked > fine. > > > > Last weekend, I was trying to replicate it again directly with LEDE … > no success. > > > > Then I tried again with OpenWRT 15.05.1 and didn’t worked, but this may > be related to the platform I was using. > > > > I reverted back to 15.05 and it worked. > > > > This has been a very slow process because I expected that simply adding > at network: > > config interface 'clat' > > option proto '464xlat' > > will make it, but, I didn’t realize that it requires a reboot, for some > reason, just ifdown/ifup, is not enough. > > > > I could ping/traceroute to both IPv4/IPv6, browse, use skype, etc., and > only having in the WAN IPv6, which is for what is meant 464XLAT of course. > > > > Once I got it stable, tried again with LEDE (17.01.0 stable), and even > having the same configuration didn't worked, or at least I was assuming that … > > > > In the packages info, it shows a dependency with libssp, so that > confused me … I also saw that the out rule was removed from 15.05, so I even > edited the 464xlat.sh to include that rule again, but no difference. > > > > Now … by chance instead of trying ping, which is the FIRST thing that > you do (specially because it worked in 15.05) … my previous browsing window > was still open and tried to reload it … and it worked! > > > > I tried it also with the trunk version from today, and also works. > > > > I tried with both a hardware router and also a VM under VirtualBox. > > > > So, I’m not sure to understand in which LEDE release is broken … > > > > What definitively is broken is the capability to issue a ping (IPv4). > 464xlat is definitely broken on LEDE as you need an ip rule which > checks the prelocal table before the local table is checked > > ip rule list > 0: from all lookup prelocal > 1: from all lookup local > > The rule to the prelocal table is required in order to route the > 464xlat traffic to the nat46 module via the xlat interface > > > > Also, there are other, probably simple to sort out (I’m not a > programmer so I’m not able to contribute myself on this), issues that may be > enhanced to have a good 464XLAT support: > > 1) option ipv4addr '192.168.0.1' seems to not work, I see in the > 464xlat.sh is fixed to 192.0.0.1, but according to my reading of RFC6877/7915 > (and all the related ones), it should be possible to select what address and > not just one address but a prefix for the translation. I believe that using > just one address, if there is a lot of flows, you can run out of “ports” for > that number of ports. This may not happen in a small residential network but > if you have a LEDE router in an enterprise is a different history. > You cannot specify an IPv4 address in the 464xlat config; all IPv4 > traffic is indeed source nated to 192.0.0.1. Large scale deployment of > 464xlat in an enterprise was not considered by Steven Barth as an > initial development target > > > 2) Same with option ip6addr '2001:470:68ee:30::1', it should be > possible to use instead of just one address, a pool of them (a prefix). > > 3) Last, I believe the default route is not being installed. In fact, > in my case, I’ve a default route for in the WAN interphase to my primary > router. This default route is still there after installing 464XLAT. My > default route is: default via fe80::1 dev eth0.6. So I
