Skip to content

Commit

Permalink
lwip-notes updated
Browse files Browse the repository at this point in the history
  • Loading branch information
@rgrr
rgrr committed Jun 26, 2023
1 parent 2b2c4f3 commit 8b2c69d
Showing 1 changed file with 70 additions and 43 deletions.
113 changes: 70 additions & 43 deletions doc/lwIP-notes.adoc
View file
Original file line number Diff line number Diff line change
Expand Up @@ -13,55 +13,69 @@ an uncountable number of additional CDC com ports. +
Currently just a Segger SysView server is listening on port 19111.
But I guess there is more to come.


## Pitfalls

lwIP had some traps waiting for me. Despite reading the official
https://www.nongnu.org/lwip/2_1_x/pitfalls.html[Common Pitfalls]
I took some of them.


MAC:: Do not use a random MAC! At least not for the first byte.
I was "lucky" choosing one with an odd first byte. Unfortunately
bit 0 marks a group address. At least Linux rejects such MAC
addresses with a more or less useless error message in the syslog.
Took a while until I found out that the MAC address was the culprit
for no communication. +
Finally I have used 0xfe as the first byte and the remaining five
bytes of the MAC address are copied from the last bytes of Picos serial number
(which actually is the serial number of the external flash).

OS Mode:: *really* take it serious what they are writing about "raw" APIs
and only using the TCPIP thread for any calls to it. +
Use `tcpip_callback_with_block(<func>, <void-arg>, 0)` for
non-blocking invocations of some function. This also saves you
from creating extra simple threads for communication tasks line
in the TineUSB/lwIP glue code. That was my first idea and it took
a while until I found out how bad that idea was. +
Same was true for the thread(!) which stuffed data for SysView into
it's server: bad idea! +
Effect of wrong API handling were random crashes or connection
disruptions.
### MAC

Do not use a random MAC! At least not for the first byte.
I was "lucky" choosing one with an odd first byte. Unfortunately
bit 0 marks a group address. At least Linux rejects such MAC
addresses with a more or less useless error message in the syslog.
Took a while until I found out that the MAC address was the culprit
for no communication. +
Finally I have used 0xfe as the first byte and the remaining five
bytes of the MAC address are copied from the last bytes of Picos serial number
(which actually is the serial number of the external flash).

RNDIS/ECM/NCM::
To be honest, I'm very confused about the system behaviour of RNDIS/ECM/NCM.
Sometimes the host gets "disconnected", because the DNS in `/etc/resolv.conf`
are changed, sometimes not. Sometimes the probe needs `dhclient` to get
the TCP/IP connection, sometimes not. Sometimes the probe has an IPv6 address, sometimes
not. And this all just on my Linux host. Interoperation with Windows
makes things even worse. +
And `/etc/network/interfaces` generates error
messages even when the device has `allow-hotplug`. +
* *RNDIS*: this was my former favorite, because it is supported by all
relevant OSs. Also throughput seemed to be good.
Unfortunately RNDIS seems to manipulate routing in a way that the
default route on my Linux wants to go through the probe. Not
really what I want...
* *NCM*: is said to be the best choice. I did not manage to get an
acceptable throughput. Transfer seems to get stuck from time to time
and SystemView aborts. So also not the favorite.
* *ECM*: works good, packets are transferred continuously, throughput
also seems to be ok. So this is the way to go. +
Unfortunately there is no driver integrated into Win10, so possible
extra trouble appears. Yes... extra trouble: cannot find a driver
for Win10.
### OS Mode

*really* take it serious what they are writing about "raw" APIs
and only using the TCPIP thread for any calls to it. +
Use `tcpip_callback_with_block(<func>, <void-arg>, 0)` for
non-blocking invocations of some function. This also saves you
from creating extra simple threads for communication tasks line
in the TineUSB/lwIP glue code. That was my first idea and it took
a while until I found out how bad that idea was. +
Same was true for the thread(!) which stuffed data for SysView into
it's server: bad idea! +
Effect of wrong API handling were random crashes or connection
disruptions.


### RNDIS/ECM/NCM

To be honest, I'm very confused about the system behaviour of RNDIS/ECM/NCM.
Sometimes the host gets "disconnected", because the DNS in `/etc/resolv.conf`
are changed, sometimes not. Sometimes the probe needs `dhclient` to get
the TCP/IP connection, sometimes not. Sometimes the probe has an IPv6 address, sometimes
not. And this all just on my Linux host. Interoperation with Windows
makes things even worse. +
And `/etc/network/interfaces` generates error
messages even when the device has `allow-hotplug`.

* *RNDIS*: this was my former favorite, because it is supported by all
relevant OSs. Also throughput seemed to be good.
Unfortunately RNDIS seems to manipulate routing in a way that the
default route on my Linux wants to go through the probe. Not
really what I want...
* *NCM*: is said to be the best choice. I did not manage to get an
acceptable throughput. Transfer seems to get stuck from time to time
and SystemView aborts. So also not the favorite. +
`iperf` is running fast, it seems that `ncm_device.c` output is triggered
by incoming packets.
* *ECM*: works good, packets are transferred continuously, throughput
also seems to be ok. So this is the way to go. +
Unfortunately there is no driver integrated into Win10, so possible
extra trouble appears. Yes... extra trouble: cannot find a driver
for Win10.
[NOTE]
====
Expand All @@ -72,8 +86,21 @@ This is not a fault of lwIP, it is a bug in the Win10 driver(?).
====


## Performance

To measure performance, `iperf` is used (which implies, that `OPT_NET_IPERF_SERVER`
must be set on built). Good command line for measurement:

iperf -c 192.168.14.1 -e -i 1 -l 1024


## Log

### 2023-06-26

* after some changes to `rtt_console.c`, `net_sysview.c` and `net_glue.c`
ECM is working again as expected

### 2023-05-12

* for unknown reasons the probe is even with ECM in stutter mode, don't know
Expand Down

0 comments on commit 8b2c69d

Please sign in to comment.