Hello Team, Do we have to enable anything in the bridge interface in Linux for processing EAPOL packets ? Currently the bridge in my setup cannot detect EAPOL packets. However the DSA lan ports are able to detect. The bridge interface contains the lan ports. Regards Simon
On 22/04/2025 06:21, SIMON BABY wrote:
Do we have to enable anything in the bridge interface in Linux for processing EAPOL packets ? Currently the bridge in my setup cannot detect EAPOL packets. However the DSA lan ports are able to detect. The bridge interface contains the lan ports.
Wrong list, but whatever. IIRC it's blocked by default. Maybe play with the group_fwd_mask sysfs setting for the bridge? If not that then there's another sys or proc entry that fixes it. -- Matthew
Thank you . On Tuesday, April 22, 2025, Matthew Newton via Freeradius-Users < freeradius-users@lists.freeradius.org> wrote:
On 22/04/2025 06:21, SIMON BABY wrote:
Do we have to enable anything in the bridge interface in Linux for processing EAPOL packets ? Currently the bridge in my setup cannot detect EAPOL packets. However the DSA lan ports are able to detect. The bridge interface contains the lan ports.
Wrong list, but whatever.
IIRC it's blocked by default. Maybe play with the group_fwd_mask sysfs setting for the bridge? If not that then there's another sys or proc entry that fixes it.
-- Matthew
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list /users.html
On Mon, 21 Apr 2025, SIMON BABY wrote:
Hello Team,
Do we have to enable anything in the bridge interface in Linux for processing EAPOL packets ? Currently the bridge in my setup cannot detect EAPOL packets. However the DSA lan ports are able to detect. The bridge interface contains the lan ports.
Regards Simon
Technically you should not see any EAPOL packets at your radius server. You should see the rad-request/rad-account UDP 1812 & 1813 (and possibly tcp 1812 & 1813) packets at your radius server so you will need to be sure those packets make it in thru what ever network config is implemented on the system hosting your radius server. EAPOL is the network protocol that your WPA supplicants (wireless devices & laptops) use to communicate to your wireless access-points and they use UDP 1812/1813 to send the request to your radius server. -- Dave Funk University of Iowa <dbfunk (at) engineering.uiowa.edu> College of Engineering 319/335-5751 FAX: 319/384-0549 1256 Seamans Center, 103 S Capitol St. Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527 #include <std_disclaimer.h> Better is not better, 'standard' is better. B{
Thank you Dave. Yes with regular port I can see radius packets at the the radius sever and between the client and hostapd I see EAPOL packets. Can you suggest what value needs to write in the fwd_mask for this to work for bridge interface ? Regards Simon On Tuesday, April 22, 2025, Dave Funk <dbfunk@engineering.uiowa.edu> wrote:
On Mon, 21 Apr 2025, SIMON BABY wrote:
Hello Team,
Do we have to enable anything in the bridge interface in Linux for processing EAPOL packets ? Currently the bridge in my setup cannot detect EAPOL packets. However the DSA lan ports are able to detect. The bridge interface contains the lan ports.
Regards Simon
Technically you should not see any EAPOL packets at your radius server.
You should see the rad-request/rad-account UDP 1812 & 1813 (and possibly tcp 1812 & 1813) packets at your radius server so you will need to be sure those packets make it in thru what ever network config is implemented on the system hosting your radius server.
EAPOL is the network protocol that your WPA supplicants (wireless devices & laptops) use to communicate to your wireless access-points and they use UDP 1812/1813 to send the request to your radius server.
-- Dave Funk University of Iowa <dbfunk (at) engineering.uiowa.edu> College of Engineering 319/335-5751 FAX: 319/384-0549 1256 Seamans Center, 10 <https://www.google.com/maps/search/amans+Center,+10?entry=gmail&source=g>3 S Capitol St. Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527 #include <std_disclaimer.h> Better is not better, 'standard' is better. B{ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list /users.html
On Tue, 22 Apr 2025, SIMON BABY wrote:
Thank you Dave. Yes with regular port I can see radius packets at the the radius sever and between the client and hostapd I see EAPOL packets.
Can you suggest what value needs to write in the fwd_mask for this to work for bridge interface ?
radius does not have a "fwd_mask" parameter so this is not a radius question. As I said, UDP/TCP 1812 & 1813 traffic from your access points ("hostapd" ?) needs to reach your radius server. You need to configure your Linux system hosting your radius server so that happens. If you are running radius inside some kind of container/vitalization system (EG: Docker, virtual-box, etc), then you need to set the network configuration for those systems to make the above happen. You need to direct your "fwd_mask" question to the appropriate group discussing what ever technology you are using, this is outside of radius. -- Dave Funk University of Iowa <dbfunk (at) engineering.uiowa.edu> College of Engineering 319/335-5751 FAX: 319/384-0549 1256 Seamans Center, 103 S Capitol St. Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527 #include <std_disclaimer.h> Better is not better, 'standard' is better. B{
Thank you Dave. Sorry I was asking the group_fwd_mask sysfs setting for the bridge interface to forward multicasts pockets and not for the radius. I will ask the question to different group then. Regards Simon On Tuesday, April 22, 2025, Dave Funk <dbfunk@engineering.uiowa.edu> wrote:
On Tue, 22 Apr 2025, SIMON BABY wrote:
Thank you Dave. Yes with regular port I can see radius packets at the the
radius sever and between the client and hostapd I see EAPOL packets.
Can you suggest what value needs to write in the fwd_mask for this to work for bridge interface ?
radius does not have a "fwd_mask" parameter so this is not a radius question.
As I said, UDP/TCP 1812 & 1813 traffic from your access points ("hostapd" ?) needs to reach your radius server.
You need to configure your Linux system hosting your radius server so that happens. If you are running radius inside some kind of container/vitalization system (EG: Docker, virtual-box, etc), then you need to set the network configuration for those systems to make the above happen.
You need to direct your "fwd_mask" question to the appropriate group discussing what ever technology you are using, this is outside of radius.
-- Dave Funk University of Iowa <dbfunk (at) engineering.uiowa.edu> College of Engineering 319/335-5751 FAX: 319/384-0549 1256 Seamans Center, 103 S Ca <https://www.google.com/maps/search/Center,+103+S+Ca?entry=gmail&source=g>pitol St. Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527 #include <std_disclaimer.h> Better is not better, 'standard' is better. B{
On Tue, 22 Apr 2025, Dave Funk wrote:
On Tue, 22 Apr 2025, SIMON BABY wrote:
Thank you Dave. Yes with regular port I can see radius packets at the the radius sever and between the client and hostapd I see EAPOL packets.
Can you suggest what value needs to write in the fwd_mask for this to work for bridge interface ?
radius does not have a "fwd_mask" parameter so this is not a radius question.
As I said, UDP/TCP 1812 & 1813 traffic from your access points ("hostapd" ?) needs to reach your radius server.
You need to configure your Linux system hosting your radius server so that happens. If you are running radius inside some kind of container/vitalization system (EG: Docker, virtual-box, etc), then you need to set the network configuration for those systems to make the above happen.
You need to direct your "fwd_mask" question to the appropriate group discussing what ever technology you are using, this is outside of radius.
OK, sorry, I did not know what "hostapd" was. It is still the case that this is not a radius question, it is a "hostapd" configuration question. If you look for the hostapd mailing list you will probably get more useful information about it: http://w1.fi/hostapd/ http://lists.infradead.org/mailman/listinfo/hostap Also google for "linux hostapd" gets a bunch of hits. -- Dave Funk University of Iowa <dbfunk (at) engineering.uiowa.edu> College of Engineering 319/335-5751 FAX: 319/384-0549 1256 Seamans Center, 103 S Capitol St. Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527 #include <std_disclaimer.h> Better is not better, 'standard' is better. B{
Thank you Dave On Tuesday, April 22, 2025, Dave Funk <dbfunk@engineering.uiowa.edu> wrote:
On Tue, 22 Apr 2025, Dave Funk wrote:
On Tue, 22 Apr 2025, SIMON BABY wrote:
Thank you Dave. Yes with regular port I can see radius packets at the the
radius sever and between the client and hostapd I see EAPOL packets.
Can you suggest what value needs to write in the fwd_mask for this to work for bridge interface ?
radius does not have a "fwd_mask" parameter so this is not a radius question.
As I said, UDP/TCP 1812 & 1813 traffic from your access points ("hostapd" ?) needs to reach your radius server.
You need to configure your Linux system hosting your radius server so that happens. If you are running radius inside some kind of container/vitalization system (EG: Docker, virtual-box, etc), then you need to set the network configuration for those systems to make the above happen.
You need to direct your "fwd_mask" question to the appropriate group discussing what ever technology you are using, this is outside of radius.
OK, sorry, I did not know what "hostapd" was. It is still the case that this is not a radius question, it is a "hostapd" configuration question.
If you look for the hostapd mailing list you will probably get more useful information about it: http://w1.fi/hostapd/ http://lists.infradead.org/mailman/listinfo/hostap
Also google for "linux hostapd" gets a bunch of hits.
-- Dave Funk University of Iowa <dbfunk (at) engineering.uiowa.edu> College of Engineering 319/335-5751 FAX: 319/384-0549 1256 Seamans Center, 103 S Capitol St. Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527 #include <std_disclaimer.h> Better is not better, 'standard' is better. B{
participants (3)
-
Dave Funk -
Matthew Newton -
SIMON BABY