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. > > Dan > >> OR >> 2. Is it defined to Activate/Deactivate context? >> >> > >> > Dan >> > >> >> > 3) proprietary control protocols (CnS, QMI, etc) >> >> > 4) standard non-serial control protocols (MBIM) >> >> > >> >> > A modem can provide any of these in combination. Which port speaks what >> >> > protocol is detected by one or more of the following methods: >> >> > >> >> > a) USB VID/PID and interface number hardcoded in the drivers or in >> >> > userland udev rules >> >> > b) USB interface type (eg, serial port or NIC port, done in userland) >> >> > c) probing with known request/response to determine different >> >> > communication protocols used if the port type is indeterminate >> >> >> >> Thanks for the information. >> >> >> >> > >> >> > Dan >> >> > >> >> >> Please correct if my understanding is not correct or incomplete. >> >> >> >> >> >> Thanks in advance for your clarifications. >> >> >> >> >> >> Warm Regards, >> >> >> Suresh >> >> >> -- >> >> >> 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 >> >> > >> >> > >> >> -- >> >> 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 >> > >> > > > -- 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
