Thanks Fabrice, this helps alot. Ali
On Fri, Oct 26, 2018 at 9:21 AM Durand fabrice <[email protected]> wrote: > 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 <[email protected]> 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 < >> [email protected]> 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 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 >>> [email protected]https://lists.sourceforge.net/lists/listinfo/packetfence-users >>> >>> _______________________________________________ >>> PacketFence-users mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/packetfence-users >>> >> >> >> -- >> Amjad Ali >> >> -- >> Fabrice [email protected] :: +1.514.447.4918 (x135) :: >> www.inverse.ca >> Inverse inc. :: Leaders behind SOGo (http://www.sogo.nu) and PacketFence >> (http://packetfence.org) >> >> > > -- > Amjad Ali > > -- Amjad Ali
_______________________________________________ PacketFence-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/packetfence-users
