Re: cdc_ether, Huawei E173u-2, wrong MAC address of packets vs wwan0
On Wed, Jun 13, 2012 at 07:58:18PM +0200, Bjørn Mork wrote: Marcin Szewczyk marcin.szewc...@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.szewc...@wodny.borg - remove b / usuń b xmpp:wo...@ubuntu.pl xmpp:wo...@jabster.pl Bus 001 Device 021: ID 12d1:1436 Huawei Technologies Co., Ltd. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 ? bDeviceProtocol 1 Interface Association bMaxPacketSize064 idVendor 0x12d1 Huawei Technologies Co., Ltd. idProduct 0x1436 bcdDevice0.00 iManufacturer 4 HUAWEI Technology iProduct3 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 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 5 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 32 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 32 Interface Association: bLength 8 bDescriptorType11 bFirstInterface 1 bInterfaceCount 2 bFunctionClass 2 Communications bFunctionSubClass 0 bFunctionProtocol 0 iFunction 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber
Re: cdc_ether, Huawei E173u-2, wrong MAC address of packets vs wwan0
Marcin Szewczyk marcin.szewc...@wodny.org writes: On Wed, Jun 13, 2012 at 07:58:18PM +0200, Bjørn Mork wrote: Marcin Szewczyk marcin.szewc...@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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bokenzaq@nemi.mork.no
cdc_ether, Huawei E173u-2, wrong MAC address of packets vs wwan0
Hi, I hope this is acceptable to post this kind of thing here. I've got a problem with Huawei E173u-2 modem. I've found only one more case on the Internet [1]. It isn't a full solution though, rather a workaround. 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. Is there anything that can be done inside the module (cdc_ether I suppose) so that it becomes more consistent and both packets and wwan0 have the same MAC address without changing MAC manually? Or maybe there is something wrong with the hardware? [1] https://groups.google.com/d/topic/comp.os.linux.hardware/BBiXbAZYfYA/discussion -- Marcin Szewczyk http://wodny.org mailto:marcin.szewc...@wodny.borg - remove b / usuń b xmpp:wo...@ubuntu.pl xmpp:wo...@jabster.pl -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120613154718.gd3...@magazyn-ziarno.chello.pl
Re: cdc_ether, Huawei E173u-2, wrong MAC address of packets vs wwan0
Marcin Szewczyk marcin.szewc...@wodny.org writes: I hope this is acceptable to post this kind of thing here. I've got a problem with Huawei E173u-2 modem. I've found only one more case on the Internet [1]. It isn't a full solution though, rather a workaround. 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. So if the firmware provides this descriptor while using another fixed address, then that is certainly a firmware bug. Not too surprising unfortunately... 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? What does lsusb -v say? Is there anything that can be done inside the module (cdc_ether I suppose) so that it becomes more consistent and both packets and wwan0 have the same MAC address without changing MAC manually? Or maybe there is something wrong with the hardware? [1] https://groups.google.com/d/topic/comp.os.linux.hardware/BBiXbAZYfYA/discussion The driver (either cdc_ether or a dedicated one for this device) could hardcode the 00:01:02:03:04:05 address, but then we'd have to know which devices to apply that to. That's probably impossible, as it will depend on firmware revision, moon phase and other unknown factors. Working around this problem now may very well cause new problems once the firmware is fixed. So I believe setting the MAC address in your local configuration is an acceptable workaround for now. Or you can bug Huawei about it... 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. SniffUsb works very well if you've got Windows XP: http://www.pcausa.com/Utilities/UsbSnoop/default.htm Bjørn -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y5nrjdqd@nemi.mork.no
