Sophos UTM: Decommissioning of obsolete URL categorization services CFFS. Click here for important info.

Thread Info
  • State Not Answered
  • Replies 11 replies
  • Subscribers 4 subscribers
  • Views 33301 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.
Parents
  • 0

    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 :

    2016:03:09-14:52:31 utmdemo-1 awed[23673]: [MASTER] new connection from 10.0.1.128:51548
    2016:03:09-14:52:31 utmdemo-1 awed[25854]: [A3601700160FEEE] RED15w from 10.0.1.128:51548 identified as A3601700160FEEE
    2016:03:09-14:52:31 utmdemo-1 awed[25854]: [A3601700160FEEE] (Re-)loaded identity and/or configuration
    2016:03:09-14:52:31 utmdemo-1 awed[25854]: [A3601700160FEEE] device sends DEV2ASG_INITIALCONTACT twice, dropping.
    2016:03:09-14:52:36 utmdemo-1 awed[23673]: [MASTER] new connection from 10.0.1.128:51549
    2016:03:09-14:52:36 utmdemo-1 awed[25865]: [A3601700160FEEE] RED15w from 10.0.1.128:51549 identified as A3601700160FEEE
    2016:03:09-14:52:36 utmdemo-1 awed[25865]: [A3601700160FEEE] (Re-)loaded identity and/or configuration
    2016:03:09-14:52:36 utmdemo-1 awed[25865]: [A3601700160FEEE] Corrupt payload. Device may have wrong key. Delete device to re-register it.
    [N]

  • 0 in reply to MariusGaertig

    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)]

  • 0 in reply to MariusGaertig

    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.

  • 0 in reply to FabianWittenberg

    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.

  • 0 in reply to FabianWittenberg

    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.

  • 0 in reply to MariusGaertig

    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.

  • 0 in reply to FabianWittenberg

    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

  • 0 in reply to FabianWittenberg

    Hi,

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

    Best regards,

    Marius

  • 0 in reply to FabianWittenberg

    Hi Fabian,

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

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

Reply
  • 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.

Children
No Data
Unfiltered HTML