Re: Netrom & linuxnode qstn..

From: Cees Tool (yqa.stmjbpkhlq@mx.dy.fi)
Date: Sat Sep 29 2001 - 13:11:41 EEST

  • Next message: pa3gcu: "Re: Netrom & linuxnode qstn.."

    Hi Richard/Tomi & others,

    Richard wrote :

    > axip: fm W5DAV-7 to PA3GCU-9 ctl SABM+
    > axip: fm PA3GCU-9 to W5DAV-7 ctl UA-
    > axip: fm W5DAV-7 to PA3GCU-9 ctl I00^ pid=CF(NET/ROM) len 238
    > NET/ROM: YO4GAB-2->PA3GCU-9 ttl 66
    > protocol family 43, proto 55
    > axip: fm PA3GCU-9 to W5DAV-7 ctl RR1v
    >
    > Now YO4GAB-2 shows up in my nodelist with an asterisk and a quality of "0"
    > Those are the packets i object to, these packets come from other partners
    as
    > well, not only w5dav, they can create quite a lot of traffic in some cases
    > much traffic, takeing into consideration that my node partner has not sent
    me
    > a broadcast for hours and sometimes a complete day, thats when these
    packets
    > start arriving.
    > In those packets are hidden nodes, note listen -a does not show the data
    > content, the LEN is 238, i once used chl-net to get a partial ascii dump
    of
    > such a packet, its full of control chars and node callsigns.
    > Thats why i dont like them, they have a content one cannot "easily see"
    which
    > makes me susspious and weary of such packets.
    >
    > If you want more info i am sure others can verifiy what i have added in
    this
    > mail.
    >

    Yes I can verify this. And it is not only happening with AXIP internet
    links, but I see rubbish like this also on our radio links.

    Do you know what software is used by YO4GAB-2 ??

    Here, we have seen some strange-frames passing our nodes and also
    connect-requests to our nodes. After debugging, those frames seem to be
    defective netrom nodes-broadcast frames. We have seen them originating from
    TNOS nodes. (but maybe other sofware is also involved) Such a
    broken-node-broadcast frame have a "sender" of the originating node. The
    netrom content of frame itself is sent to the node which would be the first
    node in the nodes-broadcast-frame and his alias is in place of the normal
    TTL, ID-bytes and opcode. When you look at the frames, the alias can still
    be recognized, however it changes every hop, because one byte is in place of
    the TTL.

    If your node is "lucky" to be the top-node in a frame of nodes-broadcast,
    then you will receive also connects of very exotic (non existing calls) on
    your netrom-appication if the bytes of the 'alias' represent a
    'connect-request'. Otherwise you may receive invalid netrom frames. I don't
    know why this is happening yet, but I hope it has the attention of writers
    of the software from where these frames seem to originate.

    The full description of what we have observed some months ago is on my
    homepage :
    http://www.qsl.net/pa3aes/pub/broken-netrom.txt

    73,
    Cees - PA3AES

    -
    To unsubscribe from this list: send the line "unsubscribe linux-hams" in
    the body of a message to xcox.oplnnhdwf@wincoll.ac.uk
    More majordomo info at http://vger.kernel.org/majordomo-info.html



    This archive was generated by hypermail 2b30 : Sat Sep 29 2001 - 13:20:35 EEST