🔭 uMWC setup tips and tricks

[shankari]

This issue will document tips and tricks for working with the uMWC, including instructions for copying logs, configuring with various network configurations, cross-compiling and debugging with the UI before we plug in to a car

[shankari]

Copying logs

• Basic everest logs are in: /tmp/everest-logs/

  • The uMWC is also configured with a packet sniffer, which stores logs in the same location, with the name ethernet-traffic.dump
  • Make sure to copy out the logs before unplugging the uWMC since /tmp is cleared on unplug

• Basic OCPP logs are in /tmp/everest_ocpp_logs

[shankari]

Changing configuration

• Default install from the initial build:

  • service definition is at /usr/lib/systemd/system/everest.service
  • That is where you need to set the environment variables and command line arguments (if any)
  • Note that you need to run systemctl daemon-reload after making changes to the service definition

• Default OCPP configuration:

  • vim /usr/share/everest/modules/OCPP201/component_config/standardized/InternalCtrlr.json
  • rm /usr/share/everest/modules/OCPP201/device_model_storage.db

• To see real-time logs

  • journalctl -u everest.service -f

• Cross-compiled install:

  • no service definition, run the manager directly with /var/everest/bin/manager --conf /etc/everest/config-cec.yaml
  • environment variables can be defined directly in the shell
  • OCPP configuration
    • vim /var/everest/share/everest/modules/OCPP201/component_config/standardized/InternalCtrlr.json
    • rm /var/everest/share/everest/modules/OCPP201/device_model_storage.db

[shankari]

Debugging using the UI

We typically configure the manager to connect to the MQTT server running on my laptop. This makes it easier for see the current operation of the system using MQTT explorer. This should also make it possible for us to test against the uMWC from the UI before we plug it into a car.

Alas, this won't work because the EvseManager is connected to a BSP that expects the connection to come from hardware, not from the simulator. Let's see if we can run with one of the simulated configs instead

Running with a simulated config fails with the following error since we did not include python and javascript layers in the yocto build. We cannot do this right now, and will need to postpone until later.

2025-01-29 06:19:39.664219 [INFO] evse_security:E  :: Module evse_security initialized [1547ms]
    from .everestpy import *
ModuleNotFoundError: No module named 'everest.framework.everestpy'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/var/everest/libexec/everest/modules/PyEvJosev/module.py", line 8, in <module>
    from everest.framework import Module, RuntimeSession, log
  File "/var/everest/lib/everest/everestpy/everest/framework/__init__.py", line 6, in <module>
    from everestpy import *
ModuleNotFoundError: No module named 'everestpy'

[shankari]

Networking options

• Connecting via ethernet: Super reliable, option to connect and reconfigure networking, but not very portable
• Connecting via hotspot: Pretty reliable with my phone, works well to connect to CSMS on laptop (configuring the OCPP URL in /usr/share/everest/modules/OCPP201/component_config/standardized/InternalCtrlr.json or /var/everest/share/everest/modules/OCPP201/component_config/standardized/InternalCtrlr.json above)
  • Does not work to connect to external CSMS because the current networking setup does not support connections to devices not also connected to the hotspot

Let's see if we can fix that.

The issue is that this is the default routing table. It configures 192.168.1.1 as the gateway although it does not exist.

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         0.0.0.0         255.255.255.255 UH    0      0        0 eth1
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 eth1
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 wlan0
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth1
172.20.10.0     0.0.0.0         255.255.255.240 U     0      0        0 wlan0
172.20.10.1     0.0.0.0         255.255.255.255 UH    0      0        0 wlan0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

The laptop is configured to 192.168.1.5 and both laptop and uMWC are on the same network with no router between them.

$ traceroute 192.168.1.100
traceroute to 192.168.1.100 (192.168.1.100), 64 hops max, 40 byte packets
 1  192.168.1.100 (192.168.1.100)  1.559 ms  0.513 ms  0.444 ms

We have several steps to try:

1. manually fix the configuration by using route or ip route
2. we also need to see why DHCP doesn't configure the hotspot as a router properly

Let's do (1) first and then work on (2)

[shankari]

1. After using commands like route del -net 0.0.0.0 gw 0.0.0.0 netmask 255.255.255.255 eth1, we get to remove a lot of entries.
2. The 169.254 subnet (as we may remember) is reserved for link-local addresses
3. route del -net default gw 192.168.1.1 netmask 0.0.0.0 wlan0 followed by route add default gw 172.20.10.1 wlan0 gives us a more palatable routing table

root@raspberrypi4:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.20.10.1     0.0.0.0         UG    0      0        0 wlan0
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 eth1
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth1
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0
172.20.10.0     0.0.0.0         255.255.255.240 U     0      0        0 wlan0
172.20.10.1     0.0.0.0         255.255.255.255 UH    0      0        0 wlan0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

We can now ping external IP addresses, but DNS still fails

Non-authoritative answer:
Name:	google.com
Address: 172.217.164.110

Non-authoritative answer:
Name:	nytimes.com
Address: 151.101.193.164
Name:	nytimes.com
Address: 151.101.65.164
Name:	nytimes.com
Address: 151.101.1.164
Name:	nytimes.com
Address: 151.101.129.164

# ping 172.217.164.110
PING 172.217.164.110 (172.217.164.110): 56 data bytes
64 bytes from 172.217.164.110: seq=0 ttl=113 time=695.490 ms
64 bytes from 172.217.164.110: seq=1 ttl=113 time=376.669 ms
64 bytes from 172.217.164.110: seq=2 ttl=113 time=55.679 ms
64 bytes from 172.217.164.110: seq=3 ttl=113 time=98.256 ms

# ping 151.101.1.164
PING 151.101.1.164 (151.101.1.164): 56 data bytes
64 bytes from 151.101.1.164: seq=0 ttl=54 time=47.880 ms
64 bytes from 151.101.1.164: seq=1 ttl=54 time=372.410 ms
64 bytes from 151.101.1.164: seq=2 ttl=54 time=1471.924 ms

root@raspberrypi4:~# ping nytimes.com
ping: bad address 'nytimes.com'
root@raspberrypi4:~# ping google.com
ping: bad address 'google.com'

We can probably get by with using IP addresses for testing, but let's see if we can set up DNS properly

[shankari]

# nslookup google.com
Server:    ::1
Address 1: ::1 localhost

nslookup: can't resolve 'google.com'

Grepping for ::1, we see that it is configured in /etc/resolv.conf and /etc/resolv-conf.connman, which are symlinks of each other. Adding our nameserver to the list as the first entry works!

# nslookup google.com
Server:    172.20.10.1
Address 1: 172.20.10.1 _gateway

Name:      google.com
Address 1: 2607:f8b0:4005:812::200e nuq04s45-in-x0e.1e100.net
Address 2: 142.251.46.206 nuq04s45-in-f14.1e100.net
root@raspberrypi4:~# ping google.com
PING google.com (142.251.46.206): 56 data bytes
64 bytes from 142.251.46.206: seq=0 ttl=112 time=510.353 ms
64 bytes from 142.251.46.206: seq=1 ttl=112 time=95.593 ms
64 bytes from 142.251.46.206: seq=2 ttl=112 time=67.529 ms
^C
--- google.com ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 67.529/224.491/510.353 ms

[shankari]

Networking hotspot + external CSMS manual workaround

Still need investigation into why hotspot didnt configure the Gateway and DNS properly in the first place (@catarial)
But this will unblock us for tomorrow

• Fix routes

  • route del -net default gw 192.168.1.1 netmask 0.0.0.0 wlan0
  • route add default gw 172.20.10.1 wlan0

• Fix DNS

  • vim /etc/resolv.conf