Re: [LEDE-DEV] MT7621 support Jumbo frames
Hello all, I found the message below in a conversation from back in August, 2016 in this mailinglist. I did not find a reply to this question. Has there ever been one? Or does anyone else happen to know the answer to this question? Thank you very much in advance. Yours sincerely, Jaap Buurman August, 2016 message: Hi all, in the MT7621 ethernet driver code (drivers/net/ethernet/mediatek/soc_mt7621.c) the FE_FLAG_JUMBO_FRAME flag is not during the device initialization. This prevents the user to set an MTU greater than 1500. Is this correct? Does MT7621 support jumbo frames? Thanks. -- gaetano catalli ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] MT7621 support Jumbo frames
I am able to test this on my DIR-860l. I could try to compile my own build to test this, but I am no C programmer myself. Am I correct in the following post about how to set the flag to allow for jumbo frames to be set?: https://forum.lede-project.org/t/build-for-the-d-link-dir-860l/948/40?u=mushoz If so, I will be able to apply the patch myself and test it. I could then send a PR if the tests are successful. Yours sincerely, Jaap Buurman On Mon, Apr 10, 2017 at 9:16 AM, Milan Kočvara wrote: > Hello all, > if someone do a testing patch for jumboFrames, I can lend a helping > hand with testing on EdgeRouter X. I think MT7621 know JumboFrames, > because of Ubiquiti FMW allow to set MTU 1536B > > 2017-04-10 2:06 GMT+02:00 : >> Probably was not in the interest of the driver writers. Based on the >> copyrights though, it's mostly LEDE/OpenWRT developers. Try modifying >> the code to test if jumbo frames work. >> >> On Sun, 2017-04-09 at 21:20 +0200, Jaap Buurman wrote: >>> Hello all, >>> >>> I found the message below in a conversation from back in August, 2016 >>> in this mailinglist. I did not find a reply to this question. Has >>> there ever been one? Or does anyone else happen to know the answer to >>> this question? Thank you very much in advance. >>> >>> Yours sincerely, >>> >>> Jaap Buurman >>> >>> August, 2016 message: >>> >>> >>> Hi all, >>> >>> in the MT7621 ethernet driver code >>> (drivers/net/ethernet/mediatek/soc_mt7621.c) the FE_FLAG_JUMBO_FRAME >>> flag is not during the device initialization. This prevents the user >>> to set an MTU greater than 1500. Is this correct? Does MT7621 support >>> jumbo frames? >>> >>> Thanks. >>> >> >> ___ >> 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] MT7621 support Jumbo frames
H_DATA_LEN) {
> - fwd_cfg &= ~FE_GDM1_JMB_EN;
> - } else {
> - fwd_cfg &= ~(FE_GDM1_JMB_LEN_MASK << FE_GDM1_JMB_LEN_SHIFT);
> - fwd_cfg |= (DIV_ROUND_UP(frag_size, 1024) <<
> - FE_GDM1_JMB_LEN_SHIFT) | FE_GDM1_JMB_EN;
> - }
> - fe_w32(fwd_cfg, FE_GDMA1_FWD_CFG);
> + if (priv->soc->set_mtu)
> + return priv->soc->set_mtu(priv, new_mtu);
>
> - return fe_open(dev);
> + return fe_set_mtu(priv, new_mtu);
> }
>
> static const struct net_device_ops fe_netdev_ops = {
> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
> b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
> index d5f8b87..3acc2c1 100644
> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
> @@ -381,6 +381,7 @@ struct fe_soc_data {
> void (*reset_fe)(void);
> void (*set_mac)(struct fe_priv *priv, unsigned char *mac);
> int (*fwd_config)(struct fe_priv *priv);
> + int (*set_mtu)(struct fe_priv *priv, int new_mtu);
> void (*tx_dma)(struct fe_tx_dma *txd);
> int (*switch_init)(struct fe_priv *priv);
> int (*switch_config)(struct fe_priv *priv);
> diff --git a/drivers/net/ethernet/mediatek/soc_mt7621.c
> b/drivers/net/ethernet/mediatek/soc_mt7621.c
> index 1609a3e..f95c354 100644
> --- a/drivers/net/ethernet/mediatek/soc_mt7621.c
> +++ b/drivers/net/ethernet/mediatek/soc_mt7621.c
> @@ -140,7 +140,7 @@ static void mt7621_init_data(struct fe_soc_data *data,
>
> priv->flags = FE_FLAG_PADDING_64B | FE_FLAG_RX_2B_OFFSET |
> FE_FLAG_RX_SG_DMA | FE_FLAG_NAPI_WEIGHT |
> - FE_FLAG_HAS_SWITCH;
> + FE_FLAG_HAS_SWITCH | FE_FLAG_JUMBO_FRAME;
>
> netdev->hw_features = NETIF_F_IP_CSUM | NETIF_F_RXCSUM |
> NETIF_F_HW_VLAN_CTAG_TX | NETIF_F_SG | NETIF_F_TSO |
> --
> 2.7.4
>
> On Mon, Apr 10, 2017 at 9:21 AM, Jaap Buurman wrote:
>> I am able to test this on my DIR-860l. I could try to compile my own
>> build to test this, but I am no C programmer myself. Am I correct in
>> the following post about how to set the flag to allow for jumbo frames
>> to be set?:
>> https://forum.lede-project.org/t/build-for-the-d-link-dir-860l/948/40?u=mushoz
>> If so, I will be able to apply the patch myself and test it. I could
>> then send a PR if the tests are successful.
>>
>> Yours sincerely,
>>
>> Jaap Buurman
>>
>> On Mon, Apr 10, 2017 at 9:16 AM, Milan Kočvara
>> wrote:
>>> Hello all,
>>> if someone do a testing patch for jumboFrames, I can lend a helping
>>> hand with testing on EdgeRouter X. I think MT7621 know JumboFrames,
>>> because of Ubiquiti FMW allow to set MTU 1536B
>>>
>>> 2017-04-10 2:06 GMT+02:00 :
>>>> Probably was not in the interest of the driver writers. Based on the
>>>> copyrights though, it's mostly LEDE/OpenWRT developers. Try modifying
>>>> the code to test if jumbo frames work.
>>>>
>>>> On Sun, 2017-04-09 at 21:20 +0200, Jaap Buurman wrote:
>>>>> Hello all,
>>>>>
>>>>> I found the message below in a conversation from back in August, 2016
>>>>> in this mailinglist. I did not find a reply to this question. Has
>>>>> there ever been one? Or does anyone else happen to know the answer to
>>>>> this question? Thank you very much in advance.
>>>>>
>>>>> Yours sincerely,
>>>>>
>>>>> Jaap Buurman
>>>>>
>>>>> August, 2016 message:
>>>>>
>>>>>
>>>>> Hi all,
>>>>>
>>>>> in the MT7621 ethernet driver code
>>>>> (drivers/net/ethernet/mediatek/soc_mt7621.c) the FE_FLAG_JUMBO_FRAME
>>>>> flag is not during the device initialization. This prevents the user
>>>>> to set an MTU greater than 1500. Is this correct? Does MT7621 support
>>>>> jumbo frames?
>>>>>
>>>>> Thanks.
>>>>>
>>>>
>>>> ___
>>>> Lede-dev mailing list
>>>> Lede-dev@lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/lede-dev
>
>
>
> --
> gaetano catalli
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] MT7621 support Jumbo frames
Ah, that sounds even better :) I will try to compile and test this
patch tomorrow or the day after tomorrow. Will let you know if it
works. Thanks again for the effort you're putting into this!
On Wed, Apr 19, 2017 at 10:23 AM, Gaetano Catalli
wrote:
> I'm still working on this since I would like to raise the limit up to
> 9KB if possible. Please, let me know if this works for you.
>
> On Wed, Apr 19, 2017 at 10:18 AM, Jaap Buurman wrote:
>> Wow, this is perfect. Thank you very much. I will try to use this
>> patch and compile my own image with up to 2kb frame support. Do you
>> have any plans on submitting this as a PR to the LEDE git?
>>
>> On Wed, Apr 19, 2017 at 9:32 AM, Gaetano Catalli
>> wrote:
>>> I've been working on this for a while. Apparently the embedded 5-port
>>> gigabit switch is able to handle packets with size up to 15KB. On the
>>> contrary, the GMAC, to which the switch is attached, has a limit of
>>> 2KB. The following is a patch that changes the max recv frame length
>>> to 2KB and allows to set the MTU up to that value. It is based on
>>> kernel 4.4.7.
>>>
>>> Signed-off-by: Gaetano Catalli
>>> ---
>>> drivers/net/ethernet/mediatek/gsw_mt7620.h | 6 +
>>> drivers/net/ethernet/mediatek/gsw_mt7621.c | 13 +++
>>> drivers/net/ethernet/mediatek/mtk_eth_soc.c | 36
>>> ++---
>>> drivers/net/ethernet/mediatek/mtk_eth_soc.h | 1 +
>>> drivers/net/ethernet/mediatek/soc_mt7621.c | 2 +-
>>> 5 files changed, 39 insertions(+), 19 deletions(-)
>>>
>>> diff --git a/drivers/net/ethernet/mediatek/gsw_mt7620.h
>>> b/drivers/net/ethernet/mediatek/gsw_mt7620.h
>>> index dcef9a8..ce3cd10 100644
>>> --- a/drivers/net/ethernet/mediatek/gsw_mt7620.h
>>> +++ b/drivers/net/ethernet/mediatek/gsw_mt7620.h
>>> @@ -45,6 +45,12 @@
>>> #define GSW_REG_ISR 0x700c
>>> #define GSW_REG_GPC1 0x7014
>>>
>>> +#define GSW_REG_MAC_P0_MCR 0x100
>>> +#define GSW_REG_MAC_P1_MCR 0x200
>>> +
>>> +// Global MAC control register
>>> +#define GSW_REG_GMACCR 0x30E0
>>> +
>>> #define SYSC_REG_CHIP_REV_ID 0x0c
>>> #define SYSC_REG_CFG1 0x14
>>> #define RST_CTRL_MCM BIT(2)
>>> diff --git a/drivers/net/ethernet/mediatek/gsw_mt7621.c
>>> b/drivers/net/ethernet/mediatek/gsw_mt7621.c
>>> index 96280b4..db5d56d 100644
>>> --- a/drivers/net/ethernet/mediatek/gsw_mt7621.c
>>> +++ b/drivers/net/ethernet/mediatek/gsw_mt7621.c
>>> @@ -99,17 +99,20 @@ static void mt7621_hw_init(struct mt7620_gsw *gsw,
>>> struct device_node *np)
>>> usleep_range(10, 20);
>>>
>>> if ((rt_sysc_r32(SYSC_REG_CHIP_REV_ID) & 0x) == 0x0101) {
>>> - /* (GE1, Force 1000M/FD, FC ON, MAX_RX_LENGTH 1536) */
>>> - mtk_switch_w32(gsw, 0x2105e30b, 0x100);
>>> + /* (GE1, Force 1000M/FD, FC ON, MAX_RX_LENGTH 2k) */
>>> + mtk_switch_w32(gsw, 0x2305e30b, GSW_REG_MAC_P0_MCR);
>>> mt7530_mdio_w32(gsw, 0x3600, 0x5e30b);
>>> } else {
>>> - /* (GE1, Force 1000M/FD, FC ON, MAX_RX_LENGTH 1536) */
>>> - mtk_switch_w32(gsw, 0x2105e33b, 0x100);
>>> + /* (GE1, Force 1000M/FD, FC ON, MAX_RX_LENGTH 2k) */
>>> + mtk_switch_w32(gsw, 0x2305e33b, GSW_REG_MAC_P0_MCR);
>>> mt7530_mdio_w32(gsw, 0x3600, 0x5e33b);
>>> }
>>>
>>> /* (GE2, Link down) */
>>> - mtk_switch_w32(gsw, 0x8000, 0x200);
>>> + mtk_switch_w32(gsw, 0x8000, GSW_REG_MAC_P1_MCR);
>>> +
>>> + /* Set switch max RX frame length to 2k */
>>> + mt7530_mdio_w32(gsw, GSW_REG_GMACCR, 0x3F0B);
>>>
>>> /* Enable Port 6, P5 as GMAC5, P5 disable */
>>> val = mt7530_mdio_r32(gsw, 0x7804);
>>> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
>>> b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
>>> index 48eda44..5edafa6 100644
>>> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
>>> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
>>> @@ -37,7 +37,7 @@
>>> #include "mdio.h"
>>> #include "ethtool.h"
>>>
>>> -#define MAX_RX_LENGTH 1536
>>> +#define MAX_RX_LENGTH 2048
>>> #define FE_RX_ETH_HLEN (VLAN_ETH_HLEN + VLAN_HLEN + ETH_FCS_LEN)
>>> #define FE_RX_HLEN (NET_SKB_PAD + FE_RX_ETH_HLEN + NET_IP_ALIGN)
>>> #define DMA_DUMMY_DESC 0x
>>> @@ -1358,11 +1358,29 @@ static int fe_do_ioctl(struct net_device *dev,
>>> struct ifreq *ifr,
Re: [LEDE-DEV] MT7621 support Jumbo frames
I have never applied patches before, so I am probably making mistakes.
The first problem I'm running into, is that it is trying to patch the
following file:
/drivers/net/ethernet/mediatek/gsw_mt7620.h
However, such a file does not exist in that path in my build_dir. I
can find gsw_mt7620.c and gsw_mt7620.o files just fine in the
aforementioned path, but not the .h file it is trying to patch. To
which branch does the patch apply cleanly? I am currently trying to
patch the master branch. Should I try the 17.01 branch instead?
On Wed, Apr 19, 2017 at 10:32 AM, Jaap Buurman wrote:
> Ah, that sounds even better :) I will try to compile and test this
> patch tomorrow or the day after tomorrow. Will let you know if it
> works. Thanks again for the effort you're putting into this!
>
> On Wed, Apr 19, 2017 at 10:23 AM, Gaetano Catalli
> wrote:
>> I'm still working on this since I would like to raise the limit up to
>> 9KB if possible. Please, let me know if this works for you.
>>
>> On Wed, Apr 19, 2017 at 10:18 AM, Jaap Buurman wrote:
>>> Wow, this is perfect. Thank you very much. I will try to use this
>>> patch and compile my own image with up to 2kb frame support. Do you
>>> have any plans on submitting this as a PR to the LEDE git?
>>>
>>> On Wed, Apr 19, 2017 at 9:32 AM, Gaetano Catalli
>>> wrote:
>>>> I've been working on this for a while. Apparently the embedded 5-port
>>>> gigabit switch is able to handle packets with size up to 15KB. On the
>>>> contrary, the GMAC, to which the switch is attached, has a limit of
>>>> 2KB. The following is a patch that changes the max recv frame length
>>>> to 2KB and allows to set the MTU up to that value. It is based on
>>>> kernel 4.4.7.
>>>>
>>>> Signed-off-by: Gaetano Catalli
>>>> ---
>>>> drivers/net/ethernet/mediatek/gsw_mt7620.h | 6 +
>>>> drivers/net/ethernet/mediatek/gsw_mt7621.c | 13 +++
>>>> drivers/net/ethernet/mediatek/mtk_eth_soc.c | 36
>>>> ++---
>>>> drivers/net/ethernet/mediatek/mtk_eth_soc.h | 1 +
>>>> drivers/net/ethernet/mediatek/soc_mt7621.c | 2 +-
>>>> 5 files changed, 39 insertions(+), 19 deletions(-)
>>>>
>>>> diff --git a/drivers/net/ethernet/mediatek/gsw_mt7620.h
>>>> b/drivers/net/ethernet/mediatek/gsw_mt7620.h
>>>> index dcef9a8..ce3cd10 100644
>>>> --- a/drivers/net/ethernet/mediatek/gsw_mt7620.h
>>>> +++ b/drivers/net/ethernet/mediatek/gsw_mt7620.h
>>>> @@ -45,6 +45,12 @@
>>>> #define GSW_REG_ISR 0x700c
>>>> #define GSW_REG_GPC1 0x7014
>>>>
>>>> +#define GSW_REG_MAC_P0_MCR 0x100
>>>> +#define GSW_REG_MAC_P1_MCR 0x200
>>>> +
>>>> +// Global MAC control register
>>>> +#define GSW_REG_GMACCR 0x30E0
>>>> +
>>>> #define SYSC_REG_CHIP_REV_ID 0x0c
>>>> #define SYSC_REG_CFG1 0x14
>>>> #define RST_CTRL_MCM BIT(2)
>>>> diff --git a/drivers/net/ethernet/mediatek/gsw_mt7621.c
>>>> b/drivers/net/ethernet/mediatek/gsw_mt7621.c
>>>> index 96280b4..db5d56d 100644
>>>> --- a/drivers/net/ethernet/mediatek/gsw_mt7621.c
>>>> +++ b/drivers/net/ethernet/mediatek/gsw_mt7621.c
>>>> @@ -99,17 +99,20 @@ static void mt7621_hw_init(struct mt7620_gsw *gsw,
>>>> struct device_node *np)
>>>> usleep_range(10, 20);
>>>>
>>>> if ((rt_sysc_r32(SYSC_REG_CHIP_REV_ID) & 0x) == 0x0101) {
>>>> - /* (GE1, Force 1000M/FD, FC ON, MAX_RX_LENGTH 1536) */
>>>> - mtk_switch_w32(gsw, 0x2105e30b, 0x100);
>>>> + /* (GE1, Force 1000M/FD, FC ON, MAX_RX_LENGTH 2k) */
>>>> + mtk_switch_w32(gsw, 0x2305e30b, GSW_REG_MAC_P0_MCR);
>>>> mt7530_mdio_w32(gsw, 0x3600, 0x5e30b);
>>>> } else {
>>>> - /* (GE1, Force 1000M/FD, FC ON, MAX_RX_LENGTH 1536) */
>>>> - mtk_switch_w32(gsw, 0x2105e33b, 0x100);
>>>> + /* (GE1, Force 1000M/FD, FC ON, MAX_RX_LENGTH 2k) */
>>>> + mtk_switch_w32(gsw, 0x2305e33b, GSW_REG_MAC_P0_MCR);
>>>> mt7530_mdio_w32(gsw, 0x3600, 0x5e33b);
>>>> }
>>>>
>>>> /* (GE2, Link down) */
>>>> - mtk_switch_w32(gsw, 0x8000, 0x200);
>>>> + mtk_switch_w32(gsw, 0x8000, GSW_REG_MAC_P1_MCR);
>>>> +
>>>> + /* Set switch max RX frame length to 2k */
>>>> + mt7530_mdio_w32(gsw, GSW_REG_GMACCR, 0x3F0B);
>>>>
>>>> /
Re: [LEDE-DEV] MT7621 support Jumbo frames
Thank you all for the suggestions. I've tried the following steps: 1) Add the patch in a file with a name so that it will be added last: 999-mtu.patch. This failed during the build. 2) Next, I wanted to write these changes manually to a patch with quilt. However, the file /drivers/net/ethernet/mediatek/gsw_mt7620.h was not there, so I could not apply those changes manually either. That was the only file that gave me issues. The other files could be found in the build_dir, and thus I could apply all the changes manually. So that's where I'm stuck at the moment. On Sun, Apr 23, 2017 at 11:34 AM, Alberto Bursi wrote: > That patch is a raw kernel patch, you need to integrate it in LEDE's > buildsystem and hope that he is working with LEDE patches already applied. > > Copy the patch's text in a text file and place this file in the /patches-* > folder in your device's source folder > > Your SoC is a ramips so it should be target/linux/ramips/patches-4.4 as he > said it is for kernel 4.4.7 > > Give it a name that makes sure it will be added last, like 999-mypatch.patch > > Then you can select your device with make menuconfig and then start a > compilation with make and see if it goes well. > > If that fails, you need to follow the tutorial as linked, and create a new > kernel patch where you write these changes manually to each file he changed, > then save the new patch, and then move the patch file you created from the > quilt kernel patch folder (platform/) to the patch folder as said above. > > There might be better ways, but that's what I did when I had to add new > kernel patches. > > -Alberto > > > On 04/22/2017 01:53 PM, Jaap Buurman wrote: > > I have never applied patches before, so I am probably making mistakes. > The first problem I'm running into, is that it is trying to patch the > following file: > > /drivers/net/ethernet/mediatek/gsw_mt7620.h > > However, such a file does not exist in that path in my build_dir. I > can find gsw_mt7620.c and gsw_mt7620.o files just fine in the > aforementioned path, but not the .h file it is trying to patch. To > which branch does the patch apply cleanly? I am currently trying to > patch the master branch. Should I try the 17.01 branch instead? > > On Wed, Apr 19, 2017 at 10:32 AM, Jaap Buurman > wrote: > > Ah, that sounds even better :) I will try to compile and test this > patch tomorrow or the day after tomorrow. Will let you know if it > works. Thanks again for the effort you're putting into this! > > On Wed, Apr 19, 2017 at 10:23 AM, Gaetano Catalli > wrote: > > I'm still working on this since I would like to raise the limit up to > 9KB if possible. Please, let me know if this works for you. > > On Wed, Apr 19, 2017 at 10:18 AM, Jaap Buurman > wrote: > > Wow, this is perfect. Thank you very much. I will try to use this > patch and compile my own image with up to 2kb frame support. Do you > have any plans on submitting this as a PR to the LEDE git? > > On Wed, Apr 19, 2017 at 9:32 AM, Gaetano Catalli > wrote: > > I've been working on this for a while. Apparently the embedded 5-port > gigabit switch is able to handle packets with size up to 15KB. On the > contrary, the GMAC, to which the switch is attached, has a limit of > 2KB. The following is a patch that changes the max recv frame length > to 2KB and allows to set the MTU up to that value. It is based on > kernel 4.4.7. > > Signed-off-by: Gaetano Catalli > --- > drivers/net/ethernet/mediatek/gsw_mt7620.h | 6 + > drivers/net/ethernet/mediatek/gsw_mt7621.c | 13 +++ > drivers/net/ethernet/mediatek/mtk_eth_soc.c | 36 > ++--- > drivers/net/ethernet/mediatek/mtk_eth_soc.h | 1 + > drivers/net/ethernet/mediatek/soc_mt7621.c | 2 +- > 5 files changed, 39 insertions(+), 19 deletions(-) > > diff --git a/drivers/net/ethernet/mediatek/gsw_mt7620.h > b/drivers/net/ethernet/mediatek/gsw_mt7620.h > index dcef9a8..ce3cd10 100644 > --- a/drivers/net/ethernet/mediatek/gsw_mt7620.h > +++ b/drivers/net/ethernet/mediatek/gsw_mt7620.h > @@ -45,6 +45,12 @@ > #define GSW_REG_ISR 0x700c > #define GSW_REG_GPC1 0x7014 > > +#define GSW_REG_MAC_P0_MCR 0x100 > +#define GSW_REG_MAC_P1_MCR 0x200 > + > +// Global MAC control register > +#define GSW_REG_GMACCR 0x30E0 > + > #define SYSC_REG_CHIP_REV_ID 0x0c > #define SYSC_REG_CFG1 0x14 > #define RST_CTRL_MCM BIT(2) > diff --git a/drivers/net/ethernet/mediatek/gsw_mt7621.c > b/drivers/net/ethernet/mediatek/gsw_mt7621.c > index 96280b4..db5d56d 100644 > --- a/drivers/net/ethernet/mediatek/gsw_mt7621.c > +++ b/drivers/net/ethernet/mediatek/gsw_mt7621.c > @@ -99,17 +99,20 @@ s
Re: [LEDE-DEV] MT7621 support Jumbo frames
The mediatek folder is not there by default. It gets generated in the during the "make" command when compiling the image by the patches. It can be found at the following full path: source/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7621/linux-4.4.61/drivers/net/ethernet/mediatek I will try if I can patch the 17.01 branch. Does anyone have an idea why gsw_mt7620.h is missing from the master branch? On Sun, Apr 23, 2017 at 2:30 PM, Alberto Bursi wrote: > Weird, I'm not seeing the whole "mediatek" folder if I try to follow > your steps from a fresh source download with LEDE master (trunk/HEAD, > whatever). > > I've checked the LEDE 17.01 branch and yes, there the "mediatek" folder > is there and also that file. Kernel version is the same for both, > 4.4.61, and that "mediatek" folder isn't there in the source package > downloaded so it must come from LEDE patches. > > So go in main source folder and write "git checkout lede-17.01" then it > should work. > > -Alberto > > > On 04/23/2017 12:52 PM, Jaap Buurman wrote: >> Thank you all for the suggestions. I've tried the following steps: >> >> 1) Add the patch in a file with a name so that it will be added last: >> 999-mtu.patch. This failed during the build. >> 2) Next, I wanted to write these changes manually to a patch with >> quilt. However, the file /drivers/net/ethernet/mediatek/gsw_mt7620.h >> was not there, so I could not apply those changes manually either. >> That was the only file that gave me issues. The other files could be >> found in the build_dir, and thus I could apply all the changes >> manually. So that's where I'm stuck at the moment. >> >> On Sun, Apr 23, 2017 at 11:34 AM, Alberto Bursi >> wrote: >>> That patch is a raw kernel patch, you need to integrate it in LEDE's >>> buildsystem and hope that he is working with LEDE patches already applied. >>> >>> Copy the patch's text in a text file and place this file in the /patches-* >>> folder in your device's source folder >>> >>> Your SoC is a ramips so it should be target/linux/ramips/patches-4.4 as he >>> said it is for kernel 4.4.7 >>> >>> Give it a name that makes sure it will be added last, like 999-mypatch.patch >>> >>> Then you can select your device with make menuconfig and then start a >>> compilation with make and see if it goes well. >>> >>> If that fails, you need to follow the tutorial as linked, and create a new >>> kernel patch where you write these changes manually to each file he changed, >>> then save the new patch, and then move the patch file you created from the >>> quilt kernel patch folder (platform/) to the patch folder as said above. >>> >>> There might be better ways, but that's what I did when I had to add new >>> kernel patches. >>> >>> -Alberto >>> >>> >>> On 04/22/2017 01:53 PM, Jaap Buurman wrote: >>> >>> I have never applied patches before, so I am probably making mistakes. >>> The first problem I'm running into, is that it is trying to patch the >>> following file: >>> >>> /drivers/net/ethernet/mediatek/gsw_mt7620.h >>> >>> However, such a file does not exist in that path in my build_dir. I >>> can find gsw_mt7620.c and gsw_mt7620.o files just fine in the >>> aforementioned path, but not the .h file it is trying to patch. To >>> which branch does the patch apply cleanly? I am currently trying to >>> patch the master branch. Should I try the 17.01 branch instead? >>> >>> On Wed, Apr 19, 2017 at 10:32 AM, Jaap Buurman >>> wrote: >>> >>> Ah, that sounds even better :) I will try to compile and test this >>> patch tomorrow or the day after tomorrow. Will let you know if it >>> works. Thanks again for the effort you're putting into this! >>> >>> On Wed, Apr 19, 2017 at 10:23 AM, Gaetano Catalli >>> wrote: >>> >>> I'm still working on this since I would like to raise the limit up to >>> 9KB if possible. Please, let me know if this works for you. >>> >>> On Wed, Apr 19, 2017 at 10:18 AM, Jaap Buurman >>> wrote: >>> >>> Wow, this is perfect. Thank you very much. I will try to use this >>> patch and compile my own image with up to 2kb frame support. Do you >>> have any plans on submitting this as a PR to the LEDE git? >>> >>> On Wed, Apr 19, 2017 at 9:32 AM, Gaetano Catalli >>> wro
Re: [LEDE-DEV] MT7621 support Jumbo frames
Excuse me for my lack of experience with the patches. It turned out the patch was just fine, but gmail probably messed up the formatting. Thank you all very much for the links to the informative patches guides. I created my own patch with quilt and applied all the changes to the source manually. This allowed me to create a patch file with the proper formatting, which applied just fine. @Gaetano Catalli Very good job at the patch! It is working flawlessly for me in the limited amount of testing that I did. If there is anything else I can help you with, just let me know. I posted my MTU test results in the following Lede forum topic: https://forum.lede-project.org/t/build-for-the-d-link-dir-860l/948/62 On Sun, Apr 23, 2017 at 2:42 PM, Jaap Buurman wrote: > The mediatek folder is not there by default. It gets generated in the > during the "make" command when compiling the image by the patches. It > can be found at the following full path: > > source/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7621/linux-4.4.61/drivers/net/ethernet/mediatek > > I will try if I can patch the 17.01 branch. Does anyone have an idea > why gsw_mt7620.h is missing from the master branch? > > On Sun, Apr 23, 2017 at 2:30 PM, Alberto Bursi > wrote: >> Weird, I'm not seeing the whole "mediatek" folder if I try to follow >> your steps from a fresh source download with LEDE master (trunk/HEAD, >> whatever). >> >> I've checked the LEDE 17.01 branch and yes, there the "mediatek" folder >> is there and also that file. Kernel version is the same for both, >> 4.4.61, and that "mediatek" folder isn't there in the source package >> downloaded so it must come from LEDE patches. >> >> So go in main source folder and write "git checkout lede-17.01" then it >> should work. >> >> -Alberto >> >> >> On 04/23/2017 12:52 PM, Jaap Buurman wrote: >>> Thank you all for the suggestions. I've tried the following steps: >>> >>> 1) Add the patch in a file with a name so that it will be added last: >>> 999-mtu.patch. This failed during the build. >>> 2) Next, I wanted to write these changes manually to a patch with >>> quilt. However, the file /drivers/net/ethernet/mediatek/gsw_mt7620.h >>> was not there, so I could not apply those changes manually either. >>> That was the only file that gave me issues. The other files could be >>> found in the build_dir, and thus I could apply all the changes >>> manually. So that's where I'm stuck at the moment. >>> >>> On Sun, Apr 23, 2017 at 11:34 AM, Alberto Bursi >>> wrote: >>>> That patch is a raw kernel patch, you need to integrate it in LEDE's >>>> buildsystem and hope that he is working with LEDE patches already applied. >>>> >>>> Copy the patch's text in a text file and place this file in the /patches-* >>>> folder in your device's source folder >>>> >>>> Your SoC is a ramips so it should be target/linux/ramips/patches-4.4 as he >>>> said it is for kernel 4.4.7 >>>> >>>> Give it a name that makes sure it will be added last, like >>>> 999-mypatch.patch >>>> >>>> Then you can select your device with make menuconfig and then start a >>>> compilation with make and see if it goes well. >>>> >>>> If that fails, you need to follow the tutorial as linked, and create a new >>>> kernel patch where you write these changes manually to each file he >>>> changed, >>>> then save the new patch, and then move the patch file you created from the >>>> quilt kernel patch folder (platform/) to the patch folder as said above. >>>> >>>> There might be better ways, but that's what I did when I had to add new >>>> kernel patches. >>>> >>>> -Alberto >>>> >>>> >>>> On 04/22/2017 01:53 PM, Jaap Buurman wrote: >>>> >>>> I have never applied patches before, so I am probably making mistakes. >>>> The first problem I'm running into, is that it is trying to patch the >>>> following file: >>>> >>>> /drivers/net/ethernet/mediatek/gsw_mt7620.h >>>> >>>> However, such a file does not exist in that path in my build_dir. I >>>> can find gsw_mt7620.c and gsw_mt7620.o files just fine in the >>>> aforementioned path, but not the .h file it is trying to patch. To >>>> which branch does the patch apply cleanly? I am currently trying to >
Re: [LEDE-DEV] mt7621 cpu stalls - need help testing
Dear John, This patch sounds very very promising! I will compile and test this first come this weekend. Thank you so very much for having a look at this issue :) Yours sincerely, Jaap ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] mt7621 cpu stalls - need help testing
Dear John, I haven't had time to test it yet myself, but in the previously mentioned topic by Bart van Zoest there have already been two reports of crashing devices with SQM cake enabled unfortunately. One of the posters provided a stack trace, which hopefully will be useful in debugging the issue: Applied blogic's patches to both current snapshot and 17.01, and tested with both fq_codel and cake. After fidling for a bit with the limits it looked like the bug was fixed, but sadly no. About 300mbit ingress/egress does the trick, and after ~15/20minutes and some heavy downloading, reboots and crashes happen. [ 945.72] INFO: rcu_sched detected stalls on CPUs/tasks: [ 945.73] 1-...: (21 GPs behind) idle=a22/0/0 softirq=25119/25120 fqs=1 [ 945.74] (detected by 3, t=6004 jiffies, g=3848, c=3847, q=313) [ 945.75] Task dump for CPU 1: [ 945.76] swapper/1 R running 0 0 1 0x0010 [ 945.77] Stack : 87c4b180 00dc 00c2 804db2a4 8049 [ 945.77] 8048874c 0001 0001 80488540 80488724 8049 8049 8000c0e0 [ 945.77] 1100fc03 0001 87c7 87c71ec0 8049 8000c410 1100fc03 0001 [ 945.77] 804db2a4 8049 804db2a4 8005ed68 8049 8001b2f8 1100fc03 [ 945.77] 0004 804884a0 00a0 8001b300 c939c939 c939c939 c939c939 c939c939 [ 945.77] ... [ 945.84] Call Trace: [ 945.85] [<8000be98>] __schedule+0x574/0x758 [ 945.86] [<8000c0e0>] schedule+0x64/0x7c [ 945.87] [<8000c410>] schedule_preempt_disabled+0x10/0x1c [ 945.88] [<8005ed68>] cpu_startup_entry+0x11c/0x1b8 [ 945.89] [<8001b300>] start_secondary+0x440/0x470 [ 945.90] [ 945.90] rcu_sched kthread starved for 6019 jiffies! g3848 c3847 f0x0 s3 ->state=0x1 Hopefully this information will be helpful! I believe we are on the right track, since with 300mbit it would normally crash within seconds for me. For this poster it took 15-20 minutes, which is quite impressive already. Yours sincerely, Jaap On Fri, Jun 30, 2017 at 1:47 PM, bart van zoest wrote: > Hi John and the rest, > > This is great news! Hopefully this will solve the problems of the > people owning mt7621 with SQM QoS! > I have compiled a build with your revised patch for the D-Link > DIR-860L B1 located at > https://forum.lede-project.org/t/optimized-build-for-the-d-link-dir-860l/948 > for the people wanting to test it. > Hopefully, there will be testers and feedback soon! > > Regards, > Bart > > On Thu, Jun 29, 2017 at 8:56 PM, John Crispin wrote: >> >> >> On 29/06/17 20:14, Jaap Buurman wrote: >>> >>> Dear John, >>> >>> This patch sounds very very promising! I will compile and test this >>> first come this weekend. Thank you so very much for having a look at >>> this issue :) >>> >>> Yours sincerely, >>> >>> Jaap >>> >>> ___ >>> Lede-dev mailing list >>> Lede-dev@lists.infradead.org >>> http://lists.infradead.org/mailman/listinfo/lede-dev >> >> i pushed a bad patch, please use this instead >> >> https://git.lede-project.org/?p=lede/blogic/staging.git;a=commit;h=c05efda56aecea0f0f52a000a3ce271775b5fb24 >> >> i'll provide a v4.9 version tomorrow >> >> 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
Re: [LEDE-DEV] mt7621 cpu stalls - need help testing
Dear all, I just had time to test it myself and I can confirm that SQM cake is still crashing the router. Hopefully we do have a nice lead now where to look for the issue. If any more testing is needed in the future, please let me know. Thank you very much again for your time and effort, John! Kind regards, Jaap On Sat, Jul 1, 2017 at 11:29 AM, Jaap Buurman wrote: > Dear John, > > I haven't had time to test it yet myself, but in the previously > mentioned topic by Bart van Zoest there have already been two reports > of crashing devices with SQM cake enabled unfortunately. > > One of the posters provided a stack trace, which hopefully will be > useful in debugging the issue: > > > Applied blogic's patches to both current snapshot and 17.01, and > tested with both fq_codel and cake. > After fidling for a bit with the limits it looked like the bug was > fixed, but sadly no. About 300mbit ingress/egress does the trick, and > after ~15/20minutes and some heavy downloading, reboots and crashes > happen. > > [ 945.72] INFO: rcu_sched detected stalls on CPUs/tasks: > [ 945.73] 1-...: (21 GPs behind) idle=a22/0/0 softirq=25119/25120 fqs=1 > [ 945.74] (detected by 3, t=6004 jiffies, g=3848, c=3847, q=313) > [ 945.75] Task dump for CPU 1: > [ 945.76] swapper/1 R running 0 0 1 0x0010 > [ 945.77] Stack : 87c4b180 00dc 00c2 > 804db2a4 8049 > [ 945.77] 8048874c 0001 0001 80488540 80488724 8049 > 8049 8000c0e0 > [ 945.77] 1100fc03 0001 87c7 87c71ec0 8049 8000c410 > 1100fc03 0001 > [ 945.77] 804db2a4 8049 804db2a4 8005ed68 8049 8001b2f8 > 1100fc03 > [ 945.77] 0004 804884a0 00a0 8001b300 c939c939 c939c939 > c939c939 c939c939 > [ 945.77] ... > [ 945.84] Call Trace: > [ 945.85] [<8000be98>] __schedule+0x574/0x758 > [ 945.86] [<8000c0e0>] schedule+0x64/0x7c > [ 945.87] [<8000c410>] schedule_preempt_disabled+0x10/0x1c > [ 945.88] [<8005ed68>] cpu_startup_entry+0x11c/0x1b8 > [ 945.89] [<8001b300>] start_secondary+0x440/0x470 > [ 945.90] > [ 945.90] rcu_sched kthread starved for 6019 jiffies! g3848 c3847 > f0x0 s3 ->state=0x1 > > > Hopefully this information will be helpful! I believe we are on the > right track, since with 300mbit it would normally crash within seconds > for me. For this poster it took 15-20 minutes, which is quite > impressive already. > > Yours sincerely, > > Jaap > > On Fri, Jun 30, 2017 at 1:47 PM, bart van zoest > wrote: >> Hi John and the rest, >> >> This is great news! Hopefully this will solve the problems of the >> people owning mt7621 with SQM QoS! >> I have compiled a build with your revised patch for the D-Link >> DIR-860L B1 located at >> https://forum.lede-project.org/t/optimized-build-for-the-d-link-dir-860l/948 >> for the people wanting to test it. >> Hopefully, there will be testers and feedback soon! >> >> Regards, >> Bart >> >> On Thu, Jun 29, 2017 at 8:56 PM, John Crispin wrote: >>> >>> >>> On 29/06/17 20:14, Jaap Buurman wrote: >>>> >>>> Dear John, >>>> >>>> This patch sounds very very promising! I will compile and test this >>>> first come this weekend. Thank you so very much for having a look at >>>> this issue :) >>>> >>>> Yours sincerely, >>>> >>>> Jaap >>>> >>>> ___ >>>> Lede-dev mailing list >>>> Lede-dev@lists.infradead.org >>>> http://lists.infradead.org/mailman/listinfo/lede-dev >>> >>> i pushed a bad patch, please use this instead >>> >>> https://git.lede-project.org/?p=lede/blogic/staging.git;a=commit;h=c05efda56aecea0f0f52a000a3ce271775b5fb24 >>> >>> i'll provide a v4.9 version tomorrow >>> >>> 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
Re: [LEDE-DEV] kernel version status
Dear Hauke, Quick question from my side: I was wondering why Ramips will probably stay with 4.9, even though the patches for 4.14 have been in master for quite a while. Since flow_offload is part of master, and it requires 4.14, I think 4.14 would be a very welcome addition for Ramips. My 2 cents :) Yours sincerely, Jaap Buurman ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] kernel version status
Dear John Crispin and Felix Fietkau, Could either of you please consider moving the Ramips target to kernel 4.14 before the fork to 18.04 happens? Without it, the new flow_offload goodies won't be usable on Ramips, which would be a shame in my opinion. Or are there good reasons to keep the target on kernel 4.9 for now? Yours sincerely, Jaap Buurman On Mon, Apr 2, 2018 at 2:11 PM, Hauke Mehrtens wrote: > On 04/02/2018 10:54 AM, Jaap Buurman wrote: >> Dear Hauke, >> >> Quick question from my side: I was wondering why Ramips will probably >> stay with 4.9, even though the patches for 4.14 have been in master >> for quite a while. Since flow_offload is part of master, and it >> requires 4.14, I think 4.14 would be a very welcome addition for >> Ramips. My 2 cents :) >> >> Yours sincerely, >> >> Jaap Buurman > > Hi Jaap, > > I do not know what Felix's and John's plans are for this target. Fi this > should go to kernel 4.14 we should switch soon. > > Hauke ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [Make-wifi-fast] ath9k airtime fairness stabiity issues?
Hi all, According to Dave Täht the following code disables Airtime Fairness: for i in /sys/kernel/debug/ieee80211/phy*/*/airtime_flags do echo 0 > $i done Wouldn't it be a good idea to ship Lede with ATF baked in, but disabled at default? That would allow end-users to easily enable ATF. Since enabling ATF takes some work, people without the knowledge wouldn't accidentally enable this feature and run into possible instability issues. But at the same time, this would enable tech savvy people to experiment. There are reports of people running their networks with ATF enabled for weeks with no issues whatsoever, so if there are instability issues it might not be as widespread as one would think. There is an interesting discussion going on here: https://bugs.lede-project.org/index.php?do=details&task_id=368 I'm curious to your thoughts! ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] LEDE-17.01 Final Release Notes available
Great job on the release notes! One minor thing that I think looks nicer would be the removal of "nothing specific" after "improved performance", since it adds no additional information. But that's just me. Also about the following: "Improvements to the WiFi stack eliminating bufferbloat on ath9k (and some ath10k) chipsets" Is this about the Airtime Fairness Patch? AFAIK this is only for ath9k and not for ath10k? Or am I mixing things up here? While're talking about 17.01 anyway when are the first RCs coming out btw? :) ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] LEDE-17.01 Final Release Notes available
Thank you very much for the clarification. That makes a lot of sense. Do you happen to know where the mt76 driver stands with respect to these different phases? I am in the market for a new router, and due to the openness of the driver I'm currently looking at a mediatek based platform, namely the dir-860l rev b1. On Sun, Jan 29, 2017 at 6:33 AM, Weedy wrote: > On 28 January 2017 at 15:56, Rich Brown wrote: >> Hi Jaap, >> >>> On Jan 28, 2017, at 6:36 AM, Jaap Buurman wrote: >>> Also about the following: "Improvements to the WiFi stack eliminating >>> bufferbloat on ath9k (and some ath10k) chipsets" >>> >>> Is this about the Airtime Fairness Patch? AFAIK this is only for ath9k >>> and not for ath10k? Or am I mixing things up here? >> >> I am not sure. I was hoping someone who has been following this more closely >> would weigh in. > > As far as I know the make-wifi-fast work was done in stages. Something like: > Phase 1: Reducing buffering all over the stack/drivers. Pretty sure > atk10k got some of this > Phase 2: Replace most/all txqueue stuff with fq_codel inside the > driver. I know Toke made patches for ath10k, I don't know if upstream > accepted them > Phase 3: Air time fairness stuff. Only for ath9k, and I don't know if > ath10k can ever get this since the chip firmware is basically a full > operating system and it does whatever it wants too. > > NB: I'm just a user, not a dev. But I like WiFi things and try to keep > informed. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] LEDE-17.01 Final Release Notes available
Thank you very much for the information! Actually, airtime fairness was added 3 days ago, both to the master branch and to the 17.01 branch as can be seen in this commit: https://git.lede-project.org/?p=source.git;a=commit;h=a6f3ea5e848fd6c23cf0af9fe7b6c9753a1bf2fe :) On Sun, Jan 29, 2017 at 2:46 PM, Toke Høiland-Jørgensen wrote: > Jaap Buurman writes: > >> Thank you very much for the clarification. That makes a lot of sense. >> Do you happen to know where the mt76 driver stands with respect to >> these different phases? I am in the market for a new router, and due >> to the openness of the driver I'm currently looking at a mediatek >> based platform, namely the dir-860l rev b1. > > The mt76 driver also uses the mac80211 debloated intermediate queues. So > yeah, maybe that should be mentioned in the announcement as well. > > As far as ath10k is concerned, the driver will use the intermediate > queues, but only if the hardware has certain capabilities. Hence the > wording in that bullet. > > The only thing that is ath9k-only is the airtime fairness patches. Which > are not in 17.01 anyway... > > -Toke ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] LEDE-17.01 Final Release Notes available
One more question if you don't mind :) With the "mac80211 debloated intermediate queues" do you also mean fq_codel (phase 2), or just phase 1? Also, has cake ever been tried instead of fq_codel to try and debloat wifi? On Sun, Jan 29, 2017 at 2:46 PM, Toke Høiland-Jørgensen wrote: > Jaap Buurman writes: > >> Thank you very much for the clarification. That makes a lot of sense. >> Do you happen to know where the mt76 driver stands with respect to >> these different phases? I am in the market for a new router, and due >> to the openness of the driver I'm currently looking at a mediatek >> based platform, namely the dir-860l rev b1. > > The mt76 driver also uses the mac80211 debloated intermediate queues. So > yeah, maybe that should be mentioned in the announcement as well. > > As far as ath10k is concerned, the driver will use the intermediate > queues, but only if the hardware has certain capabilities. Hence the > wording in that bullet. > > The only thing that is ath9k-only is the airtime fairness patches. Which > are not in 17.01 anyway... > > -Toke ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] OPKG Encryption
Hello all, Today I discovered that pulling packages from the feeds is done over http by default instead of https. I understand it is always going to be a trade-off between space requirements and features/security. However, pulling in packages over an unencrypted connection will allow for easy manipulation of the package's contents via a MITM attack. For a router that is going to run these packages, that stands between all your devices and the big bad internet that is an unacceptable trade-off in my opinion. The fix itself is quite easy and involves changing the lines in /etc/opkg/distfeeds.conf to https versions. Additionally, a package that can download over https such as wget + ca-certicates is needed. However, as you might already see, to fix this vulnerability you need to use the vulnerable component to install these packages. Or you need to pull in the packages via your computer, ssh it over to your router and install it manually. Or you need to compile these packages in. For the majority of the people they will not even be aware of this vulnerability, let alone know how to fix this in a safe way. I'd like to discuss whether it would be a good idea to make downloading over https via opkg default by changing the distfeed file and including the required packages. We might even decide to only do this on targets that are not starved for flash storage. Any opinions regarding this matter? Yours sincerely, Jaap Buurman ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] OPKG Encryption
Dear Alberto Bursi, I did not know about signature verification. I agree that there are no secrets to hide and hence signature verification should be sufficient to avoid tampering. Thank you very much for your reassurance. Yours sincerely, Jaap Buurman On Tue, Apr 17, 2018 at 10:13 AM, Alberto Bursi wrote: > > > On 17/04/2018 10:03, Jaap Buurman wrote: >> >> Hello all, >> >> Today I discovered that pulling packages from the feeds is done over >> http by default instead of https. > > > Just like many other distros (like say Debian that provides either http or > ftp mirrors) the packages themselves are signed and checked by opkg on > installation, so any MITM tampering will be detected and the package will > not be installed. There is no need to send packages over https as there are > no secrets being sent over, signatures are enough if you just need to avoid > tampering and MITM. > See wiki for details > > https://openwrt.org/docs/guide-user/security/security-features > > https://openwrt.org/docs/guide-user/security/release_signatures > > -Alberto ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] OPKG Encryption
Dear Sven, I wasn't aware of signature checking and hence I agree with yours and Jo-Philipp's sentiment that this would be a bad idea. Please disregard my suggestion. Thank you very much for teaching me about the signature verification system. Yours sincerely, Jaap Buurman On Tue, Apr 17, 2018 at 10:27 AM, Sven Eckelmann wrote: > On Dienstag, 17. April 2018 10:03:10 CEST Jaap Buurman wrote: >> Hello all, >> >> Today I discovered that pulling packages from the feeds is done over >> http by default instead of https. I understand it is always going to >> be a trade-off between space requirements and features/security. >> However, pulling in packages over an unencrypted connection will allow >> for easy manipulation of the package's contents via a MITM attack. For >> a router that is going to run these packages, that stands between all >> your devices and the big bad internet that is an unacceptable >> trade-off in my opinion. > [...] > > Are you aware of the Packages signature [1] and the sha256sums in the Packages > file? opkg is checking the signature [3] when the Packages file is downloaded. > The sha256sum is checked after the package was downloaded and before it was > installed [4] > > Kind regards, > Sven > > > [1] > https://downloads.openwrt.org/releases/17.01.4/targets/ar71xx/generic/packages/Packages.sig > [2] > https://downloads.openwrt.org/releases/17.01.4/targets/ar71xx/generic/packages/Packages > [3] > https://git.openwrt.org/?p=project/opkg-lede.git;a=blob;f=libopkg/opkg_cmd.c;h=c823df8b6006bffa2516443fab3718cd112ae3b3;hb=3b417b9f41b4ceb5912d82f867dd5534e5675b5c#l170 > [4] > https://git.openwrt.org/?p=project/opkg-lede.git;a=blob;f=libopkg/opkg_install.c;h=e6f8a1b6276ede518a5c59b2f9347f1de8e5dd7a;hb=3b417b9f41b4ceb5912d82f867dd5534e5675b5c#l1386 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] 18.06 Status?
Dear all, If a 18.06 release is still going to require quite a bit of work, I propose we should look at another 17.01 point release. That should be a nice stopgap in the form of bug fixes for people that are still running a stable release. 17.01.4 is getting ancient to be honest. What do you think? Yours sincerely, Jaap Buurman On Tue, May 1, 2018 at 2:53 PM, Rich Brown wrote: > Hi folks, > > It has been exactly a month since Hauke sent his note recommending a release > process for the next OpenWrt stable. > http://lists.infradead.org/pipermail/lede-dev/2018-April/011704.html I have > not seen any further discussion of this proposal. > > Given that the OpenWrt/LEDE merger was founded on the desire to improve > communication, I am concerned that we're not talking to each other about > important questions. > > It would be OK if we all agreed that we have too many pieces in flux to talk > about a stable release. But I don't think it's too soon to talk about pausing > the project evolution briefly and making the hard decisions about what's in, > what's out. Then most people (who're unwilling to run a snapshot) can get the > benefit of all your effort over the last year. > > Thanks for listening, > > Rich > > > > > > ___ > lede-adm mailing list > lede-...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-adm ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] 18.06 Status?
Hi all, I feel like everybody is just waiting for everybody to agree what features we want in before coming up with the next step of picking a date. Obviously this isn't working out very well. Why not turn things around? Pick a date in a few weeks time on which the Master branch will be split to a 18.0X branch. If nobody complains before that date the branch goes on as planned. People can obviously get in the features they want before said date. If somebody deems a particular feature very important to be included in this branch, but feels like it will not be finished before said date, he/she can request a delay stating: -What he/she would like to include -Why this is so important to be included before the branch. -How much extra time this will need by proposing a new date -Perhaps a request for help implementing said change Should this proposal be accepted, we will reschedule the date from there. If the other people don't think it is important enough to postpone the release, the old date will stand. This way, we can simply move forward if nobody complains about a particular date instead of the waiting around for others that is going on right now. What does everybody else think of this idea? What seems like a reasonable date? And who would be willing to take on the task of splitting the branch at said date to make sure we'll be actually moving forward with the plan at said date? Yours sincerely, Jaap Buurman On Wed, May 2, 2018 at 4:41 AM, Eric Luehrsen wrote: > On 05/01/2018 10:47 AM, Hannu Nyman wrote: >> >> I think that the main source tree is in pretty good shape, so branching >> off the 18.0X rather soon might make sense > > > I would also think its time to branch 18.[something-soon], and rather than > focus on work that needs yet to be completed, look to cut hardware and > packages that are not ready for a release. There is always some heart ache > when such decisions are made, but at a point those decisions do need to be > made. Without an official release to punctuate both the core team and other > packagers hard work, OpenWrt/LEDE could risk losing support from the > community and its limited sponsorship. I imagine this project means > something personally to the core team, so those risks should be considered. > > - Eric > > > ___ > lede-adm mailing list > lede-...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-adm ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
