K5160

[Markus Gothe]

Ah, I did notice that frame but I didn’t guess it is ARP.

Really weird.

Maybe you’re right about the NBT-32 issue… Why isn’t the kernel driver supporting 32-bit NCM?

I need to look at latest hw_cdc_driver.c (v2.09.00.00) to see which NCM modes it supports.

//M

On 01 Mar 2016, at 20:41 , Bjørn Mork <bjorn at mork.no> wrote:

> nietzsche at lysator.liu.se writes:
> 
>> Here is a sniff done with latest libmbim and ModemManager on Ubuntu.
> 
> Yuck!  Well, I mean thanks :)  But right when I was starting to think
> that *we* might be doing something wrong, you provide us with this:
> 
> 
> Frame 4031: 162 bytes on wire (1296 bits), 162 bytes captured (1296 bits) on interface 0
> ..
> Mobile Broadband Interface Model
>    NCM Transfer Header
>        Signature: ncmh
>        Header Length: 16
>        Sequence Number: 0
>        Block Length: 98
>        NDP Index: 16
>    NCM Datagram Pointer
>        Signature: ips0
>            IPS Session Id: 0
>        Length: 32
>        Reserved: 0x0000
>        Next NDP Index: 0
>        Reserved: 0x00000000
>        Datagram Index: 50
>        Datagram Length: 46
>        Datagram: 00010800060400014c549945e5d54f666e96000000000000...
>        Datagram Index: 0
>        Datagram Length: 0
>        [Number Of Datagrams: 1]
>    [Total Number Of Datagrams: 1]
> Internet Protocol, bogus version (0)
>    0000 .... = Version: 0
>        [Expert Info (Error/Protocol): Bogus IP version]
>            [Bogus IP version]
>            [Severity level: Error]
>            [Group: Protocol]
> 
> 0000  40 42 66 ee 00 00 00 00 43 03 81 0d 05 00 2d 00   @Bf.....C.....-.
> 0010  28 c4 d5 56 00 00 00 00 c7 da 02 00 00 00 00 00   (..V............
> 0020  62 00 00 00 62 00 00 00 00 00 00 00 00 00 00 00   b...b...........
> 0030  00 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00   ................
> 0040  6e 63 6d 68 10 00 00 00 62 00 00 00 10 00 00 00   ncmh....b.......
> 0050  69 70 73 00 20 00 00 00 00 00 00 00 00 00 00 00   ips. ...........
> 0060  32 00 00 00 2e 00 00 00 00 00 00 00 00 00 00 00   2...............
> 0070  00 00 00 01 08 00 06 04 00 01 4c 54 99 45 e5 d5   ..........LT.E..
> 0080  4f 66 6e 96 00 00 00 00 00 00 4f 66 6e 95 00 00   Ofn.......Ofn...
> 0090  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> 00a0  00 00                                             ..
> 
> 
> 
> Yes, wireshark is right.  That is definitely "bogus IP".  It's not IP at
> all.  Guess what it is?  It's an ARP request, minus the ethernet header.
> 
> Decoded it becomes
> 
> Address Resolution Protocol (request)
>    Hardware type: Ethernet (1)
>    Protocol type: IPv4 (0x0800)
>    Hardware size: 6
>    Protocol size: 4
>    Opcode: request (1)
>    Sender MAC address: 4c:54:99:45:e5:d5
>    Sender IP address: 79.102.110.150
>    Target MAC address: 00:00:00:00:00:00
>    Target IP address: 79.102.110.149
> 
> 
> That's never going to be valid MBIM.  Sort of settles what level of
> standard compliance we can expect here.  Not that it helps us much.  We
> have to make it work anyway.
> 
> But this firmware can only be fixed using a clue-by-four....
> 
> Let's try the function reset next.  Should be easy.  But if anything,
> the above made me more convinced that this might be a case of a firmware
> which doesn't support 16bit at all.  Windows works without it, so who
> cares what the spec says?
> 
> 
> Bjørn
> 

//Markus - The panama-hat hacker