Open murillo128 opened 1 year ago
I was afraid this would come to haunt us at some point. see #19 for context. TL;DR: I was assuming structs used in Netlink APIs would not grow in the future (since attributes are the preferred mechanism for extensibility). I was wrong.
the mechanism mentioned in that issue was never implemented, so for now I could manually remove the length check for that particular struct, since it seems to be the only one that gives us problems.
i assume new attributes would be added to the end of the struct, so we could just check if length is bigger or equal.
yes, by "removing" I actually meant "relaxing". yes, new attributes are always added at the end, never removed. by relaxing the length check we'd be silently discarding the extra data, which will work for now. eventually someone will complain they can't access the newly added fields though.
the thing is that the parsing code is autogenerated from the type definitions, so modifying the generated code is hacky. ideally we should add the ability to mark structs as "expandable" in the types, and this will instruct the code generator to relax the length check and put extra data in an __unparsed
field.
the thing is that the parsing code is autogenerated from the type definitions, so modifying the generated code is hacky. ideally we should add the ability to mark structs as "expandable" in the types, and this will instruct the code generator to relax the length check and put extra data in an __unparsed field.
ended up doing this. output of getLink()
now looks like:
{
// ...
stats64: {
rxPackets: 35n,
txPackets: 35n,
rxBytes: 3008n,
txBytes: 3008n,
rxErrors: 0n,
txErrors: 0n,
rxDropped: 0n,
txDropped: 0n,
multicast: 0n,
collisions: 0n,
rxLengthErrors: 0n,
rxOverErrors: 0n,
rxCrcErrors: 0n,
rxFrameErrors: 0n,
rxFifoErrors: 0n,
rxMissedErrors: 0n,
txAbortedErrors: 0n,
txCarrierErrors: 0n,
txFifoErrors: 0n,
txHeartbeatErrors: 0n,
txWindowErrors: 0n,
rxCompressed: 0n,
txCompressed: 0n,
__unparsed: <Buffer 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00>
},
stats: {
rxPackets: 35,
txPackets: 35,
rxBytes: 3008,
txBytes: 3008,
rxErrors: 0,
txErrors: 0,
rxDropped: 0,
txDropped: 0,
multicast: 0,
collisions: 0,
rxLengthErrors: 0,
rxOverErrors: 0,
rxCrcErrors: 0,
rxFrameErrors: 0,
rxFifoErrors: 0,
rxMissedErrors: 0,
txAbortedErrors: 0,
txCarrierErrors: 0,
txFifoErrors: 0,
txHeartbeatErrors: 0,
txWindowErrors: 0,
rxCompressed: 0,
txCompressed: 0,
__unparsed: <Buffer 00 00 00 00>
},
// ...
}
note that the rxNohandler
field is no longer parsed (breaking change), but OTOH the error is now gone for all versions of Linux.
0.3.0 is up on NPM. let's not close this issue, because this is just a workaround.
Seems that the LinkStats64 message length is set to 192 in
export const __LENGTH_LinkStats = 96
However I am getting a message length of 200, which seems to be the correct one:
https://www.kernel.org/doc/html/next/networking/statistics.html#c.rtnl_link_stats64