Is anyone working on the IP/SLIP project?

[GalenHZ]

One of the tasks listed in https://github.com/micropython/micropython/issues/1331 is to "add a TCP/IP stack with SLIP support." I've been looking at the problem, and was wondering if anyone else had already started on this.

[pfalcon]

I'd say you can assume nobody works on it yet. Note that it's listed in "advanced tasks" list, I'd suggest trying something simpler first. For that task, you'd need to do a bunch of design, not just coding work.

[dhylands]

I looked at doing it as a basis for rshell, but eventually decided against it as it wasn't well supported on Windows and Mac. It seems to fairly trivial to implement the actual SLIP packet level stuff.

I also found some PPP implementations, which would allow use with Windows/Mac/Linux, but PPP is quite bit heavier.

[pfalcon]

Yes, so the big question here is not IP-over-serial encapsulation, but selecting a good base TCP/IP stack implementation. A single one likely won't work for all cases. But after that, SLIP is the first thing to try that stack with, because indeed, SLIP implementation is trivial. Anything else, including considering PPP, comes after that. It's indeed not a small endeavor to implement both TCP/IP and PPP in one chunk of work, but if we had "standard" TCP/IP implementation in uPy, adding PPP and all the other advanced things would be next natural step(s).

[GalenHZ]

Starting with something simple makes sense; I'm doing a base64 implmentation for ubinascii, since it's the first thing on the "easy" list.

When it comes to the TCP/IP stack, I started looking at lwip. The "nice" API was designed to work as a thread in a multithreaded environment, which stmhal isn't. The raw API is implemented with callbacks, and might be possible to integrate as a library called directly by network drivers like SLIP/PPP/Ethernet. It may need a timer dedicated to it, but a first glance suggests it could work.

The real reason I asked is that I'm going to try to enable the Ethernet MAC on my Discovery board eventually, and it's of limited use without TCP/IP.

[pfalcon]

When it comes to the TCP/IP stack, I started looking at lwip.

That's reasonable choice. I'd say, good choices are lwIP and uIP from the same author (Adam Dunkels). We usually try to select the smallest thing by default for MicroPython, and that means uIP.
But I guess in this case exception for lwIP is warranted, as it gives programming/networking model closer to BSD sockets, promises better I/O performance, and we already have ports which use it (esp8266), so may enjoy reuse and collaboration. Then, uIP support can be left to those who really need truly minimal implementation .

The "nice" API was designed to work as a thread in a multithreaded environment, which stmhal isn't. The raw API is implemented with callbacks, and might be possible to integrate as a library called directly by network drivers like SLIP/PPP/Ethernet. It may need a timer dedicated to it, but a first glance suggests it could work.

I suggest targetting raw API. It definitely needs a timer, but that's all - no more bloat to bring in . And I had some ideas how to get more nice API on Python level - they should be mentioned in esp8266 tickets on github.

The real reason I asked is that I'm going to try to enable the Ethernet MAC on my Discovery board eventually, and it's of limited use without TCP/IP.

That's nice usecase, thanks for coming forward with this, and base64 patch already in works.

[GalenHZ]

I've been busy with other projects, but things have been coming along; I've at least gotten lwIP to compile, even if it can't actually do anything useful yet. I'm working on this in tandem with the ethernet hardware for the Discovery board.

My original plan was to have a static network.lwIP object whose only purpose was to be initialized and get a timer attached. This wouldn't go into the mod_network_nic_list; instead, you'd create objects like network.Ethernet or network.PPP, and these would register with the network mod, using lwip as a back-end "shared library" of sorts.

But now I think it makes more sense to do this the other way around. network.lwIP would register itself as a "nic", export the required socket functions, and objects like pyb.Ethernet or network.PPP would simply register with lwIP's backend, and the socket module would never directly interact with them.

I'm not familiar with the reasons the socket architecture works the way it does, so before I jump to any conclusions I wanted to see what other people had to say.

[dhylands]

A bound socket (when using TCP) represents a connection between 2 IP addresses. One of them will be one of your local IP addresses (you would have 2 IP addresses if you had 2 NICs), and one is for a given remote.

So if there are multiple clients connected to the pyboard running as a server, then each client will be associated with a different socket. Similarly, if the pyboard is connected as a client to a server, it will have a socket for each server port that its connected to.

[pfalcon]

GalenHZ, that's why original task is formulated as "Add TCP/IP stack with SLIP support." That's universally useful and more or less clear how to do. Once that is done, it will give insight and ideas how to generalize that to other "hardware".

[GalenHZ]

Since it's been a while since I've posted, I'll give a quick status update.

Free time to work on this project has been hard to come by, but I've at least made a little progress, committed into a branch called lwip-prototype. I'm not going to offer this for merging, it's just to hold my work. Once I've got something reasonable I'll create a new branch for the pull request.

https://github.com/galenhz/micropython/ ... -prototype

Right now, it only supports UDP, and only in simple blocking mode, but you can use send(to)/recv(from) to do simple ping-style tests. If you're crazy enough to try running it, you'll need to execute something like this on the board side:

Code: Select all

import pyb
import network
network.LWIP().start()
if = network.SLIP(pyb.UART(2, 57600, recv_buf_len=1550), "192.168.5.2", "192.168.5.1")

Then connect a linux system to the other end. I use a little FTDI board to connect to UART 2, and set it up as follows:

Code: Select all

slattach -L -p slip -s 57600 /dev/ttyUSB0 &
ifconfig sl0 192.168.5.1 pointopoint 192.168.5.2 mtu 1500

There's a lot of work that still needs to be done, besides the obvious:

• It lays claim to a chunk of RAM at compile time for it's own (interrupt-safe) memory handling; it probably grabs significantly more than it would really need, but I want to get a complete implementation before I start playing games with the default settings.
• Input is handled through a simple poll done when recv is called. I'm going to need to implement a timer callback for TCP support anyway; it makes more sense to do the polling on a regular interval, since it allows other functions (like ping responses) to work even when sockets aren't being played with.
• The SLIP object is singular. The reason for this is because of irritating limitations in the serial I/O callbacks used by the netif/slip code in lwip. I could potentially make it possible to have multiple SLIP interfaces by simply copying the code from lwip into the micropython module and altering it to fit. I may do that anyway, even if the SLIP object stays singular, because...
• The SLIP interface with the UART module is inefficient. It would make more sense to have the UART receive interrupt copy data directly into the pbuf instead of going through an intermediary buffer in the heap. Doing that would require some work on the UART module, though.

Next steps will be adding timeout support and non-blocking mode, then DNS, then TCP.