On 10/24/2016 09:36 PM, John Young wrote:
> Yes. Thanks. It results from my motivation to observe EdcaTxopN. In
> laa+wifi scenario where laa uses channelManager "Default", and udp
> traffic type is transported, I hope to see packets are held up in
> wifiAp's queue and can not be sent till being dropped, or maybe their
> waiting time to be longer. However, I do not even find the packets goes
> into the queue. And I try to figure it out with Log. I find that for
> laa+wifi scenario, after Node::ReceiveFromDevice() is called,
> WifiNetDevice::Send() is not invoked, which happens in wifi+wifi scenario.
>
> I'm not sure if I make it clear or provide useful information to
> reproduce it.
You seem to be saying for a certain WiFi AP in one operator network,
when the other operator network is WiFi, you observe
WifiNetDevice::Send() log statements on that AP, but when you change the
other operator network to LAA, the same WiFi AP does not exhibit
WifiNetDevice::Send () log messages anymore?
Perhaps the messages do not get forwarded from the IP layer because ARP
resolution failed? I think that you need to trace via debugging or
logging whether the packets get through the Ipv4L3Protocol, ArpCache,
ArpL3Protocol, Ipv4Interface objects if you do not see them showing up
on WifiNetDevice.
- Tom