• Totally stuck --> UDP packets refused

    From Palmisano@1:0/0 to All on Thu Aug 28 21:18:37 2014
    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

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From Jorgen Grahn@1:0/0 to All on Thu Aug 28 22:41:10 2014
    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 .

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From Pascal Hambourg@110:110/2002 to All on Thu Aug 28 23:05:23 2014
    Reply-To: pascal.news@plouf.fr.eu.org

    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.

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: Plouf ! (110:110/2002@linuxnet)
  • From Palmisano@1:0/0 to All on Fri Aug 29 19:20:41 2014
    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!

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From Jorgen Grahn@1:0/0 to All on Sat Aug 30 05:14:37 2014
    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 .

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From Palmisano@1:0/0 to All on Sat Aug 30 12:14:42 2014
    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


    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From Pascal Hambourg@110:110/2002 to All on Sat Aug 30 12:52:17 2014
    Reply-To: pascal.news@plouf.fr.eu.org

    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.

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: Plouf ! (110:110/2002@linuxnet)
  • From Jorgen Grahn@1:0/0 to All on Sat Aug 30 14:09:23 2014
    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 .

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From Jorgen Grahn@1:0/0 to All on Sat Aug 30 14:15:58 2014
    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 .

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From Palmisano@1:0/0 to All on Sun Aug 31 12:52:55 2014
    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!

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb