diff mbox series

[net] drivers/net/wan/hdlc: Set skb->protocol before transmitting

Message ID 20200916212507.528223-1-xie.he.0141@gmail.com
State New
Headers show
Series [net] drivers/net/wan/hdlc: Set skb->protocol before transmitting | expand

Commit Message

Xie He Sept. 16, 2020, 9:25 p.m. UTC
This patch sets skb->protocol before transmitting frames on the HDLC
device, so that a user listening on the HDLC device with an AF_PACKET
socket will see outgoing frames' sll_protocol field correctly set and
consistent with that of incoming frames.

1. Control frames in hdlc_cisco and hdlc_ppp

When these drivers send control frames, skb->protocol is not set.

This value should be set to htons(ETH_P_HDLC), because when receiving
control frames, their skb->protocol is set to htons(ETH_P_HDLC).

When receiving, hdlc_type_trans in hdlc.h is called, which then calls
cisco_type_trans or ppp_type_trans. The skb->protocol of control frames
is set to htons(ETH_P_HDLC) so that the control frames can be received
by hdlc_rcv in hdlc.c, which calls cisco_rx or ppp_rx to process the
control frames.

2. hdlc_fr

When this driver sends control frames, skb->protocol is set to internal
values used in this driver.

When this driver sends data frames (from upper stacked PVC devices),
skb->protocol is the same as that of the user data packet being sent on
the upper PVC device (for normal PVC devices), or is htons(ETH_P_802_3)
(for Ethernet-emulating PVC devices).

However, skb->protocol for both control frames and data frames should be
set to htons(ETH_P_HDLC), because when receiving, all frames received on
the HDLC device will have their skb->protocol set to htons(ETH_P_HDLC).

When receiving, hdlc_type_trans in hdlc.h is called, and because this
driver doesn't provide a type_trans function in struct hdlc_proto,
all frames will have their skb->protocol set to htons(ETH_P_HDLC).
The frames are then received by hdlc_rcv in hdlc.c, which calls fr_rx
to process the frames (control frames are consumed and data frames
are re-received on upper PVC devices).

Cc: Krzysztof Halasa <khc@pm.waw.pl>
Signed-off-by: Xie He <xie.he.0141@gmail.com>
---
 drivers/net/wan/hdlc_cisco.c | 1 +
 drivers/net/wan/hdlc_fr.c    | 3 +++
 drivers/net/wan/hdlc_ppp.c   | 1 +
 3 files changed, 5 insertions(+)

Comments

David Miller Sept. 17, 2020, 11:41 p.m. UTC | #1
From: Xie He <xie.he.0141@gmail.com>

Date: Wed, 16 Sep 2020 14:25:07 -0700

> This patch sets skb->protocol before transmitting frames on the HDLC

> device, so that a user listening on the HDLC device with an AF_PACKET

> socket will see outgoing frames' sll_protocol field correctly set and

> consistent with that of incoming frames.

> 

> 1. Control frames in hdlc_cisco and hdlc_ppp

> 

> When these drivers send control frames, skb->protocol is not set.

> 

> This value should be set to htons(ETH_P_HDLC), because when receiving

> control frames, their skb->protocol is set to htons(ETH_P_HDLC).

> 

> When receiving, hdlc_type_trans in hdlc.h is called, which then calls

> cisco_type_trans or ppp_type_trans. The skb->protocol of control frames

> is set to htons(ETH_P_HDLC) so that the control frames can be received

> by hdlc_rcv in hdlc.c, which calls cisco_rx or ppp_rx to process the

> control frames.

> 

> 2. hdlc_fr

> 

> When this driver sends control frames, skb->protocol is set to internal

> values used in this driver.

> 

> When this driver sends data frames (from upper stacked PVC devices),

> skb->protocol is the same as that of the user data packet being sent on

> the upper PVC device (for normal PVC devices), or is htons(ETH_P_802_3)

> (for Ethernet-emulating PVC devices).

> 

> However, skb->protocol for both control frames and data frames should be

> set to htons(ETH_P_HDLC), because when receiving, all frames received on

> the HDLC device will have their skb->protocol set to htons(ETH_P_HDLC).

> 

> When receiving, hdlc_type_trans in hdlc.h is called, and because this

> driver doesn't provide a type_trans function in struct hdlc_proto,

> all frames will have their skb->protocol set to htons(ETH_P_HDLC).

> The frames are then received by hdlc_rcv in hdlc.c, which calls fr_rx

> to process the frames (control frames are consumed and data frames

> are re-received on upper PVC devices).

> 

> Cc: Krzysztof Halasa <khc@pm.waw.pl>

> Signed-off-by: Xie He <xie.he.0141@gmail.com>


Applied, thank you.
diff mbox series

Patch

diff --git a/drivers/net/wan/hdlc_cisco.c b/drivers/net/wan/hdlc_cisco.c
index 444130655d8e..cb5898f7d68c 100644
--- a/drivers/net/wan/hdlc_cisco.c
+++ b/drivers/net/wan/hdlc_cisco.c
@@ -118,6 +118,7 @@  static void cisco_keepalive_send(struct net_device *dev, u32 type,
 	skb_put(skb, sizeof(struct cisco_packet));
 	skb->priority = TC_PRIO_CONTROL;
 	skb->dev = dev;
+	skb->protocol = htons(ETH_P_HDLC);
 	skb_reset_network_header(skb);
 
 	dev_queue_xmit(skb);
diff --git a/drivers/net/wan/hdlc_fr.c b/drivers/net/wan/hdlc_fr.c
index 12b35404cd8e..d6cfd51613ed 100644
--- a/drivers/net/wan/hdlc_fr.c
+++ b/drivers/net/wan/hdlc_fr.c
@@ -433,6 +433,8 @@  static netdev_tx_t pvc_xmit(struct sk_buff *skb, struct net_device *dev)
 			if (pvc->state.fecn) /* TX Congestion counter */
 				dev->stats.tx_compressed++;
 			skb->dev = pvc->frad;
+			skb->protocol = htons(ETH_P_HDLC);
+			skb_reset_network_header(skb);
 			dev_queue_xmit(skb);
 			return NETDEV_TX_OK;
 		}
@@ -555,6 +557,7 @@  static void fr_lmi_send(struct net_device *dev, int fullrep)
 	skb_put(skb, i);
 	skb->priority = TC_PRIO_CONTROL;
 	skb->dev = dev;
+	skb->protocol = htons(ETH_P_HDLC);
 	skb_reset_network_header(skb);
 
 	dev_queue_xmit(skb);
diff --git a/drivers/net/wan/hdlc_ppp.c b/drivers/net/wan/hdlc_ppp.c
index 16f33d1ffbfb..64f855651336 100644
--- a/drivers/net/wan/hdlc_ppp.c
+++ b/drivers/net/wan/hdlc_ppp.c
@@ -251,6 +251,7 @@  static void ppp_tx_cp(struct net_device *dev, u16 pid, u8 code,
 
 	skb->priority = TC_PRIO_CONTROL;
 	skb->dev = dev;
+	skb->protocol = htons(ETH_P_HDLC);
 	skb_reset_network_header(skb);
 	skb_queue_tail(&tx_queue, skb);
 }