OK, just rebuilt my kernel:
x230$ grep MC7700 umsm.c
{{ USB_VENDOR_SIERRA, USB_PRODUCT_SIERRA_MC7700}, 0},
x230$ diff if_umb.c if_umb.c.~1.31.~
276,277c276
< /* return UMATCH_IFACECLASS_IFACESUBCLASS_IFACEPROTO; */
< return UMATCH_VENDOR_IFACESUBCLASS_IFACEPROTO;
---
> return UMATCH_IFACECLASS_IFACESUBCLASS_IFACEPROTO;
x230$ ifconfig umb0
umb0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500
index 5 priority 6 llprio 3
roaming disabled registration unknown
state open cell-class none
SIM not initialized PIN required
device MC7700 ID xxxxxxxxxxxxxxx firmware SWI9200X_03.05.19.00Aap
status: down
x230$
My source is not quite at a point to allow me to check the actual
operation of the thing, but it looks good so far...
Lee.
On Wed, Feb 05, 2020 at 07:24:00PM -0700, Theo de Raadt wrote:
> I've told Lee to test something for me.
>
> I think the priority from match functions are being confused via
> these (stupid) UMATCH_* variables, which are some weird disguise for
> what is supposed to be a priority code.
>
> In his upgraded case, ubm should win. it returns
> UMATCH_IFACECLASS_IFACESUBCLASS_IFACEPROTO which is 5.
>
> umsm does fewer tests, and returns UMATCH_VENDOR_IFACESUBCLASS which
> is 6.
>
> So with my change umsm wins.
>
> I asked Lee to first test if_umb.c returning a higher value such as
> UMATCH_VENDOR_IFACESUBCLASS_IFACEPROTO which is 7
>
> On my backwards device, if_umb does not match at all, so umsm would
> win.
>
> If I am right, that would satisfy both old and new devices; I think
> umb_patch is already doing the correct "tests", but simply returning
> the wrong value.
>
> And if that helps, then I think all this should be reconsidered.
>
> I *think* the idea behind this UMATCH_* variable naming is that the
> match return value says "how many fields did I look at and how confident
> am I", and that's what the naming comes from, but what I don't
> understand is --- who cares how many fields you looked at, as far as
> the subr_conf.c code is concerned this is ONLY a priority code not some
> "what did I do" to decide thing. And the priority value is going to
> something more magical, it's not some direct mapping between "how much did
> you look at".
>
> However are a mess of relationships here with the many device need
> "first kick me off umass", so we need to be somewhat careful to pick
> at this problem from the correct end.
>
>
