Hello Ali,

reevaluate access will use CoA (wiredeauthtechnique) and restart switch will use snmp.

It's how it works in PacketFence.

Regards

Fabrice


Le 18-10-24 à 02 h 01, Amjad Ali a écrit :
Hi Fabrice

Thanks for that clarification but what about bouncing port with CoA method? When I hit the Restart Switchport button, I want PF to send a CoA bounce host port command. Currently as you said, its using the SNMP down and then SNMP up to restart switch port. Maybe we need something similar to wiredauthTechniques for bounce port such as wiredbounceportTechnique? So as to chose between which method to use while bouncing a port. Slightly unclear to me on how to go about this please help.

Thanks,
Ali

On Tue, Oct 23, 2018 at 9:13 PM Fabrice Durand <fdur...@inverse.ca <mailto:fdur...@inverse.ca>> wrote:

    Hello Ali,

    in fact
    /usr/local/pf/html/pfappserver/lib/pfappserver/Model/Node.pm
    bouncePort is made to shut/no shut the port and it use snmp.

    What you will need to do is to implement the function
    wiredeauthTechniques (for wire) or deauthTechniques (for wireless)
    in order to launch the correct function to reevaluate the access.

    Regards

    Fabrice


    Le 18-10-21 à 23 h 36, Amjad Ali a écrit :
    Hi Fabrice,

    Yes your spot on, the issue was wrong port numbers, we'll fix
    that very soon.

    A slightly different issue but I need your advice on it, I have
    changed bouncePort sub routine in Node.pm to send the mac address
    instead of switch port index for CoA to work properly. This has
    been done
    at  /usr/local/pf/html/pfappserver/lib/pfappserver/Model/Node.pm

    unless($switch->bouncePort($locationlog->{port})) { # changed
    port to mac
            $status = $STATUS::INTERNAL_SERVER_ERROR;
            $status_msg = "Couldn't restart port.";
        }


    Need to know what would be the best way to change this preferred
    behavior from SNMP to CoA. Because later on if we submit this
    module to be part of PF I guess there would be some issues about it.

    Many thanks again.
    Ali

    On Sat, Oct 20, 2018 at 11:18 AM Durand fabrice via
    PacketFence-users <packetfence-users@lists.sourceforge.net
    <mailto:packetfence-users@lists.sourceforge.net>> wrote:

        Hello Ali,

        you did the good thing but in the capture it looks that the
        switch reply on the wrong port.

        CoA request: src port 52492 dst 3799

        CoA-ACK : src port 1812 dst 3799 (it's suppose to be src 3799
        dst 52492)

        So it looks to me a switch bug.

        Regards

        Fabrice

        Le 18-10-15 à 05 h 47, Amjad Ali via PacketFence-users a écrit :
        Hi All,

        We have implemented CoA method to bounce port (reuse
        Cisco.pm _radiusBounceMac) in our new hardware module but
        with some issues.

        1) The bounce port CoA request packet is received at switch,
        the switch replies with CoA-ACK and obliges with port down
        then port port up. (It does what its supposed to do, no
        problems)
        2) The CoA-ACK reply packet also arrives at the switch (I
        confirmed it with tcpdump) but packetfence somehow can't get
        the reply packet. Instead I get the following log entries

        Oct 15 16:43:59 packetfence httpd_admin: httpd.admin(826)
        INFO: [mac:unknown] boucing MAC e0:db:55:cd:84:62 using
        RADIUS CoA-Request method (pf::Switch::Pica::bouncePort)
        Oct 15 16:43:59 packetfence httpd_admin: httpd.admin(826)
        WARN: [mac:unknown] Unable to perform RADIUS CoA-Request:
        Timeout waiting for a reply from 10.10.51.217 on port 3799
        at /usr/local/pf/lib/pf/util/radius.pm <http://radius.pm>
        line 162. (pf::Switch::Pica::catch {...} )
        Oct 15 16:43:59 packetfence httpd_admin: httpd.admin(826)
        ERROR: [mac:unknown] Cannot restart switch port for
        e0:db:55:cd:84:62
        (pfappserver::PacketFence::Controller::Node::restart_switchport)

        I checked the Radius.pm code (perform_dynauth), it sends the
        CoA request packet and listens for a reply, the reply
        arrives at the machine running packetfence but evades the
        socket listening for reply.

        I double checked the timeout and port number but couldn't
        get to the root cause. Any ideas would be highly
        appreciated. I'm attaching the capture request/reply pcap
        for your reference. Please advise.

        Thanks,
        Ali
-- Amjad Ali


        _______________________________________________
        PacketFence-users mailing list
        PacketFence-users@lists.sourceforge.net  
<mailto:PacketFence-users@lists.sourceforge.net>
        https://lists.sourceforge.net/lists/listinfo/packetfence-users
        _______________________________________________
        PacketFence-users mailing list
        PacketFence-users@lists.sourceforge.net
        <mailto:PacketFence-users@lists.sourceforge.net>
        https://lists.sourceforge.net/lists/listinfo/packetfence-users



-- Amjad Ali

-- Fabrice Durand
    fdur...@inverse.ca  <mailto:fdur...@inverse.ca>  ::  +1.514.447.4918 (x135) 
::www.inverse.ca  <http://www.inverse.ca>
    Inverse inc. :: Leaders behind SOGo (http://www.sogo.nu) and PacketFence 
(http://packetfence.org)



--
Amjad Ali
_______________________________________________
PacketFence-users mailing list
PacketFence-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/packetfence-users

Reply via email to