On Wed, Jun 13, 2012 at 07:58:18PM +0200, Bjørn Mork wrote:
> Marcin Szewczyk <Marcin.Szewczyk@wodny.org> writes:
> > When using RNDIS wwan0 interface has MAC address 02:50:f3:00:00:00 while
> > packets coming from Internet have destination MAC address set to
> > 00:01:02:03:04:05. So the workaround is to set wwan0 MAC to that value.
>
> I guess the 02:50:f3:00:00:00 comes from a USB descriptor as it's not
> exactly random.

You're right. As You suggested - it is visible as iMacAddress in lsusb
output.

> So if the firmware provides this descriptor while using
> another fixed address, then that is certainly a firmware bug. Not too
> surprising unfortunately...

Roger.

> Normally such devices will pick the MAC address they see in the DHCP
> discover message, but that doesn't seem to happen here unless you sent a
> DHCP request with 00:01:02:03:04:05 as MAC source address?

Negative. MAC address set for the interface was used.

Another thing worth noticing is that 02:50:f3:00:00:00 is used as the
destination address for outgoing packets and source address for
returning packets. Both before and after setting interface MAC address.

> What does lsusb -v say?

Output attached.

> Or you can bug Huawei about it...

I will check if Huawei cares...

> Another option would be using another usb_modeswitch command. These
> modems often support many different USB descriptor sets, selectable by
> the usb_modeswitch command. For some reason, Huawei thinks that it is a
> good idea to use different USB descriptors for Linux and Windows. Guess
> which set is tested... You could sniff the device under Windows, find
> out what the Windows driver does, and try that in Linux as well.

I will search for a Windows PC...

Thank You for a reply. I've also uploaded two tcpdumps:
1) one with default MAC
http://wodny.org/special/huawei/huawei-e137-wwan0-defaultmac.cap
2) one with MAC manually set to 00:01:02:03:04:05
http://wodny.org/special/huawei/huawei-e137-wwan0-00-05-mac.cap

--
Marcin Szewczyk http://wodny.org
mailto:Marcin.Szewczyk@wodny.borg <- remove b / usuń b
xmpp:wodny@ubuntu.pl xmpp:wodny@jabster.pl
Bus 001 Device 021: ID 12d1:1436 Huawei Technologies Co., Ltd.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2 ?
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
idVendor 0x12d1 Huawei Technologies Co., Ltd.
idProduct 0x1436
bcdDevice 0.00
iManufacturer 4 HUAWEI Technology
iProduct 3 HUAWEI Mobile
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 201
bNumInterfaces 7
bConfigurationValue 1
iConfiguration 2 Huawei Configuration
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 5
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Association:
bLength 8
bDescriptorType 11
bFirstInterface 1
bInterfaceCount 2
bFunctionClass 2 Communications
bFunctionSubClass 0
bFunctionProtocol 0
iFunction 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 6 Ethernet Networking
bInterfaceProtocol 255
iInterface 0
CDC Header:
bcdCDC 1.10
CDC Ethernet:
iMacAddress 1 0250f3000000
bmEthernetStatistics 0x00000000
wMaxSegmentSize 1536
wNumberMCFilters 0x0001
bNumberPowerFilters 0
CDC Union:
bMasterInterface 1
bSlaveInterface 2
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 5
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85 EP 5 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 4
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x86 EP 6 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 5
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk-Only
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x87 EP 7 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x05 EP 5 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 6
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk-Only
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x06 EP 6 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x88 EP 8 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2 ?
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0003
Self Powered
Remote Wakeup Enabled

Marcin Szewczyk <Marcin.Szewczyk@wodny.org> writes:

> On Wed, Jun 13, 2012 at 07:58:18PM +0200, Bjørn Mork wrote:
>> Marcin Szewczyk <Marcin.Szewczyk@wodny.org> writes:
>> > When using RNDIS wwan0 interface has MAC address 02:50:f3:00:00:00 while
>> > packets coming from Internet have destination MAC address set to
>> > 00:01:02:03:04:05. So the workaround is to set wwan0 MAC to that value.
>>
>> I guess the 02:50:f3:00:00:00 comes from a USB descriptor as it's not
>> exactly random.
>
> You're right. As You suggested - it is visible as iMacAddress in lsusb
> output.
>
>> So if the firmware provides this descriptor while using
>> another fixed address, then that is certainly a firmware bug. Not too
>> surprising unfortunately...
>
> Roger.
>
>> Normally such devices will pick the MAC address they see in the DHCP
>> discover message, but that doesn't seem to happen here unless you sent a
>> DHCP request with 00:01:02:03:04:05 as MAC source address?
>
> Negative. MAC address set for the interface was used.
>
> Another thing worth noticing is that 02:50:f3:00:00:00 is used as the
> destination address for outgoing packets and source address for
> returning packets. Both before and after setting interface MAC address.

Yuck! Looks like someone put the wrong address into the string
descriptor.



>> What does lsusb -v say?
>
> Output attached.

Yes, as expected. Fixing the mac address string descriptor shouldn't be
a big problem for Huawei.

I don't think there is any existing infrastructure in place for
overriding it in Linux. And I believe it shouldn't be added either,
given that:
- your modem is the only affected one AFAIK,
- a usable workaround exists,
- the firmware bug is extremely easy to fix for Huawei (and might
already be fixed for all we know)


>> Or you can bug Huawei about it...
>
> I will check if Huawei cares...
>
>> Another option would be using another usb_modeswitch command. These
>> modems often support many different USB descriptor sets, selectable by
>> the usb_modeswitch command. For some reason, Huawei thinks that it is a
>> good idea to use different USB descriptors for Linux and Windows. Guess
>> which set is tested... You could sniff the device under Windows, find
>> out what the Windows driver does, and try that in Linux as well.
>
> I will search for a Windows PC...
>
> Thank You for a reply. I've also uploaded two tcpdumps:
> 1) one with default MAC
> http://wodny.org/special/huawei/huawei-e137-wwan0-defaultmac.cap
> 2) one with MAC manually set to 00:01:02:03:04:05
> http://wodny.org/special/huawei/huawei-e137-wwan0-00-05-mac.cap


Thanks. That demonstrates the problem really well.



Bjørn


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87bokenzaq.fsf@nemi.mork.no">http://lists.debian.org/87bokenzaq.fsf@nemi.mork.no