[OpenWrt-Devel] Mac address randomization on rsPro ath79
I'm currently having some fun on master and noticed every reboot gives me random mac addresses. Never happened on ar71xx. LAN configuration config interface lan option ifname eth1 option type bridge option protodhcp option hostname 'repeater' option ipv6 0 config interface lanAlias option ifname br-lan option protostatic option ipaddr 192.168.69.1 option netmask 255.255.255.0 config interface lanEmerg option ifname eth0 option protostatic option ipaddr 192.168.42.1 option netmask 255.255.255.0 root@repeater:~# ifconfig br-lanLink encap:Ethernet HWaddr 1E:3C:CB:9D:D7:D7 inet addr:192.168.69.1 Bcast:192.168.69.255 Mask:255.255.255.0 ... eth0 Link encap:Ethernet HWaddr F6:1A:54:6F:68:23 inet addr:192.168.42.1 Bcast:192.168.42.255 Mask:255.255.255.0 ... Interrupt:4 eth1 Link encap:Ethernet HWaddr 1E:3C:CB:9D:D7:D7 ... Interrupt:5 root@repeater:~# ifconfig br-lanLink encap:Ethernet HWaddr 2A:F7:8A:0F:2A:65 inet addr:192.168.69.1 Bcast:192.168.69.255 Mask:255.255.255.0 ... eth0 Link encap:Ethernet HWaddr 2A:CE:6B:79:1E:B8 inet addr:192.168.42.1 Bcast:192.168.42.255 Mask:255.255.255.0 ... Interrupt:4 eth1 Link encap:Ethernet HWaddr 2A:F7:8A:0F:2A:65 ... Interrupt:5 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Package global config
On Tue, Oct 23, 2018 at 5:09 PM Etienne Champetier wrote: > > Hello OpenWRT devs, > > In zabbix package, I have 2 config options: > - ssl support > - db choice > https://github.com/openwrt/packages/blob/master/admin/zabbix/Makefile#L35 > > right now ssl support is "Package/zabbix-agentd/config" and db choice > is "Package/zabbix-server/config", > Is there a way to have the options global for the whole zabbix group > of packages ? I have a similar problem with transmission. I initially thought of removing the separate packages and have only the mbedTLS versions but have not made a decision yet. > > Thanks > Etienne > > ___ > 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
[OpenWrt-Devel] Package global config
Hello OpenWRT devs, In zabbix package, I have 2 config options: - ssl support - db choice https://github.com/openwrt/packages/blob/master/admin/zabbix/Makefile#L35 right now ssl support is "Package/zabbix-agentd/config" and db choice is "Package/zabbix-server/config", Is there a way to have the options global for the whole zabbix group of packages ? Thanks Etienne ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] kernel: tolerate using UBI/UBIFS on MLC flash (FS#1830)
Sorry, hit "Send" by accident
On Tuesday, October 23, 2018 2:37:16 PM CEST Koen Vandeputte wrote:
>
> On 22.10.18 19:27, Christian Lamparter wrote:
> > On Monday, October 22, 2018 3:48:29 PM CEST Koen Vandeputte wrote:
> >> On 20.10.18 17:46, Hauke Mehrtens wrote:
> >>> On 10/18/2018 02:28 PM, Koen Vandeputte wrote:
> starting from upstream commit 577b4eb23811 ("ubi: Reject MLC NAND")
> it is not allowed to use UBI and UBIFS on a MLC flavoured NAND flash
> chip. [1]
>
> According to David Oberhollenzer [2]:
>
> The real problem is that on MLC NAND, pages come in pairs.
>
> Multiple voltage levels inside a single, physical memory cell are used to
> encode more than one bit. Instead of just having pages that are twice as
> big,
> the flash exposes them as *two different pages*. Those pages are usually
> not
> ordered sequentially either, but according to a vendor/device specific
> pairing scheme.
>
> Within OpenWrt, devices utilizing this type of flash,
> combined with ubi(fs) will be bricked when a user upgrades
> from 17.01.4 to a newer version as the MLC will be refused.
>
> As these devices are currently advertised as supported by OpenWrt,
> we should at least maintain the original state during the lifecycle
> of the current releases.
>
> Support can be gracefully ended when a new release-branch is created.
>
> Signed-off-by: Koen Vandeputte
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v4.14.77&id=577b4eb23811dfc8e38924dc476dbc866be74253
> [2] https://lore.kernel.org/patchwork/patch/920344/
> ---
>
> Mainly intended for discussion first on this approach before applying it.
> Can be cherrypicked to 18.06.
>
> Feel free to drop your (n)ack on this approach
> >>> Have you checked if these are really MLC chips or if they are just
> >>> getting detected wrongly?
> >>> I think I saw some SPI NAND chips which a patched Linux detected as MLC
> >>> but the datasheet said they are SLC chips.
> >>>
> >>> Hauke
> >> Very good point.
> >> I've requested Mikrotik this morning to provide some details about the
> >> actual chips being used since the launch of that board ..
> > For the RB450/G you can take a look at the User Guide on their side:
> >
> >
> >
> > On Page 3 there's a "System Board View" with a bottom view of the PCB
> > and this is where the NAND chip is located. It reads:
> >
> > HY27UT084G2A
> >
> > This translates to:
> >
> >
> > HY27UT084G2A
> >
> >|||^--- T = MLC + Single Die + Large Block
> >||^---U = 2.7V~3.6V
> >|^---7 = NAND FLASH
> >^---2 = FLASH
> >
> > So, it is NAND MLC FLASH.
> >
> Received a reply from Mikrotik tech dept.:
>
>
> Hello,
>
> Mainly there are two possible NAND chips for RB450G:
> W29N04GVSIAA (see attachment);
> MT29F4G08ABADAWPD.
>
> Can you provide some device serial numbers?
>
>
> Best regards,
> Elans L.
>
>
>
>
> Checking the datasheets from both chips mentioned above shows they are both
> SLC flash.
> @Christian, do you have this board? Could you provide the serial?
No, luckily it isn't one of mine. But Mikrotik want to dig: I do have a serial
number
of an affected board: 1DFC018EF642.
I found it on the OpenWrt's Device wiki:
And interestingly enough, there's also a different list of
supported flash chips there:
Hynix NAND 512MiB 3,3V 8-bit (HY27UF082G2A, HY27UT084G2A) or Samsung 4Gibit
(K9F4G08U0B-PIB0
Regards,
Christian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] kernel: tolerate using UBI/UBIFS on MLC flash (FS#1830)
On Tuesday, October 23, 2018 2:37:16 PM CEST Koen Vandeputte wrote:
>
> On 22.10.18 19:27, Christian Lamparter wrote:
> > On Monday, October 22, 2018 3:48:29 PM CEST Koen Vandeputte wrote:
> >> On 20.10.18 17:46, Hauke Mehrtens wrote:
> >>> On 10/18/2018 02:28 PM, Koen Vandeputte wrote:
> starting from upstream commit 577b4eb23811 ("ubi: Reject MLC NAND")
> it is not allowed to use UBI and UBIFS on a MLC flavoured NAND flash
> chip. [1]
>
> According to David Oberhollenzer [2]:
>
> The real problem is that on MLC NAND, pages come in pairs.
>
> Multiple voltage levels inside a single, physical memory cell are used to
> encode more than one bit. Instead of just having pages that are twice as
> big,
> the flash exposes them as *two different pages*. Those pages are usually
> not
> ordered sequentially either, but according to a vendor/device specific
> pairing scheme.
>
> Within OpenWrt, devices utilizing this type of flash,
> combined with ubi(fs) will be bricked when a user upgrades
> from 17.01.4 to a newer version as the MLC will be refused.
>
> As these devices are currently advertised as supported by OpenWrt,
> we should at least maintain the original state during the lifecycle
> of the current releases.
>
> Support can be gracefully ended when a new release-branch is created.
>
> Signed-off-by: Koen Vandeputte
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v4.14.77&id=577b4eb23811dfc8e38924dc476dbc866be74253
> [2] https://lore.kernel.org/patchwork/patch/920344/
> ---
>
> Mainly intended for discussion first on this approach before applying it.
> Can be cherrypicked to 18.06.
>
> Feel free to drop your (n)ack on this approach
> >>> Have you checked if these are really MLC chips or if they are just
> >>> getting detected wrongly?
> >>> I think I saw some SPI NAND chips which a patched Linux detected as MLC
> >>> but the datasheet said they are SLC chips.
> >>>
> >>> Hauke
> >> Very good point.
> >> I've requested Mikrotik this morning to provide some details about the
> >> actual chips being used since the launch of that board ..
> > For the RB450/G you can take a look at the User Guide on their side:
> >
> >
> >
> > On Page 3 there's a "System Board View" with a bottom view of the PCB
> > and this is where the NAND chip is located. It reads:
> >
> > HY27UT084G2A
> >
> > This translates to:
> >
> >
> > HY27UT084G2A
> >
> >|||^--- T = MLC + Single Die + Large Block
> >||^---U = 2.7V~3.6V
> >|^---7 = NAND FLASH
> >^---2 = FLASH
> >
> > So, it is NAND MLC FLASH.
> >
> Received a reply from Mikrotik tech dept.:
>
>
> Hello,
>
> Mainly there are two possible NAND chips for RB450G:
> W29N04GVSIAA (see attachment);
> MT29F4G08ABADAWPD.
>
> Can you provide some device serial numbers?
>
>
> Best regards,
> Elans L.
>
>
>
>
> Checking the datasheets from both chips mentioned above shows they are both
> SLC flash.
> @Christian, do you have this board? Could you provide the serial?
No, luckily it isn't one of mine. But Mikrotik want to dig: I do have a serial
number
of an affected board: 1DFC018EF642.
I found it on the OpenWrt's Device wiki:
And interestingly enough, there's also a
. You can find this one on the OpenWrt WIKI
>
>
> Thanks,
>
> Koen
>
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar71xx snapshots stuck at October 9
On 23.10.18 14:56, w...@reboot.ch wrote: Hi, wondering why ar71xx snapshots are stuck at October 9 https://downloads.openwrt.org/snapshots/targets/ar71xx/generic/ Thank you! - will ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel This target got switched to kernel 4.14 around that date. The kernel is a bit too big for some boards to handle, causing snapshot builds. I'm currently working on it to get it up & running asap. Koen ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar71xx snapshots stuck at October 9
Hi, because they don't build since that date anymore. ~ Jo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] ar71xx snapshots stuck at October 9
Hi, wondering why ar71xx snapshots are stuck at October 9 https://downloads.openwrt.org/snapshots/targets/ar71xx/generic/ Thank you! - will ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] kernel: tolerate using UBI/UBIFS on MLC flash (FS#1830)
On 22.10.18 19:27, Christian Lamparter wrote:
On Monday, October 22, 2018 3:48:29 PM CEST Koen Vandeputte wrote:
On 20.10.18 17:46, Hauke Mehrtens wrote:
On 10/18/2018 02:28 PM, Koen Vandeputte wrote:
starting from upstream commit 577b4eb23811 ("ubi: Reject MLC NAND")
it is not allowed to use UBI and UBIFS on a MLC flavoured NAND flash chip. [1]
According to David Oberhollenzer [2]:
The real problem is that on MLC NAND, pages come in pairs.
Multiple voltage levels inside a single, physical memory cell are used to
encode more than one bit. Instead of just having pages that are twice as big,
the flash exposes them as *two different pages*. Those pages are usually not
ordered sequentially either, but according to a vendor/device specific
pairing scheme.
Within OpenWrt, devices utilizing this type of flash,
combined with ubi(fs) will be bricked when a user upgrades
from 17.01.4 to a newer version as the MLC will be refused.
As these devices are currently advertised as supported by OpenWrt,
we should at least maintain the original state during the lifecycle
of the current releases.
Support can be gracefully ended when a new release-branch is created.
Signed-off-by: Koen Vandeputte
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v4.14.77&id=577b4eb23811dfc8e38924dc476dbc866be74253
[2] https://lore.kernel.org/patchwork/patch/920344/
---
Mainly intended for discussion first on this approach before applying it.
Can be cherrypicked to 18.06.
Feel free to drop your (n)ack on this approach
Have you checked if these are really MLC chips or if they are just
getting detected wrongly?
I think I saw some SPI NAND chips which a patched Linux detected as MLC
but the datasheet said they are SLC chips.
Hauke
Very good point.
I've requested Mikrotik this morning to provide some details about the
actual chips being used since the launch of that board ..
For the RB450/G you can take a look at the User Guide on their side:
On Page 3 there's a "System Board View" with a bottom view of the PCB
and this is where the NAND chip is located. It reads:
HY27UT084G2A
This translates to:
HY27UT084G2A
|||^--- T = MLC + Single Die + Large Block
||^---U = 2.7V~3.6V
|^---7 = NAND FLASH
^---2 = FLASH
So, it is NAND MLC FLASH.
Received a reply from Mikrotik tech dept.:
Hello,
Mainly there are two possible NAND chips for RB450G:
W29N04GVSIAA (see attachment);
MT29F4G08ABADAWPD.
Can you provide some device serial numbers?
Best regards,
Elans L.
Checking the datasheets from both chips mentioned above shows they are both SLC
flash.
@Christian, do you have this board? Could you provide the serial?
Thanks,
Koen
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] IPv6 and comcast fails
Quoting Bjørn Mork : Dave Taht writes: We have confirmed fails for mips and x86 for even seeing any ipv6 traffic on a comcast uplink, thus dhcpv6pd fails. See: https://bugs.openwrt.org/index.php?do=details&task_id=1763 And https://forum.openwrt.org/t/openwrt-18-06-rc1-doesnt-obtain-ipv6-address/16759/6 It was bisected back a few months in the latter bug report. Which pointed to HW NAT offload for MT7621. Making a lot of sense so far. Except You say this is confirmed for x86? Lost me there, I'm afraid. Can you bisect this on x86? Can you confirm that "mips" is in fact *only* MT7621? Bjørn I seen a long thread on the Ubiquiti Edgerouter X/X-SPF (both with a MT7621 SOC) forum about this issue. https://community.ubnt.com/t5/EdgeRouter/Comcast-IPv6-issues-when-hwnat-enabled-on-ER-X/td-p/1850112 Greats, René ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] IPv6 and comcast fails
Dave Taht writes: > We have confirmed fails for mips and x86 for even seeing any > ipv6 traffic on a comcast uplink, thus dhcpv6pd fails. > > See: > > https://bugs.openwrt.org/index.php?do=details&task_id=1763 > > > And > > https://forum.openwrt.org/t/openwrt-18-06-rc1-doesnt-obtain-ipv6-address/16759/6 > > It was bisected back a few months in the latter bug report. Which pointed to HW NAT offload for MT7621. Making a lot of sense so far. Except You say this is confirmed for x86? Lost me there, I'm afraid. Can you bisect this on x86? Can you confirm that "mips" is in fact *only* MT7621? Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
