On Tue, 2014-05-13 at 17:58 +0530, Suresh Kumar N. wrote: > On Thu, May 8, 2014 at 9:08 PM, Dan Williams <dcbw@xxxxxxxxxx> wrote: > > On Wed, 2014-05-07 at 15:30 +0530, Suresh Kumar N. wrote: > >> On Tue, May 6, 2014 at 9:42 PM, Dan Williams <dcbw@xxxxxxxxxx> wrote: > >> > On Tue, 2014-05-06 at 14:27 +0530, Suresh Kumar N. wrote: > >> >> On Mon, May 5, 2014 at 8:38 PM, Dan Williams <dcbw@xxxxxxxxxx> wrote: > >> >> > On Mon, 2014-05-05 at 11:07 +0530, Suresh Kumar N. wrote: > >> >> >> Hi, > >> >> >> > >> >> >> I am new to udev and device enumeration. > >> >> >> > >> >> >> I am interested to know how USB Data Card would get enumerated. > >> >> >> > >> >> >> Based on my understanding Data Card can get enumerated below 2 possible ways - > >> >> >> 1. As a modem > >> >> >> 2. As a Network Interface Card (NIC) > >> >> > > >> >> > Or both at the same time. > >> >> > > >> >> >> Is there a Standard defining the way a Data Card should be enumerated? > >> >> > > >> >> > There is no single standard. There is a few "standards" and multiple > >> >> > proprietary mechanisms, and sometimes these are combined in the same > >> >> > device. > >> >> > > >> >> > The device simply enumerates as a normal USB device, providing to the > >> >> > host computer one or more USB interfaces. > >> >> > > >> >> > Each USB interface can be any one of: > >> >> > > >> >> > 1) serial interface (AT, QCDM, WMC, WDM, CDC-ACM, etc) > >> >> > 2) pseudo-ethernet NIC (proprietary, CDC-ETHER, CDC-NCM, etc) > >> >> > >> >> In such case (pseudo-ethernet NIC) do we assume that the firmware on > >> >> the USB Dongle is responsible to establish IP address? > >> >> In other words how does IP address allocation occur in this case? > >> > > >> > >> Thank you very much for such a clear and exhaustive explanation. > >> > >> > The firmware is always involved, because the IP address comes from the > >> > cellular network, and the firmware is what receives it. The firmware > >> > must then provide that address to the host, so that the host can > >> > communicate with the network. This happens in a few ways: > >> > > >> > 1) firmware implements a DHCP server, IPv6 Router, etc; host uses DHCP > >> > client or IPv6 Router Discovery to obtain IP address and DNS details > >> > > >> > 2) firmware provides static IP address and DNS details over AT commands > >> > > >> > 3) firmware provides static IP address and DNS details via proprietary > >> > protocols (QMI, MBIM, etc) > >> > > >> > 4) firmware implements PPP over serial port and provides IP address and > >> > DNS details via IPCP/IPV6CP > >> > >> Based on 1) and 2), Firmware refers to be driver code implemented on > >> USB device-side, but 3) and 4) refer to Firmware implemented on > >> Host-side. > >> Does Firmware here refer to Host-side or USB device-side? > > > > "Firmware" here always refers to USB device side. So all 4 of these > > refer to things that the USB device can do, based on what the USB device > > has implemented in its firmware. It's up to the host to determine which > > protocols the USB device firmware implements, and then to speak to the > > USB device with those protocols to determine the IP address the host > > must use to communicate with the USB device firmware. > > > >> > > >> > Most modems still support #4 over at least one AT-capable serial port. > >> > Many modems implement multiple methods (eg, Qualcomm firmware often does > >> > #1, #3, and #4). > >> > > >> > Note that in all cases, connection setup (with the APN and other > >> > details) must occur via control channels (with AT, QMI, MBIM, etc) > >> > before you can use any of these methods to obtain an IP address from the > >> > firmware. > >> > > >> > There is actually another class of "plug and play" 3G dongle that > >> > provides a NAT-ed IP network (192.168.0.x or 10.x) to the host over what > >> > looks like a USB ethernet NIC. These appear exactly like a normal USB > >> > ethernet dongle or a home router to the host, and to configure the > >> > device, you use a web browser on the host like you would with a home > >> > router. None of the 3G stuff is exposed to the host. One example is > >> > Huawei HiLink devices like the E3256, though not all HiLink-branded > >> > devices operate this way. > >> > >> In all of the above, how do we visualize the Connect/Disconnect option > >> provided by the Host side application? > > > > The steps you must take are *always* dependent on the specific modem > > that you are communicating with. Depending on which protocols the modem > > implements your host application must do many different things. > > > >> 1. Is it defined to just Enable/Disable a network interface (USB > >> ethernet NIC) on Host side, but in that case would the Active context > >> get Deactivated? > > > > Your host application must perform setup and context activation using > > the control channel protocols (AT commands, proprietary protocols, etc) > > before it can start real IP networking. > > > > Perhaps a concrete example will help. This is the procedure for > > connecting an Ericsson "MBM" (F3507, F3607, F5521, etc) modem. This > > modem provides 2 CDC-ACM ports which are used for AT command > > communication, and a CDC-ETHER port which emulates an ethernet > > interface. Both of these ports use standard protocols and are handled > > automatically by the Linux kernel drivers. > > > > 1) first, check and ensure that the modem is registered on the network > > with AT+CGREG. Once the modem has registered, you can proceed. > > 2) check for an existing PDP context that matches the APN you want to > > use. If there is one, save that PDP context ID for the next step. If > > not, create on with AT+CGDCONT and your APN > > 3) Set authentication for the given PDP context ID with AT*EIAAUW > > 4) Request data session activation with AT*ENAP > > 5) Poll AT*ENAP until it reports that you are connected > > 6) Finally you can run DHCP on the network port to get your IP address > > and DNS servers > > Thank You once again Dan for the explanation. > > > > > For many devices from Option NV, you follow much the same procedure > > except that the authentication command is AT$QCPDPP for Qualcomm-based > > chipsets, and AT_OPDPP for non-Qualcomm based chipsets (step 3 above). > > Then you use the AT_OWANCALL command to request the data session (step > > 4). Then to retrieve the IP configuration (step 6), you use AT_OWANDATA > > which returns the IP address, which you then apply to the network port. > > DHCP is not used with these devices. > > > > Huawei devices often have different AT commands (AT^NDISDUP and AT^DHCP) > > for data session activation. Many Qualcomm devices support QMI, which > > is used instead of AT commands for data session setup. So you see, what > > procedure you use to start the data session depends on exactly what > > specific USB device you are using. > > Please provide some references wherein I can fetch more information > about USB devices and functionality. You must either ask the manufacturer for the AT command reference for the device, or find the references with Google/etc, or run USB traces of communication in Windows to determine the protocol & commands, or consult the standards (eg, MBIM) that the device might use. It's really specific to the device and manufacturer, unfortunately. Dan -- 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
