Problem using AF_PACKET with SOCK_RAW on ieee802514 devices

protocol = htons(syscall.ETH_P_IEEE802154) syscall.Socket(syscall.AF_PACKET, syscall.SOCK_RAW, int(protocol))

} else if (sock->type != SOCK_RAW && reserve {
	skb_push(skb, reserve);
}

Hello everyone (again)!

I am using the linux-wpan stack with the atusb and at86rf230 drivers (rf212). Moreover i am using raw sockets to test some userspace implemenation of a custom protocol. In userspace i am using (attention, golang ahead)

Quoted 2 lines

protocol = htons(syscall.ETH_P_IEEE802154) syscall.Socket(syscall.AF_PACKET, syscall.SOCK_RAW, int(protocol))

to create a raw socket. This has been working as desired up until commit
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?
id=b84bbaf7a6c8cca24f8acf25a2c8e46913a947ba

After this commit the kernel mistakenly attaches two uninitialized bytes at the end of my raw data. I am currently using a patched kernel which uses the following code in af_packet.c (Modified the else if over Willem de Brujin's patch)

Quoted 3 lines

} else if (sock->type != SOCK_RAW && reserve {
	skb_push(skb, reserve);
}

Quoted 14 lines · Josef Filzmaier

Hello everyone (again)!

I am using the linux-wpan stack with the atusb and at86rf230 drivers (rf212). Moreover i am using raw sockets to test some userspace implemenation of a custom protocol. In userspace i am using (attention, golang ahead)>

Quoted 2 lines

protocol = htons(syscall.ETH_P_IEEE802154) syscall.Socket(syscall.AF_PACKET, syscall.SOCK_RAW, int(protocol))

to create a raw socket. This has been working as desired up until commit
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/
?
id=b84bbaf7a6c8cca24f8acf25a2c8e46913a947ba

Quoted 11 lines

After this commit the kernel mistakenly attaches two uninitialized bytes at
the end of my raw data. I am currently using a patched kernel which uses the following code in af_packet.c (Modified the else if over Willem de Brujin's patch)

Quoted 5 lines

} else if (sock->type != SOCK_RAW && reserve {

	skb_push(skb, reserve);

}

Check commit 9aad13b087ab ("packet: fix reserve calculation").

Push is definitely wrong here and breaks things. dev_hard_header_len is the minimum size what we allow to the driver level.

This should be 3 (can you please check that if it's 2 or 3 I think there was some off-by one fix lately and I had it on the list).

It's because drivers parse FC and SEQ, this is what I have in the architecture yet. There exists drivers which doing more but this is a whole other big issue.

- Alex

This should be 3 (can you please check that if it's 2 or 3 I think there was some off-by one fix lately and I had it on the list).

Quoted 39 lines · On Donnerstag, 14. Juni 2018 16:20:36 CEST you wrote:

Quoted 14 lines · Josef Filzmaier

Hello everyone (again)!

I am using the linux-wpan stack with the atusb and at86rf230 drivers (rf212). Moreover i am using raw sockets to test some userspace implemenation of a custom protocol. In userspace i am using (attention, golang ahead)>

Quoted 2 lines

protocol = htons(syscall.ETH_P_IEEE802154) syscall.Socket(syscall.AF_PACKET, syscall.SOCK_RAW, int(protocol))

to create a raw socket. This has been working as desired up until commit
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/
?
id=b84bbaf7a6c8cca24f8acf25a2c8e46913a947ba

Quoted 11 lines

After this commit the kernel mistakenly attaches two uninitialized bytes at
the end of my raw data. I am currently using a patched kernel which uses the following code in af_packet.c (Modified the else if over Willem de Brujin's patch)

Quoted 5 lines

} else if (sock->type != SOCK_RAW && reserve {

	skb_push(skb, reserve);

}

Check commit 9aad13b087ab ("packet: fix reserve calculation").

Push is definitely wrong here and breaks things. dev_hard_header_len is the minimum size what we allow to the driver level.

This should be 3 (can you please check that if it's 2 or 3 I think there was some off-by one fix lately and I had it on the list).

It's because drivers parse FC and SEQ, this is what I have in the architecture yet. There exists drivers which doing more but this is a whole other big issue.

Quoted 1 line

- Alex

Yes, applying 9aad13b087ab also fixes my problem.

Quoted 2 lines

This should be 3 (can you please check that if it's 2 or 3 I think there was some off-by one fix lately and I had it on the list).

I just tested, dev->hard_header_len = 2

When is this patch going to be applied to the mainline kernel? Is there any way in which i can know that it will be applied to the 4.16.x series?

Also do you use RPi kernel?

Hi,

Quoted 46 lines · Josef Filzmaier

Quoted 45 lines · On Donnerstag, 14. Juni 2018 16:20:36 CEST you wrote:

Quoted 18 lines · Josef Filzmaier

Hello everyone (again)!

I am using the linux-wpan stack with the atusb and at86rf230 drivers (rf212). Moreover i am using raw sockets to test some userspace implemenation of a custom protocol. In userspace i am using (attention,
golang ahead)>

Quoted 2 lines

protocol = htons(syscall.ETH_P_IEEE802154) syscall.Socket(syscall.AF_PACKET, syscall.SOCK_RAW, int(protocol))

to create a raw socket. This has been working as desired up until commit
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/com
mit/
?
id=b84bbaf7a6c8cca24f8acf25a2c8e46913a947ba

Quoted 13 lines

After this commit the kernel mistakenly attaches two uninitialized bytes
at
the end of my raw data. I am currently using a patched kernel which uses
the following code in af_packet.c (Modified the else if over Willem de Brujin's patch)

Quoted 5 lines

} else if (sock->type != SOCK_RAW && reserve {

	skb_push(skb, reserve);

}

Check commit 9aad13b087ab ("packet: fix reserve calculation").

Push is definitely wrong here and breaks things. dev_hard_header_len is the minimum size what we allow to the driver level.

This should be 3 (can you please check that if it's 2 or 3 I think there was some off-by one fix lately and I had it on the list).

It's because drivers parse FC and SEQ, this is what I have in the architecture yet. There exists drivers which doing more but this is a whole other big issue.

Quoted 8 lines

Quoted 1 line

- Alex

Yes, applying 9aad13b087ab also fixes my problem.

Quoted 2 lines

This should be 3 (can you please check that if it's 2 or 3 I think there was some off-by one fix lately and I had it on the list).

I just tested, dev->hard_header_len = 2

Good then we need to remove the -1 calculation since they changed it.

Quoted 3 lines

When is this patch going to be applied to the mainline kernel? Is there any
way in which i can know that it will be applied to the 4.16.x series?

It's already there [0]. When there is a new stable release everybody need to switch to it. If your distribution is too slow you need to blame them.

Also do you use RPi kernel? I got recently reported some issue with and like to know if there is somebody outside who has problems as well. Mostly report "again" about garbage data on the bus, it's not the first time when things works on mainline but not on rpi kernel.

I don't give any support on rpi kernel and it's a mess that people report problems when they tested it only on RPi kernel.

- Alex

[0]
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/log
/net/packet/af_packet.c?h=v4.16.15 --
To unsubscribe from this list: send the line "unsubscribe linux-wpan" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Hi!

Quoted 1 line

Also do you use RPi kernel?

I first encountered this problem on arch linux (x86_64) with its current stable kernel (4.16.13) using the ATUSB firmware. Then i encountered the same problem on a raspberry pi using raspbian with a rf212 directly over the spi interface. (Custom compiled kernel to debug, 4.16.14).