> However, I'm not quite sure about receiving.
> I see an "addmulti" in ip(3) but I don't quite understand the comment
> and I couldn't penetrate the source.
what comment? unfortunately, where ip(3) says
"media address", i think it really means ip address.
the code says it accepts
addmulti $rxaddr $multiaddr
or
addmulti $multiaddr # assume $rxaddr = normal rec. addr
ip(3) is quite unclear (to me, anyway) about the
differences between the ip stack's notions and
the interface' notions. perhaps i notice because
we send a lot of non-ip traffic.
in the case of multicast mac addresses, ip tries to
bridge the gap. but i don't think that current hardware
works this way. modern hardware tends to hash
multicast *ethernet* addresses, but not ip addresses.
and that's the way that addmulti/remmulti are implemented
in netif.c and /sys/src/9/pc/ether[a-z]*.c:/^[a-z0-9]+multicast
mind the gap!
also for mtu, ip assumes that it is fixed per medium,
and not per hardware device. this bit from ip(3) is misleading.
- The
- .I mtu
- is the size in bytes of the largest packet that this interface can send.
the mtu for ip(3) is the largest packet that ip tries to send.
this may be larger (that is, misconfigured), smaller or the same
as the interface mtu. in 9atom, the interface mtu may be
set by
echo mtu 9000 > /net/ether0/clone
and the /net/ether0/mtu file has the mintu mtu and maxtu.
i have been meaning to let ip discover the current mtu
by reading it from the device, but i need a solution that will
keep the mtu high for aoe even if ip wants it at 1514 to allow
ip to make sure that its idea of the interface (media) mtu
isn't wrong. i'm also somewhat uncomfortable with managing
the interface via an ip proxy.
we routinely mix 8228-byte aoe packets with 1514-byte ip
packets. the interface's mtu is set to 9000, while the ip stack's
mtu is set to 1514.
to sum up, i think there is a little confusion in the code.
i'd be interested in your results.
- erik
