RED15 integrated Wireless Access Point Error

I also have the same problem.[*-)]We configured our RED15w and connected it to the UTM. Everything works fine to this point and i can connect to the WLAN.[Y]

Now we want to change the Location from the RED. So if we want to connect to the UTM again the Log says :

I have an update for this. For my scenario it is a workaround.

While i have this problem  i go to "Wireless Protection -> Access Points -> Grouping" and delete the group/object for this RED. As soon as i deleted this object the RED/AP show itself again in the pending access points. Now i can accept it and it works again.

But when i shut down the RED the problem comes back. So i delete the Group Object again, accept pending AP ....

[^o)]

Hi,
I'm currently working on this issue. Can you specify the RED mode (Std. Unified / Std. Split / Transparent Split) you have used as well as the broadcasted wireless network mode(s) (Seperate Zone / Bridge to AP LAN / Bridge to VLAN).

Other things that might be interesting:

• VLAN settings
• AP grouping
• Basic description of the network setup

I was not able to reproduce this bahavior yet. Was this behavior discovered directly after unboxing the RED15w device or later on after some testing has been done already?

The easiest way for me to find the root cause of this issue would be to have SSH access to a box where this occures. So if you have the possibility to give me temporary access to such a box, this would be helpful.

Hi Fabian,

After the last beta update the RED15w Wifi Access Point finally came online.  Everything seems to be working right now.  Wireless is connected and tested.

Hi,

here some Information for you :

RED-Config :

DHCP-Client

Standard/Unified

WLAN-Network is bridged to LAN

We didnt configure any VLAN´s.

The Problem occured directly after the first location-change.

Hi Marius,

thanks for your fast response. Could you also provide the exact version of UTM you used for testing. The best would  be to login to UTM using SSH and typing "version". The output should look like this:

Current software version...: 9.400000
Hardware type..............: 135wr1
Serial number..............: MISSING
Installation image.........: 9.400-20160308.1
Installation type..........: ssi
Installed pattern version..: 97292
Downloaded pattern version.: 97292
Up2Dates applied...........: 0
Up2Dates available.........: 0
Factory resets.............: 0
Timewarps detected.........: 0
Team branch................: axg9400_wifi

I assume this problem was fixed by another team by chance.

Hi Fabian,

here is the output :

Current software version...: 9.375005
Hardware type..............: 220C
Serial number..............: A12041795202309
Installation image.........: 9.314-13.1
Installation type..........: ssi
Installed pattern version..: 97386
Downloaded pattern version.: 97386
Up2Dates applied...........: 9 (see below)
                             sys-9.314-9.315-13.2.1.tgz (Aug 24  2015)
                             sys-9.315-9.316-2.4.1.tgz (Nov 11 13:46)
                             sys-9.316-9.317-4.5.1.tgz (Nov 11 13:48)
                             sys-9.317-9.350-5.12.1.tgz (Dec  3 09:07)
                             sys-9.350-9.351-12.3.2.tgz (Dec  3 09:09)
                             sys-9.351-9.352-3.6.2.tgz (Dec 16 11:44)
                             sys-9.352-9.353-6.4.1.tgz (Feb  2 10:19)
                             sys-9.353-9.370-4.24.1.tgz (Feb 11 16:16)
                             sys-9.370-9.375-24.5.1.tgz (Mar  9 12:30)
Up2Dates available.........: 0
Factory resets.............: 0
Timewarps detected.........: 0

Best regards,

Marius

Hi,

i just updated our UTM to 9.400. The problem remains the same.

Best regards,

Marius

Is there a chance to get ssh access to this utm?

Hi Fabian,

of course. Send me your Email and i will give you the details.

@all: I think I was able to find the root cause of this problem. This issue occures if you put two UTM next to each other that have wifi enabled on the interface that is directing to the RED device like this:

Internet <-> UTM1 <-> UTM2 <-> RED15w.

As RED15w is obtaining DHCP after startup in parallel to the first connection attempt of the aweclient (configuration daemon for wifi) this can lead to a race condition, where the DHCP option 234 hasn't been send by UTM2 on RED15w already. This will trigger the aweclient in fallback mode to the workaround default IP "1.2.3.4". This IP will be routed by UTM2 to UTM1 which will then see the access point of the RED15w. If the AP of the RED15w was registered at UTM2 before, this will lead to a deletion of the key because UTM1 doesn't know this device and thinks it's a new one. After the key was deleted aweclient will remain in a reconnecting loop which will move it from UTM1 to UTM2 as soon as the DHCP option 234 sent by UTM2 arrived. At this time the AP in the RED15w isn't able to connect anymore as it has deleted the key before. While the RED15w is up, everything is working fine, as the IP address of UTM2 was already delivered by DHCP option 234 to the RED15w device.

This is not really a bug as it isn't supported to have two wireless controllers (UTM + Wifi) in the same network. However this behavior isn't nice so I will delay the starting of aweclient a little bit to wait for the UTM2 IP address to show up by DHCP option 234.

It might be also possible to filter 1.2.3.4 forwarding on UTM2. But I'm not really shure if this is possible as this 1.2.3.4 is handled in a special way on all UTMs. Maybe somebody could try it and report the results here.

@all: I think I was able to find the root cause of this problem. This issue occures if you put two UTM next to each other that have wifi enabled on the interface that is directing to the RED device like this:

Internet <-> UTM1 <-> UTM2 <-> RED15w.

As RED15w is obtaining DHCP after startup in parallel to the first connection attempt of the aweclient (configuration daemon for wifi) this can lead to a race condition, where the DHCP option 234 hasn't been send by UTM2 on RED15w already. This will trigger the aweclient in fallback mode to the workaround default IP "1.2.3.4". This IP will be routed by UTM2 to UTM1 which will then see the access point of the RED15w. If the AP of the RED15w was registered at UTM2 before, this will lead to a deletion of the key because UTM1 doesn't know this device and thinks it's a new one. After the key was deleted aweclient will remain in a reconnecting loop which will move it from UTM1 to UTM2 as soon as the DHCP option 234 sent by UTM2 arrived. At this time the AP in the RED15w isn't able to connect anymore as it has deleted the key before. While the RED15w is up, everything is working fine, as the IP address of UTM2 was already delivered by DHCP option 234 to the RED15w device.

This is not really a bug as it isn't supported to have two wireless controllers (UTM + Wifi) in the same network. However this behavior isn't nice so I will delay the starting of aweclient a little bit to wait for the UTM2 IP address to show up by DHCP option 234.

It might be also possible to filter 1.2.3.4 forwarding on UTM2. But I'm not really shure if this is possible as this 1.2.3.4 is handled in a special way on all UTMs. Maybe somebody could try it and report the results here.