Re: State of new Kernel AX.25 for 2.4

From: Jens David (terhi.victor@logonet.com)
Date: Tue Dec 19 2000 - 02:18:14 EET

  • Next message: Richard Adams: "KPC9612"

    Hi,

    On Sunday 17 December 2000 01:47, you wrote:
    > > I'm already working on the transition, I've some problems with
    > > the drivers though -- I hope to get it resolved over the
    > > holidays. The situation is quite a mess for some drivers have
    > > evolved independendly (the sound modem stuff for example), the
    > > KISS driver crashes on ifconfig down / ifconfig up (huh?!),

    The soundmodem stuff was optimized for good performance at low Eb/N0
    with 9600 bps FSK operation and RX/TX filter impulse has been made
    loadable via ioctl() and smfilter. it is not *that* different.
    As pointed out a thousand times before the most important differences
    exist at the now synchronous driver interface and the cleaned up
    state machine, not the fancy proc interface or the VJ compression
    for TCP/IP.
    A sophisticated LAPB implementtation, channel arbitration and driver
    interface is of very high importance when you want to Linux as node
    in a serious way. (See also TNN/XNET against FlexNet competition).

    > Noticed that (or rather that the kiss driver is unstable). That was really
    > the reason I switched back to the old stuff when I was testing the new
    > some time last spring. I need kiss to be able to run Tom's usermode
    > soundmodem stuff (porting newqpsk to it).

    You should have reported it right away. Now it's too late since I
    don`t have much spare time (final year) and moreover I had to find
    out that my parents threw away most of my hamradio equipment as
    I was away in GB.
    I will make a patch against 2.2.18 as soon as possible, but do not
    expect me to do much beyond that. I simply do not have the
    resources to spend on it any more. Joerg is working on the 2.4 port,
    and since he also spent much time into looking at the code he`s probably
    the best candidate to continue maintenance.

    > Some of the most used drivers (mkiss and 6pack IIRC at least) don't set
    > the broadcast address. That results in ARP requests not being received nor
    > answered.

    Yes. It should definetely be set in the ax25 core when a new interface
    is registered. Broadcast is always QST and it does not make sense
    to have different broadcast addresses depending on the hardware type
    used, so the driver is not the right place to do it.

    > The other one was also related to ARP. Outgoing ARP requests won't go out
    > if there is no route for the "QST" destination address.

    Huh? That shouldn't be. In fact I worked in that code area quite a long time when
    chasing a race condition that occurred at db0dar. When a frame is to be
    broadcasted it got cloned and queued to the TX queues of *all* interfaces. That
    skb_clone was not too good sind obviously some drivers manipulate the data
    inside the content of the buffer (e.g. the KISS driver adds a `0` in front of it to mark).
    I changed it to copy the skb instead so this should not be a problem any more.

    > I thought about this somewhat and I
    > wonder if it were reasonable to broadcast ARP requests on all (configured
    > somehow of course) ports and have the answer learned and remembered by
    > the kernel (or an ax25/arp daemon or whatever).

    No, it should stay the way it is, broadcast is broadcast and should be transmitted
    on either all interfaces or at least on all user access ports of a node (maybe use
    the BROADCAST interface flag for this. I am not sure whether we already do so.),
    because there is no way of knowing in advance where the host in question is located.

    > IP over NETROM doesn't work. This is a result of the patch short
    > circuiting an important part in net/ipv4/arp.c (see Alexeys "nice" comment
    > about amateur devices ). If someone can educate me how to fix NETROM so
    > that it works without the stuff Alexey thinks is so evil I'm more than
    > grateful. In the mean while the patch shouldn't touch the arp vs. netrom
    > stuff.

    IP over netrom should go via ipax0 as well, and ax25_ipax.c should make
    decisions what to do with it and whether to encap it into AX25 frames directly
    or call the apropriate functions in the netrom core instead.
    I must admit that I did not pay much attention to the Netrom and Rose stuff since
    both is IMHO quite obsolete and not present in Germany (=> no test base).
    I think Jean-Paul had a look at it and he sent me some patches. I blindly
    applied most of them.

    > If you can fix the KISS issues I'll be more than happy to hop in the NEW
    > AX.25 wagon again.

    I will take at the ifconfig up/down thing. Otherwise the driver should be
    OK, we use it at two different nodes in DA and both machines usually yield
    uptimes >2 months. Whilst heavily loaded they are mostly left alone though.

      -- Jens
    -
    To unsubscribe from this list: send the line "unsubscribe linux-hams" in
    the body of a message to svnwub@kerailya.tunkki.fi



    This archive was generated by hypermail 2b30 : Tue Dec 19 2000 - 01:18:05 EET