Skip to content

Commit df0eebc

Browse files
lxingregkh
authored andcommitted
ipip: only increase err_count for some certain type icmp in ipip_err
[ Upstream commit f3594f0 ] t->err_count is used to count the link failure on tunnel and an err will be reported to user socket in tx path if t->err_count is not 0. udp socket could even return EHOSTUNREACH to users. Since commit fd58156 ("IPIP: Use ip-tunneling code.") removed the 'switch check' for icmp type in ipip_err(), err_count would be increased by the icmp packet with ICMP_EXC_FRAGTIME code. an link failure would be reported out due to this. In Jianlin's case, when receiving ICMP_EXC_FRAGTIME a icmp packet, udp netperf failed with the err: send_data: data send error: No route to host (errno 113) We expect this error reported from tunnel to socket when receiving some certain type icmp, but not ICMP_EXC_FRAGTIME, ICMP_SR_FAILED or ICMP_PARAMETERPROB ones. This patch is to bring 'switch check' for icmp type back to ipip_err so that it only reports link failure for the right type icmp, just as in ipgre_err() and ipip6_err(). Fixes: fd58156 ("IPIP: Use ip-tunneling code.") Reported-by: Jianlin Shi <jishi@redhat.com> Signed-off-by: Xin Long <lucien.xin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
1 parent fbf9227 commit df0eebc

1 file changed

Lines changed: 42 additions & 17 deletions

File tree

net/ipv4/ipip.c

Lines changed: 42 additions & 17 deletions
Original file line numberDiff line numberDiff line change
@@ -128,43 +128,68 @@ static struct rtnl_link_ops ipip_link_ops __read_mostly;
128128

129129
static int ipip_err(struct sk_buff *skb, u32 info)
130130
{
131-
132-
/* All the routers (except for Linux) return only
133-
8 bytes of packet payload. It means, that precise relaying of
134-
ICMP in the real Internet is absolutely infeasible.
135-
*/
131+
/* All the routers (except for Linux) return only
132+
* 8 bytes of packet payload. It means, that precise relaying of
133+
* ICMP in the real Internet is absolutely infeasible.
134+
*/
136135
struct net *net = dev_net(skb->dev);
137136
struct ip_tunnel_net *itn = net_generic(net, ipip_net_id);
138137
const struct iphdr *iph = (const struct iphdr *)skb->data;
139-
struct ip_tunnel *t;
140-
int err;
141138
const int type = icmp_hdr(skb)->type;
142139
const int code = icmp_hdr(skb)->code;
140+
struct ip_tunnel *t;
141+
int err = 0;
142+
143+
switch (type) {
144+
case ICMP_DEST_UNREACH:
145+
switch (code) {
146+
case ICMP_SR_FAILED:
147+
/* Impossible event. */
148+
goto out;
149+
default:
150+
/* All others are translated to HOST_UNREACH.
151+
* rfc2003 contains "deep thoughts" about NET_UNREACH,
152+
* I believe they are just ether pollution. --ANK
153+
*/
154+
break;
155+
}
156+
break;
157+
158+
case ICMP_TIME_EXCEEDED:
159+
if (code != ICMP_EXC_TTL)
160+
goto out;
161+
break;
162+
163+
case ICMP_REDIRECT:
164+
break;
165+
166+
default:
167+
goto out;
168+
}
143169

144-
err = -ENOENT;
145170
t = ip_tunnel_lookup(itn, skb->dev->ifindex, TUNNEL_NO_KEY,
146171
iph->daddr, iph->saddr, 0);
147-
if (!t)
172+
if (!t) {
173+
err = -ENOENT;
148174
goto out;
175+
}
149176

150177
if (type == ICMP_DEST_UNREACH && code == ICMP_FRAG_NEEDED) {
151-
ipv4_update_pmtu(skb, dev_net(skb->dev), info,
152-
t->parms.link, 0, iph->protocol, 0);
153-
err = 0;
178+
ipv4_update_pmtu(skb, net, info, t->parms.link, 0,
179+
iph->protocol, 0);
154180
goto out;
155181
}
156182

157183
if (type == ICMP_REDIRECT) {
158-
ipv4_redirect(skb, dev_net(skb->dev), t->parms.link, 0,
159-
iph->protocol, 0);
160-
err = 0;
184+
ipv4_redirect(skb, net, t->parms.link, 0, iph->protocol, 0);
161185
goto out;
162186
}
163187

164-
if (t->parms.iph.daddr == 0)
188+
if (t->parms.iph.daddr == 0) {
189+
err = -ENOENT;
165190
goto out;
191+
}
166192

167-
err = 0;
168193
if (t->parms.iph.ttl == 0 && type == ICMP_TIME_EXCEEDED)
169194
goto out;
170195

0 commit comments

Comments
 (0)