The RED15w connects to the UTM 9.4 Beta without a problem and the Wireless Access Point is promptly show under wireless. However once accepted it gives errors and goes inactive.
2016:02:17-08:55:29 sweber-utm-aws awed[3511]: [MASTER] new firmware detected for RED15w: 1 2016:02:17-08:55:29 sweber-utm-aws awed[3511]: [MASTER] access point firmware available: AP15C:9400-04b82c7 AP10:9350-f57964e-7b521f0-3 AP55C:9400-04b82c7 RED15w:1 AP5:1 AP30:9350-f57964e-7b521f0-3 AP100C:9400-04b82c7 AP100X:9400-04b82c7 AP50:9350-f57964e-7b521f0-3 AP55:9400-04b82c7 AP15:9400-04b82c7 AP100:9400-04b82c7 2016:02:17-08:55:29 sweber-utm-aws awed[3511]: [MASTER] Generating SSH RSA keypair. 2016:02:17-08:55:31 sweber-utm-aws awed[3511]: [MASTER] Generating SSH ECDSA keypair. 2016:02:17-08:59:12 sweber-utm-aws awed[3511]: [MASTER] new connection from 192.168.200.128:40458 2016:02:17-08:59:13 sweber-utm-aws awed[4311]: 1 2016:02:17-08:59:16 sweber-utm-aws awed[3511]: [MASTER] new AP with ID A36018022EC39A1 2016:02:17-08:59:16 sweber-utm-aws awed[3511]: [MASTER] RED based AP. 2016:02:17-08:59:18 sweber-utm-aws awed[3511]: [MASTER] new connection from 192.168.200.128:40459 2016:02:17-08:59:18 sweber-utm-aws awed[3511]: [MASTER] AP A36018022EC39A1: Local metadata updated 2016:02:17-08:59:18 sweber-utm-aws awed[3511]: [MASTER] AP A36018022EC39A1: Configuration change detected 2016:02:17-08:59:33 sweber-utm-aws awed[3511]: [MASTER] new connection from 192.168.200.128:40460 2016:02:17-08:59:33 sweber-utm-aws awed[4415]: [A36018022EC39A1] RED15w from 192.168.200.128:40460 identified as A36018022EC39A1 2016:02:17-08:59:33 sweber-utm-aws awed[4415]: [A36018022EC39A1] (Re-)loaded identity and/or configuration 2016:02:17-08:59:33 sweber-utm-aws awed[4415]: [A36018022EC39A1] device sends DEV2ASG_INITIALCONTACT twice, dropping. 2016:02:17-08:59:38 sweber-utm-aws awed[3511]: [MASTER] new connection from 192.168.200.128:40461 2016:02:17-08:59:38 sweber-utm-aws awed[4420]: [A36018022EC39A1] RED15w from 192.168.200.128:40461 identified as A36018022EC39A1 2016:02:17-08:59:38 sweber-utm-aws awed[4420]: [A36018022EC39A1] (Re-)loaded identity and/or configuration 2016:02:17-08:59:38 sweber-utm-aws awed[4420]: [A36018022EC39A1] device sends DEV2ASG_INITIALCONTACT twice, dropping
2016:02:21-09:32:05 sweber-utm-aws awed[3511]: [MASTER] new connection from 192.168.200.128:36919
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:
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.400000Hardware type..............: 135wr1Serial number..............: MISSINGInstallation image.........: 9.400-20160308.1Installation type..........: ssiInstalled pattern version..: 97292Downloaded pattern version.: 97292Up2Dates applied...........: 0Up2Dates available.........: 0Factory resets.............: 0Timewarps detected.........: 0Team branch................: axg9400_wifi
I assume this problem was fixed by another team by chance.
here is the output :
Current software version...: 9.375005Hardware type..............: 220CSerial number..............: A12041795202309Installation image.........: 9.314-13.1Installation type..........: ssiInstalled pattern version..: 97386Downloaded pattern version.: 97386Up2Dates 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.........: 0Factory resets.............: 0Timewarps detected.........: 0
Best regards,
Marius
i just updated our UTM to 9.400. The problem remains the same.
Is there a chance to get ssh access to this utm?
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.