Thread Info
  • State Not Answered
  • Replies 11 replies
  • Subscribers 4 subscribers
  • Views 34055 views
  • Users 0 members are here
Options
Suggested

RED15 integrated Wireless Access Point Error

SteveWeber

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

2016:02:21-09:32:05 sweber-utm-aws awed[6839]: [A36018022EC39A1] RED15w from 192.168.200.128:36919 identified as A36018022EC39A1
2016:02:21-09:32:05 sweber-utm-aws awed[6839]: [A36018022EC39A1] (Re-)loaded identity and/or configuration
2016:02:21-09:32:05 sweber-utm-aws awed[6839]: [A36018022EC39A1] Corrupt payload. Device may have wrong key. Delete device to re-register it.
  • 0 in reply to MariusGaertig

    @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.

Unfiltered HTML