I want to set eth0 of RPI (Raspbian Stretch) to be DHCP, my goal is that when I will connect any device that communicates using TCP/IP protocol, that device will receive an IP address.
I have found many guides that all lead to making eth0 ip address static, which is not my intention.
Currently a device is connected through eth0 , ifconfig says it has some IP but pinging the hostname of the device gets no reply. wlan0 is connected via wifi.
Here is some info :
pi#raspberrypi:~ $ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 169.254.31.197 netmask 255.255.0.0 broadcast 169.254.255.255
inet6 fe80::ad5a:8219:4c27:b59b prefixlen 64 scopeid 0x20<link>
ether b8:27:eb:f3:f2:87 txqueuelen 1000 (Ethernet)
RX packets 81 bytes 26568 (25.9 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 46 bytes 10544 (10.2 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 31 bytes 3472 (3.3 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 31 bytes 3472 (3.3 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.71 netmask 255.255.255.0 broadcast 192.168.0.255
inet6 fd01::60ff:8818:5965:dc58 prefixlen 64 scopeid 0x0<global>
inet6 fe80::473d:110e:5474:8000 prefixlen 64 scopeid 0x20<link>
ether b8:27:eb:a6:a7:d2 txqueuelen 1000 (Ethernet)
RX packets 955 bytes 74427 (72.6 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 184 bytes 22096 (21.5 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
pi#raspberrypi:~ $ cat /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)
# Please note that this file is written to be used with dhcpcd
# For static IP, consult /etc/dhcpcd.conf and 'man dhcpcd.conf'
# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d
Any advice to how to achieve my goal will be happily received.
Have you tried this: https://wiki.debian.org/NetworkConfiguration#Using_DHCP_to_automatically_configure_the_interface
i.e. just add this to /etc/network/interfaces:
auto eth0
allow-hotplug eth0
iface eth0 inet dhcp
if you're really pedantic you could create a file like /etc/network/interfaces.d/eth0-dhcp and paste these lines into it - the end result will be the same.
If you simply want to connect two devices (without routing/forwarding/etc), i.e. for a standalone test network, this should work:
Figure out what IP range you want to use, and what IP you want your
DHCP server to have (let's call it IP_DHCP)
Install isc-dhcp server
Set static IP address for eth0 (e.g. set it to the IP_DHCP you
chose earlier)
Configure /etc/dhcp/dhcpd.conf for the desired network range (man
dhcpd has a decent reference), make it authoritative (unless there
are other DHCP servers).
Run service isc-dhcpd-server start
Example of a configuration:
sudo apt-get install isc-dhcp-server
sudo nano /etc/conf/dhcpd.conf
Uncomment #authoritative to make it authoritative
Add along the following lines(customize based on what you decided in step 1), where routers is IP_DHCP:
subnet 10.0.0.0 netmask 255.255.255.0 {
range 10.0.0.1 10.0.0.100;
option subnet-mask 255.255.255.0;
option broadcast-address 10.0.0.255;
option routers 10.0.0.1;
}
Save buffer and close
sudo service isc-dhcpd-server start
Good luck!
P.S. if you are getting connect:network not found issues, then you likely have an issue in your routing tables (route) setup.
Something along the lines of
sudo route add default gw 10.0.0.1
where the IP address is your eth0 will likely allow communication.
NetWork Manager (nmcli) might be running on the device and has been configured to work with a static IP.
The following commands can help you check if your device is managed by nmcli:
nmcli d
nmcli con show
Run the following command and replace 'Wired connection 1' with the name of your connection.
nmcli con show 'Wired connection 1' | grep 'ipv4.method'
ipv4.method will show "auto" if set to DHCP or "manual" if set to static.
http://www.intellamech.com/RaspberryPi-projects/rpi_nmcli.html
Related
I'm trying to connect my Raspberry Pi 3B+ to my network. But neither do the LAN-LEDs light up nor does the Pi even know what eth0 is. I also have no en<x><MAC>.
ifconfig outputs the following (ifconfig -a does the same):
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 10 bytes 1564 (1.5 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 10 bytes 1564 (1.5 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
wlan0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether MY-MAC-ADDRESS txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
/etc/network/interfaces is as follows:
# interfaces(5) file used by ifup(8) and ifdown(8)
# Include files from /etc/network/interfaces.d:
source /etc/network/interfaces.d/*
/etc/network/interfaces.d/ is empty.
Like I said, it doesn't know what eth0 is at all:
~$ ifup eth0
ifup: unknown interface eth0
~$ sudo dhclient eth0
Cannot find device "eth0"
The network cable works, tested it on other PCs and tried many different ones...
I believe there was a bug introduced in Bulleye.
If /boot/cmdline.txt does not have "net.ifnames=0", then add that to the end of the root= line. Then reboot.
I am interested in programming with the lwIP IP Stack. In order to experiment, I've been trying to run the echo server which is included in the example applications. However, I am having difficulty setting up the internal networking configuration to communicate with the server, and I'd like to find what I'm doing wrong. Here's what I've done so far.
So first, I'm successfully starting the echo server using sudo and setting it to listen on 172.16.0.2 with 172.16.0.1 as gateway:
>>sudo ./echop -i 172.16.0.2 -m 255.255.0.0 -g 172.16.0.1
[sudo] password for user:
Host at 172.16.0.2 mask 255.255.0.0 gateway 172.16.0.1
TCP/IP initialized.
SNMP private MIB start, detecting sensors.
Applications started.
The program successfully enables the tap0 interface and starts the gateway:
>>ifconfig
enp0s3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.0.2.15 netmask 255.255.255.0 broadcast 10.0.2.255
inet6 fe80::a00:27ff:fe4c:f329 prefixlen 64 scopeid 0x20<link>
ether 08:00:27:4c:f3:29 txqueuelen 1000 (Ethernet)
RX packets 10860 bytes 10827195 (10.8 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 8571 bytes 904790 (904.7 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1 (Local Loopback)
RX packets 811 bytes 93113 (93.1 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 811 bytes 93113 (93.1 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
tap0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 172.16.0.1 netmask 255.255.0.0 broadcast 172.16.255.255
inet6 fe80::49f:4fff:fe82:d8fb prefixlen 64 scopeid 0x20<link>
ether 06:9f:4f:82:d8:fb txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 129 bytes 14904 (14.9 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
I can successfully ping the gateway:
>>ping -c 5 172.16.0.1
PING 172.16.0.1 (172.16.0.1) 56(84) bytes of data.
64 bytes from 172.16.0.1: icmp_seq=1 ttl=64 time=0.028 ms
64 bytes from 172.16.0.1: icmp_seq=2 ttl=64 time=0.076 ms
64 bytes from 172.16.0.1: icmp_seq=3 ttl=64 time=0.097 ms
64 bytes from 172.16.0.1: icmp_seq=4 ttl=64 time=0.037 ms
64 bytes from 172.16.0.1: icmp_seq=5 ttl=64 time=0.039 ms
--- 172.16.0.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4086ms
rtt min/avg/max/mdev = 0.028/0.055/0.097/0.027 ms
However if I try to reach the actual echo server, the route is not found:
>>ping -c 5 172.16.0.2
PING 172.16.0.2 (172.16.0.2) 56(84) bytes of data.
From 172.16.0.1 icmp_seq=1 Destination Host Unreachable
From 172.16.0.1 icmp_seq=2 Destination Host Unreachable
From 172.16.0.1 icmp_seq=3 Destination Host Unreachable
From 172.16.0.1 icmp_seq=4 Destination Host Unreachable
From 172.16.0.1 icmp_seq=5 Destination Host Unreachable
It does seems as if the route has been added if I list the current routes:
>>route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default gateway 0.0.0.0 UG 100 0 0 enp0s3
10.0.2.0 0.0.0.0 255.255.255.0 U 100 0 0 enp0s3
link-local 0.0.0.0 255.255.0.0 U 1000 0 0 tap0
172.16.0.0 0.0.0.0 255.255.0.0 U 0 0 0 tap0
To make sure, I've tried to add an explicit route to the echo server, but the route still cannot be found:
>>sudo route add 172.16.0.2 dev tap0 gw 172.16.0.1
>>route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default gateway 0.0.0.0 UG 100 0 0 enp0s3
10.0.2.0 0.0.0.0 255.255.255.0 U 100 0 0 enp0s3
link-local 0.0.0.0 255.255.0.0 U 1000 0 0 tap0
172.16.0.0 0.0.0.0 255.255.0.0 U 0 0 0 tap0
172.16.0.2 172.16.0.1 255.255.255.255 UGH 0 0 0 tap0
>>ping -c 5 172.16.0.2
PING 172.16.0.2 (172.16.0.2) 56(84) bytes of data.
From 172.16.0.1 icmp_seq=1 Destination Host Unreachable
From 172.16.0.1 icmp_seq=2 Destination Host Unreachable
From 172.16.0.1 icmp_seq=3 Destination Host Unreachable
From 172.16.0.1 icmp_seq=4 Destination Host Unreachable
From 172.16.0.1 icmp_seq=5 Destination Host Unreachable
--- 172.16.0.2 ping statistics ---
5 packets transmitted, 0 received, +5 errors, 100% packet loss, time 4094ms
pipe 4
I would like help on configuring my interfaces/routes so that I can experiment with the lwIP (1.30) echo server, which is configured on port 7. Using version 1.30 as I'm using it with older devices.
OS info:
>>uname -a
Linux ReSyst 4.8.0-59-generic #64-Ubuntu SMP Thu Jun 29 19:38:34 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Thanks
I have a Linux Docker container which needs a wireless interface to work. On Linux (running it at a Linux host) I have no problem with that.
Running Docker container with arguments --privileged and --net=host I can access the host wireless interfaces, and I can manage them without any issue. The problem is when I run the same Linux Docker container on a Mac OS X host. I can't see the wireless interface inside the Docker container.
This is the output of ifconfig at Mac OS X v10.12 (Sierra) host:
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
options=1203<RXCSUM,TXCSUM,TXSTATUS,SW_TIMESTAMP>
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
nd6 options=201<PERFORMNUD,DAD>
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=b<RXCSUM,TXCSUM,VLAN_HWTAGGING>
ether 00:0c:29:fe:78:07
inet6 fe80::8ff:62ac:e141:5aa9%en0 prefixlen 64 secured scopeid 0x4
inet 192.168.0.153 netmask 0xffffff00 broadcast 192.168.0.255
nd6 options=201<PERFORMNUD,DAD>
media: autoselect (1000baseT <full-duplex>)
status: active
en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ether 00:c0:ca:5a:00:f2
nd6 options=201<PERFORMNUD,DAD>
media: autoselect (<unknown type>)
status: inactive
utun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 2000
inet6 fe80::7a12:53b9:61c3:3c7%utun0 prefixlen 64 scopeid 0x6
nd6 options=201<PERFORMNUD,DAD>
The "en1" interface is the wireless usb device. Now the ifconfig output inside the container run with the parameters described:
docker0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 172.17.0.1 netmask 255.255.0.0 broadcast 0.0.0.0
ether 02:42:67:b5:aa:36 txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.65.2 netmask 255.255.255.248 broadcast 192.168.65.7
inet6 fe80::b564:23a5:1418:8f2a prefixlen 64 scopeid 0x20<link>
ether c0:ff:ee:c0:ff:ee txqueuelen 1000 (Ethernet)
RX packets 22 bytes 2418 (2.3 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 33 bytes 3100 (3.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1 (Local Loopback)
RX packets 3 bytes 54 (54.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 3 bytes 54 (54.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
I guess the container's eth0 is "mapped" to the en0 interface and is working, and I have Internet access inside the container. But, why am I not seeing en1 mapped to any device on container?
How do I achieve this on Mac OS X? If I remove the --net=host from the command line to launch Docker, the interface docker0 disappears inside the container... is the difference, but wireless interface doesn't appear in any case.
I'm running on an embedded linux buildroot OS and have installed a custom WiFi driver which starts in "wireless extensions mode". I can see that driver from an xterm window (whether I'm running as root or a normal user) with the following commands:
cat /proc/net/dev
cat /proc/net/wireless
ifconfig -a
The wlan0 interface looks like this when printed via ifconfig -a:
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 169.254.185.103 netmask 255.255.0.0 broadcast 169.254.255.255
inet6 fe80::24b:5bfc:8a9e:b148 prefixlen 64 scopeid 0x20<link>
ether 00:23:a7:40:22:f1 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 40 overruns 0 carrier 0 collisions 0
But, when I run from my application, I can see all the interfaces on my system EXCEPT wlan0. wlan0 is completely filtered out when viewed by my application. I've tried these things from code within my application:
system("cat /proc/net/dev");
system("cat /proc/net/wireless");
system("ifconfig -a");
FILE* fopen("/proc/net/dev", "r"); fgets(...
I've run my application as both root and as a normal user and see the same results. I've changed the ownership of my program to root:root and installed it as root with the s bit and that didn't help. So, it doesn't seem to be a security issue...?
Any ideas?
I have a Xen dom0 running Debian Wheezy (7.8) and Xen 4.1, set up with bridged networking.
199.XXX.161.64 is the dom0 gateway.
199.XXX.161.65 is the dom0 address.
192.XXX.13.128/28 is the subnet for the domU's.
Configuration dom0:
root#dom0:~# cat /etc/network/interfaces
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet manual
auto xenbr0
iface xenbr0 inet static
address 199.XXX.161.65
netmask 255.255.255.254
network 199.XXX.161.64
broadcast 199.XXX.161.65
gateway 199.XXX.161.64
dns-nameservers 199.XXX.162.41 199.XXX.162.141
bridge_ports eth0
bridge_stp off # disable Spanning Tree Protocol
bridge_fd 0 # no forwarding delay
bridge_maxwait 0 # no delay before a port becomes available
allow-hotplug xenbr0 # start interface on hotplug event
root#dom0:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master xenbr0 state UP qlen 1000
link/ether 00:25:90:d5:06:1a brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 00:25:90:d5:06:1b brd ff:ff:ff:ff:ff:ff
4: xenbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
link/ether 00:25:90:d5:06:1a brd ff:ff:ff:ff:ff:ff
inet 199.XXX.161.65/31 brd 199.XXX.161.65 scope global xenbr0
inet6 fe80::XXXX:90ff:fed5:61a/64 scope link
valid_lft forever preferred_lft forever
8: vif1.0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master xenbr0 state UP qlen 32
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
inet6 fe80::fcff:ffff:feff:ffff/64 scope link
valid_lft forever preferred_lft forever
root#dom0:~# brctl show
bridge name bridge id STP enabled interfaces
xenbr0 8000.002590d5061a no eth0
vif1.0
root#dom0:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 199.XXX.161.64 0.0.0.0 UG 0 0 0 xenbr0
192.XXX.13.128 0.0.0.0 255.255.255.240 U 0 0 0 xenbr0
199.XXX.161.64 0.0.0.0 255.255.255.254 U 0 0 0 xenbr0
root#dom0:~# iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-out vif1.0 --physdev-is-bridged
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-in vif1.0 --physdev-is-bridged udp spt:68 dpt:67
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-out vif1.0 --physdev-is-bridged
ACCEPT all -- 192.XXX.13.129 0.0.0.0/0 PHYSDEV match --physdev-in vif1.0 --physdev-is-bridged
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
This host can reach its gateway and thus the internet.
root#dom0:~# ping -c 1 199.XXX.161.64
PING 199.XXX.161.64 (199.XXX.161.64) 56(84) bytes of data.
64 bytes from 199.XXX.161.64: icmp_req=1 ttl=64 time=0.459 ms
--- 199.XXX.161.64 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.459/0.459/0.459/0.000 ms
I also have a domU (with the same OS) which needs a primary IP address in a different subnet. There is no gateway on the network in this subnet. I want to keep my network setup bridged (no dom0 routing or NAT) so I added the dom0 gateway as the gateway for the domU as described in this blogpost.
Configuration domU:
root#domU:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:16:3e:b7:7e:cc brd ff:ff:ff:ff:ff:ff
inet 192.XXX.13.129/28 brd 192.XXX.13.143 scope global eth0
inet6 fe80::XXXX:3eff:feb7:7ecc/64 scope link
valid_lft forever preferred_lft forever
root#domU:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 199.XXX.161.64 0.0.0.0 UG 0 0 0 eth0
192.XXX.13.128 0.0.0.0 255.255.255.240 U 0 0 0 eth0
199.XXX.161.64 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
With this configuration the domU still has no network access. To test if the bridge was working I manually added a route to dom0.
root#domU:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 199.XXX.161.64 0.0.0.0 UG 0 0 0 eth0
192.XXX.13.128 0.0.0.0 255.255.255.240 U 0 0 0 eth0
199.XXX.161.64 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
199.XXX.161.65 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
Now the dom0 and domU can communicate through the bridge.
root#domU:~# ping -c 1 199.XXX.161.65
PING 199.XXX.161.65 (199.XXX.161.65) 56(84) bytes of data.
64 bytes from 199.XXX.161.65: icmp_req=1 ttl=64 time=0.037 ms
--- 199.XXX.161.65 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.037/0.037/0.037/0.000 ms
root#dom0:~# ping -c 1 192.XXX.13.129
PING 192.184.13.129 (192.XXX.13.129) 56(84) bytes of data.
64 bytes from 192.XXX.13.129: icmp_req=1 ttl=64 time=0.100 ms
--- 192.XXX.13.129 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.100/0.100/0.100/0.000 ms
However, the domU still can't reach the gateway.
root#domU:~# ping -c 1 199.XXX.161.64
PING 199.XXX.161.64 (199.XXX.161.64) 56(84) bytes of data.
From 192.XXX.13.129 icmp_seq=1 Destination Host Unreachable
--- 199.XXX.161.64 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
I have attempted to log establish if the traffic is actually being sent through the bridge by inserting a -j LOG rule at the top of the INPUT, OUTPUT and FORWARD iptables chains. When the domU attempts to ping the gateway the dom0 does not log a single packet. I also tried manually adding an entry for the gateway in domU's ARP table but the results were the same. The domU can't reach the gateway and thus has no network access other than being able to communicate with dom0 via static route.
So if I am understanding this correctly, the following is the network configuration for your DomU:
192.XXX.13.129/28 - DomU IP Address
199.XXX.161.64 - DomU GW Address
The problem is that your DomU does not have a route (layer 3) to allow it to talk to the GW address since the GW address is in a different subnet. So even though the router is on the same layer 2 network, the router (if it is processing your packets) does not know about your layer 3 network and is sending it's responses to it's default gateway.
That you are able to ping the Dom0 from the DomU is odd and probably the result of both the Dom0 and the DomU using the same Linux Bridge (which it not a true ethernet switch, more like a dumb hub).
The simple fix is to add an address from your DomU network to the LAN interface on your router.
The better fix would be to use VLANs to segment the different networks via layer 2 and replace Linux Bridges with Open vSwitch. This would completely isolate the Dom0 and DomU traffic so that they would be required to communication via a router and possibly a firewall.