Some problems in using aps and stations

[pekora]

Dear Ramon，
          I am  building a topology using 2 ofswitches ,1 ap, 2 hosts, and 1 station, and the topology is like this:
                                    controller(Floodlight1.2)
                                             /              |            \
                                           /                |              \
                                         /                  |                \
                                      AP1-------------S1-------------S2
                                        |                    |                   |  
                                        |                    |                   |
                                       sta1             h1                h2
         I'm trying to use sta1 to send forged LLDP packets using scapy, and I've got some problems with it.
         1 I want to use mesh to connect the sta1 to ap1, and I got two interfaces with sta1, one is 'sta1-mp0' and the other is sta1-wlan1, what does 'sta1-mp0' mean? I refer to the source code and find it created automatically, I saw it in ad hoc networks, does it work for ad hoc networks? What should I do to use only the 'sta1-wlan1' interface?
         2 Last time I asked  some question about vanet, you mentioned that I need to check connction using iw, I use both 'sta1 iw dev sta1-wlan1 link' and 'sta1 iwconfig', and here's  what I got:
 the result of 'sta1 iw dev sta1-wlan1 link' is similiar to this, does this means sta1 connected to the ap successfully? In my opinion I think this means the connection is fine.So I tried to send packet on sta1 using scapy, and the same problem occurs which is the switch cannot receive my LLDP packet and here is the result

 I forged LLDP pakcet like this and I tried to send it using scapy, the result in wireshrk is like this

I can see my forged packet on sta1-wlan1 but I can't see them on ap1-wlan1,I tried 'sta1 ping h1' and  It work well, I use scapy to send ICMP packet which works well so can you tell me why this happen? I attached my script and I hope you could try it.
      Wish you all the best!

[Ramon Fontes]

Well, there are many open questions here. You say that you want to use mesh but you are actually using managed interface. Also, the network topology doesn't explain why stay have wlan0 and wlan1, etc. 

Please make sure that you have the setup you need and you have provided all the information we need to understand what is going on. Unfortunately, I have to ask the same questions all the time. :(

Sent from my android

--
You received this message because you are subscribed to the Google Groups "mininet-wifi-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mininet-wifi-dis...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mininet-wifi-discuss/97deac61-7034-4704-afb0-4f6dc9e6b94an%40googlegroups.com.

[Ramon Fontes]

Why sta1*

Sent from my android

[pekora]

I changed my script and it is now using default wireless connection.The scripts is as follow:

from mininet.node import RemoteController
from mininet.log import setLogLevel, info
from mn_wifi.cli import CLI
from mn_wifi.net import Mininet_wifi
from mn_wifi.link import wmediumd
from mn_wifi.wmediumdConnector import interference

def topology():
    net = Mininet_wifi(link=wmediumd, wmediumd_mode=interference)
   
    s1 = net.addSwitch('s1', mac='00:00:00:00:00:01', protocols='OpenFlow13')
    s2 = net.addSwitch('s2', mac='00:00:00:00:00:02', protocols='OpenFlow13')
    ap1 = net.addAccessPoint('ap1' ,position='100,100,0', mac='00:00:00:00:00:03', ssid='ssid1', mode='g', channel='1', protocols='OpenFlow13')
    sta1 = net.addStation('sta1', position='50,50,0', mac='00:00:00:00:00:04')
    h1 = net.addHost('h1', ip='10.0.0.4/24')
    h2 = net.addHost('h2', ip='10.0.0.5/24')
   
    c0 = net.addController('c0', controller=RemoteController, ip='127.0.0.1', protocol='tcp', port=6653)
   
    net.setPropagationModel(model="logDistance", exp=3.2)
    net.configureWifiNodes()
   
    net.addLink(s1,s2)
    net.addLink(s2,ap1)
    net.addLink(h1,s1)
    net.addLink(h2,s2)

    net.addLink(ap1,sta1,0,0)
   
   
    net.build()
    c0.start()
    s1.start([c0])
    s2.start([c0])
    ap1.start([c0])

   
    CLI(net)
   
    net.stop()
   
if __name__ == '__main__':
   setLogLevel('info')
   topology()

I delete mesh and using default wireless connection between sta1 and ap1.The connection is checked by using 'sta1 iwconfig','sta1 iw dev sta1-wlan0 scan' and 'sta1 iw dev sta1-wlan0 link' and here are the results:

*** Starting CLI:
mininet-wifi> sta1 iw dev sta1-wlan0 link
Connected to 00:00:00:00:00:03 (on sta1-wlan0)
    SSID: ssid1
    freq: 2412
    RX: 11285 bytes (237 packets)
    TX: 987 bytes (10 packets)
    signal: -36 dBm
    tx bitrate: 36.0 MBit/s

    bss flags:    short-slot-time
    dtim period:    2
    beacon int:    100
mininet-wifi> sta1 iw dev sta1-wlan0 scan
BSS 00:00:00:00:00:03(on sta1-wlan0) -- associated
    last seen: 2280.764s [boottime]
    TSF: 1661600643678629 usec (19231d, 11:44:03)
    freq: 2412
    beacon interval: 100 TUs
    capability: ESS ShortSlotTime (0x0401)
    signal: -36.00 dBm
    last seen: 0 ms ago
    Information elements from Probe Response frame:
    SSID: ssid1
    Supported rates: 1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0
    DS Parameter set: channel 1
    ERP: Barker_Preamble_Mode
    Extended supported rates: 24.0 36.0 48.0 54.0
    Supported operating classes:
         * current operating class: 81
    Extended capabilities:
         * Extended Channel Switching
         * Multiple BSSID
         * Operating Mode Notification
mininet-wifi> sta1 iwconfig
lo        no wireless extensions.

sta1-wlan0  IEEE 802.11  ESSID:"ssid1"  
          Mode:Managed  Frequency:2.412 GHz  Access Point: 00:00:00:00:00:03  
          Bit Rate:1 Mb/s   Tx-Power=14 dBm  
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off
          Link Quality=70/70  Signal level=-36 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:9   Missed beacon:0

The ping command also works.

mininet-wifi> pingall
*** Ping: testing ping reachability
h1 -> *** h1 : ('ping -c1  10.0.0.5',)
PING 10.0.0.5 (10.0.0.5) 56(84) bytes of data.
64 bytes from 10.0.0.5: icmp_seq=1 ttl=64 time=4.69 ms

--- 10.0.0.5 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 4.693/4.693/4.693/0.000 ms
h2 *** h1 : ('ping -c1  10.0.0.1',)
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=5.29 ms

--- 10.0.0.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 5.293/5.293/5.293/0.000 ms
sta1
h2 -> *** h2 : ('ping -c1  10.0.0.4',)
PING 10.0.0.4 (10.0.0.4) 56(84) bytes of data.
64 bytes from 10.0.0.4: icmp_seq=1 ttl=64 time=0.150 ms

--- 10.0.0.4 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.150/0.150/0.150/0.000 ms
h1 *** h2 : ('ping -c1  10.0.0.1',)
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=7.52 ms

--- 10.0.0.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 7.519/7.519/7.519/0.000 ms
sta1
sta1 -> *** sta1 : ('ping -c1  10.0.0.4',)
PING 10.0.0.4 (10.0.0.4) 56(84) bytes of data.
64 bytes from 10.0.0.4: icmp_seq=1 ttl=64 time=1.23 ms

--- 10.0.0.4 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.233/1.233/1.233/0.000 ms
h1 *** sta1 : ('ping -c1  10.0.0.5',)
PING 10.0.0.5 (10.0.0.5) 56(84) bytes of data.
64 bytes from 10.0.0.5: icmp_seq=1 ttl=64 time=1.22 ms

--- 10.0.0.5 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.216/1.216/1.216/0.000 ms
h2
*** Results: 0% dropped (6/6 received)

The sta1 connected to ap1 successfully and the network work well, so I did further experiments.

The network is controlled by floodlight, I use scapy to send forged LLDP packet on sta1 to forge a fake link between ap1 and s2.

As you can see, I send lots of LLDP packet on port 'sta1-wlan0' but they didn't apper on port 'ap1-wlan1' and the most important thing is that I need to see them on port 'ap1-wlan1' so that I can trigger the Floodlight to create a fake link between ap1 and s2.

I did the same steps on h2 to create a fake link between ap1 and s2, it works as I expected. Here is the result.

The link is forged successfully by sending forged LLDP packet on h2 and if the sta1 works well(works the same as h2), there will be a new link between s2 and ap1.

I did this in vanet-sumo.py and got the same result as my customized script.I refer to the source code of mn_wifi and find that the 'car' is similar to 'station' , so I thought if there is some function I need to add to my script to do such things.

So the key to my problem is that I can't use station or car to send LLDP packet and I need them to do such things. So I hope if you could help me solve this.

Wish you all the best!

[Ramon Fontes]

Is network manager running?

Sent from my android

To view this discussion on the web visit https://groups.google.com/d/msgid/mininet-wifi-discuss/9a520970-45e9-495a-9427-1e9b75ffa47dn%40googlegroups.com.

[pekora]

YES, I use 'service --status-all' to check NM and it was '+' ,then i use 'systemctl stop network-manager' and it went '-' .

[pekora]

I do the same test after using 'systemctl stop network-manager' and it still can't work .

[Ramon Fontes]

Who is 06:8a:b7..?

Sent from my android

To view this discussion on the web visit https://groups.google.com/d/msgid/mininet-wifi-discuss/312e05c5-d315-4c9a-a6de-d14e546492abn%40googlegroups.com.

[pekora]

Sorry I didn't see there exists 06:8a:87, if did, it might be a host or the wired interface of ap1.

[pekora]

I tried using scapy to send forged LLDP packet in different scripts. But none of them works, I tried to send LLDP packet in example/meshAP.py and it got the same result.

I've also tried this in examples/vanet-sumo.py and here is the result.(My work needs to be done in software-defined vehicular network)

The only difference is that  I add a remote controller in the script and set  car in range(0,20).

I stop the sumo simulation at 135 seconds, and the topology in matplotlib is like this 

I use iwconfig and iw dev link to check if car1 and other cars are connected to the aps and they did(can be seen in mn_wifi debug mode too).The results are like this:

car1-wlan0  IEEE 802.11  ESSID:"vanet-ssid"  
          Mode:Managed  Frequency:2.412 GHz  Access Point: 00:00:00:11:00:04  

          Bit Rate:1 Mb/s   Tx-Power=14 dBm  
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off

          Link Quality=54/70  Signal level=-56 dBm  

          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0

          Tx excessive retries:0  Invalid misc:15   Missed beacon:0

Then I use xterm to create terminals on car1,e4, and car2, I open two terminals on car1 because one is used for wireshark and the other is used for scapy, The terminal on car2 and e4 are used for wireshark and here is the result.

LLDP packet are sent successfully on 'car1-wlan0' but ap still can't receive the LLDP packet.

I'm sure network-manager isn't running, the status is:

~/Desktop$ service network-manager status
● NetworkManager.service - Network Manager
     Loaded: loaded (/lib/systemd/system/NetworkManager.service; enabled; vendo>
     Active: inactive (dead) since Sun 2022-08-28 00:16:12 CST; 11h ago
       Docs: man:NetworkManager(8)
    Process: 676 ExecStart=/usr/sbin/NetworkManager --no-daemon (code=exited, s>
   Main PID: 676 (code=exited, status=0/SUCCESS)

8月 28 00:13:28 ns3-VirtualBox NetworkManager[676]: <info>  [1661616808.0767] a>
8月 28 00:16:12 ns3-VirtualBox systemd[1]: Stopping Network Manager...
8月 28 00:16:12 ns3-VirtualBox NetworkManager[676]: <info>  [1661616972.3063] c>
8月 28 00:16:12 ns3-VirtualBox NetworkManager[676]: <info>  [1661616972.3311] d>
8月 28 00:16:12 ns3-VirtualBox NetworkManager[676]: <info>  [1661616972.3312] d>
8月 28 00:16:12 ns3-VirtualBox NetworkManager[676]: <info>  [1661616972.3312] d>
8月 28 00:16:12 ns3-VirtualBox NetworkManager[676]: <info>  [1661616972.3318] m>
8月 28 00:16:12 ns3-VirtualBox NetworkManager[676]: <info>  [1661616972.4279] e>
8月 28 00:16:12 ns3-VirtualBox systemd[1]: NetworkManager.service: Succeeded.
8月 28 00:16:12 ns3-VirtualBox systemd[1]: Stopped Network Manager.
lines 1-17/17 (END)

I've done these experiments on two mininet-wifi environments, one is installed on ubuntu20.04 and the other is installed on ubuntu 16.04, I'm not sure if this matters. But I got the same result in these experiments.

I hope you could told me how to solve this problem.

Wish you all the best!

[Ramon Fontes]

It works with wmediumd_interference and meshAP (screenshot attached). At this point I see no reason for doing the same with vanet-sumo since it will certainly work too.

Please review your setup.

To view this discussion on the web visit https://groups.google.com/d/msgid/mininet-wifi-discuss/393b905d-ac1c-4816-8f5c-fd9cb9c029f4n%40googlegroups.com.

[pekora]

I noticed that you are capturing the packet on port 'sta2-wlan0', which means you can see the packet has been sent. 

I can also see the packet being sent on port 'sta2-wlan0' in my tests, but I don't know if the packet has been received by the ap or not. If the ap did receive the LLDP packet, there will be a new link in the controller's view and that's what I want to happen.

Using the topology in example/meshAP.py for example, the initial topology contains two ap which have one station connected to each of them, and the aps are connected with one link, if we use sta2 to send a forged LLDP packet which was designed by 

ap1 and the ap2 received the LLDP packet, there will be a new link between ap1 and ap2, that's what I want to do and it is called Link Fabrication Attack which was proposed in this paper "https://www.ndss-symposium.org/wp-content/uploads/2017/09/10_4_2.pdf" ) and that's what I want to happen.

I've done many tests based on different setups, and now  I locate this problem in  wireless connection scenario. If the station is connected to the ap by wired link, the LLDP packet can be received by the switch and if the station is connected to the ap by wireless link, the switch can't receive the LLDP packet.

I thought it might be something with wmediumed because you mentioned the wireless link is managed by it, but I know nothing about it, I hope you could give me further instructions.

Thanks for your help and wish you all the best!

[Ramon Fontes]

*which means you can see the packet has been received by sta2 that has been sent by sta1. 

As I said, it works.

Sent from my android

To view this discussion on the web visit https://groups.google.com/d/msgid/mininet-wifi-discuss/cd91a8d0-a0ff-46e6-b3c1-c8b1b4e16fd0n%40googlegroups.com.

[pekora]

Sorry, I thought maybe there is something wrong with my expression, what I need is to make the aps receive the fake LLDP packet sent by stations,  the LLDP packet is sent from stations and transported directly to the ap it connected.

If you can do this, could you share your setups? I can't do this in any of my computers, even if I make a new VM a set a new mininet-wifi and floodlight environment.

Thanks for your help!

[Ramon Fontes]

https://www.dropbox.com/s/8fhyk40lack3x2l/Screencast%202022-08-29%2006%3A40%3A57.mp4?dl=0

[pekora]

I use a new VM downloaded from mininet-wifi.github.io to do the same test and it still not work. And I recorded the steps, here is the video.

https://drive.google.com/file/d/1O47SDcKPHL-cG4GDui0Y8_inpHFmAH7z/view?usp=sharing 

I don't know which steps I went wrong, I hope you could help me find out.

Thanks for your help!

在2022年8月29日星期一 UTC+8 17:44:16<ramonre...@gmail.com> 写道：

https://www.dropbox.com/s/8fhyk40lack3x2l/Screencast%202022-08-29%2006%3A40%3A57.mp4?dl=0

[Ramon Fontes]

Who is 02:00:00:00:02:00??

[pekora]

02:00:00:00:02:00 is the addr of interface 'ap1-wlan1' ， you can see it using 'ap1 iw dev ap1-wlan1 info' and '02:00:00:00:04:00' is the addr of interface 'ap2-wlan1'.

[Ramon Fontes]

Why would you set the mac address of ap1 if the the source is sta1?? 

Sent from my android

--

You received this message because you are subscribed to the Google Groups "mininet-wifi-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mininet-wifi-dis...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mininet-wifi-discuss/ce7ec79f-77dc-4555-906f-4b90532143a0n%40googlegroups.com.

[Ramon Fontes]

Well, it seems that you have used two OS, (three?) VMs, have spent one week? And the problem is with the source mac address. :/

[pekora]

Yep, I run this in three different OS version, Ubuntu 20.04, ubuntu 16.04 and lubuntu 20.04. I think there maybe some different between mininet and mininet-wifi(or wireless scenario and wired scenario).

I was doing SDN in wired scenario (mininet of course), as far as I know, the controller build the inner link based on the source mac of LLDP and port number. This was proposed in a paper published on NDSS 2015( Poisoning Network Visibility in Software-Defined Networks: New Attacks and Countermeasures ) . And here is the description of what I want to do:

" LLDP Relay. Instead of injecting forged LLDP packets, a stronger adversary can also fabricate internal links in a relay fashion (without packet modification). That is, when receiving an LLDP packet from one target switch, the adversary repeats it to 

another target switch without any modification. In the case, the adversary constructs a fake topology view to the OpenFlow controller as if there is an internal link between those two target switches. This kind of fake link injection incurs future attack 

possibilities which we will describe more in detail as follows. Here, we discuss two ways to build a communication channel to relay LLDP packets, i.e., by physical links and by a tunnel. An intuitive relay method is that an adversary sets up physical 

links (e.g., cable or wireless) between two switches. If this is not feasible, the adversary can use another more feasible approach, which relays LLDP packets by reusing the existing OpenFlow network infrastructure as illustrated in Figure 5.Particularly, 

the dotted line is the communication channel between two users in the view of an OpenFlow controller, whereas the dashed line is the actual traffic route. To successfully launch an LLDP relay attack, the adversary first needs to find suitable relay 

host(s), which can be achieved by a connection test. Another thing we need to note is that, some OpenFlow controllers, e.g., Floodlight and POX, disable the Host Tracking Service on internal link switch ports, which hinders the deployment of the LLDP 

relay channel. However, we cannot ignore the tunnel-based LLDP relay attack on those controllers in a hybrid network scenario (i.e., a network contains both OpenFlow islands and Non-OpenFlow islands), as the OpenFlow controller can hardly stop 

Host Tracking Service on the Multi-hop link ports (i.e., switch port outgoing to another Non-OpenFlow switch)."

And if I want to do the same thing as this paper did in mininet-wifi, I need to modify the source mac of LLDP packet according to your previous email, so I think if there is something different from mininet?

Thanks for your help!

[Ramon Fontes]

You might know that OF was not designed for wireless and you cannot reproduce the same scenario with wireless. I suggest you trying the network topology with wireless and then you let me know the result.

Sent from my android

--

You received this message because you are subscribed to the Google Groups "mininet-wifi-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mininet-wifi-dis...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mininet-wifi-discuss/5abed406-fbb7-4d30-9f39-ff2feacd5d1bn%40googlegroups.com.

[Ramon Fontes]

* with physical devices. Not virtual ones.

Sent from my android

[pekora]

I tried to do the same work with physical devices, I use an ap which runs Openwrt with OVS 15.05 on it. The topology is one computer run as controller and connected to the ap with a wired connection, and my lap is connected to the ap wirelessly, I tried to send BDDP packet and of course, I need to modify the source mac to make it work, it's the same as in mn-wifi.

So why the wireless network work like this and does it defined by 802.11 or OF?

And I've got another question about physical devices,  when my lap is connected to the ap wirelessly, I can only receive BDDP packet. as far as I know, if the host is connected to the OF switch directly(wired), the host can receive both LLDP packet and BDDP packet and my tests with physical devices using  pica8 OF switch and openmesh ap(using wired connection) also confirmed this. I've encountered this situation before when working in hybrid SDN environment and only BDDP packet can be transmitted through legacy switches, so I thought this might be because the WLAN port of ap works as legacy switch and the LAN port works as OVS.But the wlan port was set by using ' ovs-vsctl add-port br0 wlan0 -- set Interface wlan0‘ command’ it should work as OVS,. By the way the OVS version is 2.3.90. So can you tell me why this happen?

Thanks for your help!!