On Fri, Oct 16, 2020 at 09:04:38AM +0200, Christian Eggers wrote:
> IPV4_HLEN() is only used for PTP. Is there any way to use "normal"
> infrastructure as in the rest of the network stack?
You answered your own question...
> It looks like PTP code
> typically has to look into multiple network lay
On Thursday, 15 October 2020, 18:56:41 CEST, Florian Fainelli wrote:
> Having recently helped someone with a bug that involved using
> IPV4_HLEN() instead of ip_hdr() in a driver's transmit path (so with the
> transport header correctly set), it would probably help if we could make
> IPV4_HLEN()'s
On 10/14/20 8:36 PM, Richard Cochran wrote:
> On Wed, Oct 14, 2020 at 01:58:05PM +0200, Christian Eggers wrote:
>> Both macros are already marked for removal.
>
> I'm not sure what Daniel Borkmann meant by that comment, but ...
>
>> switch (type & PTP_CLASS_PMASK) {
>> case PTP_CLASS_IP
On Wed, Oct 14, 2020 at 01:58:05PM +0200, Christian Eggers wrote:
> Both macros are already marked for removal.
I'm not sure what Daniel Borkmann meant by that comment, but ...
> switch (type & PTP_CLASS_PMASK) {
> case PTP_CLASS_IPV4:
> - ptr += IPV4_HLEN(ptr) + UDP_HLEN;
Both macros are already marked for removal. IPV4_HLEN(data) is
misleading as it expects an Ethernet header instead of an IPv4 header as
argument. Because it is defined (and only used) within PTP, it should be
named PTP_IPV4_HLEN or similar.
As the whole rest of the IPv4 stack has no problems using
