Colleagues,
I can't get working forwarding of redirected (externally) packets through Linux host. There is network model I'm experimenting with:
+----+(enp2) +----+ +----+
| H2 +---------+ o- +---+ H3 | (192.0.2.153)
+--+-+ | br | +----+
|(enp1) +-+--+
| |
| |
| |
+-------+--------+ +-+--+
| ovs i-br +--+ R1 |
+-------+--------+ +----+
|
|
+--+-+
| H1 | (10.9.8.100)
+----+
for traffic from H1 to H3 there is regular routing exists (through R1), but for some reasons I need to divert some kinds of the traffic through H2, using OVS rules for this. After I've added the rule:
ovs-ofctl add-flow i-br dl_type=0x0800,in_port=1,nw_proto=6,tp_dst=80,actions=output:4
I'm seeing incoming packets on enp1#H2:
15:21:51.596752 IP (tos 0x0, ttl 64, id 48926, offset 0, flags [DF], proto TCP (6), length 60)
10.9.8.100.44444 > 192.0.2.153.http: Flags [S], cksum 0x5f93 (correct), seq 774826047, win 64860, options [mss 1410,sackOK,TS val 3466298181 ecr 0,nop,wscale 7], length 0
While forwarding on H2 is allowed (net.ipv4.ip_forward=1), rpf switched off (net.ipv4.conf.(default|all).rp_filter=0), pings from H2 to both sides are working, iptables FORWARD accepts everything and routing is configured:
10.9.8.0/24 dev enp1s0 proto kernel scope link src 10.9.8.135
192.0.2.0/24 dev enp2s0 proto kernel scope link src 192.0.2.135
I don't see these packets on egress on enp2#H2.
Any ideas why this can happen and what to troubleshoot in order to find the cause?
Thank you.
Solved. It is required to rewrite dst MAC address on OVS as well, so rule must be:
ovs-ofctl add-flow i-br dl_type=0x0800,in_port=1,nw_proto=6,tp_dst=80,actions=mod_dl_dst:xx:xx:xx:xx:xx:xx,output:4
where xx:xx:xx:xx:xx:xx is H2's mac address. This is because H1, when forming ethernet header of outgoing packet, set R1's dst mac (according to H1's routing table). After being redirected on OVS, this packet comes to H2 and the latter ignores it since it's destined to another host.
Related
I heard that there are types of ip addresses like primary address etc. and tried to get the ip address using the below command
ifconfig | grep -Eo 'inet (addr:)?([0-9]*\.){3}[0-9]*' | grep -Eo '([0-9]*\.){3}[0-9]*' | grep -v '127.0.0.1'
and got the result as below
192.168.122.1
192.168.168.1
172.16.142.1
192.168.1.102
so from the above can someone answer which my primary address is?
There is no such things as "primary address" or "primary device". You have multiple ip addresses related to multiple networt devices.
You could find out what devices allows you to access to the internet and finds its local ip.
To do that, issue the command route. It will output something like
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.168.0.254 0.0.0.0 UG 0 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
Now all you need is to use the device on the line default and use it in this command:
ifconfig <DEVICENAME> | grep -Eo 'inet (addr:)?([0-9]*\.){3}[0-9]*' | grep -Eo '([0-9]*\.){3}[0-9]*'
When a machine has different IP addresses, it is impossible to define the primary IP from a network only point of view. But a machine normaly has a name that can be obtained by the command uname -n, or by the POSIX function uname. Once you have that name, you can find the IP address corresponding to it by the getent command or the gethostbyname function: what is called the primary IP address is the first address returned.
So here you could use:
getent hosts $(uname -n) | head -1 | cut -f 1 -w
Primary address depends on your usage, there is nothing as such at the network level. If you use one IP to access your server usually, you may call it primary and the network devices won't know the difference.
I created a custom Buildroot 2015.01 distribution w/ 3.10.0 Linux Kernel with enabled IPv6 support in the Toolchain and the uClibc library.
There is a strange behaviour that takes place when trying to contact any IPv6 routed address, for example:
# wget google.com
Connecting to google.com ([2a00:1450:4002:809::200e]:80)
wget: can't connect to remote host: Network is unreachable
But, if I try the same thing on a non-IPv6 address, everything works correctly:
# wget abc.com
Connecting to abc.com (199.181.132.250:80)
Connecting to abc.go.com (23.21.209.55:80)
index.html 100% |*******************************| 46408 0:00:00 ETA
This is the IPv6 kernel routing table:
# route -A inet6
Destination Next Hop Flags Metric Ref Use Iface
::1/128 :: U 0 0 1 lo
fe80::20a:a5ff:fe12:3446/128 :: U 0 0 1 lo
fe80::/64 :: U 256 0 0 eth0
ff02::1:ffdc:adf/128 :: UC 0 1 0 eth0
ff02::1:fff4:5e3d/128 :: UC 0 1 0 eth0
ff00::/8 :: U 256 0 0 eth0
IPv4 one:
# route -A inet
Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.168.0.230 0.0.0.0 UG 0 0 0 eth0
192.168.0.0 * 255.255.255.0 U 0 0 0 eth0
Any help or suggestion would be very appreciated.
I solved the issue by installing standard wget instead of the Busybox's integrated one.
As it seems our internal network was not IPv6 capable and Busybox's wget stopped when it couldn't reach the destination. Standard wget, instead, falls back to the IPv4 address, completing the download.
EDIT: apart from our network, seems Busybox's wget has some issues
I would like to script some simple shell program to see if there is somebody really connected right now to my DD-WRT router.
As long as these routers allow some simple/average shell, I think a good scriptable method could be entering the router :
ssh root#192.168.8.203 -p 1022
Host '192.168.8.203' is not in the trusted hosts file.
(fingerprint md5 ab:c5:94:c7:d3:56:52:1b:4b:8f:10:40:bf:1b:37:1a)
Do you want to continue connecting? (y/n) y
root#192.168.8.203's password:
==========================================================
____ ___ __ ______ _____ ____ _ _
| _ \| _ \ \ \ / / _ \_ _| __ _|___ \| || |
|| | || ||____\ \ /\ / /| |_) || | \ \ / / __) | || |_
||_| ||_||_____\ V V / | _ < | | \ V / / __/|__ _|
|___/|___/ \_/\_/ |_| \_\|_| \_/ |_____| |_|
DD-WRT v24
http://www.dd-wrt.com
==========================================================
BusyBox v1.4.2 (2007-08-15 14:58:26 CEST) Built-in shell (ash)
Enter 'help' for a list of built-in commands.
... then checking the ARP table:
~ # more /proc/net/arp
IP address HW type Flags HW address Mask Device
192.168.20.100 0x1 0x0 00:00:00:00:00:00 * br0
192.168.20.108 0x1 0x2 78:7E:61:C5:C6:7B * br0
192.168.20.129 0x1 0x2 F0:DB:F8:29:8F:1B * br0
192.168.20.110 0x1 0x0 28:5A:EB:35:CA:C9 * br0
192.168.8.1 0x1 0x2 00:24:A5:C7:DD:BC * vlan1
192.168.20.111 0x1 0x2 F8:A9:D0:67:02:D4 * br0
192.168.20.128 0x1 0x2 5C:97:F3:01:49:1C * br0
... and then, as long as DHCP association table is not enough (an IP address could remain there for hours after the device disconnected), trying to ping some of the LAN side (192.168.20.x in my example) devices:
~ # ping 192.168.20.111
PING 192.168.20.111 (192.168.20.111): 56 data bytes
64 bytes from 192.168.20.111: icmp_seq=0 ttl=64 time=131.8 ms
64 bytes from 192.168.20.111: icmp_seq=1 ttl=64 time=265.5 ms
64 bytes from 192.168.20.111: icmp_seq=2 ttl=64 time=83.5 ms
--- 192.168.20.111 ping statistics ---
4 packets transmitted, 3 packets received, 25% packet loss
round-trip min/avg/max = 83.5/160.2/265.5 ms
But, as you know, sometimes devices don't answer to ping requests even when they are alive (i.e: default behavior for Windows 7):
~ # ping 192.168.20.108
PING 192.168.20.108 (192.168.20.108): 56 data bytes
--- 192.168.20.108 ping statistics ---
10 packets transmitted, 0 packets received, 100% packet loss
I can not perform some nmap scan, due to it is not installed on DD-WRT.
Is there any scriptable method to know if a not-answering IP address is alive (the device is on) on the LAN?
If your router has arping, you can use it to perform an Ethernet level ping. This is lower level than ICMP, and essentially unblockable.
$ arping -I eth0 192.168.28.1
ARPING 192.168.28.1 from 192.168.28.130 eth0
Unicast reply from 192.168.28.1 [00:15:60:FF:8B:40] 1.176ms
Unicast reply from 192.168.28.1 [00:15:60:FF:8B:40] 1.249ms
This test verifies that at a minimum the remote host's NIC is responding to ARP requests. An ARP request is when your computer asks "who has such-and-such IP address?" and the remote computer responds, "that's me, and my MAC address is XYZ." Computers do not block ARP requests because to do so would make Ethernet communication impossible.
arping doesn't necessarily tell you that the OS is responsive, but it does tell you the computer is powered on. Also, in contrast to ICMP pings, ARP requests are not routable. You can only check hosts that you are physically connected to.
Even when the answer of #JohnKugelman is fine, I hope this one will be
more portable to simpler devices.
It seems that a simple arp -a command issues an attemp to locate the ARP cache devices via network ARP request:
~ # arp -a
Kelseys-iPhone (192.168.10.116) at <incomplete> on br0
danielas-iPhone (192.168.10.119) at <incomplete> on br0
iPad-de-Mery (192.168.10.114) at F0:DB:F8:29:8F:1B [ether] on br0
? (192.168.8.1) at 00:24:A5:C7:DD:BC [ether] on vlan1
sinsanguguiiPad (192.168.10.102) at <incomplete> on br0
android-a52cac45f5022d72 (192.168.10.115) at 90:B6:86:C1:5B:8F [ether] on br0
So, just greping by IP address or incomplete pattern should enough (example for the above output):
arp -a | grep "192.168.10.119" | grep "incomplet"
if [ $? -eq 0 ] ; then echo "Device not responding to ARP requests on network" ; fi
Tested working on my DD-WRT router.
(Note that I have used incomplet instead of incomplete to make it work for spanish and maybe some more languages :-) )
i've been looking for a solution for this for a while, hope you can help me.
I have a network at home like this.
+----------+
| INTERNET |
+-----+----+
|
+-----+----+
| CABLE |
| MODEM |
+-----+----+
|
+----------+---------+
| |
| |
+-----v-----+ +-----v-----+
+--------+ D-LINK | | D-LINK |
| | DIR-600 | | DI-524 |
| +-----------+ +-----+-----+
| | |
| | |
+ +-----+-----+ |
192.168.2.XXX---> Windows7 | |
+ | | |
| +-----------+ |
+ |Ubuntu | |
192.168.2.YYY +->Virtualbox <---Public IP ++
+-----------+
One Cable Modem with a Router (Dir-600) for local IPs, and an Access Point (DI-524) for public IPs.
On the local network i have a computer with Windows 7 and Virtualbox, In the virtualbox I have an Ubuntu 14.04 server. This server has internet conection on ETH0 with a bridged adapter, so it has a local IP like 192.168.2.XXX.
Also on the virtualbox i have set a wlan adapter with direct access to the virtual ubuntu server and connected to the DI-524 network with a public IP.
So, the ubuntu server has 2 interfaces:
ETH0 connected to local network with IP 192.168.2.XXX
WLAN1 connected to DI-524 with public IP.
What I want is:
Give WLAN1 the highest priority for internet access. And only if there is no WLAN connection, the virtual machine can access internet through ETH0.
I know it can be done changing metrics, but don't know how, i've tried many commands but nothing seems to work.
Can anybody help me?
Thanks in advance!
yes you can do that via ifmetric package install it on ubuntu then set number for example 10 to wlan0 and number 20 for eth0 it mean the highest priority number for wlan0 highest priority is 0 by default (priority denotes metric) check this topic enter link description here
but plz check your metric first via
route -n
then you can delete old metrics via something like this command
sudo route del -net default gw 192.168.2.XX netmask 0.0.0.0 dev wlan0 metric 0
I think this is a greping problem rather than a networking one:
My computer uses to have multiple ppp connections running at the same time, sometimes 0, sometimes 1, 2... etc.
For example, before connecting:
$ ifconfig | grep "ppp"
ppp0 Link encap:Point-to-Point Protocol
ppp1 Link encap:Point-to-Point Protocol
And, after connecting a new one:
$ ifconfig | grep "ppp"
ppp0 Link encap:Point-to-Point Protocol
ppp1 Link encap:Point-to-Point Protocol
ppp2 Link encap:Point-to-Point Protocol
How could I programmatically guess the ppp device (ppp2 in this example) just created?
EDIT-1: This could be another possible before connecting case:
$ ifconfig | grep "ppp"
$
(No ppp devices active)
EDIT-2: This could be another possible before connecting case:
$ ifconfig | grep "ppp"
ppp0 Link encap:Point-to-Point Protocol
ppp2 Link encap:Point-to-Point Protocol
A "hole" at ppp1: it does not exist, so the new ppp status after connecting will be:
$ ifconfig | grep "ppp"
ppp0 Link encap:Point-to-Point Protocol
ppp1 Link encap:Point-to-Point Protocol
ppp2 Link encap:Point-to-Point Protocol
I think the ppp devices behave that way.