Hello,
I got question about this issue.
I updated my comment on this issue here:
https://osmocom.org/issues/6197
Original my post:
I observe same situation in my setup. Cannot activate PDP context because
of missing RA-CAPABILTIY-UPDATE and RA-CAPABILITY-ACK support in osmoSGSN.
My setup is Samsung Galaxy S9 and S23, real BTS/BSC from well-known vendor
and Osmo core (SGSN/GGSN/HLR/MSC/STP) (Important thing that I'm not using
osmo-pcu).
Problem description:
S9 attach procedure (CS+PS):
1.After UE reboot I see MM procedure Location request and Location update
processed good (on DMtool). Then if needed CS calling is working
properly(connection to osmoMSC).
2.After that UE is trying GMM Attach request and it got Attach accept and
attach complete.
3.Then UE send Activate PDP context, but SGSN is reject this with cause:
"Cannot handle SM for unknown MM CTX"
4.After that UE is trying activate PDP context for second time (After timer
expired) and finally it got pdp accept (ping/traffic work) same as in this
thread. After deep inspection I found that reason of first pdp activation
reject is that TLLI is not updated (SGSN dont know it and causing Cannot
handle SM for unknown MM CTX) because when I checked pcap from bssgp I see
that BSC send RA-CAPABILTIY-UPDATE with new tlli and osmoSGSN send response
Unknown PDU with protocol unspecified but should send
RA-CAPABILTIY-UPDATE-ACK. Other thing I dont understand that in msg comes
from bsc on bvci 127 but respond goes to bvci 0 (but I didnt define it as
bsc-sgsn link use only bvci 127 not bvci 0).Also I think sig bvci 0 is not
changeable to bvci 127 on osmoSGSN.
To summarize attach procedure is long it takes 30-50 seconds(because of
this first reject).
S23 attach
Same as S9 but after first fail it not doing second attempt and stuck
without PS forever in CS domain. Its not problem with MS stack.
I tried a lot of workarounds to make s23 attach but no success. Changing to
PSonly not work, AT commands not work. Also tried with Huawei E3372,E3131
but same behaviour.
I connect this setup to other 2Gcore-simulator(not opensource) to compare
and its processed normally for both UEs and modems,it got pdp contexts
after 6-8 seconds. Difference is that here I got message
RA-CAPABILTIY-UPDATE/RA-CAPABILITY-ACK because got real BSC not osmo-pcu.
When I look into code I cannot see RA-CAPABILTIY-UPDATE and
RA-CAPABILITY-ACK support so my questions are:
1.Is this RA-CAPABILTIY-UPDATE and RA-CAPABILITY-ACK supported in osmoSGSN
and is it plan to do that?
2.Is any other workaround (changing timers,tmsi assignment or whatever to
change in bsc) in configuration to make S23/modems attached?Theoretically
if UE can set PSonly and AT command to activate PDP context it should work
but I never make it happened this AT commands on my terminals.
3.I can provide both pcaps and UE logs to see whats missing if it helps to
make add it.
4.Is it possible to add this two messages to support to osmoSGSN code?I can
test patch if you provide it.
Regards,
Jan Kosiński
Hello,
I got question about this issue.
I updated my comment on this issue here:
https://osmocom.org/issues/6197
Original my post:
I observe same situation in my setup. Cannot activate PDP context because
of missing RA-CAPABILTIY-UPDATE and RA-CAPABILITY-ACK support in osmoSGSN.
My setup is Samsung Galaxy S9 and S23, real BTS/BSC from well-known vendor
and Osmo core (SGSN/GGSN/HLR/MSC/STP) (Important thing that I'm not using
osmo-pcu).
Problem description:
S9 attach procedure (CS+PS):
1.After UE reboot I see MM procedure Location request and Location update
processed good (on DMtool). Then if needed CS calling is working
properly(connection to osmoMSC).
2.After that UE is trying GMM Attach request and it got Attach accept and
attach complete.
3.Then UE send Activate PDP context, but SGSN is reject this with cause:
"Cannot handle SM for unknown MM CTX"
4.After that UE is trying activate PDP context for second time (After timer
expired) and finally it got pdp accept (ping/traffic work) same as in this
thread. After deep inspection I found that reason of first pdp activation
reject is that TLLI is not updated (SGSN dont know it and causing Cannot
handle SM for unknown MM CTX) because when I checked pcap from bssgp I see
that BSC send RA-CAPABILTIY-UPDATE with new tlli and osmoSGSN send response
Unknown PDU with protocol unspecified but should send
RA-CAPABILTIY-UPDATE-ACK. Other thing I dont understand that in msg comes
from bsc on bvci 127 but respond goes to bvci 0 (but I didnt define it as
bsc-sgsn link use only bvci 127 not bvci 0).Also I think sig bvci 0 is not
changeable to bvci 127 on osmoSGSN.
To summarize attach procedure is long it takes 30-50 seconds(because of
this first reject).
S23 attach
Same as S9 but after first fail it not doing second attempt and stuck
without PS forever in CS domain. Its not problem with MS stack.
I tried a lot of workarounds to make s23 attach but no success. Changing to
PSonly not work, AT commands not work. Also tried with Huawei E3372,E3131
but same behaviour.
I connect this setup to other 2Gcore-simulator(not opensource) to compare
and its processed normally for both UEs and modems,it got pdp contexts
after 6-8 seconds. Difference is that here I got message
RA-CAPABILTIY-UPDATE/RA-CAPABILITY-ACK because got real BSC not osmo-pcu.
When I look into code I cannot see RA-CAPABILTIY-UPDATE and
RA-CAPABILITY-ACK support so my questions are:
1.Is this RA-CAPABILTIY-UPDATE and RA-CAPABILITY-ACK supported in osmoSGSN
and is it plan to do that?
2.Is any other workaround (changing timers,tmsi assignment or whatever to
change in bsc) in configuration to make S23/modems attached?Theoretically
if UE can set PSonly and AT command to activate PDP context it should work
but I never make it happened this AT commands on my terminals.
3.I can provide both pcaps and UE logs to see whats missing if it helps to
make add it.
4.Is it possible to add this two messages to support to osmoSGSN code?I can
test patch if you provide it.
Regards,
Jan Kosiński
Hello various Osmocom mailing lists,
the official Osmocom binary packages will not be built anymore for the
following distributions starting at 2024-02:
* Raspberry Pi OS 64-bit (use Debian_12 etc. instead)
* Ubuntu 23.04 (Ubuntu 23.10 and LTS 20.04/22.04 feeds are available)
* openSUSE 15.4 (openSUSE Tumbleweed feed is available)
* Debian Testing (Debian Unstable and 12-10 feeds are available)
For Raspberry Pi OS 64-bit users, make sure to adjust your
/etc/apt/sources.list.d as described here to switch to a Debian
aarch64 feed:
https://osmocom.org/projects/cellular-infrastructure/wiki/Latest_Builds
See the new linux distributions article for information on how long we
plan to keep building packages for each distribution:
https://osmocom.org/projects/cellular-infrastructure/wiki/Linux_distributio…
Let me know if you have questions.
Best regards,
Oliver
--
- Oliver Smith <osmith(a)sysmocom.de> https://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
NURS FPX 4020 Assessment 1In the dynamic landscape of healthcare, nursing leadership plays a pivotal role in shaping the delivery of quality patient care. NURS FPX 4020 Assessment 1 is a crucial component of the nursing curriculum, focusing on cultivating leadership skills that are essential for addressing complex challenges within healthcare systems. This article delves into the significance of Assessment 1 and its connection to NHS-FPX 5004 Assessment 1.
NURS FPX 4020 Assessment 1 is a cornerstone in the journey of aspiring nurse leaders. This assessment is meticulously designed to provide nursing students with a comprehensive understanding of leadership theories, strategies, and practical applications that empower them to drive positive changes within healthcare organizations.
Leadership Theories and Models: Assessment 1 delves into various leadership theories, offering students insights into transformational, situational, and servant leadership, among others. This exposure enables students to identify leadership styles that align with their values and the unique demands of healthcare settings.
Strategic Decision-Making: Nursing leaders are often required to make strategic decisions that impact patient care, resource allocation, and organizational outcomes. Assessment 1 equips students with the skills to analyze complex situations, evaluate options, and make informed decisions that uphold patient-centered care.
Communication and Team Building: Effective leadership hinges on clear communication and fostering collaborative teams. Assessment 1 guides students in honing communication skills, conflict resolution techniques, and strategies for building cohesive and high-performing healthcare teams.
Change Management: In the ever-evolving healthcare landscape, adaptability and change management are critical. Assessment 1 prepares students to lead and manage change initiatives, ensuring smooth transitions that enhance patient care quality.
NURS FPX 4020 Assessment 1 yields transformative outcomes for nursing students:
Leadership Competence: By mastering leadership theories and practical skills, students develop the competence to lead with confidence, promoting a positive influence on their teams and patient outcomes.
Strategic Vision: Assessment 1 instills a strategic mindset, enabling nursing leaders to envision and implement improvements that align with organizational goals while prioritizing patient welfare.
Collaborative Excellence: Effective communication and team-building skills fostered by Assessment 1 enhance collaboration among healthcare professionals, leading to enhanced care coordination and patient safety.
Change Catalysts: Nursing professionals who excel in Assessment 1 become adept at navigating change, fostering an environment where innovation and continuous improvement thrive.
NHS-FPX 5004 Assessment 1 is an extension of the leadership foundation laid by NURS FPX 4020 Assessment 1. While the latter focuses on nursing leadership within broader healthcare contexts, NHS-FPX 5004 Assessment 1 specifically addresses leadership and management within the NHS, offering insights into the unique challenges and opportunities within the UK healthcare system.
NURS FPX 4020 Assessment 1 serves as a beacon guiding nursing students towards impactful leadership roles within the healthcare sector. By imparting leadership theories, strategic acumen, and effective communication strategies, Assessment 1 transforms students into dynamic nursing leaders capable of navigating complex healthcare environments. As they progress to NHS-FPX 5004 Assessment 1, students are poised to apply their leadership prowess within the context of the NHS, ultimately contributing to the enhancement of patient care, healthcare systems, and the nursing profession as a whole.
https://onlineclassassignment.com/
[NURS FPX 4020 Assessment 1](https://onlineclassassignment.com/nurs-fpx-4020-assessment-1-improving-q… the dynamic landscape of healthcare, nursing leadership plays a pivotal role in shaping the delivery of quality patient care. NURS FPX 4020 Assessment 1 is a crucial component of the nursing curriculum, focusing on cultivating leadership skills that are essential for addressing complex challenges within healthcare systems. This article delves into the significance of Assessment 1 and its connection to NHS-FPX 5004 Assessment 1.
NURS FPX 4020 Assessment 1 is a cornerstone in the journey of aspiring nurse leaders. This assessment is meticulously designed to provide nursing students with a comprehensive understanding of leadership theories, strategies, and practical applications that empower them to drive positive changes within healthcare organizations.
Leadership Theories and Models: Assessment 1 delves into various leadership theories, offering students insights into transformational, situational, and servant leadership, among others. This exposure enables students to identify leadership styles that align with their values and the unique demands of healthcare settings.
Strategic Decision-Making: Nursing leaders are often required to make strategic decisions that impact patient care, resource allocation, and organizational outcomes. Assessment 1 equips students with the skills to analyze complex situations, evaluate options, and make informed decisions that uphold patient-centered care.
Communication and Team Building: Effective leadership hinges on clear communication and fostering collaborative teams. Assessment 1 guides students in honing communication skills, conflict resolution techniques, and strategies for building cohesive and high-performing healthcare teams.
Change Management: In the ever-evolving healthcare landscape, adaptability and change management are critical. Assessment 1 prepares students to lead and manage change initiatives, ensuring smooth transitions that enhance patient care quality.
NURS FPX 4020 Assessment 1 yields transformative outcomes for nursing students:
Leadership Competence: By mastering leadership theories and practical skills, students develop the competence to lead with confidence, promoting a positive influence on their teams and patient outcomes.
Strategic Vision: Assessment 1 instills a strategic mindset, enabling nursing leaders to envision and implement improvements that align with organizational goals while prioritizing patient welfare.
Collaborative Excellence: Effective communication and team-building skills fostered by Assessment 1 enhance collaboration among healthcare professionals, leading to enhanced care coordination and patient safety.
Change Catalysts: Nursing professionals who excel in Assessment 1 become adept at navigating change, fostering an environment where innovation and continuous improvement thrive.
NHS-FPX 5004 Assessment 1 is an extension of the leadership foundation laid by NURS FPX 4020 Assessment 1\. While the latter focuses on nursing leadership within broader healthcare contexts, NHS-FPX 5004 Assessment 1 specifically addresses leadership and management within the NHS, offering insights into the unique challenges and opportunities within the UK healthcare system.
NURS FPX 4020 Assessment 1 serves as a beacon guiding nursing students towards impactful leadership roles within the healthcare sector. By imparting leadership theories, strategic acumen, and effective communication strategies, Assessment 1 transforms students into dynamic nursing leaders capable of navigating complex healthcare environments. As they progress to [NHS-FPX 5004 Assessment 1](https://onlineclassassignment.com/nurs-fpx-5004-assessment-1-leadership-…, students are poised to apply their leadership prowess within the context of the NHS, ultimately contributing to the enhancement of patient care, healthcare systems, and the nursing profession as a whole.
[url=https://onlineclassassignment.com/nurs-fpx-4020-assessment-1-improving-… FPX 4020 Assessment 1[/url]In the dynamic landscape of healthcare, nursing leadership plays a pivotal role in shaping the delivery of quality patient care. NURS FPX 4020 Assessment 1 is a crucial component of the nursing curriculum, focusing on cultivating leadership skills that are essential for addressing complex challenges within healthcare systems. This article delves into the significance of Assessment 1 and its connection to NHS-FPX 5004 Assessment 1.
NURS FPX 4020 Assessment 1 is a cornerstone in the journey of aspiring nurse leaders. This assessment is meticulously designed to provide nursing students with a comprehensive understanding of leadership theories, strategies, and practical applications that empower them to drive positive changes within healthcare organizations.
Leadership Theories and Models: Assessment 1 delves into various leadership theories, offering students insights into transformational, situational, and servant leadership, among others. This exposure enables students to identify leadership styles that align with their values and the unique demands of healthcare settings.
Strategic Decision-Making: Nursing leaders are often required to make strategic decisions that impact patient care, resource allocation, and organizational outcomes. Assessment 1 equips students with the skills to analyze complex situations, evaluate options, and make informed decisions that uphold patient-centered care.
Communication and Team Building: Effective leadership hinges on clear communication and fostering collaborative teams. Assessment 1 guides students in honing communication skills, conflict resolution techniques, and strategies for building cohesive and high-performing healthcare teams.
Change Management: In the ever-evolving healthcare landscape, adaptability and change management are critical. Assessment 1 prepares students to lead and manage change initiatives, ensuring smooth transitions that enhance patient care quality.
NURS FPX 4020 Assessment 1 yields transformative outcomes for nursing students:
Leadership Competence: By mastering leadership theories and practical skills, students develop the competence to lead with confidence, promoting a positive influence on their teams and patient outcomes.
Strategic Vision: Assessment 1 instills a strategic mindset, enabling nursing leaders to envision and implement improvements that align with organizational goals while prioritizing patient welfare.
Collaborative Excellence: Effective communication and team-building skills fostered by Assessment 1 enhance collaboration among healthcare professionals, leading to enhanced care coordination and patient safety.
Change Catalysts: Nursing professionals who excel in Assessment 1 become adept at navigating change, fostering an environment where innovation and continuous improvement thrive.
NHS-FPX 5004 Assessment 1 is an extension of the leadership foundation laid by NURS FPX 4020 Assessment 1. While the latter focuses on nursing leadership within broader healthcare contexts, NHS-FPX 5004 Assessment 1 specifically addresses leadership and management within the NHS, offering insights into the unique challenges and opportunities within the UK healthcare system.
NURS FPX 4020 Assessment 1 serves as a beacon guiding nursing students towards impactful leadership roles within the healthcare sector. By imparting leadership theories, strategic acumen, and effective communication strategies, Assessment 1 transforms students into dynamic nursing leaders capable of navigating complex healthcare environments. As they progress to [url=https://onlineclassassignment.com/nurs-fpx-5004-assessment-1-leadership… 5004 Assessment 1[/url], students are poised to apply their leadership prowess within the context of the NHS, ultimately contributing to the enhancement of patient care, healthcare systems, and the nursing profession as a whole.
Hi,
The following patchset contains two fixes for the GTP tunnel driver:
1) Incorrect GTPA_MAX definition in UAPI headers. This is updating an
existing UAPI definition but for a good reason, this is certainly
broken. Similar fixes for incorrect _MAX definition in netlink
headers were applied in the past too.
2) Fix GTP driver PMTU with GRO packets, add missing call to
skb_gso_validate_network_len() to handle GRO packets.
Please apply, Thanks.
Pablo Neira Ayuso (2):
gtp: uapi: fix GTPA_MAX
gtp: fix fragmentation needed check with gso
drivers/net/gtp.c | 5 +++--
include/uapi/linux/gtp.h | 2 +-
2 files changed, 4 insertions(+), 3 deletions(-)
--
2.30.2
Thanks for the v2!
Adding Willem, Pablo, and Harald to CC (please CC them on future
versions).
On Thu, 12 Oct 2023 06:01:15 +0000 Takeru Hayasaka wrote:
> diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
> index f7fba0dc87e5..a2d4f2081cf3 100644
> --- a/include/uapi/linux/ethtool.h
> +++ b/include/uapi/linux/ethtool.h
> @@ -2011,6 +2011,18 @@ static inline int ethtool_validate_duplex(__u8 duplex)
> #define IPV4_FLOW 0x10 /* hash only */
> #define IPV6_FLOW 0x11 /* hash only */
> #define ETHER_FLOW 0x12 /* spec only (ether_spec) */
> +#define GTPU_V4_FLOW 0x13 /* hash only */
> +#define GTPU_V6_FLOW 0x14 /* hash only */
> +#define GTPC_V4_FLOW 0x15 /* hash only */
> +#define GTPC_V6_FLOW 0x16 /* hash only */
> +#define GTPC_TEID_V4_FLOW 0x17 /* hash only */
> +#define GTPC_TEID_V6_FLOW 0x18 /* hash only */
> +#define GTPU_EH_V4_FLOW 0x19 /* hash only */
> +#define GTPU_EH_V6_FLOW 0x20 /* hash only */
nit: please note that these are hex numbers,
next value after 0x19 is 0x1a, not 0x20.
> +#define GTPU_UL_V4_FLOW 0x21 /* hash only */
> +#define GTPU_UL_V6_FLOW 0x22 /* hash only */
> +#define GTPU_DL_V4_FLOW 0x23 /* hash only */
> +#define GTPU_DL_V6_FLOW 0x24 /* hash only */
> /* Flag to enable additional fields in struct ethtool_rx_flow_spec */
> #define FLOW_EXT 0x80000000
> #define FLOW_MAC_EXT 0x40000000
What gives me pause here is the number of flow sub-types we define
for GTP hashing.
My understanding of GTP is limited to what I just read on Wikipedia.
IIUC the GTPC vs GTPU distinction comes down to the UDP port on
which the protocol runs? Are the frames also different?
I'm guessing UL/DL are uplink/downlink but what's EH?
How do GTPU_V4_FLOW, GTPU_EH_V4_FLOW, GTPU_UL_V4_FLOW, and
GTPU_DL_V4_FLOW differ?
Key question is - are there reasonable use cases that you can think of
for enabling GTP hashing for each one of those bits individually or can
we combine some of them?
> @@ -2025,6 +2037,7 @@ static inline int ethtool_validate_duplex(__u8 duplex)
> #define RXH_IP_DST (1 << 5)
> #define RXH_L4_B_0_1 (1 << 6) /* src port in case of TCP/UDP/SCTP */
> #define RXH_L4_B_2_3 (1 << 7) /* dst port in case of TCP/UDP/SCTP */
> +#define RXH_GTP_TEID (1 << 8) /* teid in case of GTP */
> #define RXH_DISCARD (1 << 31)
Hi all,
I am happy to announce that a new version 202309 of the Osmocom CNI
(Cellular Network Infrastructure) software has been released this week.
For further information, please visit: https://osmocom.org/news/220
Regards,
Pau
--
- Pau Espin Pedrol <pespin(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
Dear Osmocom community,
while many people with a long history in FOSS development have no issues
at all with mailing lists as primary form of engaging with their
community, they have undoubtedly fallen out of fashion in favor of
various chat/messaging systems or web based forums.
In Osmocom, we've just launched an installation of the discourse forum
software available at https://discourse.osmocom.org/ providing an
alternative to our traditional mailing lists at https://lists.osmocom.org/
We're looking forward to see whether this web-based approach will
facilitate more and/or other people to engage with the Osmocom
developer/contributor community.
Feel free to join and get the discussions started. If there's a need
for more categories or sub-categories, just let one of the moderators
know and we can help with that.
The old mailing lists will continue to remain available for those who
prefer them.
--
- Harald Welte <laforge(a)osmocom.org> https://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Code that initialise a flowi4 structure manually before doing a fib
lookup can easily avoid overloading ->flowi4_tos with the RTO_ONLINK
bit. They can just set ->flowi4_scope correctly instead.
Properly separating the routing scope from ->flowi4_tos will allow to
eventually convert this field to dscp_t (to ensure proper separation
between DSCP and ECN).
Guillaume Nault (3):
gtp: Set TOS and routing scope independently for fib lookups.
dccp: Set TOS and routing scope independently for fib lookups.
sctp: Set TOS and routing scope independently for fib lookups.
drivers/net/gtp.c | 3 ++-
net/dccp/ipv4.c | 3 ++-
net/sctp/protocol.c | 3 ++-
3 files changed, 6 insertions(+), 3 deletions(-)
--
2.39.2
Hi all,
during recent patch review
(https://gerrit.osmocom.org/c/osmo-trx/+/33737) the topic of continuing
to maintain support for big endian machines has come up.
While traditionally I've always been a strong proponent of writing
portable code that can run also on big endian systems, it is not the
year 2003 or 2008 anymore, and PowerPC (the main big endian platform) is
dead by now, as is SPARC. Not just in newly-built processors, but also
in existing and still operating machines, at least of the class that
would run our code.
So unless somebody objects with strong arguments, I'd propose to
officially and explicitly drop supporting big endian systems from
osmocom CNI projects.
From what I can tell, this would primarily mean
* drop the struct_endianness check from the commit verification
* removing all our struct_endianness-generated or other code that
explicitly adds big endian support
* adding some kind of #warning or even #error to a common libosmocore
header file if anyone tries to build on big endian
This obviously doesn't mean we can abandon using [osmo_]{htonl,ntohl},
as network byte order is still network byte order.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> https://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Dear Osmocom Community,
I have noticed that the wiki page for OpenBSC GPRS at
https://osmocom.org/projects/cellular-infrastructure/wiki/OpenBSC_GPRS has
not been updated for four years, and since then, there have been
significant updates to the software. As a result, the information on the
GPRS/EDGE Setup page may be outdated, and I am struggling to configure GPRS
on my system.
I have attached my configuration files below for your review.
ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel
state DOWN group default qlen 1000
link/ether ec:8e:b5:41:cb:90 brd ff:ff:ff:ff:ff:ff
3: wlp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state
UP group default qlen 1000
link/ether b8:8a:60:4f:59:02 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.109/24 brd 192.168.1.255 scope global dynamic
noprefixroute wlp1s0
valid_lft 7152sec preferred_lft 7152sec
inet6 fe80::649b:2ab5:6dd3:8779/64 scope link noprefixroute
valid_lft forever preferred_lft forever
Hi all,
I am happy to announce that a new version 202302 of the Osmocom CNI
(Cellular Network Infrastructure) software has been released this week.
For further information, please visit: https://osmocom.org/news/207
Regards,
Pau
--
- Pau Espin Pedrol <pespin(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
Dear Osmocom community,
we're happy to announce the next incarnation of OsmoDevCall]].
when:
November 16, 2022 at 20:00 CET
where:
https://meeting5.franken.de/b/har-xbc-bsx-wvs
This time, @fixeria will be presenting on
MS/BS power control support in OsmoBSC/OsmoBTS
For those not entirely 3gpp-acronym-savyy: That's how the uplink (phone
-> network) and downlink (network -> phone) transmit RF power level is
adjusted during an active call in GSM.
This meeting will have the following schedule:
20:00 meet + greet
20:10 presentation as outlined above
21:00 unstructured supplementary social event [*]
Attendance is free of charge and open to anyone with an interest
in Osmocom or open source cellular technologies.
More information about OsmoDevCall, including the schedule
for further upcoming events can be found at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall
Looking forward to meeting you soon!
Best regards,
Harald
[*] this is how we started to call the "unstructured" part of osmocom
developer conferences in the past, basically where anyone can talk about
anything, no formal schedule or structure.
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hello various Osmocom mailing lists,
as previously announced (https://osmocom.org/news/191):
* The binary packages are being built on Osmocom's own OBS server now.
* We will stop pushing packages to the openSUSE OBS server at the end of
October (in one week).
If you are using Osmocom binary packages, please make sure that you have
configured the new repository URLs.
See the wiki for details:
https://osmocom.org/projects/cellular-infrastructure/wiki/Binary_Packages
Best,
Oliver
--
- Oliver Smith <osmith(a)sysmocom.de> https://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
Hi all,
as some of you may know, I am working on the MS side implementation of
GPRS protocol stack. The end goal is to have something similar to srsUE
(part of srsRAN, former srsLTE), but for GPRS.
In order to reduce code duplication it was decided to move some stuff
from both osmo-pcu.git and osmo-sgsn.git into shared libraries, so that
we could re-use existing code in the upcoming MS side implementation.
== What is already done
* Redmine: https://osmocom.org/projects/libosmo-gprs
* Gerrit: https://gerrit.osmocom.org/q/libosmo-gprs
* Gitea: https://gitea.osmocom.org/osmocom/libosmo-gprs
* osmo-ci.git: https://gerrit.osmocom.org/c/osmo-ci/+/29019
== What is missing
* GitHub: https://github.com/osmocom/libosmo-gprs
* cgit: https://cgit.osmocom.org/libosmo-gprs/
** Coverity pulls from this mirror
** Jenkins build verification uses this mirror
I will need some help with both GitHub and cgit, as I don't have admin
permissions. Please also let me know if I missed something.
Best regards,
Vadim.
--
- Vadim Yanitskiy <vyanitskiy at sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
hi.
i just installed the system followed the instructions on
https://security-bits.de/research/cellular/lab_setup.
but it looks the gb(ns) configuration.command encapsulation missed in this
version.
OsmoSGSN(config-ns)# list
help
list [with-flags]
show vty-attributes
show vty-attributes (application|library|global)
write terminal
write file [PATH]
write memory
write
show running-config
exit
end
timer
(tns-block|tns-block-retries|tns-reset|tns-reset-retries|tns-test|tns-alive|tns-alive-retries|tsns-prov|tsns-size-retries|tsns-config-retries|tsns-procedures-retries)
<0-65535>
nse <0-65535> [ip-sns-role-sgsn]
no nse <0-65535>
bind (fr|udp) ID
no bind ID
ip-sns-default bind ID
no ip-sns-default bind ID
OsmoSGSN(config-ns)#
libosmocore/bionic 0.9.0-7 amd64
libosmocore-dbg/bionic 0.9.0-7 amd64
libosmocore-dev/bionic 0.9.0-7 amd64
br,thornton.
Hi Team,
We are not able to make PS calls using Open SGSN and seeing always
“Activated PDP context Reject” from SGSN to BSC.
Can you please look into logs and provide any inputs on this issue with
Open SGSN.
Regards,
Bhaskar
I am currently adding GTP echo handling to osmo-upf, which uses the GTP kernel
module to handle GTP G-PDUs. What I need is a GTPv1-U ECHO response when an
GTPv1-U ECHO request comes in on the user land GTP socket.
We already have GTP implementations in
- libgtp (osmo-ggsn.git/gtp/)
- gtp_echo_responder.c (osmo-ggsn.git/utils/)
- osmo-hnodeb/gtp.c
I first used libgtp to do GTP ECHO handling in osmo-upf, but that basically
includes all of the GTP-C GSN code, in a rather inflexible way. It seems to
work, but we don't want to include this clunky dependency.
Looking at gtp_echo_responder.c, I see that the code uses none of the Osmocom
structures (osmo_fd, logging, osmo_select, osmocom/core/endian.h), and it
implements GTPv1-C and GTPv2-C, but I need GTPv1-U.
osmo-hnodeb/gtp.c does use Osmocom structures. It has its own struct gtp1u_hdr.
But apparently osmo-hnodeb doesn't do any GTP ECHO handling at all.
So I need to dig deeper to understand the GTP Echo landscape...
IIUC, there are GTPv0, GTPv1-C, GTPv1-U, GTPv2-C.
3GPP TS 29.281 is GTPv1-U.
Is 29.060 GTPv1-C? Any others?
I am now only concerned with GTPv1-U, so TS 29.281 should be all I need. Still
interesting to know, do the echos differ between the protocol versions and
planes? Can I use the GTPv1-C code from gtp_echo_responder.c for GTPv1-U?
The fact that the GTPv1-U header contains a TEID confused me at first, then I
found in 29.281 that the TEID shall be all zeros in the ECHO req + resp
messages. So, yes, ECHO is done between GSNs as a whole, not on each tunnel.
I think I am ok solving these questions, but am writing this specifically
because it feels like I or at least the next person shouldn't have to re-invent
this wheel yet again.
Will we spawn all-new GTP implementations in every osmocom repository that
touches GTP, or should I rather implement a re-usable GTP echo response now?
One proper (TM) way seems to be to rearrange libgtp in such a way that a caller
can just use the msg coding part for specific messages, and can use UDP sockets
without having to set up a complete struct gsn_t. That's some work.
Another way that comes to mind is opening a libosmo-gtp section in libosmocore,
absorb protocol definitions across the various GTP versions there, and use them
in the places where we do GTP coding now. Seems a lot of work.
...or I go the apparently quickest, easiest way, do a copy/paste/reimplement
from scratch of GTP echo coding, so that we have yet another partial GTP
implementation in osmo-upf.git. That's what I'm doing now, but it feels wrong.
Any thoughts?
~N
This series contains updates to gtp and ice driver.
Wojciech fixes smatch reported inconsistent indenting for gtp and ice.
Yang Yingliang fixes a couple of return value checks for GNSS to IS_PTR
instead of null.
Jacob adds support for trace events on tx timestamps.
The following are changes since commit 49045b9c810cd9b4ac5f8f235ad8ef17553a00fa:
Merge branch 'mediatek-next'
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue 100GbE
Jacob Keller (1):
ice: add trace events for tx timestamps
Wojciech Drewek (2):
gtp: Fix inconsistent indenting
ice: Fix inconsistent indenting in ice_switch
Yang Yingliang (1):
ice: fix return value check in ice_gnss.c
drivers/net/ethernet/intel/ice/ice_gnss.c | 4 ++--
drivers/net/ethernet/intel/ice/ice_ptp.c | 8 +++++++
drivers/net/ethernet/intel/ice/ice_switch.c | 2 +-
drivers/net/ethernet/intel/ice/ice_trace.h | 24 +++++++++++++++++++++
drivers/net/gtp.c | 2 +-
5 files changed, 36 insertions(+), 4 deletions(-)
--
2.31.1
Marcin Szycik says:
Add support for adding GTP-C and GTP-U filters in switchdev mode.
To create a filter for GTP, create a GTP-type netdev with ip tool, enable
hardware offload, add qdisc and add a filter in tc:
ip link add $GTP0 type gtp role <sgsn/ggsn> hsize <hsize>
ethtool -K $PF0 hw-tc-offload on
tc qdisc add dev $GTP0 ingress
tc filter add dev $GTP0 ingress prio 1 flower enc_key_id 1337 \
action mirred egress redirect dev $VF1_PR
By default, a filter for GTP-U will be added. To add a filter for GTP-C,
specify enc_dst_port = 2123, e.g.:
tc filter add dev $GTP0 ingress prio 1 flower enc_key_id 1337 \
enc_dst_port 2123 action mirred egress redirect dev $VF1_PR
Note: outer IPv6 offload is not supported yet.
Note: GTP-U with no payload offload is not supported yet.
ICE COMMS package is required to create a filter as it contains GTP
profiles.
Changes in iproute2 [1] are required to be able to add GTP netdev and use
GTP-specific options (QFI and PDU type).
[1] https://lore.kernel.org/netdev/20220211182902.11542-1-wojciech.drewek@intel…
---
v2: Add more CC
v3: Fix mail thread, sorry for spam
v4: Add GTP echo response in gtp module
v5: Change patch order
v6: Add GTP echo request in gtp module
v7: Fix kernel-docs in ice
v8: Remove handling of GTP Echo Response
v9: Add sending of multicast message on GTP Echo Response, fix GTP-C dummy
packet selection
v10: Rebase, fixed most 80 char line limits
v11: Rebase, collect Harald's Reviewed-by on patch 3
The following are changes since commit 59d5923536ac8640f4ff20d011a4851a3c143764:
Merge branch 'ptp-ocp-new-firmware-support'
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue 100GbE
Marcin Szycik (1):
ice: Support GTP-U and GTP-C offload in switchdev
Michal Swiatkowski (1):
ice: Fix FV offset searching
Wojciech Drewek (5):
gtp: Allow to create GTP device without FDs
gtp: Implement GTP echo response
gtp: Implement GTP echo request
net/sched: Allow flower to match on GTP options
gtp: Add support for checking GTP device type
drivers/net/ethernet/intel/ice/ice.h | 1 +
.../net/ethernet/intel/ice/ice_flex_pipe.c | 53 +-
.../net/ethernet/intel/ice/ice_flex_pipe.h | 2 +-
.../net/ethernet/intel/ice/ice_flex_type.h | 6 +-
.../ethernet/intel/ice/ice_protocol_type.h | 19 +
drivers/net/ethernet/intel/ice/ice_switch.c | 654 ++++++++++++++++--
drivers/net/ethernet/intel/ice/ice_switch.h | 9 +
drivers/net/ethernet/intel/ice/ice_tc_lib.c | 105 ++-
drivers/net/ethernet/intel/ice/ice_tc_lib.h | 3 +
drivers/net/gtp.c | 565 +++++++++++++--
include/net/gtp.h | 42 ++
include/uapi/linux/gtp.h | 1 +
include/uapi/linux/if_link.h | 2 +
include/uapi/linux/if_tunnel.h | 4 +-
include/uapi/linux/pkt_cls.h | 15 +
net/sched/cls_flower.c | 116 ++++
16 files changed, 1478 insertions(+), 119 deletions(-)
--
2.31.1
Dear fellow Osmocom developers,
as you all know, we've sadly had to skip OsmoDevCon 2020 and 2021,
trying to compensate it at least to some extent with our OsmoDevCall
every two weeks.
The COVID-19 pandemic is far from over, and we don't know what the
upcoming winter season will bring.
Nevertheless, I think it would be a good idea to start a discussion of
whether we should plan for an OsmoDevCon in 2022.
I personally would say let's plan for the usual late April 2022 time frame,
and if the pandemic situation deteriorates, we can still cancel it with
something like one month lead time.
I would also personally suggest to limit attendance to people who are fully
vaccinated, and in addition do a self-test for all participants every
morning.
In terms of venue, we might also consider to move to a venue that allows better
ventilation. Irrespective of the above we can also bring the air filters from
the sysmocom office.
So with that as an input statement, I would like to hear your opinion
on the above proposals. Who would want to attend? Any complaints against
the "vaccinated only plus daily self-tests in the morning" approach?
Regards,
Harald
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Add support for adding GTP-C and GTP-U filters in switchdev mode.
To create a filter for GTP, create a GTP-type netdev with ip tool, enable
hardware offload, add qdisc and add a filter in tc:
ip link add $GTP0 type gtp role <sgsn/ggsn> hsize <hsize>
ethtool -K $PF0 hw-tc-offload on
tc qdisc add dev $GTP0 ingress
tc filter add dev $GTP0 ingress prio 1 flower enc_key_id 1337 \
action mirred egress redirect dev $VF1_PR
By default, a filter for GTP-U will be added. To add a filter for GTP-C,
specify enc_dst_port = 2123, e.g.:
tc filter add dev $GTP0 ingress prio 1 flower enc_key_id 1337 \
enc_dst_port 2123 action mirred egress redirect dev $VF1_PR
Note: outer IPv6 offload is not supported yet.
Note: GTP-U with no payload offload is not supported yet.
ICE COMMS package is required to create a filter as it contains GTP
profiles.
Changes in iproute2 [1] are required to be able to add GTP netdev and use
GTP-specific options (QFI and PDU type).
[1] https://lore.kernel.org/netdev/20220211182902.11542-1-wojciech.drewek@intel…
---
v2: Add more CC
v3: Fix mail thread, sorry for spam
v4: Add GTP echo response in gtp module
v5: Change patch order
v6: Add GTP echo request in gtp module
v7: Fix kernel-docs in ice
v8: Remove handling of GTP Echo Response
v9: Add sending of multicast message on GTP Echo Response, fix GTP-C dummy
packet selection
v10: Rebase, fixed most 80 char line limits
Marcin Szycik (1):
ice: Support GTP-U and GTP-C offload in switchdev
Michal Swiatkowski (1):
ice: Fix FV offset searching
Wojciech Drewek (5):
gtp: Allow to create GTP device without FDs
gtp: Implement GTP echo response
gtp: Implement GTP echo request
net/sched: Allow flower to match on GTP options
gtp: Add support for checking GTP device type
drivers/net/ethernet/intel/ice/ice.h | 1 +
.../net/ethernet/intel/ice/ice_flex_pipe.c | 53 +-
.../net/ethernet/intel/ice/ice_flex_pipe.h | 2 +-
.../net/ethernet/intel/ice/ice_flex_type.h | 6 +-
.../ethernet/intel/ice/ice_protocol_type.h | 19 +
drivers/net/ethernet/intel/ice/ice_switch.c | 643 ++++++++++++++++--
drivers/net/ethernet/intel/ice/ice_switch.h | 9 +
drivers/net/ethernet/intel/ice/ice_tc_lib.c | 105 ++-
drivers/net/ethernet/intel/ice/ice_tc_lib.h | 3 +
drivers/net/gtp.c | 565 +++++++++++++--
include/net/gtp.h | 42 ++
include/uapi/linux/gtp.h | 1 +
include/uapi/linux/if_link.h | 2 +
include/uapi/linux/if_tunnel.h | 4 +-
include/uapi/linux/pkt_cls.h | 15 +
net/sched/cls_flower.c | 116 ++++
16 files changed, 1473 insertions(+), 113 deletions(-)
--
2.35.1
Add support for adding GTP-C and GTP-U filters in switchdev mode.
To create a filter for GTP, create a GTP-type netdev with ip tool, enable
hardware offload, add qdisc and add a filter in tc:
ip link add $GTP0 type gtp role <sgsn/ggsn> hsize <hsize>
ethtool -K $PF0 hw-tc-offload on
tc qdisc add dev $GTP0 ingress
tc filter add dev $GTP0 ingress prio 1 flower enc_key_id 1337 \
action mirred egress redirect dev $VF1_PR
By default, a filter for GTP-U will be added. To add a filter for GTP-C,
specify enc_dst_port = 2123, e.g.:
tc filter add dev $GTP0 ingress prio 1 flower enc_key_id 1337 \
enc_dst_port 2123 action mirred egress redirect dev $VF1_PR
Note: outer IPv6 offload is not supported yet.
Note: GTP-U with no payload offload is not supported yet.
ICE COMMS package is required to create a filter as it contains GTP
profiles.
Changes in iproute2 [1] are required to be able to add GTP netdev and use
GTP-specific options (QFI and PDU type).
[1] https://lore.kernel.org/netdev/20220211182902.11542-1-wojciech.drewek@intel…
---
v2: Add more CC
v3: Fix mail thread, sorry for spam
v4: Add GTP echo response in gtp module
v5: Change patch order
v6: Add GTP echo request in gtp module
v7: Fix kernel-docs in ice
v8: Remove handling of GTP Echo Response
v9: Add sending of multicast message on GTP Echo Response, fix GTP-C dummy
packet selection
Marcin Szycik (1):
ice: Support GTP-U and GTP-C offload in switchdev
Michal Swiatkowski (1):
ice: Fix FV offset searching
Wojciech Drewek (5):
gtp: Allow to create GTP device without FDs
gtp: Implement GTP echo response
gtp: Implement GTP echo request
net/sched: Allow flower to match on GTP options
gtp: Add support for checking GTP device type
drivers/net/ethernet/intel/ice/ice.h | 1 +
.../net/ethernet/intel/ice/ice_flex_pipe.c | 52 +-
.../net/ethernet/intel/ice/ice_flex_pipe.h | 2 +-
.../net/ethernet/intel/ice/ice_flex_type.h | 6 +-
.../ethernet/intel/ice/ice_protocol_type.h | 19 +
drivers/net/ethernet/intel/ice/ice_switch.c | 643 ++++++++++++++++--
drivers/net/ethernet/intel/ice/ice_switch.h | 9 +
drivers/net/ethernet/intel/ice/ice_tc_lib.c | 105 ++-
drivers/net/ethernet/intel/ice/ice_tc_lib.h | 3 +
drivers/net/gtp.c | 549 +++++++++++++--
include/net/gtp.h | 42 ++
include/uapi/linux/gtp.h | 1 +
include/uapi/linux/if_link.h | 2 +
include/uapi/linux/if_tunnel.h | 4 +-
include/uapi/linux/pkt_cls.h | 15 +
net/sched/cls_flower.c | 116 ++++
16 files changed, 1456 insertions(+), 113 deletions(-)
--
2.35.1
Add support for adding GTP-C and GTP-U filters in switchdev mode.
To create a filter for GTP, create a GTP-type netdev with ip tool, enable
hardware offload, add qdisc and add a filter in tc:
ip link add $GTP0 type gtp role <sgsn/ggsn> hsize <hsize>
ethtool -K $PF0 hw-tc-offload on
tc qdisc add dev $GTP0 ingress
tc filter add dev $GTP0 ingress prio 1 flower enc_key_id 1337 \
action mirred egress redirect dev $VF1_PR
By default, a filter for GTP-U will be added. To add a filter for GTP-C,
specify enc_dst_port = 2123, e.g.:
tc filter add dev $GTP0 ingress prio 1 flower enc_key_id 1337 \
enc_dst_port 2123 action mirred egress redirect dev $VF1_PR
Note: outer IPv6 offload is not supported yet.
Note: GTP-U with no payload offload is not supported yet.
ICE COMMS package is required to create a filter as it contains GTP
profiles.
Changes in iproute2 [1] are required to be able to add GTP netdev and use
GTP-specific options (QFI and PDU type).
[1] https://lore.kernel.org/netdev/20220211182902.11542-1-wojciech.drewek@intel…
---
v2: Adding more CC
v3: Fixed mail thread, sorry for spam
v4: Added GTP echo response in gtp module
v5: Change patch order
v6: Added GTP echo request in gtp module
v7: Fix kernel-docs in ice
Marcin Szycik (1):
ice: Support GTP-U and GTP-C offload in switchdev
Michal Swiatkowski (1):
ice: Fix FV offset searching
Wojciech Drewek (5):
gtp: Allow to create GTP device without FDs
gtp: Implement GTP echo response
gtp: Implement GTP echo request
net/sched: Allow flower to match on GTP options
gtp: Add support for checking GTP device type
drivers/net/ethernet/intel/ice/ice.h | 1 +
.../net/ethernet/intel/ice/ice_flex_pipe.c | 52 +-
.../net/ethernet/intel/ice/ice_flex_pipe.h | 2 +-
.../net/ethernet/intel/ice/ice_flex_type.h | 6 +-
.../ethernet/intel/ice/ice_protocol_type.h | 19 +
drivers/net/ethernet/intel/ice/ice_switch.c | 630 +++++++++++++++--
drivers/net/ethernet/intel/ice/ice_switch.h | 9 +
drivers/net/ethernet/intel/ice/ice_tc_lib.c | 105 ++-
drivers/net/ethernet/intel/ice/ice_tc_lib.h | 3 +
drivers/net/gtp.c | 661 +++++++++++++++++-
include/net/gtp.h | 42 ++
include/uapi/linux/gtp.h | 2 +
include/uapi/linux/if_link.h | 2 +
include/uapi/linux/if_tunnel.h | 4 +-
include/uapi/linux/pkt_cls.h | 15 +
net/sched/cls_flower.c | 116 +++
16 files changed, 1565 insertions(+), 104 deletions(-)
--
2.35.1
Add support for adding GTP-C and GTP-U filters in switchdev mode.
To create a filter for GTP, create a GTP-type netdev with ip tool, enable
hardware offload, add qdisc and add a filter in tc:
ip link add $GTP0 type gtp role <sgsn/ggsn> hsize <hsize>
ethtool -K $PF0 hw-tc-offload on
tc qdisc add dev $GTP0 ingress
tc filter add dev $GTP0 ingress prio 1 flower enc_key_id 1337 \
action mirred egress redirect dev $VF1_PR
By default, a filter for GTP-U will be added. To add a filter for GTP-C,
specify enc_dst_port = 2123, e.g.:
tc filter add dev $GTP0 ingress prio 1 flower enc_key_id 1337 \
enc_dst_port 2123 action mirred egress redirect dev $VF1_PR
Note: outer IPv6 offload is not supported yet.
Note: GTP-U with no payload offload is not supported yet.
ICE COMMS package is required to create a filter as it contains GTP
profiles.
Changes in iproute2 [1] are required to be able to add GTP netdev and use
GTP-specific options (QFI and PDU type).
[1] https://lore.kernel.org/netdev/20220211182902.11542-1-wojciech.drewek@intel…
---
v2: Adding more CC
v3: Fixed mail thread, sorry for spam
v4: Added GTP echo response in gtp module
v5: Change patch order
v6: Added GTP echo request in gtp module
v7: Fix kernel-docs in ice
v8: Remove handling of GTP Echo Response
Marcin Szycik (1):
ice: Support GTP-U and GTP-C offload in switchdev
Michal Swiatkowski (1):
ice: Fix FV offset searching
Wojciech Drewek (5):
gtp: Allow to create GTP device without FDs
gtp: Implement GTP echo response
gtp: Implement GTP echo request
net/sched: Allow flower to match on GTP options
gtp: Add support for checking GTP device type
drivers/net/ethernet/intel/ice/ice.h | 1 +
.../net/ethernet/intel/ice/ice_flex_pipe.c | 52 +-
.../net/ethernet/intel/ice/ice_flex_pipe.h | 2 +-
.../net/ethernet/intel/ice/ice_flex_type.h | 6 +-
.../ethernet/intel/ice/ice_protocol_type.h | 19 +
drivers/net/ethernet/intel/ice/ice_switch.c | 630 ++++++++++++++++--
drivers/net/ethernet/intel/ice/ice_switch.h | 9 +
drivers/net/ethernet/intel/ice/ice_tc_lib.c | 105 ++-
drivers/net/ethernet/intel/ice/ice_tc_lib.h | 3 +
drivers/net/gtp.c | 426 +++++++++++-
include/net/gtp.h | 42 ++
include/uapi/linux/gtp.h | 1 +
include/uapi/linux/if_link.h | 2 +
include/uapi/linux/if_tunnel.h | 4 +-
include/uapi/linux/pkt_cls.h | 15 +
net/sched/cls_flower.c | 116 ++++
16 files changed, 1330 insertions(+), 103 deletions(-)
--
2.35.1