To be honest, I have no idea... But can you try to block anything not
from the device wlan0/adhoc, but the source IP address(es) of the other
nodes?

Stephan

On Do, 2017-05-04 at 17:01 +0000, Leonel Gaspar Soares wrote:
> No, even when only connected by wi fi beacons keep showing up...
> Stephan Rottmann <rottmann@ibr.cs.tu-bs.de> escreveu em qui,
> 4/05/2017 às 17:43 :
> > Hi,
> >
> > are the nodes connected via another interface, such as Ethernet?
> > Then
> > those beacons might arrive through that one...
> >
> > Stephan
> >
> >
> >
> > Am Donnerstag, den 04.05.2017, 17:15 +0100 schrieb Leonel Gaspar
> > Soares:
> > > Thanks, I will look into your simulation, but what I don't
> > understand
> > > is why, even with blocked traffic in one node (with say iptables
> > -A
> > > INPUT -o wlan0 -j REJECT and iptables -A OUTPUT -o wlan0 -j
> > REJECT),
> > > this node still listens to packets UDP of MIH in tcpdump and
> > > whireshark still is displaying these packets... why do they keep
> > > coming, even when the traffic is blocked in this node?
> > >
> > > On Thu, May 4, 2017 at 1:25 PM, Martin Wegner <wegner@ibr.cs.tu-b
> > s.de
> > > > wrote:
> > > > Hey,
> > > >
> > > > we developed also a simulator here at IBR which can be used to
> > > > simulate
> > > > a multitude of DTN nodes via VMs running on one or several
> > hosts.
> > > > The
> > > > simulator is called Hydra (paper [0], code [1], complete
> > rewrite in
> > > > repos [2-4]).
> > > >
> > > > It came to my mind regarding your issue, as Hydra allowed
> > > > communication
> > > > between VMs, if the nodes were in communication range according
> > to
> > > > their
> > > > mobility, by setting up the corresponding iptables rules. You
> > can
> > > > find
> > > > the exact rules that were used at [5, 6].
> > > > Maybe you can extract them for your purpose, or maybe even use
> > > > Hydra
> > > > directly.
> > > >
> > > > [0] https://www.ibr.cs.tu-bs.de/bib/xml/HYDRA.html
> > > > [1] https://github.com/morgenroth/hydrasim/
> > > > [2] https://github.com/morgenroth/hydra-node
> > > > [3] https://github.com/morgenroth/hydra-webmanager
> > > > [4] https://github.com/morgenroth/hydra-slave
> > > > [5]
> > > > https://github.com/morgenroth/hydrasim/blob/master/slave/src/co
> > ntro
> > > > l.py#L151
> > > > [6]
> > > > https://github.com/morgenroth/hydra-slave/blob/master/hydraslav
> > e/co
> > > > ntrol.py#L380
> > > >
> > > > Best, Martin Wegner
> > > >
> > > > On 05/03/17 22:12, Leonel Gaspar Soares wrote:
> > > > > Thanks for the guidance! In my simulation, I have one more
> > > > issue... I
> > > > > want to block traffic in nodes, wifi interface, but iptables
> > > > rules don't
> > > > > seem to block the UDP packetes from MIH in port 4551
> > (discovery
> > > > > beacons?)... I've tried
> > > > >
> > > > >
> > > > > iptables -A INPUT -i adhoc -j REJECT
> > > > > iptables -A OUTPUT -o adhoc -j REJECT
> > > > >
> > > > > iptables -A FORWARD -i adhoc -o adhoc -j REJECT
> > > > > iptables -A FORWARD -i adhoc -o adhoc -j REJECT
> > > > >
> > > > > ip6tables -A INPUT -i adhoc -j REJECT
> > > > > ip6tables -A OUTPUT -o adhoc -j REJECT
> > > > >
> > > > > iptables -A INPUT  -m pkttype --pkt-type multicast -j REJECT
> > > > > iptables -A OUTPUT -m pkttype --pkt-type multicast -j REJECT
> > > > >
> > > > > iptables -A FORWARD  -m pkttype --pkt-type multicast -j
> > REJECT
> > > > > iptables -A FORWARD -m pkttype --pkt-type multicast -j REJECT
> > > > >
> > > > > But I can not simulate connectivity loss, beacause udp
> > packets in
> > > > port
> > > > > 4551 keep on comming, although these rules are applied...
> > anyone
> > > > tried
> > > > > iptables for simulation of connectivity loss with ibr-dtn?
> > > > >
> > > > >
> > > >
> > > > --
> > > > ,---- [ contact info ]
> > > > | Martin Wegner, M.Sc.
> > > > | IBR, research group Connected and Mobile Systems
> > > > | Technische Universität Braunschweig
> > > > | office:
> > > > |   Mühlenpfordtstraße 23, room 131
> > > > |   38106 Braunschweig, Germany
> > > > | phone: +49 531 391 3246
> > > > | mail: wegner@ibr.cs.tu-bs.de
> > > > | GnuPG key: 0x04210FF947C76DD7
> > > > `----
> > > >
> > > >
> > > > --
> > > > !! This message is brought to you via the `ibr-dtn' mailing
> > list.
> > > > !! Please do not reply to this message to unsubscribe. To
> > > > unsubscribe or adjust
> > > > !! your settings, send a mail message to <ibr-dtn-request@ibr.c
> > s.tu
> > > > -bs.de>
> > > > !! or look at https://mail.ibr.cs.tu-bs.de/listinfo/ibr-dtn.
> > > -- 
> > > !! This message is brought to you via the `ibr-dtn' mailing list.
> > > !! Please do not reply to this message to unsubscribe. To
> > unsubscribe
> > > or adjust
> > > !! your settings, send a mail message to <ibr-dtn-request@ibr.cs.
> > tu-b
> > > s.de>
> > > !! or look at https://mail.ibr.cs.tu-bs.de/listinfo/ibr-dtn.
> > --
> > Stephan Rottmann        Institut für Betriebssysteme und
> > Rechnerverbund
> > Tel.: +49-531-391-3154                           
> > Mühlenpfordtstraße 23
> > Fax.: +49-531-391-5936      TU Braunschweig        D-38106
> > Braunschweig
> >
> >
> >
> >