| 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 |
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 --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); }
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(+)