intrig-unicamp / mininet-wifi

Emulator for Software-Defined Wireless Networks
https://mn-wifi.readthedocs.io/
Other
438 stars 239 forks source link

wlan interfaces UP but not RUNNING (sometimes) #323

Closed asljivo1 closed 2 years ago

asljivo1 commented 4 years ago

Hi,

I have a network based on adhoc.py example (pretty much the same as adhoc.py, only 2 TCLinks extra are added between the 3 nodes). Out of 3 nodes, one or two show UP, BROADCAST, RUNNING, MULTICAST flags on their wireless interfaces, the remaining nodes do not show the RUNNING flag (they do show the other 3 flags). The flags change between runs randomly (or at least it appears to me that way), but all three never show the RUNNING flag in the same run. I want to set up IPv6 networking and for those nodes whose interfaces are not RUNNING, they are unreachable - they do not have link local IPv6, although they are reachable via IPv4. How do I make sure all wireless interfaces are RUNNING in mininet so that I can have fully functional IPv6 network?

ramonfontes commented 4 years ago

What would you do in the real world to make sure that all wireless interfaces are RUNNING? :) By the way, are you arguing that the network interfaces are unreachable due to the lack of the RUNNING flag?

asljivo1 commented 4 years ago

I would make sure the interface is operational and that the link exists, and that the routes exist I suppose. Regarding the existance of the RUNNING flag, it's probably the other way around: they are unreachable, hence there is no RUNNING flag? But if there was a RUNNING flag everything would be ok-which is why I formulated question like that. Wireless link does exist though (IPv4 works and iw dev <dev> link shows the link). ip -6 route show returns

aaaa::/64 dev sta2-wlan0 proto kernel metric 256 linkdown pref medium
fe80::/64 dev sta2-eth2 proto kernel metric 256 pref medium

ip addr show indicates mq state DORMANT. Link local ipv6 address is not assigned to the dormant node. This seems to be a dummy question but I don't understand why this behaviour occurs sporadically in my emulated network, nor how to avoid it. I would very much appreciate your help.

ramonfontes commented 4 years ago

It's not clear to me how those flags work with nl80211. While I can see some random changes in scenarios without authentication e.g. sudo mn --wifi, authentication.py seems to work fine. Weird..

However, adhoc.py still works without the RUNNING flag. Which routing protocol are you using?

asljivo1 commented 4 years ago

Normally I don't specify it, so whichever is the default one. I did try all four listed in adhoc.py, but the issue persists with all of them.
I did see this entry which is in line with your finding that authentication.py works fine. For now, I will use authentication.py as a baseline and keep an eye out for the cases without authentication. Thank you!

ramonfontes commented 2 years ago

Closing due to inactivity