Re: [PATCH] umb(4) fixes for ifconfig
On Thu, Nov 10, 2016 at 02:12:55PM +0100, Gerhard Roth wrote:
> On Thu, 10 Nov 2016 13:56:00 +0100 Otto Moerbeek wrote:
> > On Wed, Nov 09, 2016 at 08:51:04AM -0800, Bryan Vyhmeister wrote:
> >
> > > This patch accomplishes two things for umb(4) connections. One, some SIM
> > > cards have a plus at the beginning of the phone number while others do
> > > not. In my case, an AT&T Wireless SIM card in the US has the plus where
> > > a T-Mobile SIM card in Germany does not. The output of ifconfig(8)
> > > originally added a plus regardless which caused two plus signs to appear
> > > for me as below. With this patch, ifconfig(8) now adds the plus if it
> > > is not there and does not add the plus if it is already programmed into
> > > the SIM card.
> > >
> > > umb0: flags=8951 mtu
> > > 1430
> > > index 5 priority 0 llprio 3
> > > roaming disabled registration home network
> > > state #7 cell-class LTE rssi -79dBm speed 47.7Mps up 286Mps down
> > > SIM initialized PIN valid (3 attempts left)
> > > subscriber-id 31041088 ICC-id 8901410427 provider AT&T
> > > device EM7455 IMEI 014582000 firmware SWI9X30C_02.08.
> > > phone# ++1213555123 APN broadband
> > > dns 172.26.38.1
> > > groups: egress
> > > status: active
> > > inet 10.45.181.18 --> 10.45.181.17 netmask 0xfffc
> > >
> > >
> > > The second part of the patch also fixes the last digit of the phone
> > > number and mulitple digits of the subscriber-id, ICC-id, and IMEI being
> > > cut off. Both fixes were discussed with Gerhard Roth. I sent him an
> > > original patch but it only partially solved the issues and after
> > > discussion with him, he came up with the patch below which solves and
> > > fully accounts for the issues and possible scenarios. With this patch
> > > the output looks like this.
> > >
> > > umb0: flags=8851 mtu 1430
> > > index 5 priority 0 llprio 3
> > > roaming disabled registration home network
> > > state #7 cell-class LTE rssi -103dBm speed 47.7Mps up 286Mps down
> > > SIM initialized PIN valid (3 attempts left)
> > > subscriber-id 310410812345678 ICC-id 89014104278812345678 provider AT&T
> > > device EM7455 IMEI 014582012345678 firmware SWI9X30C_02.08.02.00
> > > phone# +12135551234 APN broadband
> > > dns 172.26.38.1
> > > status: active
> > > inet 10.84.107.51 --> 10.84.107.52 netmask 0xfff8
> > >
> > >
> > > Bryan
> > >
> > >
> > > Index: sbin/ifconfig/ifconfig.c
> > > ===
> > > RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
> > > retrieving revision 1.332
> > > diff -u -p -r1.332 ifconfig.c
> > > --- sbin/ifconfig/ifconfig.c 8 Nov 2016 14:37:20 - 1.332
> > > +++ sbin/ifconfig/ifconfig.c 9 Nov 2016 16:34:26 -
> > > @@ -5153,7 +5153,7 @@ umb_status(void)
> > > printf("\t");
> > > n = 0;
> > > if (pn[0])
> > > - printf("%sphone# +%s", n++ ? " " : "", pn);
> > > + printf("%sphone# +%s", n++ ? " " : "", pn[0] == '+' ?
> > > &pn[1] : pn);
> > > if (apn[0])
> > > printf("%sAPN %s", n++ ? " " : "", apn);
> > > printf("\n");
> > > @@ -5323,7 +5323,7 @@ done:
> > > }
> > > *out++ = isascii(c) ? (char)c : '?';
> > > in++;
> > > - inlen -= sizeof (*in);
> > > + inlen--;
> > > }
> > > }
> >
> > Id's say just print the number as-is, no special casing for plus etc.
> >
> > The inlen chunk is ok.
> >
> > By some coincidence I was looking at the H5321gw card in my thinkpad.
> > I'm making some progress; before no valid frames were received at all,
> > now at least I get some. There seems to be some problem decoding the
> > header, and that ends up getting offsets wrong (on my card the data
> > does not follow the header immediately (at offset 0x0c), but at offset
> > 0x20). More to follow later on when I find some more time
> > investigating this.
> >
> > -Otto
> >
> >
>
>
> Hi Otto,
>
> that is probably due to my mistake. I assumed the the NCM pointer
> structure will always immediately follow the NCM header because
> all devices I had for testing did so. But according to the NCM
> spec this is not necessary. And some devices apparently format
> the buffer like this:
>
> ++
> ||
> |v
> [NCM header] [datagram, i.e. payload] [NCM datagram pointer]
> ^|
> ||
> ++
>
>
> Could you please the the patch below. It'll look for the NCM pointer
> structure at the offset stored in the NCM header instead of just
> looking at the data
Re: [PATCH] umb(4) fixes for ifconfig
On Thu, 10 Nov 2016 13:56:00 +0100 Otto Moerbeek wrote:
> On Wed, Nov 09, 2016 at 08:51:04AM -0800, Bryan Vyhmeister wrote:
>
> > This patch accomplishes two things for umb(4) connections. One, some SIM
> > cards have a plus at the beginning of the phone number while others do
> > not. In my case, an AT&T Wireless SIM card in the US has the plus where
> > a T-Mobile SIM card in Germany does not. The output of ifconfig(8)
> > originally added a plus regardless which caused two plus signs to appear
> > for me as below. With this patch, ifconfig(8) now adds the plus if it
> > is not there and does not add the plus if it is already programmed into
> > the SIM card.
> >
> > umb0: flags=8951 mtu 1430
> > index 5 priority 0 llprio 3
> > roaming disabled registration home network
> > state #7 cell-class LTE rssi -79dBm speed 47.7Mps up 286Mps down
> > SIM initialized PIN valid (3 attempts left)
> > subscriber-id 31041088 ICC-id 8901410427 provider AT&T
> > device EM7455 IMEI 014582000 firmware SWI9X30C_02.08.
> > phone# ++1213555123 APN broadband
> > dns 172.26.38.1
> > groups: egress
> > status: active
> > inet 10.45.181.18 --> 10.45.181.17 netmask 0xfffc
> >
> >
> > The second part of the patch also fixes the last digit of the phone
> > number and mulitple digits of the subscriber-id, ICC-id, and IMEI being
> > cut off. Both fixes were discussed with Gerhard Roth. I sent him an
> > original patch but it only partially solved the issues and after
> > discussion with him, he came up with the patch below which solves and
> > fully accounts for the issues and possible scenarios. With this patch
> > the output looks like this.
> >
> > umb0: flags=8851 mtu 1430
> > index 5 priority 0 llprio 3
> > roaming disabled registration home network
> > state #7 cell-class LTE rssi -103dBm speed 47.7Mps up 286Mps down
> > SIM initialized PIN valid (3 attempts left)
> > subscriber-id 310410812345678 ICC-id 89014104278812345678 provider AT&T
> > device EM7455 IMEI 014582012345678 firmware SWI9X30C_02.08.02.00
> > phone# +12135551234 APN broadband
> > dns 172.26.38.1
> > status: active
> > inet 10.84.107.51 --> 10.84.107.52 netmask 0xfff8
> >
> >
> > Bryan
> >
> >
> > Index: sbin/ifconfig/ifconfig.c
> > ===
> > RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
> > retrieving revision 1.332
> > diff -u -p -r1.332 ifconfig.c
> > --- sbin/ifconfig/ifconfig.c8 Nov 2016 14:37:20 - 1.332
> > +++ sbin/ifconfig/ifconfig.c9 Nov 2016 16:34:26 -
> > @@ -5153,7 +5153,7 @@ umb_status(void)
> > printf("\t");
> > n = 0;
> > if (pn[0])
> > - printf("%sphone# +%s", n++ ? " " : "", pn);
> > + printf("%sphone# +%s", n++ ? " " : "", pn[0] == '+' ?
> > &pn[1] : pn);
> > if (apn[0])
> > printf("%sAPN %s", n++ ? " " : "", apn);
> > printf("\n");
> > @@ -5323,7 +5323,7 @@ done:
> > }
> > *out++ = isascii(c) ? (char)c : '?';
> > in++;
> > - inlen -= sizeof (*in);
> > + inlen--;
> > }
> > }
>
> Id's say just print the number as-is, no special casing for plus etc.
>
> The inlen chunk is ok.
>
> By some coincidence I was looking at the H5321gw card in my thinkpad.
> I'm making some progress; before no valid frames were received at all,
> now at least I get some. There seems to be some problem decoding the
> header, and that ends up getting offsets wrong (on my card the data
> does not follow the header immediately (at offset 0x0c), but at offset
> 0x20). More to follow later on when I find some more time
> investigating this.
>
> -Otto
>
>
Hi Otto,
that is probably due to my mistake. I assumed the the NCM pointer
structure will always immediately follow the NCM header because
all devices I had for testing did so. But according to the NCM
spec this is not necessary. And some devices apparently format
the buffer like this:
++
||
|v
[NCM header] [datagram, i.e. payload] [NCM datagram pointer]
^|
||
++
Could you please the the patch below. It'll look for the NCM pointer
structure at the offset stored in the NCM header instead of just
looking at the data after the header.
Gerhard
Index: sys/dev/usb/if_umb.c
===
RCS file: /cvs/src/sys/dev/usb/if_umb.c,v
retrieving revision 1.4
diff -u -p -u -p -r1.4 if_umb.c
--- sys/dev/usb/if_umb.c25
Re: [PATCH] umb(4) fixes for ifconfig
On Wed, Nov 09, 2016 at 08:51:04AM -0800, Bryan Vyhmeister wrote:
> This patch accomplishes two things for umb(4) connections. One, some SIM
> cards have a plus at the beginning of the phone number while others do
> not. In my case, an AT&T Wireless SIM card in the US has the plus where
> a T-Mobile SIM card in Germany does not. The output of ifconfig(8)
> originally added a plus regardless which caused two plus signs to appear
> for me as below. With this patch, ifconfig(8) now adds the plus if it
> is not there and does not add the plus if it is already programmed into
> the SIM card.
>
> umb0: flags=8951 mtu 1430
> index 5 priority 0 llprio 3
> roaming disabled registration home network
> state #7 cell-class LTE rssi -79dBm speed 47.7Mps up 286Mps down
> SIM initialized PIN valid (3 attempts left)
> subscriber-id 31041088 ICC-id 8901410427 provider AT&T
> device EM7455 IMEI 014582000 firmware SWI9X30C_02.08.
> phone# ++1213555123 APN broadband
> dns 172.26.38.1
> groups: egress
> status: active
> inet 10.45.181.18 --> 10.45.181.17 netmask 0xfffc
>
>
> The second part of the patch also fixes the last digit of the phone
> number and mulitple digits of the subscriber-id, ICC-id, and IMEI being
> cut off. Both fixes were discussed with Gerhard Roth. I sent him an
> original patch but it only partially solved the issues and after
> discussion with him, he came up with the patch below which solves and
> fully accounts for the issues and possible scenarios. With this patch
> the output looks like this.
>
> umb0: flags=8851 mtu 1430
> index 5 priority 0 llprio 3
> roaming disabled registration home network
> state #7 cell-class LTE rssi -103dBm speed 47.7Mps up 286Mps down
> SIM initialized PIN valid (3 attempts left)
> subscriber-id 310410812345678 ICC-id 89014104278812345678 provider AT&T
> device EM7455 IMEI 014582012345678 firmware SWI9X30C_02.08.02.00
> phone# +12135551234 APN broadband
> dns 172.26.38.1
> status: active
> inet 10.84.107.51 --> 10.84.107.52 netmask 0xfff8
>
>
> Bryan
>
>
> Index: sbin/ifconfig/ifconfig.c
> ===
> RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
> retrieving revision 1.332
> diff -u -p -r1.332 ifconfig.c
> --- sbin/ifconfig/ifconfig.c 8 Nov 2016 14:37:20 - 1.332
> +++ sbin/ifconfig/ifconfig.c 9 Nov 2016 16:34:26 -
> @@ -5153,7 +5153,7 @@ umb_status(void)
> printf("\t");
> n = 0;
> if (pn[0])
> - printf("%sphone# +%s", n++ ? " " : "", pn);
> + printf("%sphone# +%s", n++ ? " " : "", pn[0] == '+' ?
> &pn[1] : pn);
> if (apn[0])
> printf("%sAPN %s", n++ ? " " : "", apn);
> printf("\n");
> @@ -5323,7 +5323,7 @@ done:
> }
> *out++ = isascii(c) ? (char)c : '?';
> in++;
> - inlen -= sizeof (*in);
> + inlen--;
> }
> }
Id's say just print the number as-is, no special casing for plus etc.
The inlen chunk is ok.
By some coincidence I was looking at the H5321gw card in my thinkpad.
I'm making some progress; before no valid frames were received at all,
now at least I get some. There seems to be some problem decoding the
header, and that ends up getting offsets wrong (on my card the data
does not follow the header immediately (at offset 0x0c), but at offset
0x20). More to follow later on when I find some more time
investigating this.
-Otto
[PATCH] umb(4) fixes for ifconfig
This patch accomplishes two things for umb(4) connections. One, some SIM
cards have a plus at the beginning of the phone number while others do
not. In my case, an AT&T Wireless SIM card in the US has the plus where
a T-Mobile SIM card in Germany does not. The output of ifconfig(8)
originally added a plus regardless which caused two plus signs to appear
for me as below. With this patch, ifconfig(8) now adds the plus if it
is not there and does not add the plus if it is already programmed into
the SIM card.
umb0: flags=8951 mtu 1430
index 5 priority 0 llprio 3
roaming disabled registration home network
state #7 cell-class LTE rssi -79dBm speed 47.7Mps up 286Mps down
SIM initialized PIN valid (3 attempts left)
subscriber-id 31041088 ICC-id 8901410427 provider AT&T
device EM7455 IMEI 014582000 firmware SWI9X30C_02.08.
phone# ++1213555123 APN broadband
dns 172.26.38.1
groups: egress
status: active
inet 10.45.181.18 --> 10.45.181.17 netmask 0xfffc
The second part of the patch also fixes the last digit of the phone
number and mulitple digits of the subscriber-id, ICC-id, and IMEI being
cut off. Both fixes were discussed with Gerhard Roth. I sent him an
original patch but it only partially solved the issues and after
discussion with him, he came up with the patch below which solves and
fully accounts for the issues and possible scenarios. With this patch
the output looks like this.
umb0: flags=8851 mtu 1430
index 5 priority 0 llprio 3
roaming disabled registration home network
state #7 cell-class LTE rssi -103dBm speed 47.7Mps up 286Mps down
SIM initialized PIN valid (3 attempts left)
subscriber-id 310410812345678 ICC-id 89014104278812345678 provider AT&T
device EM7455 IMEI 014582012345678 firmware SWI9X30C_02.08.02.00
phone# +12135551234 APN broadband
dns 172.26.38.1
status: active
inet 10.84.107.51 --> 10.84.107.52 netmask 0xfff8
Bryan
Index: sbin/ifconfig/ifconfig.c
===
RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
retrieving revision 1.332
diff -u -p -r1.332 ifconfig.c
--- sbin/ifconfig/ifconfig.c8 Nov 2016 14:37:20 - 1.332
+++ sbin/ifconfig/ifconfig.c9 Nov 2016 16:34:26 -
@@ -5153,7 +5153,7 @@ umb_status(void)
printf("\t");
n = 0;
if (pn[0])
- printf("%sphone# +%s", n++ ? " " : "", pn);
+ printf("%sphone# +%s", n++ ? " " : "", pn[0] == '+' ?
&pn[1] : pn);
if (apn[0])
printf("%sAPN %s", n++ ? " " : "", apn);
printf("\n");
@@ -5323,7 +5323,7 @@ done:
}
*out++ = isascii(c) ? (char)c : '?';
in++;
- inlen -= sizeof (*in);
+ inlen--;
}
}
