Hello Bjorn, One question out of curiosity... I am trying to ping from host to target, and I see perfect ARP request coming to the target (all 42 octets as required). But I do not see any reply from the target. It seems to me, According what I am reading that something is very wrong configured in my menuconfig. I do not see any messages coming to RNDIS (as you have mentioned), especially to > skb_pull(skb, ...). I have in lsmod : Module Size Used by cdc_ether 9612 0 cdc_subset 3069 0 usbnet 28738 2 cdc_ether,cdc_subset mii 4310 1 usbnet And as outcome of cat /proc/bus/usb/devices T: Bus=02 Lev=02 Prnt=03 Port=00 Cnt=01 Dev#= 18 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=02(comm.) Sub=00 Prot=00 MxPS=64 #Cfgs= 2 P: Vendor=0525 ProdID=a4a2 Rev= 3.27 S: Manufacturer=Linux 2.6.34.10-WR4.3.0.0_standard with max_udc S: Product=RNDIS/Ethernet Gadget C: #Ifs= 2 Cfg#= 2 Atr=c0 MxPwr= 2mA A: FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=06 Prot=00 I: If#= 0 Alt= 0 #EPs= 0 Cls=02(comm.) Sub=02 Prot=ff Driver= I: If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver= E: Ad=83(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms C:* #Ifs= 2 Cfg#= 1 Atr=c0 MxPwr= 2mA I:* If#= 0 Alt= 0 #EPs= 0 Cls=02(comm.) Sub=06 Prot=00 Driver=(none) I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_subset I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_subset E: Ad=83(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms According to what you wrote, I should have as lsmod ONLY g_ether And outcome of cat /proc/bus/usb/devices I:* If#= 0 Alt= 0 #EPs= 0 Cls=02(comm.) Sub=06 Prot=00 Driver=cdc_ether I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether Could you, please, elaborate more of this, what I wrote?! Thank you, Zoran Stojsavljevic -----Original Message----- From: linux-usb-owner@xxxxxxxxxxxxxxx [mailto:linux-usb-owner@xxxxxxxxxxxxxxx] On Behalf Of Marcel Holtmann Sent: Monday, February 13, 2012 3:37 PM To: Bjørn Mork Cc: Dan Williams; Thomas Schäfer; linux-usb@xxxxxxxxxxxxxxx Subject: Re: Qualcomm "raw IP" mode (was Re: Huawei E398 cdc/serialmodem-ppp 3G/4G) Hi Bjorn, > >> Try setting the data format then to make sure it's in 802.3 mode. > >> See the CTL/Set Data Format command: > >> > >> 26 00 09 00 01 01 00 00 10 02 00 01 00 > >> > >> Cmd: 0x0026 (SET_DATA_FORMAT) > >> Size: 0x0009 > >> > >> TLV: 0x01 (Format) > >> Size: 0x0001 > >> Data: 0x00 (0 = no QoS Header, 1 = include QoS header) > >> > >> TLV: 0x10 (Protocol) > >> Size: 0x0002 > >> Data[0]: 0x01 (1 = 802.3, 2 = raw IP mode) > >> Data[1]: 0x00 > >> > >> > Ugh. So I now send the QMI command only on reconnects. Seems to > >> > do the job. But I expect there are other weird issues like this... > >> > >> Try the data format thing. I don't think that's a firmware bug > >> really, but simply that you didn't set the format first. The > >> UML290 sends this command to ensure the data format is always [ no QoS, raw IP ]. > > > > I rather have these all running in raw IP mode. The 802.3 framing is > > utterly stupid. > > > > The only reason why people do 802.3, because that is the only way to > > make DHCP work in most operating system. And in Linux that is even > > true for dhclient. > > > > Since you mentioned WiMAX above, the original netdev was pure IP > > without any fake 802.3 framing. We could just make this fly with dhclient. > > > > The real lesson learned is that IP configuration has to come out of > > band anyway. Otherwise this all turns into insane stuff. > > I have now played a bit with the command Dan posted above, and it > works reliably as he documented it. The only issues to be aware of is > that you cannot change mode while a connection is active and that the > mode is reset to default when the device is reset. Both making sense. > > But I am starting to wonder whether supporting this mode makes any > sense... What do you expect from it? > > There are several possible approaches, all with drawbacks: > 1) define a new "raw IP" header format and don't touch the packets in > the driver > 2) use ARPHRD_NONE (which is correct AFAICS) and don't touch the packets > in the driver > 3) keep ARPHRD_ETHER and strip/add headers in the driver > > There is no doubt that alternative 3 works best. It makes every tool, > like any DHCP client, sniffer app or even IPv6 SLAAC just work. And > the driver changes are not much either: Add NOARP flag on open, > skb_pull(skb, ETH_HLEN) on tx, and skb_push(skb, ETH_HLEN) on rx (with > a few additional lines filling in some sane content). > > But why? The device already does this work for us. Saving 1% on the > USB link doesn't seem to matter much, does it? > > Alternative 1 or 2 could have made some sense if there were any tools > readily available to use such interfaces. But there are not. Like > DHCP, which is supported by the device in the raw IP mode as well. > You'd have to write your own client to use it. Or SLAAC, where you'd > have to add some workaround to net/ipv6/addrconf.c. This can of > course be fixed, but adding complexity to both driver and userspace > tools should require some justification. > > I just don't think any of this is worth bothering with, unless there > are some advantages to the raw IP mode. And I can't find any. I do not wanna run DHCP at all on these links. I assume we have a command that tells us what IP and DNS are used and then we just set it. Running DHCP is as stupid as using PPP for communication with the modem. Actually DHCP and an Ethernet card has the inherent disadvantage that you need a netmask and also have to deal with ARP. Why would you do that if your device is not an Ethernet card. Essentially you are blocking more than the one needed IP address and forcing extra overhead in just getting your packets over the network. The over the air links are IP and the kernel just exposing a Point-to-point network interface is perfectly fine. It can like any other device you create with TUN/TAP for example. It does not matter what type it is as long as you make it Point-to-point. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html -------------------------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 ��.n��������+%������w��{.n�����{���)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
