Fwd: file descriptor, row socket in fdnetdevice

[Mohamed Bouti]

---------- Forwarded message ---------
De : Mohamed Bouti <mbou...@gmail.com>
Date: lun. 19 juin 2023 à 14:13
Subject: file descriptor, row socket in fdnetdevice
To: <ns-3-...@googlegroups.com>

Hello,

Excuse me if my question is so simple but I really need guidance so I can solve this problem. I'm new to ns3, and i'm waiting for an answer from the previous week...i'm still searching but i need some advice please !!! i hope someone will have the time to read my question !

 

I'm currently trying to ping an NS3 node located in laptop one with another laptop, both of them in the same network but using a real wifi interface since it did work with  a real ethernet interface...as i told in a previous question :

How to attach an NS-3 object to a real physical wireless interface

but i'm very much struggling to understand correctly the link between file descriptor, row socket and the real interface in fdnetdevice.

I have found a script called raw-socket-creator that creates a row socket but I'm thinking that it is connected with just an ethernet interface. Maybe this is the reasen that I can't use it with the wifi interface ?    

If you can just guide me so i can know i'm on a good path...or correct my understanding please !🙏🙏🙏

 Below you can find the:

raw-socket-creator.cc

the fd-ping-emu.cc

[Bill Tao]

Hi, Mohamed.

In the fd-emu-ping.cc example, it looks like you could just replace the device name "eth0" with your wireless interface name. You could find this via the "ifconfig" command. There are some configurations described at the beginning of the example that you need to satisfy, but I guess you have done that given you were able to get an ethernet interface working. 

A raw socket is a software interface that gives your program direct access to a network device from layer 2 (see OSI model). This contrasts a 'typical' socket which operates on layer 4. And these sockets exist in the form of file descriptors that you can write to and read from. In the example of fd-emu-ping.cc, it uses a EmuFdNetDeviceHelper to hide away to low-level handling of the socket creation and corresponding file descriptor, so you just need to supply your wireless interface name to it.

However, with all this said, some of the things here may be inaccurate because I am also a novice in this field. So hopefully more experienced people could chip in soon, while my answer is hopefully enough to get you going.

--
Posting to this group should follow these guidelines https://www.nsnam.org/wiki/Ns-3-users-guidelines-for-posting
---
You received this message because you are subscribed to the Google Groups "ns-3-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ns-3-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ns-3-users/CAH-KihesmWkgWurUf4VVrDyk-Qdwmc%2BJ4U9rfzZC_0iTWBkTaw%40mail.gmail.com.

[Mohamed Bouti]

Hello,

Thank you so much Bill ! for your answer, actually i did that in the beginning in fd-emu-ping.cc i just changed the name of the ethernet interface into the wireless one, i also changed the ip addresses to the corresponding one but it did not work ...i tried to do a normal ping to confirm that my lan is working and everything went well.

I also put the interface into a promiscuous mode.

I tried to see in detail the EmuFdNetDeviceHelper to understand but it doesn't not specify the interface type.

 I found this about wireless interfaces but I did not understand what it truly means. If you can help me !

''it is up to the user of this device to provide a file descriptor. The type of file descriptor being provided determines what is being modelled. For instance, if the file descriptor provides a raw socket to a WiFi card on the host machine, the device being modelled is a WiFi device.''

''The FdNetDevice class currently supports three encapsulation modes, DIX for Ethernet II frames, LLC for 802.2 LLC/SNAP frames, and DIXPI for Ethernet II frames with an additional TAP PI header. This means that traffic traversing the file descriptor is expected to be Ethernet II compatible. IEEE 802.1q (VLAN) tagging is not supported. Attaching an FdNetDevice to a wireless interface is possible as long as the driver provides Ethernet II frames to the socket API. Note that to associate a FdNetDevice to a wireless card in ad-hoc mode, the MAC address of the device must be set to the real card MAC address, else any incoming traffic a fake MAC address will be discarded by the driver.''

My wifi card is in infrastructure mode not ad hoc.

How can I confirm that my driver provides Ethernet II frames to the socket API

This is the page that delivers this  information.

https://www.nsnam.org/docs/models/html/fd-net-device.html

Thank you in advance for your answers and guidance.

Best regards.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/ns-3-users/CAHCSpuqRxKQjs_ng%2BxLwSMQYCVdy1X1e19%3DRwUY3m5VLrT3e5w%40mail.gmail.com.

[Bill Tao]

Hi, Mohamed.

You are right. Firstly, I was able to reproduce your issue, i.e. I could get successful pings when connecting to my LAN via ethernet, but it failed when I tried with wifi. 

After looking at this bit of information you pointed to: "Note that to associate a FdNetDevice to a wireless card in ad-hoc mode, the MAC address of the device must be set to the real card MAC address, else any incoming traffic a fake MAC address will be discarded by the driver", I tried to align the sending packets' MAC address with my real wireless interface's MAC address. I did this by hacking line 223 to:

device->SetAttribute("Address", Mac48AddressValue(Mac48Address("my-wireless-mac")));




After this I seemed to get successful ping over wifi. Note this is a quick hack and there are more proper ways to assign MAC address that matches your real interface.




I can only suspect that this is due to the different driver implementation in the ethernet driver and the wifi driver, despite that both of them have been set to promiscuous mode. 

Again, hoping someone with more experience could confirm or clarify this.

To view this discussion on the web visit https://groups.google.com/d/msgid/ns-3-users/CAH-KihfinCW4ZmAJfoPMAPs25c60zhh67%3D2u0%3D2KWzyVq2iEfg%40mail.gmail.com.

[Charles Pandian]

Hi Bill Tao,

At last, you provided a simple solution to fix this wifi-related issue - at least we can ping a wifi node now.

But, I think, architecturally it is incorrect.
The reason is : The mac addres that we are setting here is the mac address of the simulated ns-3 node. So, setting it to another real, external node's mac address may be architecturally incorrect.

It is like packet spoofing, specifically saying, a kind of arp-spoofing. We are just spoofing a mac packet with the address of a wifi node so that it is allowing it to enter into it by believing it as its own mac packet😊.

Anyway, it works to some extent. (at least we may not have any issues at IP layer).

Charles Pandian,

To view this discussion on the web visit https://groups.google.com/d/msgid/ns-3-users/CAHCSpuoY7Z96D_x-VB8n4k3yfZMhwV%3DcFZAUXOz1TUPJPNBiNg%40mail.gmail.com.

[Charles Pandian]

Hi Bill Tao,

Kindly provide your comment on my reply.

"The mac address that we are setting here is the mac address of the simulated ns-3 node."

is it correct?

Or do we really need to set the mac address of the simulated node to the physical address of the device? (since we are setting it to promiscuous mode)

A little confusion here.

Charles Pandian,

[Bill Tao]

Hi Charles,

comment inline.

On Wed, 21 Jun 2023 at 15:27, Charles Pandian <igs...@gmail.com> wrote:

Hi Bill Tao,

Kindly provide your comment on my reply.

"The mac address that we are setting here is the mac address of the simulated ns-3 node."

is it correct?

Yes, this is what I did. And I agree with your argument that architecturally it's a bit unrealistic. Because the simulated MAC layer is sitting above the wifi MAC layer, so the line between the two layers blurs a bit.

 

Or do we really need to set the mac address of the simulated node to the physical address of the device? (since we are setting it to promiscuous mode)

I am not sure I understand this question. Isn't this the same as the first option, presumably by "the physical address of the device" you meant the wifi interface's MAC address? 

A little confusion here.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/ns-3-users/CAHXeiM-GPZQA15jLhR0_o9MfGZpRRgkmeLDfWWThF_Q-UJMy%2Bg%40mail.gmail.com.

[Charles Pandian]

Hi Bill Tao,

Thank you for the reply.

"I am not sure I understand this question. Isn't this the same as the first option, presumably by "the physical address of the device" you meant the wifi interface's MAC address?"

I mean, will the 'ns-3 emulation concept' really require the mac address of the physical device (whether it may be a wired or wireless device?) to be set as the mac address of the simulated ns-3 node?  - that is what I mentioned as "A little confusion here."

Anyway, thank you for your answer.

Charles Pandian,

To view this discussion on the web visit https://groups.google.com/d/msgid/ns-3-users/CAHCSpuq8yHMuRwj1hG7daLq98RxohoE%2B3HMVU-x26TV27ft%3DnA%40mail.gmail.com.

[Bill Tao]

"I mean, will the 'ns-3 emulation concept' really require the mac address of the physical device (whether it may be a wired or wireless device?) to be set as the mac address of the simulated ns-3 node?"

I think not. Conceptually, the simulated node should be completely independent. I think the mac configuration here is an unfortunate fact due to the wireless mac (or driver?) implementation, but I may not be the most qualified to make this comment.

To view this discussion on the web visit https://groups.google.com/d/msgid/ns-3-users/CAHXeiM8gYwu0bUCiA3UivWAc7jd-Av61tnUdFgh2r-9RPWLCfA%40mail.gmail.com.

[Mohamed Bouti]

Hi Bill Tao,

Hi Charles Pandian,

Thank you very much Bill Tao 🙏🙏for your efficient answer and help, and thank you that you took the time to reproduce the issue and solve it! I am very much grateful and appreciate it !

I did the same as you told me and it did work correctly, however now i understand where was the problem, and yes it did solve it, actually to understand why the node in ns3 emulation mode use a different mac adresse and do not need the real mac of the device i have found this below in https://www.nsnam.org/docs/release/3.10/manual/html/emu.html:

"The Emu net device allows a simulation node to send and receive packets over a real network. The emulated net device relies on a specified interface being in promiscuous mode. It opens a raw socket and binds to that interface. We perform MAC spoofing to separate simulation network traffic from other network traffic that may be flowing to and from the host.

One can use the Emu net device in a testbed situation where the host on which the simulation is running has a specific interface of interest which drives the testbed hardware. You would also need to set this specific interface into promiscuous mode and provide an appropriate device name to the ns-3 emulated net device. An example of this environment is the ORBIT testbed as described above. PS:(apparently with wifi card it's not the same as the ethernet one)

The Emu net device only works if the underlying interface is up and in promiscuous mode. Packets will be sent out over the device, but we use MAC spoofing. The MAC addresses will be generated (by default) using the Organizationally Unique Identifier (OUI) 00:00:00 as a base. This vendor code is not assigned to any organization and so should not conflict with any real hardware.

It is always up to the user to determine that using these MAC addresses is okay on your network and won’t conflict with anything else (including another simulation using Emu devices) on your network. If you are using the emulated net device in separate simulations you must consider global MAC address assignment issues and ensure that MAC addresses are unique across all simulations. The emulated net device respects the MAC address provided in the SetAddress method so you can do this manually. For larger simulations, you may want to set the OUI in the MAC address allocation function."

I will now try to use it, so i can send packets from two different nodes located in two differents devices , i have found an example caled fd-emu-onoff.cc, i will try to adapt it to my emulations topology which is making the packets passing  from node one to the real gateway and then to the node 2!

If you have some remarks about this implementation I'll be very much happy to read it!😊

Thank you again 🙏🙏!

Best regards

Bouti mohamed hasnaoui 

To view this discussion on the web visit https://groups.google.com/d/msgid/ns-3-users/CAHCSpuoY7Z96D_x-VB8n4k3yfZMhwV%3DcFZAUXOz1TUPJPNBiNg%40mail.gmail.com.

[Charles Pandian]

According to the information provided at  https://www.nsnam.org/docs/release/3.10/manual/html/emu.html, the MAC address that we are talking about here is the MAC address of the ns-3 node.  So, in case, if we need to create a lot of simulated ns-3 nodes, then those nodes also will require unique MAC addresses - setting all the MAC addresses of the ns-3 nodes to a single physical MAC address may lead to other conflicts.

So, I believe that setting the MAC address of a ns-3 node to the MAC address of a physical node (whether it may be wired or wireless) is not the proper way of overcoming this problem. The reason is: if we set the ns-3 node's address to the MAC address of the wifi node, it will allow that packet as found by Bill Tao; but it seems architecturally wrong. 

The proper solution may be resolving this issue in any one of the following ways (that we do not know now 😊)

1. 🤔Try to rewrite the code of EmuNetDevice - so that it may work without promiscuous mode (Is it really possible?).
2. 🤔Try to find a way to really set the Wifi node to real promiscuous mode (is there any way?)

3. 🤔Try to make the Wifi node to act like a normal node (by making it to allow any packet without any security restrictions - Will it be possible?)

4. 🤔Try to make the ns-3 node to pass the security of the Wifi node (by making it to authenticate with WiFi Network- Will it be possible?)

Again, the above hypothetical solutions have additional questions along with it 😇

Charles Pandian,

To view this discussion on the web visit https://groups.google.com/d/msgid/ns-3-users/CAH-KihdDiEzayT7CxygB0jFYe%2BJ7edDsW02g7%2BrEvNDef7Sxuw%40mail.gmail.com.

[Charles Pandian]

1. 🤔Try to rewrite the code of EmuNetDevice - so that it may work without promiscuous mode (Is it really possible?).
2. 🤔Try to find a way to really set the Wifi node to real promiscuous mode (is there any way?)

Sorry. I think the first two hypothetical solutions will not solve the wifi related issue that we are facing here (because, it seems like a WiFi security-related issue).

Charles Pandian,