This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.
laforge gerrit-no-reply at lists.osmocom.orglaforge has posted comments on this change. ( https://gerrit.osmocom.org/c/libosmocore/+/22909 )
Change subject: gprs_ns2_fr: pass MTU changes to the NSE
......................................................................
Patch Set 1:
(3 comments)
https://gerrit.osmocom.org/c/libosmocore/+/22909/1//COMMIT_MSG
Commit Message:
https://gerrit.osmocom.org/c/libosmocore/+/22909/1//COMMIT_MSG@9
PS1, Line 9: W
In practice, I wouldn't really expect the MTU to change at runtime at all. I'm not even sure it can happen while the device is up. It's purely hypothetical in all practical deployments, IMHO.
What does matter is that we determine the MTU of the underlying network device at least once when we open the AF_PACKET socket, rather than using our compile-time default.
This can likely be achieved the same way (if we have mnl support included), but the commit should then emphasize the important use case, rather than the esoteric one.
https://gerrit.osmocom.org/c/libosmocore/+/22909/1//COMMIT_MSG@12
PS1, Line 12: T
I would suggest to extend the STATUS primitive from NS to BSSGP
https://gerrit.osmocom.org/c/libosmocore/+/22909/1/src/gb/gprs_ns2_fr.c
File src/gb/gprs_ns2_fr.c:
https://gerrit.osmocom.org/c/libosmocore/+/22909/1/src/gb/gprs_ns2_fr.c@610
PS1, Line 610: /* 2 byte DLCI header */
: bind->mtu = mtu - 2;
I was not entirely sure about that part. AFAIR the AF_PACKET/SOCK_RAW code internally manages this somehow and adds size of the header.
See https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/packet/af_packet.c#n2940
"(len > dev->mtu + reserve + VLAN_HLEN + extra_len)" is the actual conditoion, and "reserve" corresponds to dev->hard_header_len. This normally is the size of an ethernet header on ethernet-style devices. So I would have assumed it's the size of a FR header on a HDLC/FR device.
However, much to my surprise. hdlc_fr.c actually sets hard_header_len to zero, so it seems you're right.
--
To view, visit https://gerrit.osmocom.org/c/libosmocore/+/22909
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: libosmocore
Gerrit-Branch: master
Gerrit-Change-Id: I946f7655c9526ffd98dabdce219c6a419b71e00c
Gerrit-Change-Number: 22909
Gerrit-PatchSet: 1
Gerrit-Owner: lynxis lazus <lynxis at fe80.eu>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: daniel <dwillmann at sysmocom.de>
Gerrit-Reviewer: laforge <laforge at osmocom.org>
Gerrit-Comment-Date: Mon, 15 Feb 2021 10:55:30 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Gerrit-MessageType: comment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20210215/cabf7fa9/attachment.htm>