netdev
[Top] [All Lists]

missing icmp errors for udp packets

To: netdev@xxxxxxxxxxx
Subject: missing icmp errors for udp packets
From: clemens <therapy@xxxxxxxxxxxxx>
Date: Wed, 25 Jul 2001 22:00:29 +0200
Sender: owner-netdev@xxxxxxxxxxx
User-agent: Mutt/1.3.18i
hi folks!

assertation:

2.4.7 omits icmp port unreachable errors for unbound udp ports on non-local
interfaces. sounds strange? here are my observations:

linux host guardian 
linux host ghanima

[session 1]
ghanima:~# tcpdump -i eth0 host guardian and port not ssh
tcpdump: listening on eth0
..

[session 2]
guardian:/home/guardian/therapy# nmap -sU -p 1-10 ghanima.endorphin.org
(nmap is asked to udp scan ghanima port 1-10)

Starting nmap V. 2.54BETA22 ( www.insecure.org/nmap/ )
Interesting ports on  (62.116.8.197):
Port       State       Service
1/udp      open        tcpmux                  
2/udp      open        compressnet             
3/udp      open        compressnet             
4/udp      open        unknown                 
5/udp      open        rje                     
6/udp      open        unknown                 
7/udp      open        echo                    
8/udp      open        unknown                 
9/udp      open        discard                 
10/udp     open        unknown                 

all ports opened? can't be!
let's look at the tcpdump trace on ghanima for it's eth0 output:

[session 1]
21:35:57.781649 guardian > ghanima.endorphin.org: icmp: echo request
21:35:57.781683 ghanima.endorphin.org > guardian: icmp: echo reply
21:35:58.096727 guardian.51277 > ghanima.endorphin.org.echo:  udp 0
21:35:58.096871 guardian.51277 > ghanima.endorphin.org.8:  udp 0
21:35:58.097673 guardian.51277 > ghanima.endorphin.org.discard:  udp 0
21:35:58.098479 guardian.51277 > ghanima.endorphin.org.1:  udp 0
21:35:58.099285 guardian.51277 > ghanima.endorphin.org.2:  udp 0
21:35:58.100029 guardian.51277 > ghanima.endorphin.org.3:  udp 0
21:35:58.100721 guardian.51277 > ghanima.endorphin.org.6:  udp 0
..and so on.

really there are no icmp destination, port unreachable errors sent.
so nmap assumes all ports are opened.
some output filters in iptables, you might think?

ghanima:~# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

definatly not.

let's try something else:

[session 1]
ghanima:~# tcpdump -i lo                                 
tcpdump: listening on lo

[session 2]
ghanima:~# nmap -sU -p 1-10 localhost

Starting nmap V. 2.54BETA22 ( www.insecure.org/nmap/ )
All 10 scanned ports on localhost (127.0.0.1) are: closed

Nmap run completed -- 1 IP address (1 host up) scanned in 1 second
ghanima:~$ 

[session 1]
21:43:05.255608 localhost > localhost: icmp: echo request
21:43:05.255648 localhost > localhost: icmp: echo reply
21:43:05.256945 localhost.41478 > localhost.www: . ack 4120283222 win 4096
21:43:05.256978 localhost.www > localhost.41478: R 4120283222:4120283222(0)
win 0 (DF)
21:43:05.558663 localhost.41458 > localhost.10:  udp 0
21:43:05.558719 localhost > localhost: icmp: localhost udp port 10
unreachable [tos 0xc0] 
21:43:05.559668 localhost.41458 > localhost.echo:  udp 0
21:43:05.559688 localhost > localhost: icmp: localhost udp port echo
unreachable [tos 0xc0] 
21:43:05.560165 localhost.41458 > localhost.discard:  udp 0
21:43:05.560183 localhost > localhost: icmp: localhost udp port discard
unreachable [tos 0xc0] 
.. and so on.

huch, now we have icmp errors replied for the udp probe packets.

this problem has been confirmed for at least for 2.4.7-pre8 in a totally
different network setup.

my debugging attempts so far:

for both scans, local and non local, the udp "No Port" counter is increased.
(/proc/net/snmp)
which means for both scans an icmp packet is tried to be transmitted as far
as concerning net/ipv4/udp.c

[from udp.c - line 917]

        UDP_INC_STATS_BH(UdpNoPorts);
        icmp_send(skb, ICMP_DEST_UNREACH, ICMP_PORT_UNREACH, 0);

i tried to use kdb to trace the icmp_send, but got stuck somewhere after
ip_output in dev_queue_xmit. so obviously 2.4.7 really tries to send
something out to eth0, but fails somewhere in low-level routines.

since i'm not that good at kernel debugging, i'm handing this issue over.

clemens

p.s.: i'm using 8139too for eth0, but that really shouldn't matter.

<Prev in Thread] Current Thread [Next in Thread>