Re: [PATCH] sunxi: ensure NanoPi R1 has unique MAC address
Hi Jan-Niklas,
On 12/22/22 21:12, Jan-Niklas Burfeind wrote:
+generate_mac_from_mmc_cid()
+{
+ local mmc_dev=$1
+
+ local sd_hash=$(sha256sum/sys/class/block/$mmc_dev/device/cid)
+ local mac_base=$(macaddr_canonicalize "$(echo "${sd_hash}" | dd bs=1 count=12
2>/dev/null)")
+ echo "$(macaddr_unsetbit_mc "$(macaddr_setbit_la "${mac_base}")")"
+}
+
rename this function to macaddr_generate_from_mmc_cid and add it to the
base-files package.
Also change the other consumer from using its implementation to the shared one.
Best
David
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Secure cookie handling upon https to http downgrade
On 12/22/22 13:50, Oscar Hjelm wrote: I’m not familiar with the luci interface, but to help you get started: - One workaround would be to use a different cookie name on the new secure cookies (or a new name on the older cookies, if that is preferred). The two cookies could co-exist. Yes, thank you. I was able to rename the cookie to "sysauth-http" in the old code. This requires fixups in in 8 or so places to work properly, but seems to do the right thing. Setting the Secure flag is considered best-practice. However, if the end user deployment relies on self-signed certificates, then the security offered is low. A user is unfortunately likely to approve a certificate error and proceed anyway, leaking the session token to a potential attacker. There's no question that a lot of the security measures I'm taking are theater (see my previous posts), but the hoops have to be jumped through. And I think they'll help out others in the future. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] sunxi: ensure NanoPi R1 has unique MAC address
Ensure the MAC address for all NanoPi R1 boards is assigned unique for
each board.
The venor ships the device in two variants; one with and one without
eMMC; but both without static mac-addresses.
In order to assign both board types unique MAC addresses, fall back on
the same method used for the NanoPi R2S and R4S in case the EEPROM
chip is not present by generating the board MAC from the SD card CID.
[0] https://wiki.friendlyelec.com/wiki/index.php/NanoPi_R1#Hardware_Spec
Similar too and based on:
commit b5675f500daf ("rockchip: ensure NanoPi R4S has unique MAC address")
Co-authored-by: David Bauer
Signed-off-by: Jan-Niklas Burfeind
---
.../sunxi/base-files/etc/board.d/02_network | 34 +++
1 file changed, 34 insertions(+)
diff --git a/target/linux/sunxi/base-files/etc/board.d/02_network
b/target/linux/sunxi/base-files/etc/board.d/02_network
index 46ace1f67c..311699dfb5 100644
--- a/target/linux/sunxi/base-files/etc/board.d/02_network
+++ b/target/linux/sunxi/base-files/etc/board.d/02_network
@@ -29,6 +29,36 @@ sunxi_setup_interfaces()
esac
}
+generate_mac_from_mmc_cid()
+{
+ local mmc_dev=$1
+
+ local sd_hash=$(sha256sum /sys/class/block/$mmc_dev/device/cid)
+ local mac_base=$(macaddr_canonicalize "$(echo "${sd_hash}" | dd bs=1
count=12 2>/dev/null)")
+ echo "$(macaddr_unsetbit_mc "$(macaddr_setbit_la "${mac_base}")")"
+}
+
+nanopi_r1_get_mac()
+{
+ local interface=$1
+ local eeprom_path="/sys/bus/i2c/devices/2-0051/eeprom"
+ local address
+
+ if [ -f "$eeprom_path" ]; then
+ address=$(get_mac_binary "$eeprom_path" 0xfa)
+ if [ "$interface" = "lan" ]; then
+ address=$(macaddr_setbit_la "$address")
+ fi
+ else
+ address=$(generate_mac_from_mmc_cid mmcblk1)
+ if [ "$interface" = "lan" ]; then
+ address=$(macaddr_add "$address" 1)
+ fi
+ fi
+
+ echo "$address"
+}
+
sunxi_setup_macs()
{
local board="$1"
@@ -37,6 +67,10 @@ sunxi_setup_macs()
local label_mac=""
case "$board" in
+ friendlyarm,nanopi-r1)
+ wan_mac=$(nanopi_r1_get_mac wan)
+ lan_mac=$(nanopi_r1_get_mac lan)
+ ;;
friendlyarm,nanopi-r1s-h5)
lan_mac=$(get_mac_binary "/sys/bus/i2c/devices/0-0051/eeprom"
0xfa)
;;
--
2.39.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Ethernet switch with linux/openwrt and DSA
Hi Janusz, BTW, this switch have some issues with IPv6? Simple remove lan2 from switch/bridge and configure manually - connect my device directly to eth2 port. Seems IPv4 works correctly - while IPv6 not (ping6 ff02::1%lan2 - no answer). Same config (with removed lan2 from bridge) works perfectly with mt7530 (also dsa) on my mt7621 board. I just tested this on my HPE 1920-48G, and it works. But I'm running a build with some patches, so that may be the reason. You could try if the changes from my multicast-snooping branch [1] fix the issue. One of them fixes an issue that can occur even without multicast snooping enabled and results in corruption of the unknown multicast port mask. Best, Jan [1] https://github.com/janh/openwrt/commits/realtek-multicast-snooping ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Secure cookie handling upon https to http downgrade
Some background. I have two versions of OpenWrt code:
One is legacy version based upon a mismash of versions, but is approximately
luci code from mid-2021. The webserver is http only. I'm able to change this
code for bug fixes, but don't want to pull in anything too large.
The other is based upon very current 22.03 code, and https is set.
The problem is that for some purposes, we may need to downgrade. If the login
is done on the https setup, then the sysauth cookie is set, with the "secure"
flag set on the cookie. All fine.
However, if we go back to the older code, then it's not possible to login in
luci. I've been through dispatcher.lua and what I think is happening is that
the cookie isn't being updated:
http.header("Set-Cookie", 'sysauth=%s; path=%s; SameSite=Strict; HttpOnly%s' %{
sid, build_url(), http.getenv("HTTPS") == "on" and ";
secure" or ""
})
Now that would be justified, since you wouldn't want a website to update a
cookie from an HTTP page with one already set from an HTTPS page. So what
happens is that the authentication "works" but there is another check in
dispatcher.lua for the session ID vs cookie, and this fails, and so no login
can be made until the cookie is cleared from the browser (or the cookie
is manually modified in the browser to be not secure). Or in practice,
flushing the cache for the page.
I know also there have been significant changes in the dispatcher code between
the legacy OpenWrt code I'm using and the 22.03 code, but it's not clear that
this has been addressed.
Looking for suggestions on work arounds - maintaining the integrity of the
security of my latest code is important, but if I have to weaken things in the
legacy code, that's probably OK.
Thanks!
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Ethernet switch with linux/openwrt and DSA
czw., 22 gru 2022 o 02:24 Luiz Angelo Daros de Luca napisał(a): > > > Thanks all! > > Finally buy: D-LINK DGS-1210-48 G1. > > > > U-Boot 2011.12.(2.1.5.67086)-Candidate1 (Apr 13 2017 - 13:58:11) > > > > Board: RTL839x CPU:700MHz LXB:200MHz MEM:400MHz > > DRAM: 128 MB > > SPI-F: 1x32 MB > > > > Next: > > - connected serial cable > > - stop in uboot > > - boot from > > tftp/openwrt-realtek-rtl839x-d-link_dgs-1210-52-initramfs-kernel.bin > > - next simple scp/sysupgrade > > openwrt-realtek-rtl839x-d-link_dgs-1210-52-squashfs-sysupgrade.bin > > > Great news! Interesting, is it the same model as 1210-52 but with the > extra ports as non combo? Or are SFP+ still combo ports with 45-48 > ports? Currently 49-52 they are disabled in -52 variant but they might > introduce a problem if someone gets that fixed and they are missing in > your device. Ports are statically defined in the DTS file and they > might brick the device if missing. > Ports 49-52 seems to be "shared" I have both eth and sfp ports with same numbers (btw eth ports 49-52 don't work correctly) > Did you try the image1 firmware? It should work from the web interface > but you need to write it to the image1, not image2 slot. If it is that > close to F1 series, might be able to dual boot the device back to the > original firmware. If that doesn't work, we might need to change some > flags in the dlink image generator. Is the original firmware shared > between -f1 and -g1 series? > From original GUI/SW wasn't able to change image1/image2 - only config1/config2. Because of that decide to run directly from uboout and RAM via tftp - just to check if will up correctly. But original SW show double mtds for kernel/rootfs - so maybe only GUI issue? Linux version 2.6.19 (jonathan@210Server) (gcc version 3.4.4 mipssde-6.03.00-20051020) #2 PREEMPT Fri Oct 6 14:29:30 CST 2017 CPU revision is: 00019555 Determined physical RAM map: memory: 0200 @ (usable) User-defined physical RAM map: memory: 0790 @ (usable) Built 1 zonelists. Total pages: 30734 Kernel command line: console=ttyS0,115200 mem=121M noinitrd root=/dev/mtdblock4 rw rootfstype=squashfs csb=0x0157CCD6 cso=0x0794DD64 csf=0x42662D12 sfin=,32MB,8376352;8335392 Primary instruction cache 32kB, physically tagged, 4-way, linesize 32 bytes. Primary data cache 32kB, 4-way, linesize 32 bytes. Synthesized TLB refill handler (20 instructions). Synthesized TLB load handler fastpath (32 instructions). Synthesized TLB store handler fastpath (32 instructions). Synthesized TLB modify handler fastpath (31 instructions). Cache parity protection disabled PID hash table entries: 512 (order: 9, 2048 bytes) Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 120320k/123904k available (1786k kernel code, 3460k reserved, 393k data, 104k init, 0k highmem) Mount-cache hash table entries: 512 Checking for 'wait' instruction... available. NET: Registered protocol family 16 NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 4096 (order: 2, 16384 bytes) TCP bind hash table entries: 2048 (order: 1, 8192 bytes) TCP: Hash tables configured (established 4096 bind 2048) TCP reno registered squashfs: version 3.3 (2007/10/31) Phillip Lougher JFFS2 version 2.2. (NAND) (C) 2001-2006 Red Hat, Inc. io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered (default) Serial: 8250/16550 driver $Revision: 1.1.1.1 $ 1 ports, IRQ sharing disabled serial8250: ttyS0 at MMIO 0x0 (irq = 31) is a 16550A Probe: SPI CS1 Flash Type MX25L25635F Creating 9 MTD partitions on "Total SPI FLASH": 0x-0x0008 : "BOOT" 0x0008-0x000c : "BDINFO" 0x000c-0x0010 : "BDINFO2" 0x0010-0x0028 : "KERNEL1" 0x0028-0x00e8 : "ROOTFS1" 0x00e8-0x0100 : "KERNEL2" 0x0100-0x0104 : "SYSINFO" 0x0104-0x01c4 : "ROOTFS2" 0x01c4-0x0200 : "JFFS2" TCP cubic registered > I would include a new DTS file/firmware generation, even if it only > includes/copies -52 variant. It would make the lives of newcomers much > easier. > G1 - have dedicated SW - DGS-1210-48-G1-7-00-B006.hex BTW, this switch have some issues with IPv6? Simple remove lan2 from switch/bridge and configure manually - connect my device directly to eth2 port. Seems IPv4 works correctly - while IPv6 not (ping6 ff02::1%lan2 - no answer). Same config (with removed lan2 from bridge) works perfectly with mt7530 (also dsa) on my mt7621 board. Or we miss some configuration? Some logs below: Thu Dec 22 15:05:20 2022 kern.info kernel: [98039.948092] rtl83xx-switch switch@1b00 lan2: Link is Up - 1Gbps/Full - flow control rx/tx Thu Dec 22 15:05:20 2022 kern.info kernel: [98039.957695] IPv6: ADDRCONF(NETDEV_CHANGE): lan2: link becomes ready Thu Dec 22 15:05:20 2022 daemon.notice netifd: Network device
