Ticket #771 (closed: fixed)

Opened 9 years ago

Last modified 6 years ago

Hkratno delovanje kot AP in ad-hoc

Reported by: mitar Owned by: kostko
Priority: major Milestone: 3.0b
Component: firmware Version:
Keywords: Cc: domen
Related nodes: Realization state:
Blocking: Effort: normal
Blocked by: Security sensitive: no

Description

Na routerjih, ki to podpirajo, omogočiti hkratno delovanje kot AP in ad-hoc. Predlagam, da bi se potem SSID AP imenoval open.wlan-lj.net, ad-hoc mesh.wlan-lj.net in točke, ki bi bile point-to-point N pa backbone.wlan-lj.net. Vprašanje je, če bi omogočali prijavo uporabnikov na slednja dva SSID?

Change History

comment:1 follow-up: ↓ 2 Changed 9 years ago by Musti

Se strinjam s tem predlogom, uporabniki se načeloma tako samo povezujejo na AP oz na en node. To se spremeni le z mobilnimi nodi, ko imaš roaming. Če je backbone N na 2.4GHz, pol bi jaz dovoljeval povezavo uporabnikov, na 5GHz pa samo node, da ohranimo neko trdno strukturo. Backbone je ponavadi tak point-to-point, kar nekak ne omogoča povezave uporabnikov...

comment:2 in reply to: ↑ 1 Changed 9 years ago by mitar

Replying to Musti:

To se spremeni le z mobilnimi nodi, ko imaš roaming.

He he. Ravno v tem je trik. Če bi imeli AP za uporabnike, bi lahko oni roamali po omrežju brez dodatnih programov, že z napravo, ki podpira WiFi standard.

Sicer je kar nekaj tehničnih stvari, ki jih moramo mi še razviti in narediti, da bi bilo to možno, ampak da, je pa možno. Torej več dela se potem nam naredi s tem. Ampak o tem kdaj drugič. Še testiram. Je pa pač to potrebni korak, da se lahko naredi tudi roaming.

Saj ta ticket je čisto v skladu z načrtom razvoja?. Torej dokler nimamo več radijev na točki, morajo biti točke ad-hoc, če želimo, da se povezujejo med seboj. Sedaj, ko bomo dodajali N, lahko stare routerje prestavljamo v AP delovanje, ker je pač za cliente boljše. Ta ticket pa pravi, da bi mogoče lahko poskusili na routerjih, ki omogočajo tako ad-hoc in AP, pa še nimajo N povezave, nekaj vmesnega.

Če je backbone N na 2.4GHz, pol bi jaz dovoljeval povezavo uporabnikov, na 5GHz pa samo node, da ohranimo neko trdno strukturo.

Ne vidim, zakaj bi bila kakšna razlika med 2.4 GHz in 5 GHz. Torej ta "ohranimo trdno strukturo" mi malo diši po samo sebi namen. Pač, ker v "resnih" omrežjih kao backbone ni dostopen uporabnikom direktno, naj ne bo tudi v našem. Jaz bi mogoče malo bolj konkretne argumente. Lahko pa tudi poskusimo, pa potem vidimo, če so težave.

No, v vsakem primeru backbone ne bo nikoli na 2.4 GHz. To je popoln nesmisel. Tam bomo imeli AP (G oziroma G/N compatibility) ali ad-hoc (ali WiFi direct).

Backbone je ponavadi tak point-to-point, kar nekak ne omogoča povezave uporabnikov...

Point-to-point pomeni AP na eni strani + client na drugi. Torej zakaj se ne bi uporabniki prijavljali na AP, tam kjer bo?

En resen minus pa je, da če bomo kdaj imeli točke, ki bodo le AP, bomo zmanjšali možnost meshanja na 2.4 GHz (kar je recimo problem, če želimo kdaj videti mobilne telefone, ki bi se na široko meshali med seboj na 2.4 GHz). Tako da tisto bi še bilo potrebno razmisliti.

comment:3 Changed 9 years ago by Musti

Glede backbone in uporabnikov. Jaz sem si backbone predstavljal strogo kot povezavo med dvema točkama, usmerjeno in umerjeno za delovanje med A in B. Sej če pokrivaš večje področja pa imaš več točk, ki se potem povezujejo dalje na 2.4GHz, potem pa je to že neke vrste mesh.

comment:4 Changed 9 years ago by mitar

Mislim, da je najboljše, da vidimo, kako se bodo stvari razvijale sploh. Ampak da, tu bo potrebno verjetno najti nek kompromis.

comment:5 Changed 7 years ago by mitar

I got an idea that for routers which do not support both AP and ad-hoc at the same time, we could run only AP and if the VPN connection fails, we switch to ad-hoc. In this way we get the best of both worlds: all users can use our network, but if there is no connectivity to the rest of the network, AP mode has no benefit, so we switch to mesh and hope it will connect to other nodes, we limit the clients then again, but at least we can get the network back on.

Would we do something like this also for backbone links?

comment:6 Changed 7 years ago by Musti

That does not seem reasonable, because no nodes can connect onto the one in AP mode, thus meshing wont work. AP mode could only be available if there are no nodes around wanting to mesh, but I am not sure how often then ad-hoc should be activated to poll of nodes around.

Ad-hoc is not possible for 5GHz and backbone, I see no point in it.

comment:7 Changed 7 years ago by mitar

I do not understand your argument. If you have a node which is running in AP mode and it loses connectivity to the rest of the network, then there is no big use of this node for clients. Switching to mesh mode could at least open a possibility that it reconnects to the rest of the network. There are two options:

  • only this node lost the connectivity to the rest of the network, other nodes stay in AP: then this node will not be able to connect to them, so there will be no big difference if it is running in AP or ad-hoc, in any way it is pretty much useless
  • also other nodes lost the connectivity to the rest of the network (VPN server failure for example), so they will also switch to ad-hoc, if they are close enough, they will be able to form a mesh network

The only negative side I see is that we lose the client who are unable to connect to ad-hoc. When the node is unable to connect to anywhere else in any way, if it would stay in AP, it could help those clients connect among themselves. As they are unable to use ad-hoc, they also cannot connect directly between themselves. So AP in-between could help here.

Ad-hoc is possible for 5 GHz? Just not standard N, as there is no standard. At least on the hardware which are using currently in the backbone (Atheros-based chipsets).

comment:8 follow-up: ↓ 9 Changed 7 years ago by Musti

My argument is that if a node has VPN connectivity and is in AP mode, a node next to it without VPN cannot wireless connect and offer connectivity to its clients, albeit in ad-hoc mode.

I cannot see what would be the point of using ad-hoc for backbone, it is only ptp or ptmp. Mesh implementation in this case would fail, because there would be huge timing issues, nodes with big separation cannot hear eachother, so technoogies like AirMax (TDMA) must be employed.

comment:9 in reply to: ↑ 8 Changed 7 years ago by mitar

Replying to Musti:

My argument is that if a node has VPN connectivity and is in AP mode, a node next to it without VPN cannot wireless connect and offer connectivity to its clients, albeit in ad-hoc mode.

True. This is the first case above. And my argument is that if it has no connectivity and no chance of one, it does not matter if it is in AP or ad-hoc. But in ad-hoc it has at least a chance of connecting over the WiFi (if also some other node changes to ad-hoc, or is already in ad-hoc (because runs both AP and ad-hoc at the same time).

Mesh implementation in this case would fail, because there would be huge timing issues, nodes with big separation cannot hear eachother, so technoogies like AirMax (TDMA) must be employed.

I cannot agree with this. Timing does not have anything with mesh. And TDMA also not. Those things only improve performance, but connectivity can still be achieved. Limited, also range limited, but still better than nothing.

So for backbone we wouldn't change to ad-hoc when connectivity to the rest of the network fails, but when also a node does not have any clients (if it is AP itself) or is not connected to any AP (if it is client itself). Then backbone nodes could switch to ad-hoc and try to get anything there. Once they would and it would be a link which is configured for backbone, they could switch back. Nodes could also scan all the time and check if there are APs already back.

So for the backbone it is not necessary the best to change things. But for independent nodes capable of only AP, I do not see the reason why not move to ad-hoc.

comment:11 Changed 7 years ago by Musti

Managed to get it working AP + AD-HOC on openwrt trunk r30919 on wr741nd v2.4. full config

Whow wifi interface has to be configured:

root@OpenWrt:/# cat /etc/config/wireless
config wifi-device  radio0
        option type     mac80211
        option channel  11
        option macaddr  54:e6:fc:f3:ac:aa
        option hwmode   11ng
        option htmode   HT20
        list ht_capab   SHORT-GI-40
        list ht_capab   TX-STBC
        list ht_capab   RX-STBC1
        list ht_capab   DSSS_CCK-40
 
config wifi-iface
        option device   radio0
        option network  lan
        option mode     ap
        option ssid     OpenWrt1
        option encryption none
 
config wifi-iface
        option device   radio0
        option network  lan
        option mode     adhoc
        option ssid     OpenWrt2
        option bssid 02:ca:ff:ee:ba:be
        option encryption none

Moving on to test this with wr741nd and wlan-si firmware.

Last edited 7 years ago by Musti (previous) (diff)

comment:12 Changed 7 years ago by Musti

Works with wr741nd v4.3 and the following config. Needs implementation in existing configs.

config wifi-device 'radio0'
        option type 'mac80211'
        option channel '8'
        option hwmode '11ng'
        option htmode 'HT20'
        list ht_capab 'SHORT-GI-40'
        list ht_capab 'SHORT-GI-20'
        list ht_capab 'RX-STBC1'
        list ht_capab 'DSSS_CCK-40'
        option macaddr 'f8:d1:11:37:b8:0c'

config wifi-iface
        option device 'radio0'
        option network 'mesh'
        option mode 'adhoc'
        option ssid 'open.wlan-si.net'
        option bssid '02:CA:FF:EE:BA:BE'
        option encryption 'none'

config wifi-iface
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option ssid 'ap.wlan-si.net'

comment:13 Changed 7 years ago by Musti

I suggest we use the SSID open.wlan-si.net for the mesh interface as it allows backwards compatibility and SSID connect.wlan-si.net or similar for ap interface. Please feedback.

comment:14 Changed 7 years ago by mitar

No. We once decided that open.wlan-si.net to be the AP SSID (for clients, so that it is same as now) and then we use mesh.wlan-si.net for ad-hoc. backbone.wlan-si.net for 5 GHz directional links.

Mesh nodes do not care about SSID, only BSSID. So existing open.wlan-si.net mesh nodes will peer normally with mesh.wlan-si.net nodes. The idea is that clients now that they can simply connect to open.wlan-si.net SSID and use the Internet. If we can support AP on a given node, then in AP mode, if not, then ad-hoc. But same SSID still.

comment:15 Changed 7 years ago by domen

  • Cc domen added

comment:16 Changed 7 years ago by gw0

Confirming that using this approach on Fonera (Atheros AR2315) two interfaces ath0 (for AP) and ath1 (for ad-hoc) with corresponding SSIDs appear, but there are some other issues related to the renamed devices on Fonera built for wlan slovenija therefore I didn't test if it is working without problems.

config wifi-device wifi0
        option type atheros
        option channel 4
        option diversity 0
        option rxantenna 1
        option txantenna 1

config wifi-iface
        option device   wifi0
        option network  mesh
        option mode     ap
        option ssid     open.wlan-si.net
        option encryption none

config wifi-iface
        option device   wifi0
        option network  mesh
        option mode     adhoc
        option ssid     mesh.wlan-si.net
        option bssid    02:CA:FF:EE:BA:BE
        option encryption none

It is also interesting to know how to set this up manually (with wlanconfig command):
https://forum.openwrt.org/viewtopic.php?pid=49086#p49086

It should also be noted that there are also various issues while connecting to ad-hoc networks in some OSes and network managers (not just Android), therefore this ticket should have higher priority.

comment:17 Changed 7 years ago by mitar

Thanks for reporting. Yes, we know that we should migrate from ad-hoc for clients.

BTW, when you will upgrade your node to horizontal polarization antenna?

comment:18 Changed 7 years ago by kostko

This is already working in the latest version of our firmware for ar71xx (TP-Links) and should also work on Foneras (atheros architecture).

comment:19 follow-up: ↓ 20 Changed 7 years ago by gw0

With manual configuration it is probably working for "Fonera (2.6 kernel)", but the latest firmware (v2.0b-33-gbb622cc) does not implement it! (Tested it a few minutes ago.)

comment:20 in reply to: ↑ 19 Changed 7 years ago by kostko

Replying to gw0:

With manual configuration it is probably working for "Fonera (2.6 kernel)", but the latest firmware (v2.0b-33-gbb622cc) does not implement it! (Tested it a few minutes ago.)

That is not the latest firmware, this is the old firmware. The latest firmware is experimental and currently holds the version number git.763e678 and is currently only in the process of being made available for Foneras. I just said that it should work not that it is already available in the generator.

comment:21 Changed 7 years ago by mitar

The old firmware used madwifi. The AP+ad-hoc we are doing now uses ath line of drivers. What will new firmware for Fonera use?

comment:22 Changed 6 years ago by kostko

  • Status changed from new to closed
  • Resolution set to fixed

AFAIK the new Fonera firmware uses the ath5k driver (the new driver also built on mac80211). So all these configurations should be supported. I am closing this ticket as its milestone specified 3.0b and this has been supported in 3.0b for some time now (it is not and will not be supported in 2.0 Fonera configurations).

comment:23 Changed 6 years ago by mitar

  • Status changed from closed to reopened
  • Resolution fixed deleted

But we have not tested how it works on Fonera. We have to test it first before we can close the ticket.

comment:24 Changed 6 years ago by kostko

  • Status changed from reopened to closed
  • Resolution set to fixed

This ticket is not about Fonera support. By your logic we then first have to test it on all OpenWrt supported devices. This thing is considered fixed as it can be configured in 3.0b. If it does not work a new ticket should be opened for that specific device.

Note: See TracTickets for help on using tickets.