[eap] Treat an EAP Request-Identity as indicating a blocked link
A switch port using 802.1x authentication will send EAP
Request-Identity packets once the physical link is up, and will not be
forwarding packets until the port identity has been established.
We do not currently support 802.1x authentication. However, a
reasonably common configuration involves using a preset list of
permitted MAC addresses, with the "authentication" taking place
between the switch and a RADIUS server. In this configuration, the
end device does not need to perform any authentication step, but does
need to be prepared for the switch port to fail to forward packets for
a substantial time after physical link-up. This exactly matches the
"blocked link" semantics already used when detecting a non-forwarding
switch port via LACP or STP.
Treat a received EAP Request-Identity as indicating a blocked link.
Unlike LACP or STP, there is no way to determine the expected time
until the next EAP packet and so we must choose a fixed timeout.
Erroneously assuming that the link is blocked is relatively harmless
since we will still attempt to transmit and receive data even over a
link that is marked as blocked, and so the net effect is merely to
prolong DHCP attempts. In contrast, erroneously assuming that the
link is unblocked will potentially cause DHCP to time out and give up,
resulting in a failed boot.
The default EAP Request-Identity interval in Cisco switches (where
this is most likely to be encountered in practice) is 30 seconds, so
choose 45 seconds as a timeout that is likely to avoid gaps during
which we falsely assume that the link is unblocked.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2021-01-19 12:37:50 +00:00
|
|
|
/*
|
|
|
|
|
* Copyright (C) 2021 Michael Brown <mbrown@fensystems.co.uk>.
|
|
|
|
|
*
|
|
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
|
* modify it under the terms of the GNU General Public License as
|
|
|
|
|
* published by the Free Software Foundation; either version 2 of the
|
|
|
|
|
* License, or any later version.
|
|
|
|
|
*
|
|
|
|
|
* This program is distributed in the hope that it will be useful, but
|
|
|
|
|
* WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
|
* General Public License for more details.
|
|
|
|
|
*
|
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
|
* along with this program; if not, write to the Free Software
|
|
|
|
|
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
|
|
|
|
|
* 02110-1301, USA.
|
|
|
|
|
*
|
|
|
|
|
* You can also choose to distribute this program under the terms of
|
|
|
|
|
* the Unmodified Binary Distribution Licence (as given in the file
|
|
|
|
|
* COPYING.UBDL), provided that you have satisfied its requirements.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
FILE_LICENCE ( GPL2_OR_LATER_OR_UBDL );
|
|
|
|
|
|
2024-01-10 15:30:36 +00:00
|
|
|
#include <stdlib.h>
|
[eap] Treat an EAP Request-Identity as indicating a blocked link
A switch port using 802.1x authentication will send EAP
Request-Identity packets once the physical link is up, and will not be
forwarding packets until the port identity has been established.
We do not currently support 802.1x authentication. However, a
reasonably common configuration involves using a preset list of
permitted MAC addresses, with the "authentication" taking place
between the switch and a RADIUS server. In this configuration, the
end device does not need to perform any authentication step, but does
need to be prepared for the switch port to fail to forward packets for
a substantial time after physical link-up. This exactly matches the
"blocked link" semantics already used when detecting a non-forwarding
switch port via LACP or STP.
Treat a received EAP Request-Identity as indicating a blocked link.
Unlike LACP or STP, there is no way to determine the expected time
until the next EAP packet and so we must choose a fixed timeout.
Erroneously assuming that the link is blocked is relatively harmless
since we will still attempt to transmit and receive data even over a
link that is marked as blocked, and so the net effect is merely to
prolong DHCP attempts. In contrast, erroneously assuming that the
link is unblocked will potentially cause DHCP to time out and give up,
resulting in a failed boot.
The default EAP Request-Identity interval in Cisco switches (where
this is most likely to be encountered in practice) is 30 seconds, so
choose 45 seconds as a timeout that is likely to avoid gaps during
which we falsely assume that the link is unblocked.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2021-01-19 12:37:50 +00:00
|
|
|
#include <errno.h>
|
2024-01-10 15:30:36 +00:00
|
|
|
#include <string.h>
|
|
|
|
|
#include <byteswap.h>
|
[eap] Treat an EAP Request-Identity as indicating a blocked link
A switch port using 802.1x authentication will send EAP
Request-Identity packets once the physical link is up, and will not be
forwarding packets until the port identity has been established.
We do not currently support 802.1x authentication. However, a
reasonably common configuration involves using a preset list of
permitted MAC addresses, with the "authentication" taking place
between the switch and a RADIUS server. In this configuration, the
end device does not need to perform any authentication step, but does
need to be prepared for the switch port to fail to forward packets for
a substantial time after physical link-up. This exactly matches the
"blocked link" semantics already used when detecting a non-forwarding
switch port via LACP or STP.
Treat a received EAP Request-Identity as indicating a blocked link.
Unlike LACP or STP, there is no way to determine the expected time
until the next EAP packet and so we must choose a fixed timeout.
Erroneously assuming that the link is blocked is relatively harmless
since we will still attempt to transmit and receive data even over a
link that is marked as blocked, and so the net effect is merely to
prolong DHCP attempts. In contrast, erroneously assuming that the
link is unblocked will potentially cause DHCP to time out and give up,
resulting in a failed boot.
The default EAP Request-Identity interval in Cisco switches (where
this is most likely to be encountered in practice) is 30 seconds, so
choose 45 seconds as a timeout that is likely to avoid gaps during
which we falsely assume that the link is unblocked.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2021-01-19 12:37:50 +00:00
|
|
|
#include <ipxe/netdevice.h>
|
|
|
|
|
#include <ipxe/eap.h>
|
|
|
|
|
|
|
|
|
|
/** @file
|
|
|
|
|
*
|
|
|
|
|
* Extensible Authentication Protocol
|
|
|
|
|
*
|
|
|
|
|
*/
|
|
|
|
|
|
2024-01-10 15:30:36 +00:00
|
|
|
/**
|
|
|
|
|
* Transmit EAP response
|
|
|
|
|
*
|
|
|
|
|
* @v supplicant EAP supplicant
|
|
|
|
|
* @v rsp Response type data
|
|
|
|
|
* @v rsp_len Length of response type data
|
|
|
|
|
* @ret rc Return status code
|
|
|
|
|
*/
|
2024-02-23 12:33:57 +00:00
|
|
|
int eap_tx_response ( struct eap_supplicant *supplicant,
|
|
|
|
|
const void *rsp, size_t rsp_len ) {
|
2024-01-10 15:30:36 +00:00
|
|
|
struct net_device *netdev = supplicant->netdev;
|
|
|
|
|
struct eap_message *msg;
|
|
|
|
|
size_t len;
|
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
|
|
/* Allocate and populate response */
|
|
|
|
|
len = ( sizeof ( *msg ) + rsp_len );
|
|
|
|
|
msg = malloc ( len );
|
|
|
|
|
if ( ! msg ) {
|
|
|
|
|
rc = -ENOMEM;
|
|
|
|
|
goto err_alloc;
|
|
|
|
|
}
|
|
|
|
|
msg->hdr.code = EAP_CODE_RESPONSE;
|
|
|
|
|
msg->hdr.id = supplicant->id;
|
|
|
|
|
msg->hdr.len = htons ( len );
|
|
|
|
|
msg->type = supplicant->type;
|
|
|
|
|
memcpy ( msg->data, rsp, rsp_len );
|
2024-02-23 15:58:51 +00:00
|
|
|
DBGC ( netdev, "EAP %s Response id %#02x type %d\n",
|
|
|
|
|
netdev->name, msg->hdr.id, msg->type );
|
2024-01-10 15:30:36 +00:00
|
|
|
|
|
|
|
|
/* Transmit response */
|
|
|
|
|
if ( ( rc = supplicant->tx ( supplicant, msg, len ) ) != 0 ) {
|
|
|
|
|
DBGC ( netdev, "EAP %s could not transmit: %s\n",
|
|
|
|
|
netdev->name, strerror ( rc ) );
|
|
|
|
|
goto err_tx;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
err_tx:
|
|
|
|
|
free ( msg );
|
|
|
|
|
err_alloc:
|
|
|
|
|
return rc;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Transmit EAP NAK
|
|
|
|
|
*
|
|
|
|
|
* @v supplicant EAP supplicant
|
|
|
|
|
* @ret rc Return status code
|
|
|
|
|
*/
|
|
|
|
|
static int eap_tx_nak ( struct eap_supplicant *supplicant ) {
|
2024-02-23 15:58:51 +00:00
|
|
|
struct net_device *netdev = supplicant->netdev;
|
2024-01-10 15:30:36 +00:00
|
|
|
unsigned int max = table_num_entries ( EAP_METHODS );
|
|
|
|
|
uint8_t methods[ max + 1 /* potential EAP_TYPE_NONE */ ];
|
|
|
|
|
unsigned int count = 0;
|
|
|
|
|
struct eap_method *method;
|
|
|
|
|
|
|
|
|
|
/* Populate methods list */
|
2024-02-23 15:58:51 +00:00
|
|
|
DBGC ( netdev, "EAP %s Nak offering types {", netdev->name );
|
2024-01-10 15:30:36 +00:00
|
|
|
for_each_table_entry ( method, EAP_METHODS ) {
|
2024-02-23 15:58:51 +00:00
|
|
|
if ( method->type > EAP_TYPE_NAK ) {
|
|
|
|
|
DBGC ( netdev, "%s%d",
|
|
|
|
|
( count ? ", " : "" ), method->type );
|
2024-01-10 15:30:36 +00:00
|
|
|
methods[count++] = method->type;
|
2024-02-23 15:58:51 +00:00
|
|
|
}
|
2024-01-10 15:30:36 +00:00
|
|
|
}
|
|
|
|
|
if ( ! count )
|
|
|
|
|
methods[count++] = EAP_TYPE_NONE;
|
2024-02-23 15:58:51 +00:00
|
|
|
DBGC ( netdev, "}\n" );
|
2024-01-10 15:30:36 +00:00
|
|
|
assert ( count <= max );
|
|
|
|
|
|
|
|
|
|
/* Transmit response */
|
|
|
|
|
supplicant->type = EAP_TYPE_NAK;
|
|
|
|
|
return eap_tx_response ( supplicant, methods, count );
|
|
|
|
|
}
|
|
|
|
|
|
[eap] Treat an EAP Request-Identity as indicating a blocked link
A switch port using 802.1x authentication will send EAP
Request-Identity packets once the physical link is up, and will not be
forwarding packets until the port identity has been established.
We do not currently support 802.1x authentication. However, a
reasonably common configuration involves using a preset list of
permitted MAC addresses, with the "authentication" taking place
between the switch and a RADIUS server. In this configuration, the
end device does not need to perform any authentication step, but does
need to be prepared for the switch port to fail to forward packets for
a substantial time after physical link-up. This exactly matches the
"blocked link" semantics already used when detecting a non-forwarding
switch port via LACP or STP.
Treat a received EAP Request-Identity as indicating a blocked link.
Unlike LACP or STP, there is no way to determine the expected time
until the next EAP packet and so we must choose a fixed timeout.
Erroneously assuming that the link is blocked is relatively harmless
since we will still attempt to transmit and receive data even over a
link that is marked as blocked, and so the net effect is merely to
prolong DHCP attempts. In contrast, erroneously assuming that the
link is unblocked will potentially cause DHCP to time out and give up,
resulting in a failed boot.
The default EAP Request-Identity interval in Cisco switches (where
this is most likely to be encountered in practice) is 30 seconds, so
choose 45 seconds as a timeout that is likely to avoid gaps during
which we falsely assume that the link is unblocked.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2021-01-19 12:37:50 +00:00
|
|
|
/**
|
|
|
|
|
* Handle EAP Request-Identity
|
|
|
|
|
*
|
2023-09-15 16:10:07 +01:00
|
|
|
* @v supplicant EAP supplicant
|
2024-01-10 15:30:36 +00:00
|
|
|
* @v req Request type data
|
|
|
|
|
* @v req_len Length of request type data
|
[eap] Treat an EAP Request-Identity as indicating a blocked link
A switch port using 802.1x authentication will send EAP
Request-Identity packets once the physical link is up, and will not be
forwarding packets until the port identity has been established.
We do not currently support 802.1x authentication. However, a
reasonably common configuration involves using a preset list of
permitted MAC addresses, with the "authentication" taking place
between the switch and a RADIUS server. In this configuration, the
end device does not need to perform any authentication step, but does
need to be prepared for the switch port to fail to forward packets for
a substantial time after physical link-up. This exactly matches the
"blocked link" semantics already used when detecting a non-forwarding
switch port via LACP or STP.
Treat a received EAP Request-Identity as indicating a blocked link.
Unlike LACP or STP, there is no way to determine the expected time
until the next EAP packet and so we must choose a fixed timeout.
Erroneously assuming that the link is blocked is relatively harmless
since we will still attempt to transmit and receive data even over a
link that is marked as blocked, and so the net effect is merely to
prolong DHCP attempts. In contrast, erroneously assuming that the
link is unblocked will potentially cause DHCP to time out and give up,
resulting in a failed boot.
The default EAP Request-Identity interval in Cisco switches (where
this is most likely to be encountered in practice) is 30 seconds, so
choose 45 seconds as a timeout that is likely to avoid gaps during
which we falsely assume that the link is unblocked.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2021-01-19 12:37:50 +00:00
|
|
|
* @ret rc Return status code
|
|
|
|
|
*/
|
2024-01-10 15:30:36 +00:00
|
|
|
static int eap_rx_identity ( struct eap_supplicant *supplicant,
|
|
|
|
|
const void *req, size_t req_len ) {
|
2023-09-15 16:10:07 +01:00
|
|
|
struct net_device *netdev = supplicant->netdev;
|
2024-01-10 15:30:36 +00:00
|
|
|
void *rsp;
|
|
|
|
|
int rsp_len;
|
|
|
|
|
int rc;
|
[eap] Treat an EAP Request-Identity as indicating a blocked link
A switch port using 802.1x authentication will send EAP
Request-Identity packets once the physical link is up, and will not be
forwarding packets until the port identity has been established.
We do not currently support 802.1x authentication. However, a
reasonably common configuration involves using a preset list of
permitted MAC addresses, with the "authentication" taking place
between the switch and a RADIUS server. In this configuration, the
end device does not need to perform any authentication step, but does
need to be prepared for the switch port to fail to forward packets for
a substantial time after physical link-up. This exactly matches the
"blocked link" semantics already used when detecting a non-forwarding
switch port via LACP or STP.
Treat a received EAP Request-Identity as indicating a blocked link.
Unlike LACP or STP, there is no way to determine the expected time
until the next EAP packet and so we must choose a fixed timeout.
Erroneously assuming that the link is blocked is relatively harmless
since we will still attempt to transmit and receive data even over a
link that is marked as blocked, and so the net effect is merely to
prolong DHCP attempts. In contrast, erroneously assuming that the
link is unblocked will potentially cause DHCP to time out and give up,
resulting in a failed boot.
The default EAP Request-Identity interval in Cisco switches (where
this is most likely to be encountered in practice) is 30 seconds, so
choose 45 seconds as a timeout that is likely to avoid gaps during
which we falsely assume that the link is unblocked.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2021-01-19 12:37:50 +00:00
|
|
|
|
|
|
|
|
/* Treat Request-Identity as blocking the link */
|
|
|
|
|
DBGC ( netdev, "EAP %s Request-Identity blocking link\n",
|
|
|
|
|
netdev->name );
|
2024-01-10 15:30:36 +00:00
|
|
|
DBGC_HDA ( netdev, 0, req, req_len );
|
[eap] Treat an EAP Request-Identity as indicating a blocked link
A switch port using 802.1x authentication will send EAP
Request-Identity packets once the physical link is up, and will not be
forwarding packets until the port identity has been established.
We do not currently support 802.1x authentication. However, a
reasonably common configuration involves using a preset list of
permitted MAC addresses, with the "authentication" taking place
between the switch and a RADIUS server. In this configuration, the
end device does not need to perform any authentication step, but does
need to be prepared for the switch port to fail to forward packets for
a substantial time after physical link-up. This exactly matches the
"blocked link" semantics already used when detecting a non-forwarding
switch port via LACP or STP.
Treat a received EAP Request-Identity as indicating a blocked link.
Unlike LACP or STP, there is no way to determine the expected time
until the next EAP packet and so we must choose a fixed timeout.
Erroneously assuming that the link is blocked is relatively harmless
since we will still attempt to transmit and receive data even over a
link that is marked as blocked, and so the net effect is merely to
prolong DHCP attempts. In contrast, erroneously assuming that the
link is unblocked will potentially cause DHCP to time out and give up,
resulting in a failed boot.
The default EAP Request-Identity interval in Cisco switches (where
this is most likely to be encountered in practice) is 30 seconds, so
choose 45 seconds as a timeout that is likely to avoid gaps during
which we falsely assume that the link is unblocked.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2021-01-19 12:37:50 +00:00
|
|
|
netdev_link_block ( netdev, EAP_BLOCK_TIMEOUT );
|
|
|
|
|
|
2023-11-07 11:08:33 +00:00
|
|
|
/* Mark EAP as in progress */
|
|
|
|
|
supplicant->flags |= EAP_FL_ONGOING;
|
|
|
|
|
|
2024-01-10 15:30:36 +00:00
|
|
|
/* Construct response, if applicable */
|
|
|
|
|
rsp_len = fetch_raw_setting_copy ( netdev_settings ( netdev ),
|
|
|
|
|
&username_setting, &rsp );
|
|
|
|
|
if ( rsp_len < 0 ) {
|
|
|
|
|
/* We have no identity to offer, so wait until the
|
|
|
|
|
* switch times out and switches to MAC Authentication
|
|
|
|
|
* Bypass (MAB).
|
|
|
|
|
*/
|
|
|
|
|
DBGC2 ( netdev, "EAP %s has no identity\n", netdev->name );
|
|
|
|
|
supplicant->flags |= EAP_FL_PASSIVE;
|
|
|
|
|
rc = 0;
|
|
|
|
|
goto no_response;
|
|
|
|
|
}
|
2023-11-07 11:08:33 +00:00
|
|
|
|
2024-01-10 15:30:36 +00:00
|
|
|
/* Transmit response */
|
|
|
|
|
if ( ( rc = eap_tx_response ( supplicant, rsp, rsp_len ) ) != 0 )
|
|
|
|
|
goto err_tx;
|
|
|
|
|
|
|
|
|
|
err_tx:
|
|
|
|
|
free ( rsp );
|
|
|
|
|
no_response:
|
|
|
|
|
return rc;
|
[eap] Treat an EAP Request-Identity as indicating a blocked link
A switch port using 802.1x authentication will send EAP
Request-Identity packets once the physical link is up, and will not be
forwarding packets until the port identity has been established.
We do not currently support 802.1x authentication. However, a
reasonably common configuration involves using a preset list of
permitted MAC addresses, with the "authentication" taking place
between the switch and a RADIUS server. In this configuration, the
end device does not need to perform any authentication step, but does
need to be prepared for the switch port to fail to forward packets for
a substantial time after physical link-up. This exactly matches the
"blocked link" semantics already used when detecting a non-forwarding
switch port via LACP or STP.
Treat a received EAP Request-Identity as indicating a blocked link.
Unlike LACP or STP, there is no way to determine the expected time
until the next EAP packet and so we must choose a fixed timeout.
Erroneously assuming that the link is blocked is relatively harmless
since we will still attempt to transmit and receive data even over a
link that is marked as blocked, and so the net effect is merely to
prolong DHCP attempts. In contrast, erroneously assuming that the
link is unblocked will potentially cause DHCP to time out and give up,
resulting in a failed boot.
The default EAP Request-Identity interval in Cisco switches (where
this is most likely to be encountered in practice) is 30 seconds, so
choose 45 seconds as a timeout that is likely to avoid gaps during
which we falsely assume that the link is unblocked.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2021-01-19 12:37:50 +00:00
|
|
|
}
|
|
|
|
|
|
2024-01-10 15:30:36 +00:00
|
|
|
/** EAP Request-Identity method */
|
|
|
|
|
struct eap_method eap_identity_method __eap_method = {
|
|
|
|
|
.type = EAP_TYPE_IDENTITY,
|
|
|
|
|
.rx = eap_rx_identity,
|
|
|
|
|
};
|
|
|
|
|
|
[eap] Treat an EAP Request-Identity as indicating a blocked link
A switch port using 802.1x authentication will send EAP
Request-Identity packets once the physical link is up, and will not be
forwarding packets until the port identity has been established.
We do not currently support 802.1x authentication. However, a
reasonably common configuration involves using a preset list of
permitted MAC addresses, with the "authentication" taking place
between the switch and a RADIUS server. In this configuration, the
end device does not need to perform any authentication step, but does
need to be prepared for the switch port to fail to forward packets for
a substantial time after physical link-up. This exactly matches the
"blocked link" semantics already used when detecting a non-forwarding
switch port via LACP or STP.
Treat a received EAP Request-Identity as indicating a blocked link.
Unlike LACP or STP, there is no way to determine the expected time
until the next EAP packet and so we must choose a fixed timeout.
Erroneously assuming that the link is blocked is relatively harmless
since we will still attempt to transmit and receive data even over a
link that is marked as blocked, and so the net effect is merely to
prolong DHCP attempts. In contrast, erroneously assuming that the
link is unblocked will potentially cause DHCP to time out and give up,
resulting in a failed boot.
The default EAP Request-Identity interval in Cisco switches (where
this is most likely to be encountered in practice) is 30 seconds, so
choose 45 seconds as a timeout that is likely to avoid gaps during
which we falsely assume that the link is unblocked.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2021-01-19 12:37:50 +00:00
|
|
|
/**
|
|
|
|
|
* Handle EAP Request
|
|
|
|
|
*
|
2023-09-15 16:10:07 +01:00
|
|
|
* @v supplicant EAP supplicant
|
2024-01-10 15:30:36 +00:00
|
|
|
* @v msg EAP request
|
[eap] Treat an EAP Request-Identity as indicating a blocked link
A switch port using 802.1x authentication will send EAP
Request-Identity packets once the physical link is up, and will not be
forwarding packets until the port identity has been established.
We do not currently support 802.1x authentication. However, a
reasonably common configuration involves using a preset list of
permitted MAC addresses, with the "authentication" taking place
between the switch and a RADIUS server. In this configuration, the
end device does not need to perform any authentication step, but does
need to be prepared for the switch port to fail to forward packets for
a substantial time after physical link-up. This exactly matches the
"blocked link" semantics already used when detecting a non-forwarding
switch port via LACP or STP.
Treat a received EAP Request-Identity as indicating a blocked link.
Unlike LACP or STP, there is no way to determine the expected time
until the next EAP packet and so we must choose a fixed timeout.
Erroneously assuming that the link is blocked is relatively harmless
since we will still attempt to transmit and receive data even over a
link that is marked as blocked, and so the net effect is merely to
prolong DHCP attempts. In contrast, erroneously assuming that the
link is unblocked will potentially cause DHCP to time out and give up,
resulting in a failed boot.
The default EAP Request-Identity interval in Cisco switches (where
this is most likely to be encountered in practice) is 30 seconds, so
choose 45 seconds as a timeout that is likely to avoid gaps during
which we falsely assume that the link is unblocked.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2021-01-19 12:37:50 +00:00
|
|
|
* @v len Length of EAP request
|
|
|
|
|
* @ret rc Return status code
|
|
|
|
|
*/
|
2023-09-15 16:10:07 +01:00
|
|
|
static int eap_rx_request ( struct eap_supplicant *supplicant,
|
2024-01-10 15:30:36 +00:00
|
|
|
const struct eap_message *msg, size_t len ) {
|
2023-09-15 16:10:07 +01:00
|
|
|
struct net_device *netdev = supplicant->netdev;
|
2024-01-10 15:30:36 +00:00
|
|
|
struct eap_method *method;
|
|
|
|
|
const void *req;
|
|
|
|
|
size_t req_len;
|
[eap] Treat an EAP Request-Identity as indicating a blocked link
A switch port using 802.1x authentication will send EAP
Request-Identity packets once the physical link is up, and will not be
forwarding packets until the port identity has been established.
We do not currently support 802.1x authentication. However, a
reasonably common configuration involves using a preset list of
permitted MAC addresses, with the "authentication" taking place
between the switch and a RADIUS server. In this configuration, the
end device does not need to perform any authentication step, but does
need to be prepared for the switch port to fail to forward packets for
a substantial time after physical link-up. This exactly matches the
"blocked link" semantics already used when detecting a non-forwarding
switch port via LACP or STP.
Treat a received EAP Request-Identity as indicating a blocked link.
Unlike LACP or STP, there is no way to determine the expected time
until the next EAP packet and so we must choose a fixed timeout.
Erroneously assuming that the link is blocked is relatively harmless
since we will still attempt to transmit and receive data even over a
link that is marked as blocked, and so the net effect is merely to
prolong DHCP attempts. In contrast, erroneously assuming that the
link is unblocked will potentially cause DHCP to time out and give up,
resulting in a failed boot.
The default EAP Request-Identity interval in Cisco switches (where
this is most likely to be encountered in practice) is 30 seconds, so
choose 45 seconds as a timeout that is likely to avoid gaps during
which we falsely assume that the link is unblocked.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2021-01-19 12:37:50 +00:00
|
|
|
|
2024-01-10 15:30:36 +00:00
|
|
|
/* Sanity checks */
|
|
|
|
|
if ( len < sizeof ( *msg ) ) {
|
[eap] Treat an EAP Request-Identity as indicating a blocked link
A switch port using 802.1x authentication will send EAP
Request-Identity packets once the physical link is up, and will not be
forwarding packets until the port identity has been established.
We do not currently support 802.1x authentication. However, a
reasonably common configuration involves using a preset list of
permitted MAC addresses, with the "authentication" taking place
between the switch and a RADIUS server. In this configuration, the
end device does not need to perform any authentication step, but does
need to be prepared for the switch port to fail to forward packets for
a substantial time after physical link-up. This exactly matches the
"blocked link" semantics already used when detecting a non-forwarding
switch port via LACP or STP.
Treat a received EAP Request-Identity as indicating a blocked link.
Unlike LACP or STP, there is no way to determine the expected time
until the next EAP packet and so we must choose a fixed timeout.
Erroneously assuming that the link is blocked is relatively harmless
since we will still attempt to transmit and receive data even over a
link that is marked as blocked, and so the net effect is merely to
prolong DHCP attempts. In contrast, erroneously assuming that the
link is unblocked will potentially cause DHCP to time out and give up,
resulting in a failed boot.
The default EAP Request-Identity interval in Cisco switches (where
this is most likely to be encountered in practice) is 30 seconds, so
choose 45 seconds as a timeout that is likely to avoid gaps during
which we falsely assume that the link is unblocked.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2021-01-19 12:37:50 +00:00
|
|
|
DBGC ( netdev, "EAP %s underlength request:\n", netdev->name );
|
2024-01-10 15:30:36 +00:00
|
|
|
DBGC_HDA ( netdev, 0, msg, len );
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
if ( len < ntohs ( msg->hdr.len ) ) {
|
|
|
|
|
DBGC ( netdev, "EAP %s truncated request:\n", netdev->name );
|
|
|
|
|
DBGC_HDA ( netdev, 0, msg, len );
|
[eap] Treat an EAP Request-Identity as indicating a blocked link
A switch port using 802.1x authentication will send EAP
Request-Identity packets once the physical link is up, and will not be
forwarding packets until the port identity has been established.
We do not currently support 802.1x authentication. However, a
reasonably common configuration involves using a preset list of
permitted MAC addresses, with the "authentication" taking place
between the switch and a RADIUS server. In this configuration, the
end device does not need to perform any authentication step, but does
need to be prepared for the switch port to fail to forward packets for
a substantial time after physical link-up. This exactly matches the
"blocked link" semantics already used when detecting a non-forwarding
switch port via LACP or STP.
Treat a received EAP Request-Identity as indicating a blocked link.
Unlike LACP or STP, there is no way to determine the expected time
until the next EAP packet and so we must choose a fixed timeout.
Erroneously assuming that the link is blocked is relatively harmless
since we will still attempt to transmit and receive data even over a
link that is marked as blocked, and so the net effect is merely to
prolong DHCP attempts. In contrast, erroneously assuming that the
link is unblocked will potentially cause DHCP to time out and give up,
resulting in a failed boot.
The default EAP Request-Identity interval in Cisco switches (where
this is most likely to be encountered in practice) is 30 seconds, so
choose 45 seconds as a timeout that is likely to avoid gaps during
which we falsely assume that the link is unblocked.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2021-01-19 12:37:50 +00:00
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
2024-01-10 15:30:36 +00:00
|
|
|
req = msg->data;
|
|
|
|
|
req_len = ( ntohs ( msg->hdr.len ) - sizeof ( *msg ) );
|
|
|
|
|
|
|
|
|
|
/* Record request details */
|
|
|
|
|
supplicant->id = msg->hdr.id;
|
|
|
|
|
supplicant->type = msg->type;
|
2024-02-23 15:58:51 +00:00
|
|
|
DBGC ( netdev, "EAP %s Request id %#02x type %d\n",
|
|
|
|
|
netdev->name, msg->hdr.id, msg->type );
|
[eap] Treat an EAP Request-Identity as indicating a blocked link
A switch port using 802.1x authentication will send EAP
Request-Identity packets once the physical link is up, and will not be
forwarding packets until the port identity has been established.
We do not currently support 802.1x authentication. However, a
reasonably common configuration involves using a preset list of
permitted MAC addresses, with the "authentication" taking place
between the switch and a RADIUS server. In this configuration, the
end device does not need to perform any authentication step, but does
need to be prepared for the switch port to fail to forward packets for
a substantial time after physical link-up. This exactly matches the
"blocked link" semantics already used when detecting a non-forwarding
switch port via LACP or STP.
Treat a received EAP Request-Identity as indicating a blocked link.
Unlike LACP or STP, there is no way to determine the expected time
until the next EAP packet and so we must choose a fixed timeout.
Erroneously assuming that the link is blocked is relatively harmless
since we will still attempt to transmit and receive data even over a
link that is marked as blocked, and so the net effect is merely to
prolong DHCP attempts. In contrast, erroneously assuming that the
link is unblocked will potentially cause DHCP to time out and give up,
resulting in a failed boot.
The default EAP Request-Identity interval in Cisco switches (where
this is most likely to be encountered in practice) is 30 seconds, so
choose 45 seconds as a timeout that is likely to avoid gaps during
which we falsely assume that the link is unblocked.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2021-01-19 12:37:50 +00:00
|
|
|
|
|
|
|
|
/* Handle according to type */
|
2024-01-10 15:30:36 +00:00
|
|
|
for_each_table_entry ( method, EAP_METHODS ) {
|
|
|
|
|
if ( msg->type == method->type )
|
|
|
|
|
return method->rx ( supplicant, req, req_len );
|
[eap] Treat an EAP Request-Identity as indicating a blocked link
A switch port using 802.1x authentication will send EAP
Request-Identity packets once the physical link is up, and will not be
forwarding packets until the port identity has been established.
We do not currently support 802.1x authentication. However, a
reasonably common configuration involves using a preset list of
permitted MAC addresses, with the "authentication" taking place
between the switch and a RADIUS server. In this configuration, the
end device does not need to perform any authentication step, but does
need to be prepared for the switch port to fail to forward packets for
a substantial time after physical link-up. This exactly matches the
"blocked link" semantics already used when detecting a non-forwarding
switch port via LACP or STP.
Treat a received EAP Request-Identity as indicating a blocked link.
Unlike LACP or STP, there is no way to determine the expected time
until the next EAP packet and so we must choose a fixed timeout.
Erroneously assuming that the link is blocked is relatively harmless
since we will still attempt to transmit and receive data even over a
link that is marked as blocked, and so the net effect is merely to
prolong DHCP attempts. In contrast, erroneously assuming that the
link is unblocked will potentially cause DHCP to time out and give up,
resulting in a failed boot.
The default EAP Request-Identity interval in Cisco switches (where
this is most likely to be encountered in practice) is 30 seconds, so
choose 45 seconds as a timeout that is likely to avoid gaps during
which we falsely assume that the link is unblocked.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2021-01-19 12:37:50 +00:00
|
|
|
}
|
2024-01-10 15:30:36 +00:00
|
|
|
DBGC ( netdev, "EAP %s requested type %d unknown:\n",
|
|
|
|
|
netdev->name, msg->type );
|
|
|
|
|
DBGC_HDA ( netdev, 0, msg, len );
|
|
|
|
|
|
|
|
|
|
/* Send NAK if applicable */
|
|
|
|
|
if ( msg->type > EAP_TYPE_NAK )
|
|
|
|
|
return eap_tx_nak ( supplicant );
|
|
|
|
|
|
|
|
|
|
return -ENOTSUP;
|
[eap] Treat an EAP Request-Identity as indicating a blocked link
A switch port using 802.1x authentication will send EAP
Request-Identity packets once the physical link is up, and will not be
forwarding packets until the port identity has been established.
We do not currently support 802.1x authentication. However, a
reasonably common configuration involves using a preset list of
permitted MAC addresses, with the "authentication" taking place
between the switch and a RADIUS server. In this configuration, the
end device does not need to perform any authentication step, but does
need to be prepared for the switch port to fail to forward packets for
a substantial time after physical link-up. This exactly matches the
"blocked link" semantics already used when detecting a non-forwarding
switch port via LACP or STP.
Treat a received EAP Request-Identity as indicating a blocked link.
Unlike LACP or STP, there is no way to determine the expected time
until the next EAP packet and so we must choose a fixed timeout.
Erroneously assuming that the link is blocked is relatively harmless
since we will still attempt to transmit and receive data even over a
link that is marked as blocked, and so the net effect is merely to
prolong DHCP attempts. In contrast, erroneously assuming that the
link is unblocked will potentially cause DHCP to time out and give up,
resulting in a failed boot.
The default EAP Request-Identity interval in Cisco switches (where
this is most likely to be encountered in practice) is 30 seconds, so
choose 45 seconds as a timeout that is likely to avoid gaps during
which we falsely assume that the link is unblocked.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2021-01-19 12:37:50 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Handle EAP Success
|
|
|
|
|
*
|
2023-09-15 16:10:07 +01:00
|
|
|
* @v supplicant EAP supplicant
|
[eap] Treat an EAP Request-Identity as indicating a blocked link
A switch port using 802.1x authentication will send EAP
Request-Identity packets once the physical link is up, and will not be
forwarding packets until the port identity has been established.
We do not currently support 802.1x authentication. However, a
reasonably common configuration involves using a preset list of
permitted MAC addresses, with the "authentication" taking place
between the switch and a RADIUS server. In this configuration, the
end device does not need to perform any authentication step, but does
need to be prepared for the switch port to fail to forward packets for
a substantial time after physical link-up. This exactly matches the
"blocked link" semantics already used when detecting a non-forwarding
switch port via LACP or STP.
Treat a received EAP Request-Identity as indicating a blocked link.
Unlike LACP or STP, there is no way to determine the expected time
until the next EAP packet and so we must choose a fixed timeout.
Erroneously assuming that the link is blocked is relatively harmless
since we will still attempt to transmit and receive data even over a
link that is marked as blocked, and so the net effect is merely to
prolong DHCP attempts. In contrast, erroneously assuming that the
link is unblocked will potentially cause DHCP to time out and give up,
resulting in a failed boot.
The default EAP Request-Identity interval in Cisco switches (where
this is most likely to be encountered in practice) is 30 seconds, so
choose 45 seconds as a timeout that is likely to avoid gaps during
which we falsely assume that the link is unblocked.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2021-01-19 12:37:50 +00:00
|
|
|
* @ret rc Return status code
|
|
|
|
|
*/
|
2023-09-15 16:10:07 +01:00
|
|
|
static int eap_rx_success ( struct eap_supplicant *supplicant ) {
|
|
|
|
|
struct net_device *netdev = supplicant->netdev;
|
|
|
|
|
|
|
|
|
|
/* Mark authentication as complete */
|
2023-11-07 11:08:33 +00:00
|
|
|
supplicant->flags = EAP_FL_PASSIVE;
|
[eap] Treat an EAP Request-Identity as indicating a blocked link
A switch port using 802.1x authentication will send EAP
Request-Identity packets once the physical link is up, and will not be
forwarding packets until the port identity has been established.
We do not currently support 802.1x authentication. However, a
reasonably common configuration involves using a preset list of
permitted MAC addresses, with the "authentication" taking place
between the switch and a RADIUS server. In this configuration, the
end device does not need to perform any authentication step, but does
need to be prepared for the switch port to fail to forward packets for
a substantial time after physical link-up. This exactly matches the
"blocked link" semantics already used when detecting a non-forwarding
switch port via LACP or STP.
Treat a received EAP Request-Identity as indicating a blocked link.
Unlike LACP or STP, there is no way to determine the expected time
until the next EAP packet and so we must choose a fixed timeout.
Erroneously assuming that the link is blocked is relatively harmless
since we will still attempt to transmit and receive data even over a
link that is marked as blocked, and so the net effect is merely to
prolong DHCP attempts. In contrast, erroneously assuming that the
link is unblocked will potentially cause DHCP to time out and give up,
resulting in a failed boot.
The default EAP Request-Identity interval in Cisco switches (where
this is most likely to be encountered in practice) is 30 seconds, so
choose 45 seconds as a timeout that is likely to avoid gaps during
which we falsely assume that the link is unblocked.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2021-01-19 12:37:50 +00:00
|
|
|
|
|
|
|
|
/* Mark link as unblocked */
|
|
|
|
|
DBGC ( netdev, "EAP %s Success\n", netdev->name );
|
|
|
|
|
netdev_link_unblock ( netdev );
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Handle EAP Failure
|
|
|
|
|
*
|
2023-09-15 16:10:07 +01:00
|
|
|
* @v supplicant EAP supplicant
|
[eap] Treat an EAP Request-Identity as indicating a blocked link
A switch port using 802.1x authentication will send EAP
Request-Identity packets once the physical link is up, and will not be
forwarding packets until the port identity has been established.
We do not currently support 802.1x authentication. However, a
reasonably common configuration involves using a preset list of
permitted MAC addresses, with the "authentication" taking place
between the switch and a RADIUS server. In this configuration, the
end device does not need to perform any authentication step, but does
need to be prepared for the switch port to fail to forward packets for
a substantial time after physical link-up. This exactly matches the
"blocked link" semantics already used when detecting a non-forwarding
switch port via LACP or STP.
Treat a received EAP Request-Identity as indicating a blocked link.
Unlike LACP or STP, there is no way to determine the expected time
until the next EAP packet and so we must choose a fixed timeout.
Erroneously assuming that the link is blocked is relatively harmless
since we will still attempt to transmit and receive data even over a
link that is marked as blocked, and so the net effect is merely to
prolong DHCP attempts. In contrast, erroneously assuming that the
link is unblocked will potentially cause DHCP to time out and give up,
resulting in a failed boot.
The default EAP Request-Identity interval in Cisco switches (where
this is most likely to be encountered in practice) is 30 seconds, so
choose 45 seconds as a timeout that is likely to avoid gaps during
which we falsely assume that the link is unblocked.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2021-01-19 12:37:50 +00:00
|
|
|
* @ret rc Return status code
|
|
|
|
|
*/
|
2023-09-15 16:10:07 +01:00
|
|
|
static int eap_rx_failure ( struct eap_supplicant *supplicant ) {
|
|
|
|
|
struct net_device *netdev = supplicant->netdev;
|
|
|
|
|
|
|
|
|
|
/* Mark authentication as complete */
|
2023-11-07 11:08:33 +00:00
|
|
|
supplicant->flags = EAP_FL_PASSIVE;
|
[eap] Treat an EAP Request-Identity as indicating a blocked link
A switch port using 802.1x authentication will send EAP
Request-Identity packets once the physical link is up, and will not be
forwarding packets until the port identity has been established.
We do not currently support 802.1x authentication. However, a
reasonably common configuration involves using a preset list of
permitted MAC addresses, with the "authentication" taking place
between the switch and a RADIUS server. In this configuration, the
end device does not need to perform any authentication step, but does
need to be prepared for the switch port to fail to forward packets for
a substantial time after physical link-up. This exactly matches the
"blocked link" semantics already used when detecting a non-forwarding
switch port via LACP or STP.
Treat a received EAP Request-Identity as indicating a blocked link.
Unlike LACP or STP, there is no way to determine the expected time
until the next EAP packet and so we must choose a fixed timeout.
Erroneously assuming that the link is blocked is relatively harmless
since we will still attempt to transmit and receive data even over a
link that is marked as blocked, and so the net effect is merely to
prolong DHCP attempts. In contrast, erroneously assuming that the
link is unblocked will potentially cause DHCP to time out and give up,
resulting in a failed boot.
The default EAP Request-Identity interval in Cisco switches (where
this is most likely to be encountered in practice) is 30 seconds, so
choose 45 seconds as a timeout that is likely to avoid gaps during
which we falsely assume that the link is unblocked.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2021-01-19 12:37:50 +00:00
|
|
|
|
|
|
|
|
/* Record error */
|
|
|
|
|
DBGC ( netdev, "EAP %s Failure\n", netdev->name );
|
|
|
|
|
return -EPERM;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Handle EAP packet
|
|
|
|
|
*
|
2023-09-15 16:10:07 +01:00
|
|
|
* @v supplicant EAP supplicant
|
[eap] Treat an EAP Request-Identity as indicating a blocked link
A switch port using 802.1x authentication will send EAP
Request-Identity packets once the physical link is up, and will not be
forwarding packets until the port identity has been established.
We do not currently support 802.1x authentication. However, a
reasonably common configuration involves using a preset list of
permitted MAC addresses, with the "authentication" taking place
between the switch and a RADIUS server. In this configuration, the
end device does not need to perform any authentication step, but does
need to be prepared for the switch port to fail to forward packets for
a substantial time after physical link-up. This exactly matches the
"blocked link" semantics already used when detecting a non-forwarding
switch port via LACP or STP.
Treat a received EAP Request-Identity as indicating a blocked link.
Unlike LACP or STP, there is no way to determine the expected time
until the next EAP packet and so we must choose a fixed timeout.
Erroneously assuming that the link is blocked is relatively harmless
since we will still attempt to transmit and receive data even over a
link that is marked as blocked, and so the net effect is merely to
prolong DHCP attempts. In contrast, erroneously assuming that the
link is unblocked will potentially cause DHCP to time out and give up,
resulting in a failed boot.
The default EAP Request-Identity interval in Cisco switches (where
this is most likely to be encountered in practice) is 30 seconds, so
choose 45 seconds as a timeout that is likely to avoid gaps during
which we falsely assume that the link is unblocked.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2021-01-19 12:37:50 +00:00
|
|
|
* @v data EAP packet
|
|
|
|
|
* @v len Length of EAP packet
|
|
|
|
|
* @ret rc Return status code
|
|
|
|
|
*/
|
2023-09-15 16:10:07 +01:00
|
|
|
int eap_rx ( struct eap_supplicant *supplicant, const void *data,
|
|
|
|
|
size_t len ) {
|
|
|
|
|
struct net_device *netdev = supplicant->netdev;
|
[eap] Treat an EAP Request-Identity as indicating a blocked link
A switch port using 802.1x authentication will send EAP
Request-Identity packets once the physical link is up, and will not be
forwarding packets until the port identity has been established.
We do not currently support 802.1x authentication. However, a
reasonably common configuration involves using a preset list of
permitted MAC addresses, with the "authentication" taking place
between the switch and a RADIUS server. In this configuration, the
end device does not need to perform any authentication step, but does
need to be prepared for the switch port to fail to forward packets for
a substantial time after physical link-up. This exactly matches the
"blocked link" semantics already used when detecting a non-forwarding
switch port via LACP or STP.
Treat a received EAP Request-Identity as indicating a blocked link.
Unlike LACP or STP, there is no way to determine the expected time
until the next EAP packet and so we must choose a fixed timeout.
Erroneously assuming that the link is blocked is relatively harmless
since we will still attempt to transmit and receive data even over a
link that is marked as blocked, and so the net effect is merely to
prolong DHCP attempts. In contrast, erroneously assuming that the
link is unblocked will potentially cause DHCP to time out and give up,
resulting in a failed boot.
The default EAP Request-Identity interval in Cisco switches (where
this is most likely to be encountered in practice) is 30 seconds, so
choose 45 seconds as a timeout that is likely to avoid gaps during
which we falsely assume that the link is unblocked.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2021-01-19 12:37:50 +00:00
|
|
|
const union eap_packet *eap = data;
|
|
|
|
|
|
|
|
|
|
/* Sanity check */
|
|
|
|
|
if ( len < sizeof ( eap->hdr ) ) {
|
|
|
|
|
DBGC ( netdev, "EAP %s underlength header:\n", netdev->name );
|
|
|
|
|
DBGC_HDA ( netdev, 0, eap, len );
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Handle according to code */
|
|
|
|
|
switch ( eap->hdr.code ) {
|
|
|
|
|
case EAP_CODE_REQUEST:
|
2024-01-10 15:30:36 +00:00
|
|
|
return eap_rx_request ( supplicant, &eap->msg, len );
|
2024-01-10 15:28:59 +00:00
|
|
|
case EAP_CODE_RESPONSE:
|
|
|
|
|
DBGC2 ( netdev, "EAP %s ignoring response\n", netdev->name );
|
|
|
|
|
return 0;
|
[eap] Treat an EAP Request-Identity as indicating a blocked link
A switch port using 802.1x authentication will send EAP
Request-Identity packets once the physical link is up, and will not be
forwarding packets until the port identity has been established.
We do not currently support 802.1x authentication. However, a
reasonably common configuration involves using a preset list of
permitted MAC addresses, with the "authentication" taking place
between the switch and a RADIUS server. In this configuration, the
end device does not need to perform any authentication step, but does
need to be prepared for the switch port to fail to forward packets for
a substantial time after physical link-up. This exactly matches the
"blocked link" semantics already used when detecting a non-forwarding
switch port via LACP or STP.
Treat a received EAP Request-Identity as indicating a blocked link.
Unlike LACP or STP, there is no way to determine the expected time
until the next EAP packet and so we must choose a fixed timeout.
Erroneously assuming that the link is blocked is relatively harmless
since we will still attempt to transmit and receive data even over a
link that is marked as blocked, and so the net effect is merely to
prolong DHCP attempts. In contrast, erroneously assuming that the
link is unblocked will potentially cause DHCP to time out and give up,
resulting in a failed boot.
The default EAP Request-Identity interval in Cisco switches (where
this is most likely to be encountered in practice) is 30 seconds, so
choose 45 seconds as a timeout that is likely to avoid gaps during
which we falsely assume that the link is unblocked.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2021-01-19 12:37:50 +00:00
|
|
|
case EAP_CODE_SUCCESS:
|
2023-09-15 16:10:07 +01:00
|
|
|
return eap_rx_success ( supplicant );
|
[eap] Treat an EAP Request-Identity as indicating a blocked link
A switch port using 802.1x authentication will send EAP
Request-Identity packets once the physical link is up, and will not be
forwarding packets until the port identity has been established.
We do not currently support 802.1x authentication. However, a
reasonably common configuration involves using a preset list of
permitted MAC addresses, with the "authentication" taking place
between the switch and a RADIUS server. In this configuration, the
end device does not need to perform any authentication step, but does
need to be prepared for the switch port to fail to forward packets for
a substantial time after physical link-up. This exactly matches the
"blocked link" semantics already used when detecting a non-forwarding
switch port via LACP or STP.
Treat a received EAP Request-Identity as indicating a blocked link.
Unlike LACP or STP, there is no way to determine the expected time
until the next EAP packet and so we must choose a fixed timeout.
Erroneously assuming that the link is blocked is relatively harmless
since we will still attempt to transmit and receive data even over a
link that is marked as blocked, and so the net effect is merely to
prolong DHCP attempts. In contrast, erroneously assuming that the
link is unblocked will potentially cause DHCP to time out and give up,
resulting in a failed boot.
The default EAP Request-Identity interval in Cisco switches (where
this is most likely to be encountered in practice) is 30 seconds, so
choose 45 seconds as a timeout that is likely to avoid gaps during
which we falsely assume that the link is unblocked.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2021-01-19 12:37:50 +00:00
|
|
|
case EAP_CODE_FAILURE:
|
2023-09-15 16:10:07 +01:00
|
|
|
return eap_rx_failure ( supplicant );
|
[eap] Treat an EAP Request-Identity as indicating a blocked link
A switch port using 802.1x authentication will send EAP
Request-Identity packets once the physical link is up, and will not be
forwarding packets until the port identity has been established.
We do not currently support 802.1x authentication. However, a
reasonably common configuration involves using a preset list of
permitted MAC addresses, with the "authentication" taking place
between the switch and a RADIUS server. In this configuration, the
end device does not need to perform any authentication step, but does
need to be prepared for the switch port to fail to forward packets for
a substantial time after physical link-up. This exactly matches the
"blocked link" semantics already used when detecting a non-forwarding
switch port via LACP or STP.
Treat a received EAP Request-Identity as indicating a blocked link.
Unlike LACP or STP, there is no way to determine the expected time
until the next EAP packet and so we must choose a fixed timeout.
Erroneously assuming that the link is blocked is relatively harmless
since we will still attempt to transmit and receive data even over a
link that is marked as blocked, and so the net effect is merely to
prolong DHCP attempts. In contrast, erroneously assuming that the
link is unblocked will potentially cause DHCP to time out and give up,
resulting in a failed boot.
The default EAP Request-Identity interval in Cisco switches (where
this is most likely to be encountered in practice) is 30 seconds, so
choose 45 seconds as a timeout that is likely to avoid gaps during
which we falsely assume that the link is unblocked.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2021-01-19 12:37:50 +00:00
|
|
|
default:
|
|
|
|
|
DBGC ( netdev, "EAP %s unsupported code %d\n",
|
|
|
|
|
netdev->name, eap->hdr.code );
|
|
|
|
|
DBGC_HDA ( netdev, 0, eap, len );
|
|
|
|
|
return -ENOTSUP;
|
|
|
|
|
}
|
|
|
|
|
}
|
2024-02-23 12:33:57 +00:00
|
|
|
|
|
|
|
|
/* Drag in objects via eap_rx() */
|
|
|
|
|
REQUIRING_SYMBOL ( eap_rx );
|
|
|
|
|
|
|
|
|
|
/* Drag in EAP configuration */
|
|
|
|
|
REQUIRE_OBJECT ( config_eap );
|