Alexander Aring <alex.aring@xxxxxxxxx> wrote:
> New behaviour?:
> The new behaviour should also deal with hardware where we don't get FCS
> information from hardware (cc2520 in non promicuousmode is such
> hardware).
Nice.
> Important node - you can change this behaviour for monitors:
> Rx: while monitor interface generation you can decide if you want FCS
> Tx: while monitor interface generation you can decide if you want to
> send FCS
Do you return FCS as auxdata if asked for?
> If the hardware doesn't support that - it will not allow you to generate
> such interface.
Do you mean, if the hardware can't return FCS? Or insists on generating FCS
itself?
> IMPORTANT NOTE:
> This will of course break userspace software - fix should be simple, but
> it's already broken somehow. E.g. tx with wireshark, it thinks there is
> a FCS there, but there is no FCS...
> We should fix all userspace software afterwards...
> What we need is just some behaviour which everybody acks now and we
> don't touch it again! Please comment this mail with your opinions about
> default behaviours of FCS and different interface types (node vs
> monitor) in combination with AF_PACKET RAW.
It is unfortunate, but I think that the number of people doing monitoring
on 15.4 is relatively small, and it's mostly with wireshark.
Is there a way to determine old behaviour vs new behaviour?
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] mcr@xxxxxxxxxxxx http://www.sandelman.ca/ | ruby on rails [
Attachment:
signature.asc
Description: PGP signature
