linux/net/ax25/ax25_ip.c: ax25_encapsulate - wrong protocol type ..

From: Thomas Osterried (wtngt.qfxv@tvr.ro)
Date: Fri Sep 21 2001 - 13:36:18 EEST

  • Next message: Peter: "AXIP"

    hello,

    while experimenting with bpqether, i wondered where the kernel messages
    "kernel: AX.25: ax25_encapsulate - wrong protocol type 0x22.2" came
    from.

    nb, there's a format-typo in printk(). i'd suggest
      printk(KERN_ERR "AX.25: ax25_encapsulate - wrong protoco l type 0x%02x\n", type);

    let's look how mkiss and 6pack (drivers/net/hamradio/) work, and why
    -in my opinion- bpqether, scc, yam, .. have problems:

    while in mkiss
            dev->hard_header = ax_header;
    is a wapper in the form

    | /* Return the frame type ID */
    | static int ax_header(struct sk_buff *skb, struct net_device *dev, unsigned short
    | type,
    | void *daddr, void *saddr, unsigned len)
    | {
    | #ifdef CONFIG_INET
    | if (type != htons(ETH_P_AX25))
    | return ax25_encapsulate(skb, dev, type, daddr, saddr, len);
    | #endif
    | return 0;
    | }

    in bpqether.c, .. ax25_encapsulate() is assigned directly:
            dev->hard_header = ax25_encapsulate;

    thus, when you have attached a software with it's own ax25 stack to sp0
    (6pack device), everything is fine. but with bpq0 there are problems,
    because the received data is sent directly to ax25_encapsulate(),
    without honouring the set protocol type ETH_P_AX25, which indicates that
    the packet has already a functional ax25 header (including kiss), that
    must not got through the encapsulator (thought for raw IP) anymore.

    that's at least the point how i understood the problem.

    before the other drivers will be fixed, i'd suggest to add this check
    from mkiss.c to ax25_ip.c:

    | int ax25_encapsulate(struct sk_buff *skb, struct device *dev, unsigned short type, void *daddr, void *saddr, unsigned len)
    | {
    |
    | unsigned char *buff;
    |
    | if (type == ETH_P_AX25) {
    | // has already header
    | return AX25_HEADER_LEN;
    | }
    |
    | /* header is an AX.25 UI frame from us to them */
    | buff = skb_push(skb, AX25_HEADER_LEN);

    it may be discussed, if we should return 0 (as in mkiss.c) or
    AX25_HEADER_LEN (as it's used in ax25_encapsulate()) because we can
    expect a full ax25 header (including leading kiss byte) - can we?
    or perhaps (untested):
      return ((daddr != NULL) ? AX25_HEADER_LEN : 0);

    73,
            - thomas <dl9sau>
    -
    To unsubscribe from this list: send the line "unsubscribe linux-hams" in
    the body of a message to mlfljnbp@irit.fr
    More majordomo info at http://vger.kernel.org/majordomo-info.html



    This archive was generated by hypermail 2b30 : Fri Sep 21 2001 - 13:45:52 EEST