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?
Hi Leonel,
Why not take a look at an emulation tool like the Common Open Research Emulator (CORE) ? This gives you the much needed
* Scalability in terms of number of nodes * Customizability in terms of the services/applications that you want to run on nodes, * Fine grained control over connectivity making/breaking by configuring mobility scenarios. * Ease of use manually (GUI) and programatically (python API).
Hope that helps.
Thanks and regards, Vijay
On Thu, May 4, 2017 at 1:42 AM, Leonel Gaspar Soares < leonelgasparsoares@gmail.com> 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?
-- !! 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-bs.de !! or look at https://mail.ibr.cs.tu-bs.de/listinfo/ibr-dtn.
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/control.py#L151 [6] https://github.com/morgenroth/hydra-slave/blob/master/hydraslave/control.py#...
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?
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-bs.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/control.py#L151 [6] https://github.com/morgenroth/hydra-slave/blob/master/ hydraslave/control.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.cs.tu-bs.de !! or look at https://mail.ibr.cs.tu-bs.de/listinfo/ibr-dtn.
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-bs.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/contro l.py#L151 [6] https://github.com/morgenroth/hydra-slave/blob/master/hydraslave/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.cs.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.
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-bs.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/contro l.py#L151 [6] https://github.com/morgenroth/hydra-slave/blob/master/hydraslave/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.cs.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
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
All other tráfic Gets bloked except these Packets Stephan Rottmann rottmann@ibr.cs.tu-bs.de escreveu em qui, 4/05/2017 às 18:32 :
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
Hey,
I think without (a lot of) further details nobody here might be able to help you. When you reply, try to supply as many relevant information as possible and needed, e. g., - what is the exact IP (i.e., IPv4 *and* IPv6) config of your interface(s), - what *exact* packets do you see in wireshark? protocol names, ports, addresses (again IPv4 *and/or* IPv6?), packet types, etc., or even the actual trace, - possibly even your network config, routing tables, anything modified with sysctl, and so on.
In your initial mail, you wrote a set of ip(6)tables commands. I noticed, that only 1 out of the 5 pairs is for ip6tables - have you, e. g., tried also blocking IPv6 multicast traffic? This seems at least to be missing from your provided commands.
# Martin
On 05/04/2017 07:43 PM, Leonel Gaspar Soares wrote:
All other tráfic Gets bloked except these Packets Stephan Rottmann <rottmann@ibr.cs.tu-bs.de mailto:rottmann@ibr.cs.tu-bs.de> escreveu em qui, 4/05/2017 às 18:32 :
[…]
The two nodes involved have adresses 10.0.0.1 and 10.0.0.3. When I aply in 10.0.0.1 the rule
iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP
I expect to reject all traffic in this node, am I right? Whith these rules, in node 10.0.0.1, in the interface adhoc (wifi) after these rules been applied, the packets I see with tcpdump -i adhoc are:
IP 10.0.0.3.4551 > 224.0.0.142.4551: UDP
Should'nt these packets been rejected/blocked in node 10.0.0.1? IBR-DTN is not running in 10.0.0.1, but running in 10.0.0.3.
On Thu, May 4, 2017 at 7:17 PM, Martin Wegner wegner@ibr.cs.tu-bs.de wrote:
Hey,
I think without (a lot of) further details nobody here might be able to help you. When you reply, try to supply as many relevant information as possible and needed, e. g.,
- what is the exact IP (i.e., IPv4 *and* IPv6) config of your interface(s),
- what *exact* packets do you see in wireshark? protocol names, ports,
addresses (again IPv4 *and/or* IPv6?), packet types, etc., or even the actual trace,
- possibly even your network config, routing tables, anything modified
with sysctl, and so on.
In your initial mail, you wrote a set of ip(6)tables commands. I noticed, that only 1 out of the 5 pairs is for ip6tables - have you, e. g., tried also blocking IPv6 multicast traffic? This seems at least to be missing from your provided commands.
# Martin
On 05/04/2017 07:43 PM, Leonel Gaspar Soares wrote:
All other tráfic Gets bloked except these Packets Stephan Rottmann <rottmann@ibr.cs.tu-bs.de mailto:rottmann@ibr.cs.tu-bs.de> escreveu em qui, 4/05/2017 às 18:32 :
[…]
-- ,---- [ 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 `----
Thanks for the details, that rules some of the possibilities out.
Ok, so a quick google search ("wireshark and iptables") revealed that due to libpcap, wireshark is able to see network packets directly from the NIC before they are handled by the OS [0].
This means, that you will see packets in wireshark which are to be dropped via iptables, however, they should not arrive in the application.
[0] https://unix.stackexchange.com/questions/248090/how-can-wireshark-see-packet...
Hope that helps,
Martin
On 05/04/2017 08:29 PM, Leonel Gaspar Soares wrote:
The two nodes involved have adresses 10.0.0.1 and 10.0.0.3. When I aply in 10.0.0.1 the rule
iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP
I expect to reject all traffic in this node, am I right? Whith these rules, in node 10.0.0.1, in the interface adhoc (wifi) after these rules been applied, the packets I see with tcpdump -i adhoc are:
IP 10.0.0.3.4551 > 224.0.0.142.4551: UDP
Should'nt these packets been rejected/blocked in node 10.0.0.1? IBR-DTN is not running in 10.0.0.1, but running in 10.0.0.3.
On Thu, May 4, 2017 at 7:17 PM, Martin Wegner <wegner@ibr.cs.tu-bs.de mailto:wegner@ibr.cs.tu-bs.de> wrote:
Hey, I think without (a lot of) further details nobody here might be able to help you. When you reply, try to supply as many relevant information as possible and needed, e. g., - what is the exact IP (i.e., IPv4 *and* IPv6) config of your interface(s), - what *exact* packets do you see in wireshark? protocol names, ports, addresses (again IPv4 *and/or* IPv6?), packet types, etc., or even the actual trace, - possibly even your network config, routing tables, anything modified with sysctl, and so on. In your initial mail, you wrote a set of ip(6)tables commands. I noticed, that only 1 out of the 5 pairs is for ip6tables - have you, e. g., tried also blocking IPv6 multicast traffic? This seems at least to be missing from your provided commands. # Martin On 05/04/2017 07:43 PM, Leonel Gaspar Soares wrote: > All other tráfic Gets bloked except these Packets > Stephan Rottmann <rottmann@ibr.cs.tu-bs.de <mailto:rottmann@ibr.cs.tu-bs.de> > <mailto:rottmann@ibr.cs.tu-bs.de <mailto:rottmann@ibr.cs.tu-bs.de>>> escreveu em qui, 4/05/2017 às 18:32 : > > […] -- ,---- [ 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 <tel:%2B49%20531%20391%203246> | mail: wegner@ibr.cs.tu-bs.de <mailto:wegner@ibr.cs.tu-bs.de> | GnuPG key: 0x04210FF947C76DD7 `----
Thanks for the help! Since my iptables are intended to reject everything in adhoc interface (iptables -A INPUT -i adhoc -j REJECT and iptables -A OUTPUT -o adhoc -j REJECT), the problem that you pointed must be whats happening. Thanks for help :)
On Thu, May 4, 2017 at 7:34 PM, Martin Wegner wegner@ibr.cs.tu-bs.de wrote:
Thanks for the details, that rules some of the possibilities out.
Ok, so a quick google search ("wireshark and iptables") revealed that due to libpcap, wireshark is able to see network packets directly from the NIC before they are handled by the OS [0].
This means, that you will see packets in wireshark which are to be dropped via iptables, however, they should not arrive in the application.
[0] https://unix.stackexchange.com/questions/248090/how-can- wireshark-see-packets-dropped-by-iptables
Hope that helps,
Martin
On 05/04/2017 08:29 PM, Leonel Gaspar Soares wrote:
The two nodes involved have adresses 10.0.0.1 and 10.0.0.3. When I aply in 10.0.0.1 the rule
iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP
I expect to reject all traffic in this node, am I right? Whith these rules, in node 10.0.0.1, in the interface adhoc (wifi) after these rules been applied, the packets I see with tcpdump -i adhoc are:
IP 10.0.0.3.4551 > 224.0.0.142.4551: UDP
Should'nt these packets been rejected/blocked in node 10.0.0.1? IBR-DTN is not running in 10.0.0.1, but running in 10.0.0.3.
On Thu, May 4, 2017 at 7:17 PM, Martin Wegner <wegner@ibr.cs.tu-bs.de mailto:wegner@ibr.cs.tu-bs.de> wrote:
Hey, I think without (a lot of) further details nobody here might be ableto
help you. When you reply, try to supply as many relevant informationas
possible and needed, e. g., - what is the exact IP (i.e., IPv4 *and* IPv6) config of your interface(s), - what *exact* packets do you see in wireshark? protocol names,ports,
addresses (again IPv4 *and/or* IPv6?), packet types, etc., or eventhe
actual trace, - possibly even your network config, routing tables, anythingmodified
with sysctl, and so on. In your initial mail, you wrote a set of ip(6)tables commands. I noticed, that only 1 out of the 5 pairs is for ip6tables - have you,e.
g., tried also blocking IPv6 multicast traffic? This seems at leastto
be missing from your provided commands. # Martin On 05/04/2017 07:43 PM, Leonel Gaspar Soares wrote: > All other tráfic Gets bloked except these Packets > Stephan Rottmann <rottmann@ibr.cs.tu-bs.de <mailto:rottmann@ibr.cs.tu-bs.de>
> <mailto:rottmann@ibr.cs.tu-bs.de <mailto:rottmann@ibr.cs.tu-bs.de>>> escreveu em qui, 4/05/2017 às 18:32 : > > […] -- ,---- [ 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 <tel:%2B49%20531%20391%203246> | mail: wegner@ibr.cs.tu-bs.de <mailto:wegner@ibr.cs.tu-bs.de> | GnuPG key: 0x04210FF947C76DD7 `------ ,---- [ 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 `----
participants (4)
-
Leonel Gaspar Soares -
Martin Wegner -
Stephan Rottmann -
Vijayasarathy Rajagopalan