Local nework routing while connected to a mobile phone tether

English Network/Internet
1

Hi,

When away from home I often connect this laptop to my Android phone to get some Internet, be it via usb cable or via wifi.

I see a local application that I use some times which, when at home, can connect to my multimedia center, but without a connection can be used to manipulate some local multimedia files (CridManager).

The thing is, that even when I’m not at home, and thus that multimedia center is unreachable, the app is continuously trying to connect to it, about once per second. And not knowing how well programmed is my Android phone, I do not know if it tries to send those packages to Internet…,.

I tried a traceroute, which tries and tries, instead of bailing out… or am I reading it wrong?

my IP: 192.168.42.167
my GW (phone): 192.168.42.129

The target, non existing, multimedia machine: 192.168.1.2


minas-tirith:~ # traceroute 192.168.1.2
traceroute to 192.168.1.2 (192.168.1.2), 30 hops max, 60 byte packets
1  192.168.42.129 (192.168.42.129)  0.881 ms  1.942 ms  1.919 ms
2  * * *
3  * * *
4  * * *
5  * * *
....
30  * * *
minas-tirith:~ #

minas-tirith:~ # ifconfig
enp0s29f7 Link encap:Ethernet  HWaddr 7A:B6:92:46:CF:C6
inet addr:192.168.42.167  Bcast:192.168.42.255  Mask:255.255.255.0
....

minas-tirith:~ # route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.42.129  0.0.0.0         UG    0      0        0 enp0s29f7u1
192.168.42.0    *               255.255.255.0   U     1      0        0 enp0s29f7u1
minas-tirith:~ #

I have tried to explicitly re-route those packages, but I failed:


minas-tirith:~ # route add --net 192.168.1.0 netmask 255.255.255.0 dev wlan0
NET/ROM: this needs to be written
minas-tirith:~ # route add --net 192.168.1.0  dev wlan0
NET/ROM: this needs to be written
minas-tirith:~ # route add --net 192.168.1.0 wlan0
NET/ROM: this needs to be written
minas-tirith:~ #

and the route is unchanged. I have no idea what the error message means.

–
Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

2

A route has to point to a router (an IP address), not to a device. We discussed this earlier.

BTW, you did not prove that wlan0 exists. As your cable device seems to be enp0s29f7u1, which is a naming acording to the new “perdictable” way of giving names. I doubt that wlan0 exists.

3

On 2014-08-04 15:56, hcvv wrote:
>
> A route has to point to a router (an IP address), not to a device. We
> discussed this earlier.

Not according to the man page:

EXAMPLES
route add -net 127.0.0.0

adds the normal loopback entry, using netmask 255.0.0.0
(class A net, determined from the destination address) and associated
with the “lo” device (assuming this device
was prviously set up correctly with ifconfig(8)).

route add -net 192.56.76.0 netmask 255.255.255.0 dev eth0

adds a route to the network 192.56.76.x via “eth0”. The
Class C netmask modifier is not really necessary here because 192.* is a
Class C IP address. The word “dev” can be
omitted here.

> BTW, you did not prove that wlan0 exists.

Of course it does. The interface exists, with no IPv4 adress, according
to ifconfig:

wlan0 Link encap:Ethernet HWaddr 0C:EE:E6:D7:BB:5F
inet6 addr: fe80::eee:e6ff:fed7:bb5f/64 Scope:Link
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:213113 errors:0 dropped:0 overruns:0 frame:0
TX packets:424900 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:69701704 (66.4 Mb) TX bytes:565605489 (539.4 Mb)

But all that is besides the main point. What I want to find out is if
those packets are really going out to Internet (because they use some of
my cap), and if they do, block them in some manner. If using “route” to
send them to black hole may not be the way, then perhaps an egress
iptables rule, which I have no idea how to do.

–
Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

4

You have made a mistake with syntax

# route add --net 192.168.1.0 netmask 255.255.255.0 dev wlan0

It should be

# route add -net 192.168.1.0 netmask 255.255.255.0 dev wlan0

Then it will take effect. :slight_smile:

5

On 2014-08-04 15:56, hcvv wrote:
>
> A route has to point to a router (an IP address), not to a device. We
> discussed this earlier.

Not according to the man page:

Henk is actually correct. However, the act of assigning the IP address and netmask to a given interface defines how the routing will work (according to the routing methodology he already outlined in a previous thread).

6

On 2014-08-04 22:16, deano ferrari wrote:
>
> You have made a mistake with syntax

…

> Then it will take effect. :slight_smile:

Duh!


minas-tirith:~ # route add -net 192.168.1.0 netmask 255.255.255.0 dev wlan0
minas-tirith:~ # route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.42.129  0.0.0.0         UG    0      0        0 enp0s29f7u1
192.168.1.0     *               255.255.255.0   U     0      0        0 wlan0
192.168.42.0    *               255.255.255.0   U     1      0        0 enp0s29f7u1
minas-tirith:~ #

Yes, it works. Or at least, it is accepted :wink:


minas-tirith:~ # traceroute moria
traceroute to moria (192.168.1.2), 30 hops max, 60 byte packets
1  minas-tirith.valinor (192.168.42.154)  2282.803 ms !H  2282.764 ms !H  2282.756 ms !H
minas-tirith:~ #

I can see in gkrelm and iptraf that the constant network requests to 192.168.1.2 have stopped, which was the main intention I had.

–
Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

7

Excellent. Mission accomplished. :slight_smile:

8

On 2014-08-04 22:26, deano ferrari wrote:
>
>> On 2014-08-04 15:56, hcvv wrote:
>>>
>>> A route has to point to a router (an IP address), not to a device. We
>>> discussed this earlier.
>>
>> Not according to the man page:
>
> Henk is actually correct. However, the act of assigning the IP address
> and netmask to a given interface defines how the routing will work
> (according to the routing methodology he already outlined in a previous
> thread).

But the route command I used, with an interface specified in it, was correct.
My error was the double dash you found, not specifying “wlan” interface.

And the output of the route command very clearly prints the interface:


minas-tirith:~ # route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.42.129  0.0.0.0         UG    0      0        0 enp0s29f7u1
192.168.1.0     *               255.255.255.0   U     0      0        0 wlan0
192.168.42.0    *               255.255.255.0   U     1      0        0 enp0s29f7u1
minas-tirith:~ #

–
Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

9

Yes, IP addresses and netmasks get assigned to specific network interfaces, but I think Henk was trying to make the point that routing is based on IP addresses,masks and metrics - not interfaces per se. There is a subtle difference. It becomes apparent in more complex routing schemes.

10

On 2014-08-05 00:36, deano ferrari wrote:

>> I can see in gkrelm and iptraf that the constant network requests to
>> 192.168.1.2 have stopped, which was the main intention I had.
> Excellent. Mission accomplished. :slight_smile:

Got a weird side effect. When internet goes down, I get in the log:


<0.4> 2014-08-05 14:51:26 minas-tirith kernel - - - [451089.176081] IPv4: martian destination 0.0.0.0 from 192.168.1.2, dev wlan0
<0.4> 2014-08-05 14:51:32 minas-tirith kernel - - - [451095.178075] IPv4: martian destination 0.0.0.0 from 192.168.1.2, dev wlan0
<0.4> 2014-08-05 14:51:38 minas-tirith kernel - - - [451101.180066] IPv4: martian destination 0.0.0.0 from 192.168.1.2, dev wlan0
<0.4> 2014-08-05 14:51:44 minas-tirith kernel - - - [451107.180080] IPv4: martian destination 0.0.0.0 from 192.168.1.2, dev wlan0
<0.4> 2014-08-05 14:51:44 minas-tirith kernel - - - [451107.180139] IPv4: martian destination 0.0.0.0 from 192.168.1.2, dev wlan0
<0.4> 2014-08-05 14:51:50 minas-tirith kernel - - - [451113.182089] IPv4: martian destination 0.0.0.0 from 192.168.1.2, dev wlan0
<0.4> 2014-08-05 14:51:56 minas-tirith kernel - - - [451119.184075] IPv4: martian destination 0.0.0.0 from 192.168.1.2, dev wlan0

A lot of them, filling the log… possibly a worse effect than the original one…

(it can not be “from 192.168.1.2”, as that machine is kilometers from here, no connection at all…)

I can not win. Sigh…

Of course, I could edit syslog config to kill those messages. Another dirty hack.

–
Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

11

Now that I’ve re-read your situation outlined in the opening post, it might have been useful to see how much (broadcast?) traffic the application was generating with wireshark or similar. Maybe a firewall rule is in order…

12

On 2014-08-05 20:56, deano ferrari wrote:
>
> Now that I’ve re-read your situation outlined in the opening post, it
> might have been useful to see how much (broadcast?) traffic the
> application was generating with wireshark or similar. Maybe a firewall
> rule is in order…

It is not a broadcast. It is an FTP connection attempt (SYN) about once
every five seconds to the 192.168.1.2 host, which exists at home, but
not here.

And it uses the default gateway, enp0s29f7, which is connected to
internet via mobile phone, and there is a cap. I do not want that
traffic going there at all. I do not know if the phone sends that
outside or not.

Of course I know that if it goes outside, on Internet, it will
not go anywhere, a private address can not be routed on Internet.
My issue is causing useless traffic on an expensive connection.

One way it the route hack, another would be an egress firewall rule,
which I have never used and I’m unsure how to implement. Or perhaps with
apparmour, which I don’t know how to use for the purpose. I have some
ideas, but the route hack seemed the fastest to implement.

–
Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

13

Well, if it really is a significant amount for traffic (which I find hard to believe), or was impacting on your connection somehow, then I would consider blocking that traffic to that ‘no-reachable’ address eg

# iptables -A OUTPUT -d 192.168.1.2 -j DROP

# iptables -A OUTPUT -d 192.168.1.2 -j DROP
linux-bbgi:/home/dean # ping 192.168.1.2
PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
14

On 2014-08-06 01:16, deano ferrari wrote:
>
> Well, if it really is a significant amount for traffic (which I find
> hard to believe), or was impacting on your connection somehow,

LOL.

No, I suppose it is not that big an impact, although I have not done any
calculation on it. Mostly it makes my network measurement applet to
register activity, so that I do not know if I can disconnect or not the
tether cable.

Let me see… it is 74 bytes every 5 seconds, so about 1 KB/min. 43
MB/month, which is about 4% of my monthly allowance, if I had it on full
day.

Not much, just a nuisance :slight_smile:

(the nuisance is that I don’t know when there is no activity, and when
to decide to disconnect the phone).

>
> Code:
> --------------------
> # iptables -A OUTPUT -d 192.168.1.2 -j DROP
> linux-bbgi:/home/dean # ping 192.168.1.2
> PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
> ping: sendmsg: Operation not permitted
> ping: sendmsg: Operation not permitted
> ping: sendmsg: Operation not permitted
>
> --------------------

Ok, thanks.

Eum… how do I delete the rule when not longer needed?

–
Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

15

Ok, thanks.

Eum… how do I delete the rule when not longer needed?

–
Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

For a single rule, you just delete it using the ‘-D’ option

iptables -D OUTPUT -d 192.168.1.2 -j DROP

*It’s not persistent, so a reboot will kill it too.

16

On 2014-08-06 02:16, deano ferrari wrote:
>
>> Ok, thanks.
>>
>> Eum… how do I delete the rule when not longer needed?

> For a single rule, you just delete it using the ‘-D’ option
>
> Code:
> --------------------
> iptables -D OUTPUT -d 192.168.1.2 -j DROP
> --------------------

Thanks.

>
> *It’s not persistent, so a reboot will kill it too.

Yes, of course. But I hibernate the machine. The current uptime is 13
days. If I go home and don’t know how to disable the rule, I have to
reboot :wink:

–
Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

17

Yes, of course. But I hibernate the machine. The current uptime is 13
days. If I go home and don’t know how to disable the rule, I have to
reboot :wink:

I see. Are you away on holiday or work-related? :slight_smile:

18

On 8/5/2014 8:54 PM, Carlos E. R. wrote:
> On 2014-08-06 02:16, deano ferrari wrote:
>>
<snip>
>> For a single rule, you just delete it using the ‘-D’ option
>>
>> Code:
>> --------------------
>> iptables -D OUTPUT -d 192.168.1.2 -j DROP
>> --------------------
>
> Thanks.
>
>>
>> *It’s not persistent, so a reboot will kill it too.
>
> Yes, of course. But I hibernate the machine. The current uptime is 13
> days. If I go home and don’t know how to disable the rule, I have to
> reboot :wink:
>
Carlos;

I believe just restarting SuSEfirewall2 will suffice.


euler3:~ # iptables -A OUTPUT -d 192.168.0.75 -j DROP
euler3:~ # ping -c3 192.168.0.75
PING 192.168.0.75 (192.168.0.75) 56(84) bytes of data.
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted

--- 192.168.0.75 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2010ms

euler3:~ # systemctl restart SuSEfirewall2
euler3:~ # ping -c3 192.168.0.75
PING 192.168.0.75 (192.168.0.75) 56(84) bytes of data.
From 192.168.0.104 icmp_seq=1 Destination Host Unreachable
From 192.168.0.104 icmp_seq=2 Destination Host Unreachable
From 192.168.0.104 icmp_seq=3 Destination Host Unreachable

--- 192.168.0.75 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2008ms
pipe 3

Note that 192.168.0.75 does not exist, but it becomes “Unreachable” rather than “not permitted” after the firewall is
restarted.

SuSEfirewall2 regenerates the iptables when it starts. That is why you can not use the iptables command to make
permanent changes to the firewall.

–
P.V.
“We’re all in this together, I’m pulling for you” Red Green

19

On 2014-08-06 04:36, deano ferrari wrote:
>
>> Yes, of course. But I hibernate the machine. The current uptime is 13
>> days. If I go home and don’t know how to disable the rule, I have to
>> reboot :wink:
>>
> I see. Are you away on holiday or work-related? :slight_smile:

Half and half.

Slowly painting walls and general repairs on a beach apartment :wink:

(and I don’t like the beach)

–
Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

20

On 2014-08-06 05:02, PV wrote:

> Carlos;
>
> I believe just restarting SuSEfirewall2 will suffice.

Ah, I should have guessed. O:-)

> Note that 192.168.0.75 does not exist, but it becomes “Unreachable”
> rather than “not permitted” after the firewall is restarted.
>
> SuSEfirewall2 regenerates the iptables when it starts. That is why you
> can not use the iptables command to make permanent changes to the
> firewall.

Yes, I knew the second part, so I should have know the first part :wink:

I just tried the method, it works.

How would I block the entire “192.168.1." network? I tried both
"192.168.1.” and “192.168.1.0”, neither works.

The change route method has the advantage that it should work correctly
at the home network, if I forget to remove it, as the “192.168.1.0”
network uses precisely the wlan0 interface.

–
Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))