SLCAN specification mismatch/collision

[matthiasbock]

I believe, incorrect command-selecting bytes are being used in the SLCAN message parser in slcan.c:

    } else if (buf[0] == 'm' || buf[0] == 'M') {
        // set mode command
        if (buf[1] == 1) {
            // mode 1: silent
            can_set_silent(1);
        } else {
            // default to normal mode
            can_set_silent(0);
        }
        return 0;

    } else if (buf[0] == 'F') {
        // set filter command
        uint32_t id = 0;
        for (i = 1; i < len; i++) {
            id *= 16;
            id += buf[i];
        }
        current_filter_id = id;
        can_set_filter(current_filter_id, current_filter_mask);

    } else if (buf[0] == 'K') {
        // set mask command
        uint32_t mask = 0;
        for (i = 1; i < len; i++) {
            mask *= 16;
            mask += buf[i];
        }
        current_filter_mask = mask;
        can_set_filter(current_filter_id, current_filter_mask);

    }

'm' and 'M' are used to set the "mode" of the adapter, while 'F' and 'K' are used to set filter ID and mask. Instead, according to the LAWICEL CAN232 protocol, 'm' and 'M' should be used to set filter mask and ID.

See also: https://github.com/linux-can/can-utils/blob/master/slcanpty.c#L130

[Dark-Guan]

Oh,it is a sad news.What is the all about the slcan protocol?