Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.networking > #3058 > unrolled thread

Totally stuck --> UDP packets refused

Back to article view | Back to comp.os.linux.networking

Contents

  Totally stuck --> UDP packets refused Palmisano <xspalm1@hotmail.com> - 2014-08-28 23:18 +0200
    Re: Totally stuck --> UDP packets refused Jorgen Grahn <grahn+nntp@snipabacken.se> - 2014-08-28 22:41 +0000
      Re: Totally stuck --> UDP packets refused Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> - 2014-08-29 01:05 +0200
        Re: Totally stuck --> UDP packets refused Palmisano <xspalm1@hotmail.com> - 2014-08-29 21:20 +0200
          Re: Totally stuck --> UDP packets refused Jorgen Grahn <grahn+nntp@snipabacken.se> - 2014-08-30 05:14 +0000
            Re: Totally stuck --> UDP packets refused Palmisano <xspalm1@hotmail.com> - 2014-08-30 14:14 +0200
              Re: Totally stuck --> UDP packets refused Jorgen Grahn <grahn+nntp@snipabacken.se> - 2014-08-30 14:15 +0000
                Re: Totally stuck --> UDP packets refused Palmisano <xspalm1@hotmail.com> - 2014-08-31 14:52 +0200
          Re: Totally stuck --> UDP packets refused Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> - 2014-08-30 14:52 +0200
            Re: Totally stuck --> UDP packets refused Jorgen Grahn <grahn+nntp@snipabacken.se> - 2014-08-30 14:09 +0000

#3058 — Totally stuck --> UDP packets refused

Hello,

I did try to fix this myself, for some hours but no success. I am sure
it is a simple thing I am overlooking, but what...

I wrote a C program on my Fedora server, that does the following.
The prog on my server (name=zon IP=192.168.1.1) sends a command to a
device on the LAN (name=ics1000, IP=192.168.1.246) using UDP port 9760
(this is a command to switch on a lamp).
The UDP command works, because the lamp goes on.

The device returns an acknowledge message on UDP port 9761 (so a
different port). My program is trying to read that response on the
9761 port, but the ack message never reaches the program because the
server seems to block the port (the select() times out).


Here is a tcpdump of the em1 ifc when I send the command:

# tcpdump host 192.168.1.246
23:01:02.112832 IP zon.57758 > ics1000.9760: UDP, length 11
23:01:02.221171 IP ics1000.9760 > zon.9761: UDP, length 8
23:01:02.221196 IP zon > ics1000: ICMP zon udp port 9761 unreachable, 

aha, unreachable...

So my thought was: FIREWALL.  So I added 9761 UDP to iptables (and
restarted iptables):
---------------
# iptables -L

Chain INPUT (policy ACCEPT)
target  prot opt source               destination
ACCEPT  udp  --  anywhere  anywhere   udp dpt:9761
ACCEPT  all  --  anywhere  anywhere   state RELATED,ESTABLISHED
ACCEPT  icmp --  anywhere  anywhere
ACCEPT  all  --  anywhere  anywhere
ACCEPT  tcp  --  anywhere  anywhere   state NEW tcp dpt:ftp
ACCEPT  udp  --  anywhere  anywhere   state NEW udp dpt:netbios-ns
...
...
ACCEPT  udp  --  anywhere  anywhere   state NEW udp dpts:dpap:8775
ACCEPT  udp  --  anywhere  anywhere   state NEW udp dpt:9761
ACCEPT  udp  --  anywhere  anywhere   state NEW udp dpt:dsm-scm-target
REJECT  all  --  anywhere  anywhere   reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
REJECT     all  --  anywhere             anywhere
reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination





I even switched iptables off:
# systemctl stop iptables.service


Makes NO difference. I am totally lost now. Any hints?

Thx, Palmi

[toc] | [next] | [standalone]

#3059

On Thu, 2014-08-28, Palmisano wrote:
> Hello,
>
> I did try to fix this myself, for some hours but no success. I am sure
> it is a simple thing I am overlooking, but what...
>
> I wrote a C program on my Fedora server, that does the following.
> The prog on my server (name=zon IP=192.168.1.1) sends a command to a

I.e. your server is the client.

> device on the LAN (name=ics1000, IP=192.168.1.246) using UDP port 9760
> (this is a command to switch on a lamp).
> The UDP command works, because the lamp goes on.
>
> The device returns an acknowledge message on UDP port 9761 (so a
> different port).

It is more usual for an UDP server to send the response to the host
and port where the request came from.  Uses up less fixed port
numbers, is nicer to firewalls, and easier to debug (you can use
netcat -u to talk to the server).

> My program is trying to read that response on the
> 9761 port, but the ack message never reaches the program because the
> server seems to block the port (the select() times out).
>
>
> Here is a tcpdump of the em1 ifc when I send the command:
>
> # tcpdump host 192.168.1.246
> 23:01:02.112832 IP zon.57758 > ics1000.9760: UDP, length 11
> 23:01:02.221171 IP ics1000.9760 > zon.9761: UDP, length 8
> 23:01:02.221196 IP zon > ics1000: ICMP zon udp port 9761 unreachable, 
>
> aha, unreachable...
>
> So my thought was: FIREWALL.  So I added 9761 UDP to iptables

The more likely explanation is that noone is listening on zon.9761
(or *.9761). Check with netstat -uapn.  You can also run your client
program under strace to see if it sets up the socket properly.

...

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#3060

Jorgen Grahn a écrit :
>>
>> # tcpdump host 192.168.1.246
>> 23:01:02.112832 IP zon.57758 > ics1000.9760: UDP, length 11
>> 23:01:02.221171 IP ics1000.9760 > zon.9761: UDP, length 8
>> 23:01:02.221196 IP zon > ics1000: ICMP zon udp port 9761 unreachable, 
>>
>> aha, unreachable...
>>
>> So my thought was: FIREWALL.  So I added 9761 UDP to iptables
> 
> The more likely explanation is that noone is listening on zon.9761
> (or *.9761).

I agree. "Port unreachable" is the ICMP type/code generated by the UDP
stack when nothing listens on the destination port. The REJECT rule at
the end of the INPUT chain in the iptables ruleset would have generated
a "host prohibited" ICMP type/code.

[toc] | [prev] | [next] | [standalone]

#3061

On Fri, 29 Aug 2014 01:05:23 +0200, Pascal Hambourg
<boite-a-spam@plouf.fr.eu.org> wrote:

>Jorgen Grahn a écrit :
>>>
>>> # tcpdump host 192.168.1.246
>>> 23:01:02.112832 IP zon.57758 > ics1000.9760: UDP, length 11
>>> 23:01:02.221171 IP ics1000.9760 > zon.9761: UDP, length 8
>>> 23:01:02.221196 IP zon > ics1000: ICMP zon udp port 9761 unreachable, 
>>>
>>> aha, unreachable...
>>>
>>> So my thought was: FIREWALL.  So I added 9761 UDP to iptables
>> 
>> The more likely explanation is that noone is listening on zon.9761
>> (or *.9761).
>
>I agree. "Port unreachable" is the ICMP type/code generated by the UDP
>stack when nothing listens on the destination port. The REJECT rule at
>the end of the INPUT chain in the iptables ruleset would have generated
>a "host prohibited" ICMP type/code.
Great advice guys. I am blushing with shame.
The bind() failed and due to a typo that I overlooked <n> times, the
exit value test didn't notic ethe failure.

Fixed now.

BTW: I agree that replying on another port is weird. But I didn't
build the device that accepts the commands :-).

Your help is appreciated!

[toc] | [prev] | [next] | [standalone]

#3062

On Fri, 2014-08-29, Palmisano wrote:
> On Fri, 29 Aug 2014 01:05:23 +0200, Pascal Hambourg
> <boite-a-spam@plouf.fr.eu.org> wrote:
>
>>Jorgen Grahn a écrit :
>>>>
>>>> # tcpdump host 192.168.1.246
>>>> 23:01:02.112832 IP zon.57758 > ics1000.9760: UDP, length 11
>>>> 23:01:02.221171 IP ics1000.9760 > zon.9761: UDP, length 8
>>>> 23:01:02.221196 IP zon > ics1000: ICMP zon udp port 9761 unreachable, 
>>>>
>>>> aha, unreachable...
>>>>
>>>> So my thought was: FIREWALL.  So I added 9761 UDP to iptables
>>> 
>>> The more likely explanation is that noone is listening on zon.9761
>>> (or *.9761).
>>
>>I agree. "Port unreachable" is the ICMP type/code generated by the UDP
>>stack when nothing listens on the destination port. The REJECT rule at
>>the end of the INPUT chain in the iptables ruleset would have generated
>>a "host prohibited" ICMP type/code.

> Great advice guys. I am blushing with shame.
> The bind() failed and due to a typo that I overlooked <n> times, the
> exit value test didn't notic ethe failure.

That's the beauty of strace: no matter how badly your code handles
errors from system calls, strace will reveal them.

> BTW: I agree that replying on another port is weird. But I didn't
> build the device that accepts the commands :-).

Oh.  Well, one thing I've learned is that a lot of protocols are
designed by people who don't quite understand what they're doing.
So if the protocol seems weird to me, it may not be my fault ...

> Your help is appreciated!

Happy to help!  Done this kind of debugging many times myself ...

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#3063

On 30 Aug 2014 05:14:37 GMT, Jorgen Grahn <grahn+nntp@snipabacken.se>
wrote:

>On Fri, 2014-08-29, Palmisano wrote:
>> On Fri, 29 Aug 2014 01:05:23 +0200, Pascal Hambourg
>> <boite-a-spam@plouf.fr.eu.org> wrote:
>>
>>>Jorgen Grahn a écrit :
>>>>>
>>>>> # tcpdump host 192.168.1.246
>>>>> 23:01:02.112832 IP zon.57758 > ics1000.9760: UDP, length 11
>>>>> 23:01:02.221171 IP ics1000.9760 > zon.9761: UDP, length 8
>>>>> 23:01:02.221196 IP zon > ics1000: ICMP zon udp port 9761 unreachable, 
>>>>>
>>>>> aha, unreachable...
>>>>>
>>>>> So my thought was: FIREWALL.  So I added 9761 UDP to iptables
>>>> 
>>>> The more likely explanation is that noone is listening on zon.9761
>>>> (or *.9761).
>>>
>>>I agree. "Port unreachable" is the ICMP type/code generated by the UDP
>>>stack when nothing listens on the destination port. The REJECT rule at
>>>the end of the INPUT chain in the iptables ruleset would have generated
>>>a "host prohibited" ICMP type/code.
>
>> Great advice guys. I am blushing with shame.
>> The bind() failed and due to a typo that I overlooked <n> times, the
>> exit value test didn't notic ethe failure.
>
>That's the beauty of strace: no matter how badly your code handles
>errors from system calls, strace will reveal them.
Ouch, that hurt...  I am always *very* precise with defensive
programming and error handling. This time a quick & dirty experiment
showed that quick is indeed often dirty.
>
>> BTW: I agree that replying on another port is weird. But I didn't
>> build the device that accepts the commands :-).
>
>Oh.  Well, one thing I've learned is that a lot of protocols are
>designed by people who don't quite understand what they're doing.
>So if the protocol seems weird to me, it may not be my fault ...
Hmm, the whole device interface is 'suboptimal'. It works, but it was
never well thought over before it was created.
>
>> Your help is appreciated!
>
>Happy to help!  Done this kind of debugging many times myself ...
>
>/Jorgen

[toc] | [prev] | [next] | [standalone]

#3066

On Sat, 2014-08-30, Palmisano wrote:
> On 30 Aug 2014 05:14:37 GMT, Jorgen Grahn <grahn+nntp@snipabacken.se>
> wrote:
>
>>On Fri, 2014-08-29, Palmisano wrote:
...
>>> Great advice guys. I am blushing with shame.
>>> The bind() failed and due to a typo that I overlooked <n> times, the
>>> exit value test didn't notic ethe failure.
>>
>>That's the beauty of strace: no matter how badly your code handles
>>errors from system calls, strace will reveal them.

> Ouch, that hurt...  I am always *very* precise with defensive
> programming and error handling. This time a quick & dirty experiment
> showed that quick is indeed often dirty.

The hurting was unintentional.  I just meant that it doesn't matter to
strace how well you handle errors.  I'm often sloppy with error
handling when I'm prototyping new socket code, because I know I can
rely on strace.  Then I fix it up, of course, and pay attention to
what the man pages say about errors.

I should also mention ltrace, which does the same thing but on the
libc interface level.  If you use e.g. getaddrinfo(3) (and you should
use it!) that maps to a whole bunch of system calls that you're not
really interested in.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#3072

On 30 Aug 2014 14:15:58 GMT, Jorgen Grahn <grahn+nntp@snipabacken.se>
wrote:

>On Sat, 2014-08-30, Palmisano wrote:
>> On 30 Aug 2014 05:14:37 GMT, Jorgen Grahn <grahn+nntp@snipabacken.se>
>> wrote:
>>
>>>On Fri, 2014-08-29, Palmisano wrote:
>...
>>>> Great advice guys. I am blushing with shame.
>>>> The bind() failed and due to a typo that I overlooked <n> times, the
>>>> exit value test didn't notic ethe failure.
>>>
>>>That's the beauty of strace: no matter how badly your code handles
>>>errors from system calls, strace will reveal them.
>
>> Ouch, that hurt...  I am always *very* precise with defensive
>> programming and error handling. This time a quick & dirty experiment
>> showed that quick is indeed often dirty.
>
>The hurting was unintentional.  I just meant that it doesn't matter to
>strace how well you handle errors.  I'm often sloppy with error
>handling when I'm prototyping new socket code, because I know I can
>rely on strace.  Then I fix it up, of course, and pay attention to
>what the man pages say about errors.
>
>I should also mention ltrace, which does the same thing but on the
>libc interface level.  If you use e.g. getaddrinfo(3) (and you should
>use it!) that maps to a whole bunch of system calls that you're not
>really interested in.
>
>/Jorgen


The hurting was a joke :-). The strace is a good tip!  Thx again!

[toc] | [prev] | [next] | [standalone]

#3064

Palmisano a écrit :
> On Fri, 29 Aug 2014 01:05:23 +0200, Pascal Hambourg wrote:
> 
>> Jorgen Grahn a écrit :
>>>> # tcpdump host 192.168.1.246
>>>> 23:01:02.112832 IP zon.57758 > ics1000.9760: UDP, length 11
>>>> 23:01:02.221171 IP ics1000.9760 > zon.9761: UDP, length 8
>>>> 23:01:02.221196 IP zon > ics1000: ICMP zon udp port 9761 unreachable, 
>>>>
>>>> aha, unreachable...
>>>>
>>>> So my thought was: FIREWALL.  So I added 9761 UDP to iptables
>>> The more likely explanation is that noone is listening on zon.9761
>>> (or *.9761).
>> I agree. "Port unreachable" is the ICMP type/code generated by the UDP
>> stack when nothing listens on the destination port. The REJECT rule at
>> the end of the INPUT chain in the iptables ruleset would have generated
>> a "host prohibited" ICMP type/code.
> Great advice guys. I am blushing with shame.
> The bind() failed and due to a typo that I overlooked <n> times, the
> exit value test didn't notic ethe failure.
> 
> Fixed now.
> 
> BTW: I agree that replying on another port is weird. But I didn't
> build the device that accepts the commands :-).

It may make things a bit easier to use 9761 as the source port for the
outgoing packet instead of an ephemeral port. I see two advantages :
- it requires only one single UDP socket for sending and receiving ;
- a stateful iptables ruleset can handle the reply packet automatically
(as ESTABLISHED) without requiring an explicit rule in the INPUT chain.

[toc] | [prev] | [next] | [standalone]

#3065

On Sat, 2014-08-30, Pascal Hambourg wrote:
...
>> BTW: I agree that replying on another port is weird. But I didn't
>> build the device that accepts the commands :-).
>
> It may make things a bit easier to use 9761 as the source port for the
> outgoing packet instead of an ephemeral port. I see two advantages :
> - it requires only one single UDP socket for sending and receiving ;
> - a stateful iptables ruleset can handle the reply packet automatically
> (as ESTABLISHED) without requiring an explicit rule in the INPUT chain.

A third one: it's easier to see that someone else is using the port,
so the client can't do its job properly.  With two sockets, you'd have
to claim 9761 first and then create the sending one.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.networking

csiph-web