Lan.status() show the state of the previous connection

I’m using a portenta with a vison shield with ethernet module.
I’m a bit confuse with the lan.status()
It suppose to show the status of the lan interface:

0: Link Down
1: Link Join
2: Link No-IP
3: Link Up
It’s actually show the status of the previous lan connection.
If i connect the lan cable and connect to the network it show 0 but i got an ip adress from my dhcp.
then If i disconnect the lan cable it show 3 but i have a timeout error (which is expected.)
There is no deinit() function like the wlan.
My goal is to check if there is a cable connected to the ethernet module and if not to fall back on the wifi connection.
I could wait for the timeout with try: error: but i would prefer to check the status of the lan and act accordingly.
Am i doing something wrong ?

No, it’s just new code that’s not well debugged.


I definitely don’t see this issue, with the cable connected I get 2 before DHCP, and then 3 after an IP as expected, I tried it a few times. If the link status is stuck from last connection you could try active(False) before active(True)…The only issue I see is there’s no way to check for link status before actuve(True) which times out if there’s no link, you’re just going to have to handle the exception.

Thanks for your reply.
So i can’t use lan.status() prior the
Which is useless to detect the presence of the cable.
I can deal with the exception but i will have to wait for the timeout of the to fall back to the wifi which increase considerably the network connection time.
Why do we need to have a cable connected to activate the lan? It doesn’t make sense in network point of view. I can have an activated network interface without cable and connect the cable only when needed ( at least in C++).
do you think the micropython firmware will have future improvement regarding this issue ?

I don’t know and yes I agree it doesn’t make sense, but again you’re asking in the wrong place these are standard Micropython drivers (for WLAN and LAN) we use them as they are without any changes. You should ask them about it on their forums or github:

If something gets fixed it will be automatically fixed in our firmware when we update Micropython.

Sorry but I’m discovering micro python through openmv, not by choice but by customer requirement. i’m a C++ developer and try to do my best with the very steep learning curve of openmv and micropython. Lot of ref in micropython doc say “depend on which port your are working with” some function available in mycropython are not available in openmv. how can i guess ?

Hi, if you can compile the C code then you can just change this behavior. The firmware guide is here:

Once you have the ability to compile the PORTENA firmware with “make TARGET=PORTENTA” then you can just edit the file in question:

Which is called from:

Apologizes for the steep learning curve. We didn’t design that to be the case. It’s more of that the product is just missing features people want since it’s new.

Hi, thanks for your reply.
i’m dealing with portenta and multiple OpnMVh7 camera for this project and don’t want to tailor firmware for the 2 different hardware because of time development constrain that’s why i prefer to ask to the community and then turn around the problem by using the state of the art of your firmware which i understand (no problem with that) is in constant evolution.
The steep learning curve is because of my lack of skills in pyhton and micropython more than your product :slight_smile:

I see. Well, if you look at the code being called it’s pretty straight forwards in behavior. I can’t see any clear error with it.

I guess the netip struct is not getting zeroed on lab disconnect. I don’t know though it’d that’s a feature of the Ethernet PHY to detect that and interrupt the main CPU.

We enable all the features available in the stm32 port (which is the port you’re using) and we add extra built-in drivers, libraries and modules plus all the OpenMV specific modules (image library, drivers, tensorflow, image sensors etc…). The Micropython documentation (on which we base our own docs) does Not specify which functions or arguments are available for which ports, or how they differ between ports, but if something is not available in the stm32 port you’ll get an exception when calling it.

This doesn’t look right, the link status register is 1, registers 0 and 16 are not relevant… I’m not sure if there’s a reason it’s done like that, but could be a bug will report it upstream. However, you still need to activate the lan to read any registers.

@marcoind I’ll be able to fix this issue for you in the next release.

Thanks so much.
I’ll try it as soon it’s available.