Might not be that important.

Hostname to IP could be done by extracting the IP from the connect message when conneting directly to a URL
Blocking issue BlackbirdHQ/atat#69.

• Offer hotspot from module

Connecting the device to a wifi network.

UDP error handeling creates orphan sockets when using an invalid socket handle with the connect() method.
Orphan sockets live in the modem, but the driver does not know of them.

• Receive certificates and keys and load into module
• Implementing a TLS trait for upgrading sockets

There are a few chores to be fixed before we can look into releasing a 0.1.0 version of this to crates.io

• Readme
• Github Actions
• Repository description
• Repository topics
• Rid git dependencies
  • Bump embedded-nal to release version
• Merge feature/extended-data into master

The driver will stall if the WiFi module is not reset before starting the driver.
Since the driver utilizes defmt as the logging framework it is not possible to get logs out without resetting the processor. Which in my application also resets the WiFi module. Meaning there is no logs for the issue.

Relevant links:

• https://github.com/u-blox/extended-data-mode-example-application-py/blob/b2cffee087987b69c81a0e88e7d7ea5aac33b3d8/edm.py#L139
• https://www.u-blox.com/sites/default/files/ExtendedDataMode_ProtocolSpec_%28UBX-14044126%29.pdf

self.send_at(Ping {
    hostname: hostname,
    retry_num: 1,
})?;
while self.dns_state.get() == DNSState::Resolving {
    self.spin()?;
}

If there is no response, the program will loop indefinitely

Reset does not reset the AT client or the sockets nor does it include resetting the various states in the driver.

Closing a peer after creation before connection is established, is not registered correctly.
Since having two connections to the same socket address is not allowed the module throws an error if a reconnection is tried.

This should not be possible, as connect should be blocking, but #30 makes this possible. So it might be classified as a symptom of another bug.

161351 DEBUG [TCP] Opening socket
161352 DEBUG Adding socket! 0 Tcp
161352 DEBUG [TCP] Connect socket
161371 DEBUG Sending command with too long payload (80 bytes) to log! (Connect)
161391 DEBUG [Handle(0)] TCP state change: State::Created -> State::WaitingForConnect
161391 DEBUG [Handle(0)] Updating handle Handle(4)
161391 TRACE [TCP] Connecting socket: Handle(4) to url: tcp://34.253.44.78:8883/?ca=root_ca&cert=cert&privKey=priv_key
161392 DEBUG Network connected!
161392 INFO  MQTT connecting..
161394 ERROR [send] NetworkError::Write
161394 DEBUG Disconnecting!
161394 DEBUG [TCP] Closing socket: Handle(4)	(Close is not registered by module)
161394 DEBUG Removing socket! 4 Some(Tcp)
161412 DEBUG Sending command with too long payload (67 bytes) to log! (DNS)
161443 TRACE [EDM_URC] IPv4ConnectEvent! Channel_id: ChannelId(4)	(Peer now connected at modem)
161443 TRACE [EDM_MAP] Handle(4) tied to ChannelId(4)
161443 DEBUG [Handle(4)] TCP state change: State::WaitingForConnect -> State::Connected
161444 TRACE [URC] PeerConnected
161474 TRACE [URC] PingResponse
161474 DEBUG [TCP] Opening socket
161475 DEBUG Adding socket! 0 Tcp
161476 DEBUG [TCP] Connect socket
161494 DEBUG Sending command with too long payload (80 bytes) to log! (Connect to same IP again)
161514 TRACE Digest ReceivingResponse / b"\xaa\x00\x0b\x00E\r\nERROR\r\nU"
161514 ERROR Received error response InvalidResponse
161515 ERROR InvalidResponse: b"\xaa\x00L\x00DAT+UDCP=\"tcp://34.253.44.78:8883/?ca=root_ca&cert=cert&privKey=priv_key\"\r\nU"

Solution

Block untill state changes?
This could cause other issues, as it will cause a stall if the socket ends in this state by mistake.

This looks like a great crate. I would love to use it with the Arduino Nano 33 IoT. The arduino_nano33iot crate (version 0.7.0) uses embedded-hal ^0.2. Is there a way to make this crate compatible? E.g. with https://github.com/ryankurte/embedded-hal-compat

I can't seem to figure out how to do this. Help would be much appreciated. This is my list of dependencies:

arduino_nano33iot = { version = "0.7.0", features = ["usb"] }
atsamd-hal = { version = "0.14", features = ["usb", "unproven"] }
cortex-m = "0.7"
cortex-m-rtic = "1"
embedded-hal = "0.2"
panic-semihosting = "0.6"
systick-monotonic = "1"
usb-device = "0.2"
usbd-serial = "0.1"

The libreary uses peer handles as socket handles, this causes major issues.
The module reuses peer handles imediatly after closing them, often only twice before incrementing for some reason.
Sockets are always closed by reciving a EDM_URC disconnect event. This causes all closes to be through ShutdownForWrite.
This means even if a socket is closed, it will excist in the set untill the timeout is reached(15 sek). If a new socket is created and connected, you will have 2 with the same handle. This causes a close to only change the first(old) one, leaving the second(new) one in the state Connected or WaitingForConnection in the socketset.
This also causes crossover during connection, as the state of the old socket is read, and connect is exited before an EDM_URC has arrived

An example is shown below:

110889 DEBUG [TCP] Opening socket
110890 DEBUG Adding socket! 0 Tcp
110890 DEBUG [Socket Set] Adding to: [(Handle(2), Tcp(State::ShutdownForWrite))]
110890 DEBUG [TCP] Connect socket
110909 DEBUG Sending command with too long payload (81 bytes) to log! #(Connection attempt)
110939 DEBUG [Handle(0)] TCP state change: State::Created -> State::WaitingForConnect
110939 DEBUG [Handle(0)] Updating handle Handle(2)
110939 TRACE [TCP] Connecting socket: Handle(2) to url: tcp://54.194.121.54:8883/?ca=root_ca&cert=cert&privKey=priv_key
110939 DEBUG Network connected!
110939 INFO  MQTT connecting..
110942 ERROR [send] NetworkError::Write
110942 DEBUG Disconnecting!
110942 DEBUG [TCP] Closing socket: Handle(2)
110942 DEBUG Removing socket! 2 Some(Tcp)
110959 DEBUG Sending command with too long payload (67 bytes) to log! #(DNS)
110980 TRACE [EDM_URC] IPv4ConnectEvent! Channel_id: ChannelId(2)
110980 TRACE [EDM_MAP] Handle(2) tied to ChannelId(2)
110980 DEBUG [Handle(2)] TCP state change: State::WaitingForConnect -> State::Connected
110980 TRACE [URC] PeerConnected
111021 TRACE [URC] PingResponse
111021 DEBUG [TCP] Opening socket
111022 DEBUG Adding socket! 0 Tcp
111022 DEBUG [Socket Set] Adding to: [(Handle(2), Tcp(State::Connected))]

As it requires one empty space in the set, it can never lock the set, as it will leave one open space.

This is recreatable by creating a connection to anywhere, closing it, and creating a connection to the same place again.

Solution

Decouble Peer handles and socket handles, in the same way peer handle and channel id is set up.

Alternative

Close any sockets with the same peer handle, as they do not match the modem state anymore. This is quite an easy fix.

• Open ports to the network
• Send data to connected device
• Handle incoming data
• Test capability to offer service over hotspot

• Serialization and deserialization for AT commands in EDM context
• Serialization and deserialization for AT URCs in EDM context
• Serialization and deserialization for EDM Events
• Serialization and deserialization for EDM specific commands

Only one unconnected socket can exist in the socket set at any one time. Since the socket set checks for dublicate socket handles.

Example:

161642 DEBUG [TCP] Opening socket
161643 DEBUG Adding socket! 0 Tcp
161643 DEBUG [Socket Set] Adding to: [(Handle(0), Tcp(State::Created)), (Handle(2), Tcp(State::Connected)), (Handle(4), Tcp(State::Connected))]
161644 ERROR [TCP] Opening socket Error: DuplicateSocket

Solution

Decouble Peer handles and socket handles, in the same way peer handle and channel id is set up.

Alternative

Create increasing "first" socket handles. This is quite an easy fix. Great care should be taken as to not overlap with the peer handles gotten back from the modem.
Another way would be eliminating the need for actually allocating anything upon creation of the socket, but then the "right of way" is moved onto the client connecting their socket first.

It would be nice if we could add some kind of connections manager around the config slots in UWSC.

It should be able to do basics of:

• Add, list, modify & delete stored wifi connections (All parameters of UWSC)
• Activate & deactivate stored wifi connections (UWSCA)
• Rank known connections to return best available connection (See https://askubuntu.com/questions/1348220/how-does-networkmanager-choose-which-wifi-network-to-connect-to-when-muliple-are & https://github.com/digsrc/wpa_supplicant/blob/515eb37dd1df3f4a05fc2a31c265db6358301988/wpa_supplicant/scan.c#L1658 for inspiration on how this is handled in wpa_supplicant)

• Handeling custom digest functions BlackbirdHQ/atat#70
• Changing traits to handle commands without responses. Might shove into own pull req. BlackbirdHQ/atat#70
• Expand with missing datatypes (CharVec catchall) BlackbirdHQ/atat#68

Currently the hostname of the device will be set to "odin-w2-xxxxxxxxxxxx" where "xxxxxxxxxxxx" is a device-specific number.

It should be possible to set a desired hostname during the client instantiation.

Relevant:
10.1 Network host name +UNHN

https://www.u-blox.com/sites/default/files/u-connect-ATCommands-Manual_%28UBX-14044127%29.pdf

• heapless v0.7.0

Changes from generic_array to const generics
Example:

impl<C, N, L> Dns for UbloxClient<C, N, L>
where
    C: atat::AtatClient,
    N: ArrayLength<Option<crate::sockets::SocketSetItem<L>>>,
    L: ArrayLength<u8>,
{

becomes:

impl<C, const N: usize, const L: usize> Dns for UbloxClient<C, N, L>
where
    C: atat::AtatClient
{

• embedded-nal v0.6.0

Drops the requirement of interior mutability (RefCell & Cell)

no-std-net dependency can be dropped, as those are re-exported by embedded-nal, thus not requiring us to version match the two on upgrades.

• atat v0.11.0

No big changes worth mentioning

• embedded-time v0.11.0

No changes

EDM data events can be 4KB in size as per specification.
This means the line defining DATA_PACKAGE_SIZE is wrong.

With the current way of buffering data this means ATAT needs to be required to allocate multiples times this size.. For it to function properly.

Not configuring this size of buffer would will stall the driver.