Workaround for trailing data on AARP packets

This commit is contained in:
Josh Deprez 2024-06-16 10:21:56 +10:00
parent d498f5d6cc
commit 2f1b4c1ce1
Signed by: josh
SSH key fingerprint: SHA256:zZji7w1Ilh2RuUpbQcqkLPrqmRwpiCSycbF2EfKm6Kw

View file

@ -37,6 +37,8 @@ const (
maxAMTEntryAge = 30 * time.Second maxAMTEntryAge = 30 * time.Second
aarpRequestRetransmit = 1 * time.Second aarpRequestRetransmit = 1 * time.Second
aarpRequestTimeout = 10 * time.Second aarpRequestTimeout = 10 * time.Second
aarpBodyLength = 28 // bytes
) )
const aarpStatusTemplate = ` const aarpStatusTemplate = `
@ -181,8 +183,17 @@ func (a *AARPMachine) Run(ctx context.Context) error {
a.incomingCh = nil a.incomingCh = nil
} }
// sfiera/multitalk will return an "excess data" error if the
// payload is too big. Most traffic I've seen locally does not have
// this problem, but I've seen one report with some junk trailing
// data on AARP packets.
payload := ethFrame.Payload
if len(payload) > aarpBodyLength {
payload = payload[:aarpBodyLength]
}
var aapkt aarp.Packet var aapkt aarp.Packet
if err := aarp.Unmarshal(ethFrame.Payload, &aapkt); err != nil { if err := aarp.Unmarshal(payload, &aapkt); err != nil {
log.Printf("Couldn't unmarshal AARP packet: %v", err) log.Printf("Couldn't unmarshal AARP packet: %v", err)
continue continue
} }