OpenWrt 22.03.0 first stable release
Hi, The OpenWrt community is proud to announce the first stable release of the OpenWrt 22.03 stable version series. It incorporates over 3800 commits since branching the previous OpenWrt 21.02 release and has been under development for about one year. Download firmware image for your device (firmware selector): * https://firmware-selector.openwrt.org/?version=22.03.0 Download firmware images directly from OpenWrt download servers: * https://downloads.openwrt.org/releases/22.03.0/targets/ Highlights in OpenWrt 22.03.0 = Firewall4 based on nftables === Firewall4 is used by default, superseding the iptables-based firewall3 implementation in the OpenWrt default images. Firewall4 uses nftables instead of iptables to configure the Linux netfilter ruleset. Firewall4 keeps the same UCI firewall configuration syntax and should work as a drop-in replacement for fw3 with most common setups, emitting nftables rules instead of iptables ones. Including custom firewall rules through /etc/firewall.user still works, but requires marking the file as compatible first, otherwise it is ignored. Firewall4 additionally allows to include nftables snippets. The firewall documentation https://openwrt.org/docs/guide-user/firewall/firewall_configuration explains how to include custom firewall rules with firewall4. Some community packages that add firewall rules might not work for now, and will need to be adapted to fw4: this will happen gradually throughout the lifetime of the 22.03 release series. The legacy iptables utilities are not included in the default images anymore, but can be added back using opkg or the Image Builder if needed. The transitional packages iptables-nft, arptables-nft, ebtables-nft and xtables-nft can be used to create nftables rules using the old iptables command line syntax. Many new devices added == OpenWrt 22.03 supports over 1580 devices. Support for over 180 new devices was added in addition to the device support by OpenWrt 21.02. OpenWrt 22.03 supports more than 15 devices capable of Wifi 6 (IEEE 802.11ax) using the MediaTek MT7915 wifi chip. More targets converted to DSA = The following targets or boards were migrated from swconfig to DSA with OpenWrt 22.03 in addition to the systems already migrated with OpenWrt 21.02: * bcm53xx: All board using this target were converted to DSA * lantiq: All boards using the xrx200 / vr9 SoC * sunxi: Bananapi Lamobo R1 (only sunxi board with switch) Dark mode in LuCI = The LuCI bootstrap design supports a dark mode. The default design activates dark mode depending on the browser settings. Change it manually at “System” -> “System” -> “Language and Style”. Year 2038 problem handled = OpenWrt 22.03 uses musl 1.2.x, which changed the time_t type from 32 bit to 64 bit on 32 bit systems, on 64 bit system it was always 64 bit long. When a Unix time stamp is stored in a signed 32 bit integer it will overflow on 19 January 2038. With the change to 64 bit this will happen 292 billion years later. This is a change of the musl libc ABI and needs a recompilation of all user space applications linked against musl libc. For 64 bit systems this was done when the ABI was defined many years ago, the glibc ARC ABI already has a 64 bit time_t. Core components update == Core components have the following versions in 22.03.0: * Updated toolchain: * musl libc 1.2.3 * glibc 2.34 * gcc 11.2.0 * binutils 2.37 * Updated Linux kernel * 5.10.138 for all targets * Network: * hostapd 2.10, dnsmasq 2.86, dropbear 2022.82 * cfg80211/mac80211 from kernel 5.15.58 * System userland: * busybox 1.35.0 In addition to the listed applications, many others were also updated see the detailed Changelog for more information. https://openwrt.org/releases/22.03/changelog-22.03.0 Upgrading to 22.03.0 Sysupgrade can be used to upgrade a device from OpenWrt 21.02 to 22.03, and configuration will be preserved in most cases. Upgrades from a previous 22.03.0 release candidate are also supported. * Sysupgrade from 19.07 to 22.03 is not supported. * There is no migration path for targets that switched from swconfig to DSA. In that case, sysupgrade will refuse to proceed with an appropriate error message: Image version mismatch. image 1.1 device 1.0 Please wipe config during upgrade (force required) or reinstall. Config cannot be migrated from swconfig to DSA Image check failed - Full release notes and upgrade instructions are available at https://openwrt.org/releases/22.03/notes-22.03.0 In particular, make sure to read the regressions and known issues before upgrading: https://openwrt.org/releases/22.03/notes-22.03.0#known_issues For a detailed list of all changes since 21.02, refer to
[PATCH] uqmi: add APN profile commands
Add commands to create and modify default APN profile
--get-default-profile-number
--get-profile-settings
--create-profile
--modify-profile
Signed-off-by: Henrik Ginstmark
---
uqmi/src/commands-wds.c | 346 +---
uqmi/src/commands-wds.h | 22 +++
2 files changed, 312 insertions(+), 56 deletions(-)
diff --git a/uqmi/src/commands-wds.c b/uqmi/src/commands-wds.c
index 3aecefd..3d0f524 100644
--- a/uqmi/src/commands-wds.c
+++ b/uqmi/src/commands-wds.c
@@ -24,17 +24,70 @@
#include "qmi-message.h"
+static const struct {
+ const char *auth_name;
+ QmiWdsAuthentication auth;
+} auth_modes[] = {
+ { "none", QMI_WDS_AUTHENTICATION_NONE },
+ { "pap", QMI_WDS_AUTHENTICATION_PAP },
+ { "chap", QMI_WDS_AUTHENTICATION_CHAP },
+ { "both", QMI_WDS_AUTHENTICATION_PAP | QMI_WDS_AUTHENTICATION_CHAP },
+};
+
+static const struct {
+ const char *ipfam_name;
+ const QmiWdsIpFamily mode;
+} ipfam_modes[] = {
+ { "ipv4", QMI_WDS_IP_FAMILY_IPV4 },
+ { "ipv6", QMI_WDS_IP_FAMILY_IPV6 },
+ { "unspecified", QMI_WDS_IP_FAMILY_UNSPECIFIED },
+};
+
+static const struct {
+ const char *pdp_name;
+ const QmiWdsPdpType type;
+} pdp_types[] = {
+ { "ipv4", QMI_WDS_PDP_TYPE_IPV4 },
+ { "ppp", QMI_WDS_PDP_TYPE_PPP },
+ { "ipv6", QMI_WDS_PDP_TYPE_IPV6 },
+ { "ipv4v6", QMI_WDS_PDP_TYPE_IPV4_OR_IPV6 },
+};
+
+static const struct {
+ const char *profile_name;
+ const QmiWdsProfileType profile;
+} profile_types[] = {
+ { "3gpp", QMI_WDS_PROFILE_TYPE_3GPP },
+ { "3gpp2", QMI_WDS_PROFILE_TYPE_3GPP2 },
+};
+
static struct qmi_wds_start_network_request wds_sn_req = {
QMI_INIT(authentication_preference,
QMI_WDS_AUTHENTICATION_PAP | QMI_WDS_AUTHENTICATION_CHAP),
};
+
static struct qmi_wds_stop_network_request wds_stn_req;
+static struct qmi_wds_modify_profile_request wds_mp_req = {
+ QMI_INIT_SEQUENCE(profile_identifier,
+ .profile_type = QMI_WDS_PROFILE_TYPE_3GPP,
+ .profile_index = 1,
+ ),
+ QMI_INIT(apn_disabled_flag, false),
+};
+
+static struct qmi_wds_create_profile_request wds_cp_req = {
+ QMI_INIT(profile_type,QMI_WDS_PROFILE_TYPE_3GPP),
+ QMI_INIT(apn_disabled_flag, false),
+};
+
#define cmd_wds_set_apn_cb no_cb
static enum qmi_cmd_result
cmd_wds_set_apn_prepare(struct qmi_dev *qmi, struct qmi_request *req, struct
qmi_msg *msg, char *arg)
{
qmi_set_ptr(_sn_req, apn, arg);
+ qmi_set_ptr(_mp_req, apn_name, arg);
+ qmi_set_ptr(_cp_req, apn_name, arg);
return QMI_CMD_DONE;
}
@@ -42,22 +95,14 @@ cmd_wds_set_apn_prepare(struct qmi_dev *qmi, struct
qmi_request *req, struct qmi
static enum qmi_cmd_result
cmd_wds_set_auth_prepare(struct qmi_dev *qmi, struct qmi_request *req, struct
qmi_msg *msg, char *arg)
{
- static const struct {
- const char *name;
- QmiWdsAuthentication auth;
- } modes[] = {
- { "pap", QMI_WDS_AUTHENTICATION_PAP },
- { "chap", QMI_WDS_AUTHENTICATION_CHAP },
- { "both", QMI_WDS_AUTHENTICATION_PAP |
QMI_WDS_AUTHENTICATION_CHAP },
- { "none", QMI_WDS_AUTHENTICATION_NONE },
- };
int i;
-
- for (i = 0; i < ARRAY_SIZE(modes); i++) {
- if (strcasecmp(modes[i].name, arg) != 0)
+ for (i = 0; i < ARRAY_SIZE(auth_modes); i++) {
+ if (strcasecmp(auth_modes[i].auth_name, arg) != 0)
continue;
- qmi_set(_sn_req, authentication_preference, modes[i].auth);
+ qmi_set(_sn_req, authentication_preference,
auth_modes[i].auth);
+ qmi_set(_mp_req, authentication, auth_modes[i].auth);
+ qmi_set(_cp_req, authentication, auth_modes[i].auth);
return QMI_CMD_DONE;
}
@@ -70,6 +115,8 @@ static enum qmi_cmd_result
cmd_wds_set_username_prepare(struct qmi_dev *qmi, struct qmi_request *req,
struct qmi_msg *msg, char *arg)
{
qmi_set_ptr(_sn_req, username, arg);
+ qmi_set_ptr(_mp_req, username, arg);
+ qmi_set_ptr(_cp_req, username, arg);
return QMI_CMD_DONE;
}
@@ -78,6 +125,8 @@ static enum qmi_cmd_result
cmd_wds_set_password_prepare(struct qmi_dev *qmi, struct qmi_request *req,
struct qmi_msg *msg, char *arg)
{
qmi_set_ptr(_sn_req, password, arg);
+ qmi_set_ptr(_mp_req, password, arg);
+ qmi_set_ptr(_cp_req, password, arg);
return QMI_CMD_DONE;
}
@@ -94,21 +143,12 @@ cmd_wds_set_autoconnect_prepare(struct qmi_dev *qmi,
struct qmi_request *req, st
static enum qmi_cmd_result
cmd_wds_set_ip_family_pref_prepare(struct qmi_dev *qmi, struct qmi_request
*req, struct qmi_msg *msg, char *arg)
{
- static const struct {
- const char *name;
- const QmiWdsIpFamily mode;
- } modes[] = {
- { "ipv4",
re: DSA Mini-tutorial
Hello Arınç (and the rest of the list), It's good to hear from you again. > On Sep 4, 2022, at 5:32 PM, Arınç ÜNAL wrote: > > I don't see much content to document DSA. All DSA does is creating a network > interface for each switch port. What I think should > be properly documented is the Bridge VLAN filtering feature. I have made some > efforts to do that on my playground here: > > https://openwrt.org/playground/arinc9/start I had not looked at your pages recently but we should make sure all the information makes it out of the playground into the main wiki. I see that we have slightly different definitions for "interface" and "device" in DSA. Here are the versions: DSA Mini-Tutorial - Terminology: https://openwrt.org/docs/guide-user/network/dsa/dsa-mini-tutorial#terminology Playground - Definition of a Network Interface https://openwrt.org/playground/arinc9/network.interfaces#definition_of_a_network_interface Because I don't really know about DSA, I don't know how important it is to call an Ethernet switch port a "device" or whether it's OK simply to call it an "Ethernet interface". How could we start to merge all these documents? Thanks. Rich PS Thoughts from other readers would be welcome! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: tcpdump looks broken
On Fri, Sep 2, 2022 at 5:35 PM e9hack wrote: > > Hi, > > it looks like, that tcpdump (mini) is broken. It is used by adblock to > generate reports. > > tcpdump -nn -p -s0 -i any port 53 > > version 4.99.1 > 16:11:26.070312 UNSUPPORTED > 0x: 0800 0020 0001 0306 f8e4 e37c ...| Looks like some VLAN 0 in-there? Maybe tcpdump (mini) doesn't know VLANs? > 0x0010: 4db3 4500 0047 8910 8011 6241 M...E..G..bA > 0x0020: c0a8 0102 c0a8 0101 d6f9 0035 0033 f8cf ...5.3.. > 0x0030: 0002 0100 0001 0377 .www > 0x0040: 0568 6569 7365 0264 6508 .heise.de.xx > 0x0050: 036c 616e 0100 01 xx.lan. > > version 4.9.3 > 16:11:47.879165 IP 192.168.1.2.57308 > 192.168.1.1.53: 2+ A? > www.heise.de..lan. (43) > > Adblock doesn't generate reports anymore. > > 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
