connman_curses doesn't make clear which wireless interface is using when two or more wireless interfaces are available

[alan-mushi]

Hello,

Recently I've started using connman_curses with two wireless interfaces simultaneously and I've found some confusing behaviors (they may be only confusing to me). I'll open a ticket per issue and you'll see if it's a real problem or not =). The first one is, when two or more wireless interfaces are available (it may be applicable to other technologies) connman_curses doesn't make clear which interface is using.

Testcase

1. Make available two or more wireless interfaces to the system
2. Disconnect from all wireless networks
3. Launch connman_curses
4. Select the wifi technology
   • connman_curses shows repeated some APs and doesn't specify which interface detects which AP and therefore I have no way to select conscientiously which interface connects to a specific AP.

In the above image some AP essids are repeated, eg. INFINITUMl8p4 , not all of them are repeated because one of the wireless interfaces is more sensitive than the other.

Expected behavior

I think connman_curses should state which wireless interface is detecting which AP or should list only once every AP detected if no specification is displayed, in that case it should use the interface with better range detection by default.

[alan-mushi]

Hi,

Again, see #6, it's more connman's job: connman status signals (used to update/display the services/AP list) don't include which interface detected the AP.
Seeing the AP twice is absolutely normal : connman don't group services on any criteria.

[pfl]

Take a look at the 'Ethernet' property in the ConnMan service API to distinguish between devices/MAC addresses.

[pfl]

BTW, the string 'psk' actually means WPA/WPA2 in plaintext.

[jobol]

@pfl thank you for the hint! finding that wifi's interface is in the ethernet field is not obvious for sure. experts are very welcome.

[alan-mushi]

Will something like this do ? The preposterously long eSSID will be truncated (it can be 32 chars in the standard but we have to reduce it to 23 chars to make it fit on the smallest screen resolution).

I can't test nor show this with multiple interfaces because I only have one...

[javier-lopez]

From my point of view it's enough =). I couldn't stop however noticing the blank spaces in the signal strength field, would make sense to take the required chars from that field so the essid field can display the whole names? The state field has a good amount of empty spaces too.

I can help testing multiple interfaces (is there a branch from where to pull these modifications?)

Thanks for your continue support.

[alan-mushi]

the blank spaces in the signal strength field

Yes I can steal some spaces there by renaming "Signal strength" to "Signal" so the alignment is kept.

The state field has a good amount of empty spaces too.

We can't touch these ones, the state string can be quite long connman doc.

I can help testing multiple interfaces (is there a branch from where to pull these modifications?)

Thanks ! I will put them there alan-mushi/connman-json-client branch issue5.

[javier-lopez]

Awesome, this is how it looks in my setup. It seems like the security field is talking a little bit more space that what it should but besides that, it works =). Thanks!

[jobol]

I agree that security field is much cryptic

[alan-mushi]

Yes I agree (there was a reserve/note in the commit about this), We can "gain" 4 char by removing [ and the symmetric.
@chilicuil I pushed this modification and my nearby networks don't have multiple entries for the security array, could you try and post the picture please ?

[javier-lopez]

Now it's aligned quite fine =). Thanks!

[alan-mushi]

@jobol Is there a problem with this PR ? If it's about the length of the "security" field I might be able to glean some characters here and there but in the end the minimal screen resolution is fairly small.