Hello Taehee,
I have been experimenting with MESH mode on kernel 4.0.7. It is
sending beacons out, but is unable to establish a connection.
I have two rtl8192cu based dongles connected to identical VMs and am
using the following commands to set up the mesh:
iw dev wls160u2 set type mesh
ip addr add 192.168.2.1/24 broadcast 192.168.2.255 dev wls160u2
ip link set wls160u2 up
iw dev wls160u2 mesh join lmmesh
Running 'iw dev wls160u2 mpath dump' produces no results and there is
nothing regarding mesh in dmesg. I can't find any other information on
mesh with rtl8192cu other than the patch which you submitted.
I am wondering if it does work, but there is a step I am missing or if
something is wrong with the code?
Thank you,
Richard.
2015-07-03 18:59 GMT+09:00 Bruno Randolf <[email protected]>:
> On 07/03/2015 10:34 AM, Richard Palethorpe wrote:
>> Hello Taehee,
>>
>> I have been experimenting with MESH mode on kernel 4.0.7. It is
>> sending beacons out, but is unable to establish a connection.
>>
>> I have two rtl8192cu based dongles connected to identical VMs and am
>> using the following commands to set up the mesh:
>>
>> iw dev wls160u2 set type mesh
>> ip addr add 192.168.2.1/24 broadcast 192.168.2.255 dev wls160u2
>> ip link set wls160u2 up
>> iw dev wls160u2 mesh join lmmesh
>>
>> Running 'iw dev wls160u2 mpath dump' produces no results and there is
>> nothing regarding mesh in dmesg. I can't find any other information on
>> mesh with rtl8192cu other than the patch which you submitted.
>>
>> I am wondering if it does work, but there is a step I am missing or if
>> something is wrong with the code?
>
> I don't know about this 'mesh' mode, but I have noted problems in ad-hoc
> mode with this chipset and driver. The problem seems to be that ARP
> replies are not sent on the air... Not sure what the reason is or if
> it's possible to fix it in the driver, but my conclusion for now is that
> this device is unusable for ad-hoc mode. Similar problems may exist for
> mesh?
>
> bruno
>
I don't know about a mesh network.
But, according to my ping test result, 'mpath dump' shows ping traffics.
Did you generate any traffics?
On Mon, Jul 6, 2015 at 8:04 PM, Bruno Randolf <[email protected]> wrote:
>
> On 07/06/2015 11:46 AM, Richard Palethorpe wrote:
> > Bruno, that surprises me somewhat because I have got IBSS mode to work
> > on kernel 4.0+. Are you using a slightly older kernel?
>
> I'm using kernel 3.18 with wireless drivers from backports in OpenWRT
> CC, so it should be pretty recent...
>
> I wonder to what level did you verify the IBSS operation?
>
> I did get it to basically work as well, sometimes it works well, but
> sometimes I get a packet loss of about 15-20% and outages of
> connectivity for a while. This happens not always immediately, but
> reproducibly after some time. Try pinging for an hour or so...?
>
> I traced it down to ARP replies being apparently "sent" on the device
> (tcpdump shows it locally) but they don't make it onto the "air"...
>
> If you or anyone else can confirm ad-hoc mode really works, on some
> version of the driver, I'll start to investigate more.
>
> bruno
>
I don't recall how long I tested it for before, but I have tested it
again and now it is settling down to about 15-20% packet loss. arping
has a lower packet loss of around 6%. So as you say, that probably
means the handling of at least ARP frames/packets is broken in some
way.
On 07/06/2015 11:46 AM, Richard Palethorpe wrote:
> Bruno, that surprises me somewhat because I have got IBSS mode to work
> on kernel 4.0+. Are you using a slightly older kernel?
I'm using kernel 3.18 with wireless drivers from backports in OpenWRT
CC, so it should be pretty recent...
I wonder to what level did you verify the IBSS operation?
I did get it to basically work as well, sometimes it works well, but
sometimes I get a packet loss of about 15-20% and outages of
connectivity for a while. This happens not always immediately, but
reproducibly after some time. Try pinging for an hour or so...?
I traced it down to ARP replies being apparently "sent" on the device
(tcpdump shows it locally) but they don't make it onto the "air"...
If you or anyone else can confirm ad-hoc mode really works, on some
version of the driver, I'll start to investigate more.
bruno
On 07/03/2015 10:34 AM, Richard Palethorpe wrote:
> Hello Taehee,
>
> I have been experimenting with MESH mode on kernel 4.0.7. It is
> sending beacons out, but is unable to establish a connection.
>
> I have two rtl8192cu based dongles connected to identical VMs and am
> using the following commands to set up the mesh:
>
> iw dev wls160u2 set type mesh
> ip addr add 192.168.2.1/24 broadcast 192.168.2.255 dev wls160u2
> ip link set wls160u2 up
> iw dev wls160u2 mesh join lmmesh
>
> Running 'iw dev wls160u2 mpath dump' produces no results and there is
> nothing regarding mesh in dmesg. I can't find any other information on
> mesh with rtl8192cu other than the patch which you submitted.
>
> I am wondering if it does work, but there is a step I am missing or if
> something is wrong with the code?
I don't know about this 'mesh' mode, but I have noted problems in ad-hoc
mode with this chipset and driver. The problem seems to be that ARP
replies are not sent on the air... Not sure what the reason is or if
it's possible to fix it in the driver, but my conclusion for now is that
this device is unusable for ad-hoc mode. Similar problems may exist for
mesh?
bruno
On Sat, Jul 4, 2015 at 3:15 AM, Taehee Yoo <[email protected]> wrote:
> 2015-07-03 18:59 GMT+09:00 Bruno Randolf <[email protected]>:
>> On 07/03/2015 10:34 AM, Richard Palethorpe wrote:
>>> Hello Taehee,
>>>
>>> I have been experimenting with MESH mode on kernel 4.0.7. It is
>>> sending beacons out, but is unable to establish a connection.
>>>
>>> I have two rtl8192cu based dongles connected to identical VMs and am
>>> using the following commands to set up the mesh:
>>>
>>> iw dev wls160u2 set type mesh
>>> ip addr add 192.168.2.1/24 broadcast 192.168.2.255 dev wls160u2
>>> ip link set wls160u2 up
>>> iw dev wls160u2 mesh join lmmesh
>>>
>>> Running 'iw dev wls160u2 mpath dump' produces no results and there is
>>> nothing regarding mesh in dmesg. I can't find any other information on
>>> mesh with rtl8192cu other than the patch which you submitted.
>>>
>>> I am wondering if it does work, but there is a step I am missing or if
>>> something is wrong with the code?
>>
>> I don't know about this 'mesh' mode, but I have noted problems in ad-hoc
>> mode with this chipset and driver. The problem seems to be that ARP
>> replies are not sent on the air... Not sure what the reason is or if
>> it's possible to fix it in the driver, but my conclusion for now is that
>> this device is unusable for ad-hoc mode. Similar problems may exist for
>> mesh?
>>
>> bruno
>>
>
> I don't know about a mesh network.
> But, according to my ping test result, 'mpath dump' shows ping traffics.
>
> Did you generate any traffics?
Bruno, that surprises me somewhat because I have got IBSS mode to work
on kernel 4.0+. Are you using a slightly older kernel?
Taehee, I tried to ping with "ping -I wls160u2 192.168.2.1" which
didn't work. It is my understanding that "iw mpath dump" should show
other nodes in the network as soon as they have connected by doing "iw
dev <dev> mesh join <network>".
According to this page:
https://wireless.wiki.kernel.org/en/developers/documentation/mac80211/api,
there are a number of things that need to be done for mesh. I quote:
"
- react to the set_tim() callback or fetch each beacon from mac80211
For MESH mode, it must
- - allow beacons to be transmitted for NL80211_IFTYPE_MESH_POINT
interfaces. These can be AP or IBSS style beacons.
- - receive beacons and control frames for NL80211_IFTYPE_MESH_POINT interfaces
- - set the NL80211_IFTYPE_MESH_POINT bit in the
hw→wiphy→interface_modes mask to indicate that MP mode is supported.
...
"
The driver doesn't use the TIM callback, so it should "fetch each
beacon from mac80211". The driver does appear to send beacons, so that
part should be OK. I don't know if it receives beacons correctly in
mesh mode however.