Modem manager

.github/workflows/unit.yml

@@ -23,6 +23,7 @@ jobs:
  run: |
  make test
  - name : Test (TPM Required)
+ timeout-minutes: 30
  run: |
  bash tools/tpm-tests-on-qemu.sh
  - name: Report test results as Annotations

docs/BOOTING.md

@@ -266,6 +266,23 @@ You will see a set of files in the current directory to locate into you tftp ser
 dhcp server to `ipxe.efi` (actually, it will use configuration from `ipxe.efi.cfg`). Files `kernel`, `initrd.img` and `initrd.bits`
 should be available via HTTP/HTTPs and you need to modify `ipxe.efi.cfg` with location of those files.
 
+## Boot options effect on TPM measurements (PCR-1)
+
+During the boot process, as stated by the TCG specification, BIOS/UEFI should measure the enumerated boot options into the TPM.
+UEFI measures the list of boot options and their configuration data in PCR-1. EVE is using PCR-1 as one of the sealing
+PCRs to protect the vault key from unauthorized access (check [Encrypted Data Store](./SECURITY.md#encrypted-data-store) for more details),
+so it is important for the edge node to have a fixed and consistent list of boot options after onboarding. Attaching any
+bootable device, most notably USB devices, will result in a different set of boot options and subsequently change of
+the PCR-1 value. If a USB disk is used as an extra storage, **it is important to make sure the attached USB device has no bootable partition present**.
+
+### Check USB is bootable or not
+
+You can check it by examining the `Flags` output of a tool like `parted`, for example executing the following command should result in no output (make sure to replace `/dev/sda` with your own USB device, you can list all using `parted -l`):
+
+```bash
+parted /dev/sda print | grep boot
+```
+
 ## Console access
 
 Access via console is enabled during initial bootstrap and will be disabled after first reboot of onboarded edge node.

docs/BUILD.md

@@ -399,7 +399,7 @@ The following custom packages are used:
 * `onboot` packages:
  * `lfedge/eve-rngd` - custom `lfedge/eve-rngd` package, rather than the standard linuxkit one. This micro-fork accommodates the [following hack](https://github.com/lf-edge/eve/blob/master/pkg/rngd/cmd/rngd/rng_linux_arm64.go) which provides some semblance of seeding randomness on ARM. Without this HiKey board won't boot.
 * `services` packages:
- * `lfedge/eve-wwan` - WWAN drivers and software. LTE/3G/2G. Mostly experimental.
+ * `lfedge/eve-wwan` - WWAN drivers and software. 5G/LTE/3G/2G. See [wwan/README.md](../pkg/wwan/README.md) for detailed documentation.
  * `lfedge/eve-wlan` - WLAN drivers and software. Currently a glorified wrapper around wpa_supplicant.
  * `lfedge/eve-guacd` - [Apache Guacamole service](http://guacamole.apache.org/) that provides console and VDI services to running VMs and containers.
  * `lfedge/eve-zedctr` - a "catch-all" package for EVE tools; see below.

docs/CONFIG.md

@@ -13,6 +13,7 @@ In general, EVE is trying to make sure that its controller always has the last w
 * `wpa_supplicant.conf` - a legacy way of configuring EVE's WiFi
 * `authorized_keys` - initial authorized SSH keys for accessing EVE's debug console; DO NOT use options, we only accept 'keytype, base64-encoded key, comment' format
 * `bootstrap-config.pb`- initial device configuration used only until device is onboarded (see below for details)
+* `remote_access_disabled`- a file indicating remote access status, if it exist remote access (edge-view and ssh) is disabled. Please check [config document](SECURITY.md#disabling-remote-access) for more information.
 
 The initial content of these configuration files is stored in the EVE's source tree under [config](../config) folder. From there, these configuration files are baked into the EVE installer images. For the read-write bootable disk installer image these files can further be tweaked by mounting the "EVE" partition and editing those files directly on the installer image. This gives you an ability to take the default installer image and tweak it for your needs without re-building EVE from scratch (obviously this is not an option for a read-only ISO installer image). A typical workflow is to take an installer image from the official EVE build, flash it onto a USB flash drive, insert that USB flash drive into your desktop and edit file on the partition called EVE.
 
@@ -184,7 +185,8 @@ An example file with eth0 being static and eth1 using dhcp is:
 }
 ```
 
-To specify that wwan0 should be secondary (only used if eth0 can not be used to reach the controller), and eth1 only be if neither eth0 nor wwan0 works, one would set non-zero costs. For example,
+To specify that a cellular modem should be secondary (only used if eth0 can not be used to reach the controller),
+and eth1 only be used if neither eth0 nor the modem works, one would set non-zero costs. For example,
 
 ```json
 {
@@ -201,10 +203,23 @@ To specify that wwan0 should be secondary (only used if eth0 can not be used to
  {
  "Dhcp": 4,
  "Cost": 1,
- "IfName": "wwan0",
+ "USBAddr": "1:1.4",
+ "PCIAddr": "0000:01:00.0",
  "IsMgmt": true,
- "Name": "Management1"
- }
+ "Name": "Management1",
+ "WirelessCfg": {
+ "WType": 1,
+ "CellularV2": {
+ "AccessPoints": [
+ {
+ "SIMSlot": 0,
+ "Activated": true,
+ "APN": "internet"
+ }
+ ]
+ }
+ }
+ },
  {
  "Dhcp": 4,
  "Cost": 2,

docs/DEVICE-CONNECTIVITY.md

@@ -33,7 +33,7 @@ When EVE is installed using a generic EVE installer without device bootstrap con
 
 - DHCP is enabled on one of the Ethernet ports
 - WiFi is not assumed (since WiFi needs credentials)
-- If cellular connectivity is assumed, the default APN (`internet`) will work to connect to the network
+- Cellular connectivity is not assumed (without cellular config every discovered modem will have RF function disabled)
 - No enterprise proxy configuration is required to be able to connect to the controller.
 
 If any of those assumptions is not satisfied, then it is necessary to either install EVE using a single-use EVE installer, shipped with the initial "bootstrap" configuration prepared for the target device (the preferred method) or to use one of the legacy mechanisms for off-line configuration management.
@@ -65,7 +65,7 @@ At least one port must be set to be a management port, and that port needs to re
 
 ### Last resort
 
-If `network.fallback.any.eth` [configuration property](CONFIG-PROPERTIES.md) is set to `enabled` (by default it is disabled), then there is an additional lowest priority item in the list of DevicePortConfigs, called "Last resort" DPC (pubsub key `lastresort`), based on finding all of the Ethernet and Ethernet-like interfaces (an example of the latter is WiFi and cellular modems) which are not used exclusively by applications. The last resort configuration assumes DHCP and no enterprise proxies.
+If `network.fallback.any.eth` [configuration property](CONFIG-PROPERTIES.md) is set to `enabled` (by default it is disabled), then there is an additional lowest priority item in the list of DevicePortConfigs, called "Last resort" DPC (pubsub key `lastresort`), based on finding all Ethernet interfaces (i.e. excluding wireless connectivity options) which are not used exclusively by applications. The last resort configuration assumes DHCP and no enterprise proxies.
 
 However, independent of the above property setting, if the device has no source of network configuration available (no bootstrap, override or persisted config), then EVE will use the Last resort *forcefully*. This, for example, happens when device boots for the very first time, without [bootstrap config](#bootstrap-configuration) or the (legacy) network config override being provided. In that case, device may remain stuck with no connectivity indefinitely (unless the user plugs in a USB stick with a network config later), therefore EVE will try to use Last resort to see if it can provide connectivity with the controller. Once device obtains a proper network config (from the controller or a USB stick), EVE will stop using Last resort forcefully and will keep this network config inside `DevicePortConfigList` only if and as long as it is enabled explicitly by the config (`network.fallback.any.eth` is `enabled`).
 
@@ -189,7 +189,7 @@ with `eve verbose off`.
 ### Connectivity-Related Logs
 
 The progression and outcome of [network configuration testing](#testing) is logged with messages
-prefixed with `DPC verify:` (not that DPC is abbreviation for `DevicePortConfig`, which is a Go
+prefixed with `DPC verify:` (note that DPC is abbreviation for `DevicePortConfig`, which is a Go
 structure holding configuration for all management and app-shared interfaces). These messages
 can explain why a particular device is not using the latest configuration but instead has fallen
 back to a previous one. These logs are quite concise yet pack enough information to tell when
@@ -271,19 +271,20 @@ troubleshooting:
  Once device is onboarded, `DeviceUUID` field will be non-empty and contain the assigned
  device UUID (also printed to `/persist/status/uuid`).
 
-Finally, the [wwan microservice](../pkg/wwan), managing the [cellular connectivity](./WIRELESS.md),
-is a shell script outside of the pillar container, not using pubsub for IPC. Instead, it exchanges
-wwan config, status and metrics with NIM simply by reading/writing files located under `/run/wwan`
-directory:
+For WWAN connectivity info, refer to these pubsub topics:
 
-- `config.json` is published by NIM and may contain configuration for a cellular modem.
+- `/run/nim/WwanConfig/global.json` is published by NIM and contains configuration for cellular modems.
+- `/run/wwan/WwanStatus/global.json` is published by wwan microservice to inform zedagent, NIM
+ and some other microservices about the current cellular connectivity status.
+- `/run/wwan/WwanMetrics/global.json` is published by wwan microservice and contains packet/byte
+ counters reported by cellular modems (i.e. not from the Linux network stack)
 
-- `status.json` and `metrics.json` are published by wwan microservice to inform NIM about the current
- cellular connectivity status and to publish packet/byte counters, respectively.
-
-- `resolv.conf/<interface-name>.dhcp` contains the list of nameservers that should be used with
- a given wwan interface (published by wwan to NIM and further via `DeviceNetworkStatus` to other
- microservices, like downloader)
+Separately to pubsub topics, file `/run/wwan/resolv.conf/<interface-name>.dhcp` is updated
+by the wwan microservice and contain the list of nameservers that should be used with the given
+wwan interface. This is similar to how dhcpcd reports DNS servers for ethernet interfaces
+(for both DHCP and static IP config). In NIM, where this info is processed and further published
+via `DeviceNetworkStatus` pubsub topic, we can therefore process nameservers for ethernet
+and wwan interfaces in a very similar way and reuse some code.
 
 ### Netdump and Nettrace
 
@@ -340,7 +341,7 @@ topic name with a publication timestamp plus the `.tgz` extension, for example:
 `downloader-fail-2023-01-03T14-25-04.tgz`, `nim-ok-2023-01-03T13-30-36`, etc.
 
 Not all microservices that communicate over the network are traced and contribute with netdumps.
-Currently traced HTTP requests are:
+Currently, traced HTTP requests are:
 
 - `/ping` request done by NIM to verify connectivity for the *latest* DPC (testing of older DPCs
  is never traced). Packet capture is also enabled and the obtained pcap files are included in

docs/ECO-METADATA.md

@@ -61,10 +61,10 @@ Standalone GPS receivers are currently not supported.
 
 However, by default EVE does not use the location service of the LTE modem and the location
 information is therefore not available.
-To enable location reporting for the device, the `wwan*` adapter (corresponding to the LTE modem)
-must be **configured as port shared between applications and/or for device management** with
-**location tracking** enabled. When the modem is disabled or directly assigned to an application,
-EVE is not able to access the location service and obtain location information.
+To enable location reporting for the device, the cellular modem adapter must be **configured as port
+shared between applications and/or for device management** with **location tracking** enabled.
+When the modem is disabled or directly assigned to an application, EVE is not able to access
+the location service and obtain location information.
 In EVE API this is done by setting the field `NetworkConfig.wireless.cellularCfg.location_tracking`
 to `true`. For more details refer to [netconfig.proto](https://github.com/lf-edge/eve-api/tree/main/proto/config/netconfig.proto).
 
@@ -112,6 +112,8 @@ Uncertainty and reliability fields describe how accurate the provided location i
 with single-precision floating-point values. Negative values are not valid and represent
 unavailable uncertainty.
 Reliability is one of: `not-set` (unavailable), `very-low`, `low`, `medium` and `high`.
+Note that Uncertainty and Reliability are no longer available in newer EVE versions
+(returned are zero values).
 
 The frequency at which EVE updates location information is configurable using the option
 [timer.location.app.interval](../docs/CONFIG-PROPERTIES.md). By default, the interval is 20
@@ -206,7 +208,7 @@ curl 169.254.169.254/eve/v1/wwan/status.json 2>/dev/null | jq
 ```
 
 The underlying structure, used by EVE to store the information and output it as JSON,
-is named `WwanStatus` and can be found in [zedroutertypes.go](../pkg/pillar/types/zedroutertypes.go).
+is named `WwanStatus` and can be found in [wwan.go](../pkg/pillar/types/wwan.go).
 
 The endpoint returns a list of entries, one for every cellular modem, with the modem's
 logical label (from the device model) used as a reference. The physical connection between
@@ -275,7 +277,7 @@ curl 169.254.169.254/eve/v1/wwan/metrics.json 2>/dev/null | jq
 ```
 
 The underlying structure, used by EVE to store the information and output it as JSON,
-is named `WwanMetrics` and can be found in [zedroutertypes.go](../pkg/pillar/types/zedroutertypes.go).
+is named `WwanMetrics` and can be found in [wwan.go](../pkg/pillar/types/wwan.go).
 
 The endpoint returns a list of entries, one for every cellular modem, with the modem's
 logical label (from the device model) used as a reference. Just like in the

docs/EDGEVIEW-CONTAINER-API.md

@@ -1,10 +1,10 @@
 # Edge-View Container and APIs
 
-EVE provides the Edge-View mainly for device and application troubleshooting tasks. It is a system-level container similar to `newlogd`, `wwan`, etc.
+EVE provides the Edge-View mainly for device and application troubleshooting tasks. It is a system-level container similar to `newlogd`, `wlan`, etc.
 
 Edge-View as a service on EVE, it needs to receive/update user configurations from the controller; and it needs to send/update Edge-View running status to the controller.
 
-The software integration level of Edge-View is somewhere between the services like `newlogd` and `wwan`. `newlogd` is an integral part of the EVE, while `wwan` is a generic Linux service without any specific EVE related changes. The Edge-View container runs on the EVE device and has many tasks designed specifically for EVE device and application usage, but it can also run as a normal Linux docker container on any host; the same container is used for Edge-View client runs on the user's laptop. Thus design of Edge-View container tries to minimize the interaction with the rest of the EVE system while still being configured from the controller and sending status to the controller.
+The software integration level of Edge-View is somewhere between the services like `newlogd` and `wlan`. `newlogd` is an integral part of the EVE, while `wlan` is a generic Linux service without any specific EVE related changes. The Edge-View container runs on the EVE device and has many tasks designed specifically for EVE device and application usage, but it can also run as a normal Linux docker container on any host; the same container is used for Edge-View client runs on the user's laptop. Thus design of Edge-View container tries to minimize the interaction with the rest of the EVE system while still being configured from the controller and sending status to the controller.
 
 This Wiki page describes the provisioning, security and status update for Edge-View in [Edge-View Doc](https://wiki.lfedge.org/display/EVE/Edge-View).
 

docs/HARDWARE-MODEL.md

@@ -61,7 +61,7 @@ Starting from the generated model file and add or adjust:
 - Optionally, if the intended application pre-determined and e.g., eth1 will be connected to the shopfloor network, you can set the logicallabel field to "shopfloor". That makes it more clear in the UI the intended use of that port.
 - If the model file shows multiple USB controllers, then plug in e.g., a USB stick in each physical USB port and use ```lsusb``` and ```lspci``` to tell which controller to which port is connected.
 - If the device has multiple physical USB ports, please add a entry for each one of them in the json file (on the correct USB controller if there are multiple)
-- If you device has a cellular modem verify that there is one or two wwan interfaces in the generated file, and if not add one. If it is connected via a USB controller (```lsusb``` will tell you that) it needs to be in the same assignment group as the USB controller.
+- If your device has a cellular modem, verify that the PCI and USB addresses recognized by spec.sh are actually correct. The script will make sure that modem connected over USB bus will be in the same assignment group as the USB controller itself.
 - If some controllers have an empty assignment group there might be an issue with an unknown controller/function. The ```-v``` option to the script can be used to get more information about such unknown controllers/functions.
 
 #### Check for unknown controllers/functions

docs/SECURITY.md

@@ -158,6 +158,10 @@ Two ECOs communicating using the overlay will get an secure channel since LISP w
 
 In addition, the LISP map server can provide ability to limit access to the mappings for certain EIDs based on the EID which is trying to look them up.
 
+## Disabling Remote Access
+
+EVE provides a mechanism to build an image with remote access disabled (edge-view and ssh), this can be done by configuring EVE when building an installer. Enabling remote access back requires access to the cloud controller to enable console keyboard access on the edge node, plus physical access to the edge node to issue `eve remote-access` command on the edge node. In addition changing remote access status from its initial value to anything else will result in change of PCR-14 value and subsequent failure in unsealing the vault key that needs to be handled using the cloud controller. Check [config document](CONFIG.md#eve-configuration) for more information.
+
 ## Details on keys and certificates
 
 These details are specified in [KEYS-AND-CERTS](KEYS-AND-CERTS.md).