Manmita Das (2da48b64) at 20 Mar 16:32

... and 1 more commit

Manmita Das (64347e15) at 20 Mar 08:56

@tommypec

I had another question about using bind(Address): from what I could find, % is only valid for link-local IPv6 addresses.

root@localhost:~# ping6 20:20:20:20:20:20:20:30%eth1 — for a global routing address it fails ping6: 20:20:20:20:20:20:20:30%eth1: Name or service not known

But for a link-local address it works:

root@localhost:~# ping fe80::5054:ff:fe7e:1f90%eth1 PING fe80::5054:ff:fe7e:1f90%eth1 (fe80::5054:ff:fe7e:1f90%eth1) 56 data bytes

I was thinking if we should add sin6_scope_id similar field to IPv6Address.h or should we create something like ScopedV6Address

Please let me know what would be a better way to achieve this

in the udp-test BindToNetDevice was already getting tested hence I added this behavior's test in that test-suite.

Manmita Das (f0560736) at 20 Mar 00:46

Manmita Das (0600b8a5) at 20 Mar 00:26

... and 5 more commits

Manmita Das (290b528a) at 20 Mar 00:25

yeah, will do

Manmita Das (efa51b8f) at 19 Mar 22:32

Closes #802

Hello,

I would like to work on this

I checked in Linux in Docker: if I try to ping with the -I flag on an interface on which a route does not exist, the packet does not leave the container, while the socket class BindToNetDevice says it forces packet to leave.

For example:

192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.1 192.168.2.0/24 dev eth1 proto kernel scope link src 192.168.2.1

If I do ping -I eth1 192.168.2.2, in tcpdump on eth1 I do not see any packet. From this, I can say that the correct statement should be: route lookup should result in failure if the oif of the route does not match the oif of m_boundnetdevice; thus, the packet can’t be sent if an incorrect netdevice was bound.

In ns-3, I could find that most routing protocols follow Linux behaviour: StaticRouting (v4+v6), GlobalRouting, AodvRouting, DsdvRouting, RIP, RipNg, NixVector, and OlsrRouting. If oif is set, then the resultant route oif should match the m_bound interface.

The routing protocols which do not run this oif check at all, for example ListRouting (v4+v6), for which I am raising a MR, which a check similar to the other modules

Thanks

Manmita Das (20123781) at 19 Mar 22:09

Manmita Das (1ae527b3) at 19 Mar 21:55

... and 9 more commits

Manmita Das (86bd06bc) at 09 Mar 08:24

... and 3 more commits

Manmita Das (5edef6e4) at 09 Mar 08:14

... and 1 more commit

Modified the code to fire m_macPromiscRxTrace even if m_promiscRxCallback is null.

Closes #962

Manmita Das (3f15217e) at 09 Mar 07:59

Hi @tommypec ,

I would like to pickup this issue.

I went through the git history to find out where the code changed were added this is the commit that added the packetSniffers https://github.com/nsnam/ns-3-dev-git/commit/a10c3623689a757f79edf17851daf4640f6aedf3

These were my traces of interest m_snifferTrace m_promiscSnifferTrace m_macRxTrace m_macPromiscRxTrace m_macTxTrace

On the receive, I can say the m_snifferTraces and m_macRxTraces are called with no difference in logic, but on Tx path m_macTxTrace is called before enqueing to the device queue and sniffer traces were called after dequeing from device queues.

Although on the RX path the traces might be redundant but not the Tx path please correct me if I am wrong.

Todos: bug of m_macPromiscRxTrace not called being if m_promiscRxCallback is not set,

Note: I think we shouldn’t remove the m_snifferTraces.