Re: mac address issue of tp-link wdr3600 and archer c7-v2
C7v2 here. 21.02
eth0: 73
eth1: 72 (br-lan)
wlan0: 71 (11n+ac, 5GHz)
wlan1: 72 (11bgn, 2.4GHz)
Works fine as is.
On 2021-11-15 21:04, e9hack wrote:
Hi,
I'm using two tp-link routers. Both are using the same mac address for
one eth and one wlan interface:
archer c7-v2:
uboot 60:xx:xx:xx:xx:E6
eth0 60:xx:xx:xx:xx:E7
eth1 60:xx:xx:xx:xx:E6
wlan0 60:xx:xx:xx:xx:E4 5G
wlan1 60:xx:xx:xx:xx:E6 2.4G
wdr3600:
uboot C0:xx:xx:xx:xx:60
eth0 C0:xx:xx:xx:xx:60
wlan0 C0:xx:xx:xx:xx:5F 2.4G
wlan1 C0:xx:xx:xx:xx:60 5G
It looks like if an address decrement is missing for one wlan interface.
I don't know if this can trigger a problem.
With a small patch, I did fix it for both of my routers:
--- a/target/linux/ath79/dts/ar9344_tplink_tl-wdr4300.dtsi
+++ b/target/linux/ath79/dts/ar9344_tplink_tl-wdr4300.dtsi
@@ -82,6 +82,7 @@
{
nvmem-cells = <_uboot_1fc00>;
nvmem-cell-names = "mac-address";
+ mac-address-increment = <(-2)>;
};
{
--- a/target/linux/ath79/dts/qca9558_tplink_archer-c7-v2.dts
+++ b/target/linux/ath79/dts/qca9558_tplink_archer-c7-v2.dts
@@ -64,6 +64,7 @@
nvmem-cells = <_uboot_1fc00>;
nvmem-cell-names = "mac-address";
+ mac-address-increment = <(-1)>;
};
{
Now I get:
archer c7-v2:
eth0 60:xx:xx:xx:xx:E7
eth1 60:xx:xx:xx:xx:E6
wlan0 60:xx:xx:xx:xx:E4 5G
wlan1 60:xx:xx:xx:xx:E5 2.4G
wdr3600:
eth0 C0:xx:xx:xx:xx:60
wlan0 C0:xx:xx:xx:xx:5F 2.4G
wlan1 C0:xx:xx:xx:xx:5E 5G
I don't know, if exist some rule whether decrement by -1/-2 shall refer
to the interface number or to the frequency.
Regards,
Hartmut
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ipv6 quirk openwrt 21.02.1
Understood - thank you. So DF provokes the detection of the weakest link for MTU discovery. So a bit of digging and development is necessary if I wish to have that option available in the luci GUI. Complex? The weird thing in this setup is that the IPv4 PMTU is 1480 all the way. It's only at IPv6 layer the PMTU is reduced. possibly something similar occuring at IPv6. Is it possible something unusual is happening in 6in4 or lower? On 2021-11-04 23:04, Nathan Lutchansky wrote: On 11/4/21 11:52 AM, Paul D wrote: Having a bit of IPv6 6in4 problem. I set a static MTU to 1480 locally and remotely (HE tunnel). As I interpret the RFC [1] as referenced by overarching RFC [2], it notes: > When using the static tunnel MTU, the Don't Fragment bit MUST NOT be > set in the encapsulating IPv4 header. As a result, the encapsulator > should not receive any ICMPv4 "packet too big" messages as a result > of the packets it has encapsulated. But pcaps clearly show in the IPv4 packet: > Flags: 0x40, Don't fragment > 0... = Reserved bit: Not set > .1.. = Don't fragment: Set > ..0. = More fragments: Not set Is this considered normal IPv6 tunneling behaviour? Or is this broken? This is normal for Linux. Since forcing routers to perform fragmentation mid-path is a huge performance hit, Linux uses path MTU discovery to determine the real MTU of the tunnel, and then generates fragmentation-needed errors at the tunnel ingress if the outer packet would be too large for the path. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ipv6 quirk openwrt 21.02.1
Clarification: I ping6 the next ipv6 hop after my 6in4 tunnel, to rule out PMTU being at fault. On 2021-11-04 16:52, Paul D wrote: Having a bit of IPv6 6in4 problem. I set a static MTU to 1480 locally and remotely (HE tunnel). ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
ipv6 quirk openwrt 21.02.1
Having a bit of IPv6 6in4 problem. I set a static MTU to 1480 locally and remotely (HE tunnel). As I interpret the RFC [1] as referenced by overarching RFC [2], it notes: > When using the static tunnel MTU, the Don't Fragment bit MUST NOT be > set in the encapsulating IPv4 header. As a result, the encapsulator > should not receive any ICMPv4 "packet too big" messages as a result > of the packets it has encapsulated. But pcaps clearly show in the IPv4 packet: > Flags: 0x40, Don't fragment > 0... = Reserved bit: Not set > .1.. = Don't fragment: Set > ..0. = More fragments: Not set Is this considered normal IPv6 tunneling behaviour? Or is this broken? The diagnostics I perform are at IPv6, so if broken, 6in4 seems to be errantly setting the DF bit in the IPv4 packet, and the 6in4 interface sends a packet-too-big reply back for the re-assembled IPv6 ping reply, if ping6 -s size is >= 1232 That in itself seems like a bug - that ipv6 on openwrt sends a packet-too-big despite a static MTU big enough: 21 2021-11-04 14:56:06.394484 2001:470:XX:YY:ZZ::3 2001:470:XX-1:YY::1 IPv6 1318 IPv6 fragment (off=0 more=y ident=0xc6c3481c nxt=58) 22 2021-11-04 14:56:06.394538 2001:470:XX:YY:ZZ::3 2001:470:XX-1:YY::1 ICMPv6 102 Echo (ping) request id=0x0557, seq=0, hop limit=63 (reply in 23) 23 2021-11-04 14:56:06.437221 2001:470:XX-1:YY::1 2001:470:XX:YY:ZZ::3 ICMPv6 1326 Echo (ping) reply id=0x0557, seq=0, hop limit=64 (request in 22) 24 2021-11-04 14:56:06.437491 2001:470:XX-1:YY::2 2001:470:XX-1:YY::1 ICMPv6 1318 Packet Too Big All underlying MTUs which are available to set, are ~1480-1500. Can anyone else confirm this behaviour, also? 21.02.1 [1] https://datatracker.ietf.org/doc/html/rfc4213#section-3.2.1 [2] https://datatracker.ietf.org/doc/html/rfc7059 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
LUCI behaviour
If I use js e.g. :
o = ss.option(form.TextValue, 'blah', _('blah'), _('blah.'));
o.optional = true;
o.monospace = true;
And add either:
o.width = "500px";
or:
o.width = "60ch";
I do not get the desired effect. Is this normal?
Here ( https://openwrt.github.io/luci/jsapi/LuCI.form.TextValue.html )
it says about width:
==
When the property is set to a string value, it is applied as-is to the
CSS width property.
This property has no effect on options that are not children of grid or
table section elements.
==
How does one know that it's a child of said element? ( Is it talking
about HTML elements? Or LUCI? Also, which 'options'? )
If it is, is this a bug? The width always seems to be "100%".
HTML produced never has px or ch width. As soon as I set 'o.cols' then
the element aligns with other form elements. e.g. ~210px width.
So damned if I do, damned if I don't. How can one constrain width?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Release goals for 22.XX
The below is a fairly prescient analysis of the situation, and a good approach, Rui. I think openwrt will be fine staying put on iptables, until bpfilter matures. I think I have about 20 individual rules on my FW. Having the capability is nice, but most home users probably don't have or need 1 rules on their potatoes. Why not just have one 'big' change for the next major version? Like "we're aiming for all platforms on 5.10". Then if that's done, the focus is on quality. (We're still waiting on ar79 to get DSA patches in during 21.x) Many forum users have shown themselves to be fairly decent testers and guinea-pigs for rc testing. On 2021-10-06 19:42, Rui Salvaterra wrote: Hi, Rich, On Wed, 6 Oct 2021 at 17:54, Rich Brown wrote: Paul, Rafał, I think our emails passed in the ether... (http://lists.openwrt.org/pipermail/openwrt-devel/2021-October/036637.html) As I said in that message, I am very aware of the time constraints of the volunteers for OpenWrt. And I don't mean to suck the conversation into "grand strategies" without any endpoint. Let's focus on our next step. In my earlier note, I asked: 1) What would prevent us from accomplishing the 22.XX Release Goals in March 2022? (https://openwrt.org/docs/guide-developer/releases/goals/22.xx) - How do we see the time between now and March playing out? - Are there things we should leave out? Or should the release date be shifted? I think the target date is fine, as long as we don't try to bite more than we can chew. :) I'm a bit wary of the firewall4 migration, to be honest. Do we have performance numbers comparing nftables vs iptables, for complex rule sets? I'm asking because nftables can be slower than iptables [1], in at least in some scenarios. I also believe the priority should be to get all targets at 5.10 by default and to drop those which are stuck at 5.4 for some reason (small flash/RAM, unmaintained, etc.). And a dropped target doesn't mean it's gone forever, it can always be revived in the future, with enough interest, talent and Git. :) With this out of the way, bumping mac80211 to 5.15 is probably the hardest task at hand and, after it's done, I think we're release-worthy. Anything else (say, DSA for ath79 targets with qca8k switches) would be a nice bonus, but never a release blocker. Just my 0.02 €. Thoughts? Thanks, Rui [1] https://www.phoronix.com/scan.php?page=news_item=BPFILTER-2021 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Release goals for 22.XX
Wise words from the experienced! If making a yearly release is unattainable, isn't making point releases more achievable? Even if it's adding a single commit, point releases send a signal to the outside world that the project is still active, and e.g. that security is in focus. Any point release can be done for trivial amendments and GUI fixes. ( I do not make light of the steps involved in doing a release ). The idea being that at least these point releases can be done regularly. So the 'yearly' release is unattainable: is this largely due to the amount of new material that goes into the 'main/master/head' branch that needs to be picked and normalized and made stable (if that's how I might summarize making all the platforms behave consistently)? I would be fine without regular yearly releases. nightlies are available etc. On 2021-10-06 07:58, Rafał Miłecki wrote: On 30.09.2021 03:34, Rich Brown wrote: My desire would be to name our next release "22.03", with a target release date in March 2022. And we should name the following release "22.09" with a release date in September. And so on - every six months (or whatever interval we believe we can sustain for the long term.) This is absolutely undoable. We have too little manpower and too little people actually interested in preparing releases. It takes testing, checking feedback, reviewing bug reports, debugging issues, backporting changes. That is a lot of work. Every time we have a discussion about releases there comes an idea of time-based releases. Also a lot of people have opinions on when to branch and how to proceed with development. When it comes to actually working on a release there are very people that stay involved. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Suggestion: Explicitly warn to not use GitHub web UI for patches
On 2021-10-05 21:17, Rich Brown wrote: On Oct 5, 2021, at 10:24 AM, Paul D wrote: Write this up into an FAQ/howto on openwrt.org (this is, after all, the OWRT way) Yes, it's always more powerful (and useful) to tell people what TO do, instead of what NOT to do. I contribute very occasionally, and by trial and error, I *think* I have found the procedure. (And if it's not right, or not optimal, I would be delighted to learn how to do it better...) - In Github, fork the official repo into my personal Github account - Clone my personal copy of the repo to my laptop - Create a branch for my changes on my laptop - Monkey around, improve the world, then... - Squash my commits so that there's only one change (optional, but it tends to improve the commit messages) - Push my commits back to my personal repo - From my personal Github account, create a PR for my branch back to the official OpenWrt repo Do I have the gist of it? Many thanks. Rich Yeah, that's roughly my SOP. -fork repo -clone -edit -commit -push (--force) to my clone -PR with optional: -add remote: original repo -pull -rebase -commit --amend -push --force ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Suggestion: Explicitly warn to not use GitHub web UI for patches
Roughly Write this up into an FAQ/howto on openwrt.org (this is, after all, the OWRT way) Link to it in a https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/troubleshooting-required-status-checks which looks for any commit containing: Committer: "GitHub " Accepting "drive-by" PRs is overall a good thing, even if it is a bumpy path. On 2021-10-03 23:22, Adrian Schmutzler wrote: Hi, I've repeatedly made the observation that people who submit PRs with edits from GitHub's web interface cannot do history edits there when we request them. This leads to a lot of frustration both for the reviewers and the submitters. Eventually, it's mostly one of the following three undesirable options: ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH uci] cmake: Allow overwrite of install directories
Overwrite or override? Seems like override - distinction here is important... ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] dnsmasq: add match_tag for --dhcp-host
Did not understand significance of vendorclass. Should this give a new option for uci, match_tag? On 2021-09-23 09:28, Paul Fertser wrote: A set of tags can be specified for --dhcp-host option to restrict the assignment to the requests which match all the tags. Example usage: config vendorclass option networkid 'udhcp' option vendorclass 'udhcp' config host option mac '*:*:*:*:*:*' list match_tag 'switch.10' list match_tag 'udhcp' option ip '192.168.25.10' ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02.0 Fourth release candidate - DSA docs
On 2021-09-17 13:27, Perry wrote: Hi all, On 9/17/21 1:30 PM, Rich Brown wrote: Hi Arınç On Sep 17, 2021, at 3:17 AM, Arınç ÜNAL wrote: The current naming used on LuCI/UCI is inaccurate and confusing. The “interfaces” under Network → Interfaces actually represent networks. The actual interfaces are called “device”. I agree that the terminology is confusing. I really struggled with the names when I added them into the preface to the DSA Mini-tutorial (https://openwrt.org/docs/guide-user/network/dsa/dsa-mini-tutorial). I did some research looking at the original DSA documentation: it didn't offer much in the way of definitions. So I followed my usual practice of documenting the lingo of whatever application I'm using. After looking hard at how LuCI seemed to work, I wrote: • Devices are physical connections that convey bits/frames to other computers. They operate at layer 2 in the protocol stack, have a MAC address along with several other configurable parameters... • Interfaces route IP packets and operate at layer 3 in the protocol stack. An interface is associated with a single device that sends/receives its packets. Interfaces get their IP address parameters by the choice of protocol... - I haven't heard any corrections from others about these assertions, so I am hopeful that I got those definitions right. When you say that "interfaces... actually represent networks" I think you mean that they're "subnets" (and have a subnet address range, IP address, and other characteristics). Is that what you mean? Although I'm neither a Linux OS or network expert, I can see an explanation for using the terms "devices" and "interfaces" as defined above. This is not always the case. For example, it is possible to have a tun or tap interface which does not have a corresponding ip address. This is more than just a device, because layer 3 packets can arrive on such an interface. Another example, from Freifunk, are mesh (either Ad-Hoc or 802.11s) interfaces. These are interfaces which have a static IP address, but the netmask is 255.255.255.255. This is not a network in the sense most people are used to using, but still a completely valid configuration. I think staying with the terminology "device" and "interface" is the right way to go. Greets, Perry Largely agree - device --> hardware device --> hwdev interface ? GUI is an interface. NIC is an interface. This is abstract. Trying to make it concrete is just confusing. Specify: L3interface L4interface MLinterface (multi layer) This terminology desperately needs disambiguating (just an observation, not a criticism), at least away from single word terms. But currently it seems to be: -device is the hardware -interface is hardware configured to operate at some network layer What do Linux (kernel) devs use? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
starting point for SOF_TIMESTAMPING_TX_SOFTWARE in bridges
Someone more experienced than I am might have a good answer. How trivial is it to patch openwrt 21 and/or master in one place, such that my brX/br-lan has the flag SOF_TIMESTAMPING_TX_SOFTWARE if the underlying hardware/eth driver also has it? I would like to run ptp4l on my bridge (swconfig, ath, DSA not in yet) and ptp4l mandates at least SOF_TIMESTAMPING_TX_SOFTWARE. But weirdness ensues and the source IP chosen is the WAN and packets just disappear when using L3. Forum post here: https://forum.openwrt.org/t/ptp-224-0-0-x-and-224-0-1-x-multicast-on-21-02/103721 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ath79 porting of NEtgear R6100
In my (admittedly limited) experience, there are sometimes multiple ways of accessing the same hardware. So while what you have works, it might need refinement, or changing completely. It might require reading data-sheets of the chips your board has. e.g. https://datasheetspdf.com/pdf-file/825113/Atheros/AR9344/1 In the first few pages, I see that accessing ethX is done via: MII, RMII, RGMII. Page 61 has a nice overview. So you may need to stare and compare with existing devices to see how they did it. Not everything will make sense... On 2021-08-17 08:47, Enrico Mioso wrote: Hello all!! Well, sorry, I've been unclear about the fact that this dmesg comes from ar71x. Thanks Paul for the the hints. I tried looking at similar devices, like the hiveap-121, but s far I had no luck. And so decided it would be best to follow a more "technical" pproach. Trials and errors worked well in other cases but I guess this time they may not. Side note: recovery ath79 image is accepted via tftp. On Mon, 16 Aug 2021, Paul D wrote: Date: Mon, 16 Aug 2021 23:16:54 From: Paul D To: openwrt-devel@lists.openwrt.org Subject: Re: ath79 porting of NEtgear R6100 On 2021-08-16 17:24, Enrico Mioso wrote: Hello all!! It's me, again trying to port a device to ath79. And guess where I am stuck ... in the Ethernet part and switch configuration. :) The device runs ar71xx, I have the io package installed. I can get replies from the device, but ping doesn't see them (only tcpdump), which means something in the timing or data is wrong. The system is otherwise able to boot. Can you help, maybe poiting me where I can look? At the moment I have no UART access to the system, so I was trying to debug things in ar71xx and take inspiration looking at the DTS files around. My guess is that you forgot the switch config, or DSA support. Look at similar devices. I guess you need some trial and error. Otherwise, DSA support. Look at other ath79 DSA porting efforts: https://github.com/openwrt/openwrt/pull/4036 I see eth0 and eth1 in the bootlog, so that's a good thing. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ath79 porting of NEtgear R6100
On 2021-08-16 17:24, Enrico Mioso wrote: Hello all!! It's me, again trying to port a device to ath79. And guess where I am stuck ... in the Ethernet part and switch configuration. :) The device runs ar71xx, I have the io package installed. I can get replies from the device, but ping doesn't see them (only tcpdump), which means something in the timing or data is wrong. The system is otherwise able to boot. Can you help, maybe poiting me where I can look? At the moment I have no UART access to the system, so I was trying to debug things in ar71xx and take inspiration looking at the DTS files around. My guess is that you forgot the switch config, or DSA support. Look at similar devices. I guess you need some trial and error. Otherwise, DSA support. Look at other ath79 DSA porting efforts: https://github.com/openwrt/openwrt/pull/4036 I see eth0 and eth1 in the bootlog, so that's a good thing. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
FRAG Attacks (new vuln for wifi)
https://www.fragattacks.com/ https://lore.kernel.org/linux-wireless/20210511180259.159598-1-johan...@sipsolutions.net/ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
