QNX6 listens to all UDP ports?

QNX Newsgroups (Archives) qdn.public.qnxrtp.os
1

Something very strange happened in my office this afternoon. All the
machines using DHCP went insane. After a couple quick diagnostics, I
found that my QNX6 box was advertising that it listens on UDP port 67,
the DHCP port. In fact, a service scan of the QNX6 box showed that it
was listening to all UDP ports. Physically removing the QNX6 box from
the network restored sanity to the world.

I’m curious to know if this is a “feature” of QNX6 or of the box I’m
using (a flavor of a standard PC board).

I’ve checked all the configuration files I know about and don’t see
anything where I’m starting up DHCP services. In fact, from the behavior
of my network this afternoon, I suspect that QNX6 is not, in fact,
serving DHCP, but is advertising that it listens to the port. Thus, it
looks like the DHCP server for the subnet, but doesn’t act like one.

Is this likely to be my problem (e.g. configuration), QNX6’s problem
(e.g. design feature), or the box’s problem (e.g. a feature of the
ethernet interface)?

2

In article <993fpu$f59$1@inn.qnx.com>,
“Igor Kovalenko” <kovalenko@home.com> wrote:

This is confusing. For what I know (I can be wrong of course, especially
considering Windows):

Yes it was. Sorry for the confusion. Here is some more information that
may help clarify.

  1. There is no way to tell if some box is listenig to a port other than to
    try to establish a connection or send a packet.

I understand this. I have a network tool, AGNetTools, which does a “port
scan” at an IP number of my choosing. The tool reports back which TCP
and UDP ports at which that IP listening. This same tool will also do a
“service scan”, whereby you tell it an IP range and a port number and
the tool tells you which IP numbers are listenting to that TCP or UDP
port. I don’t know the magic by which it determines this information,
but there it is. Presumably, it tries to make a connection and reports
whether it succeeds.

  1. DHCP servers do not advertize anything, they just reply to incoming
    requests. DHCP clients send their requests either through broadcast or to
    specific pre-configured IP. If no server replies, DHCP client just times out
    and Windows complains.

…or MacOS assigns a default IP number, or something else specific to
the OS and TCP/IP stack.

Given that, your box can’t ‘look like’ anything to your subnet if it does
not actually serve clients’ requests. What do you mean by ‘went insane’? Did
Windows complain about no DHCP server or did it get bogus IP?

The raw data I have is that, overnight, all the DHCP machines in the
office failed to get new valid IP addresses, as if the DHCP server had
gone away or given bad addresses. The DHCP server was not misconfigured
and was working properly.

After a hard reset of the network, I did a service scan of the network
and found two machines which respoded to port 67/UDP (the DHCP server
address), the DHCP server and the QNX6 box. I then did a port scan on
the QNX6 box and the tool reported that all tested UDP ports were
“alive” (however the tool tests it).

After taking the QNX6 box off the network, the problem has not recurred
in 48 hours. I’ll admit that this is not iron clad evidence of a
problem, but I find it odd that the QNX6 box responded to all UDP ports.
No other box on the network did that.

Any further clues?

Thanks for your help,
Eric

3

Previously, Eric Berdahl wrote in qdn.public.qnxrtp.os:

After a hard reset of the network, I did a service scan of the network
and found two machines which respoded to port 67/UDP (the DHCP server
address), the DHCP server and the QNX6 box. I then did a port scan on
the QNX6 box and the tool reported that all tested UDP ports were
“alive” (however the tool tests it).

I’m not real sure about what was going on, but it doesn’t surprise
me that QNX6 was listening on all ports. I believe that this is
the job of inetd, to listen on all ports, and when it gets a message,
create the appropriate daemon. Or does it just listen on
ports mentioned in the /etc/services files?



Mitchell Schoenbrun --------- maschoen@pobox.com

4

This is confusing. For what I know (I can be wrong of course, especially
considering Windows):

  1. There is no way to tell if some box is listenig to a port other than to
    try to establish a connection or send a packet.

  2. DHCP servers do not advertize anything, they just reply to incoming
    requests. DHCP clients send their requests either through broadcast or to
    specific pre-configured IP. If no server replies, DHCP client just times out
    and Windows complains.

Given that, your box can’t ‘look like’ anything to your subnet if it does
not actually serve clients’ requests. What do you mean by ‘went insane’? Did
Windows complain about no DHCP server or did it get bogus IP?

  • igor

“Eric Berdahl” <berdahl@intelligentparadigm.com> wrote in message
news:berdahl-7A428C.00575918032001@nntp.qnx.com…

Something very strange happened in my office this afternoon. All the
machines using DHCP went insane. After a couple quick diagnostics, I
found that my QNX6 box was advertising that it listens on UDP port 67,
the DHCP port. In fact, a service scan of the QNX6 box showed that it
was listening to all UDP ports. Physically removing the QNX6 box from
the network restored sanity to the world.

I’m curious to know if this is a “feature” of QNX6 or of the box I’m
using (a flavor of a standard PC board).

I’ve checked all the configuration files I know about and don’t see
anything where I’m starting up DHCP services. In fact, from the behavior
of my network this afternoon, I suspect that QNX6 is not, in fact,
serving DHCP, but is advertising that it listens to the port. Thus, it
looks like the DHCP server for the subnet, but doesn’t act like one.

Is this likely to be my problem (e.g. configuration), QNX6’s problem
(e.g. design feature), or the box’s problem (e.g. a feature of the
ethernet interface)?

5

The small stack doesn’t send out an icmp port unreachable
message if that’s what you’re looking for. But it’s not
listening on all ports. Datagrams not associated to any
current port are discarded. If this is a problem for you,
you might consider moving to the full stack.

-seanb

Eric Berdahl <berdahl@intelligentparadigm.com> wrote:
: Something very strange happened in my office this afternoon. All the
: machines using DHCP went insane. After a couple quick diagnostics, I
: found that my QNX6 box was advertising that it listens on UDP port 67,
: the DHCP port. In fact, a service scan of the QNX6 box showed that it
: was listening to all UDP ports. Physically removing the QNX6 box from
: the network restored sanity to the world.

: I’m curious to know if this is a “feature” of QNX6 or of the box I’m
: using (a flavor of a standard PC board).

: I’ve checked all the configuration files I know about and don’t see
: anything where I’m starting up DHCP services. In fact, from the behavior
: of my network this afternoon, I suspect that QNX6 is not, in fact,
: serving DHCP, but is advertising that it listens to the port. Thus, it
: looks like the DHCP server for the subnet, but doesn’t act like one.

: Is this likely to be my problem (e.g. configuration), QNX6’s problem
: (e.g. design feature), or the box’s problem (e.g. a feature of the
: ethernet interface)?

6

In article <9955i4$e00$1@nntp.qnx.com>, Sean Boudreau <seanb@qnx.com>
wrote:

The small stack doesn’t send out an icmp port unreachable
message if that’s what you’re looking for. But it’s not
listening on all ports. Datagrams not associated to any
current port are discarded. If this is a problem for you,
you might consider moving to the full stack.

Bingo!! That solved the problem I was seeing. After even more network
debugging, the QNX6 box was merely exacerbating another problem that
existed on the net. Moving the to full TCP/IP stack fixed the UDP
behavior I was seeing on the QNX6 box.

Thanks,
Eric

7

Previously, Mitchell Schoenbrun wrote in qdn.public.qnxrtp.os:

Previously, Eric Berdahl wrote in qdn.public.qnxrtp.os:

After a hard reset of the network, I did a service scan of the network
and found two machines which respoded to port 67/UDP (the DHCP server
address), the DHCP server and the QNX6 box. I then did a port scan on
the QNX6 box and the tool reported that all tested UDP ports were
“alive” (however the tool tests it).

I’m not real sure about what was going on, but it doesn’t surprise
me that QNX6 was listening on all ports. I believe that this is
the job of inetd, to listen on all ports, and when it gets a message,
create the appropriate daemon. Or does it just listen on
ports mentioned in the /etc/services files?

It only listens on ports mentioned in /etc/inetd.conf, which is
usually a small subset of the ports mentioned in /etc/services.
“listen” in the programming sense of the word only applies to TCP, not
UDP, so I don’t know what the port scanning software was doing to
determine that UDP ports were open.

Cheers,
Andrew

8

In article <Voyager.010320153229.569373C@andrewhome.cogent.ca>,
Andrew Thomas <Andrew@cogent.ca> wrote:

It only listens on ports mentioned in /etc/inetd.conf, which is
usually a small subset of the ports mentioned in /etc/services.
“listen” in the programming sense of the word only applies to TCP, not
UDP, so I don’t know what the port scanning software was doing to
determine that UDP ports were open.

Me neither, but from the various responses posted here, I have some
idea. The QNX6 box as I described it was running the “tiny” TCP stack,
ttcpip. When I change it to run the full stack, tcpip, the port scanning
tool I was using stopped reporting the QNX6 box as listening on all UDP
ports.

From Sean’s answer in this thread, I understand that one of the
differences between the tiny stack and the full stack is that the tiny
stack does not send an ICMP “port not responding” packet for UDP ports
which are not “active” (whatever the appropriate term is for not
responding to a UDP port). Thus, I infer that the tool is doing UDP
“sensing” by sending a packet to a UDP port and waiting for an ICMP port
not responding packet in return. In the absence of such a packet, the
tool assumes that someone is listening on the UDP port.

Or I could be completely bonkers. Either way, upgrading to the full
stack solved my problem.

9

“Eric Berdahl” <berdahl@intelligentparadigm.com> wrote in message
news:berdahl-A25C77.13175820032001@nntp.qnx.com…

In article <> Voyager.010320153229.569373C@andrewhome.cogent.ca> >,


From Sean’s answer in this thread, I understand that one of the
differences between the tiny stack and the full stack is that the tiny
stack does not send an ICMP “port not responding” packet for UDP ports
which are not “active” (whatever the appropriate term is for not
responding to a UDP port).

Somewhat counter-intuitive, that the scanning software determines that the
port is active if it doesn’t receive a response from it :wink:

Rennie