Change default docker0 bridge ip address - docker-ce

After starting docker-ce (18.06.1-ce, build e68fc7a) on Ubuntu Server 16.04, the following is created:
$ ifconfig
docker0 Link encap:Ethernet HWaddr 02:42:fe:36:81:72
inet addr:172.17.0.1 Bcast:0.0.0.0 Mask:255.255.0.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Unfortunately, my PC is on this network. Meaning that as soon as the docker starts, I lose ssh connectivity to the server.
Attempt 1
Several forums are saying to add the following to /etc/docker/daemon.json:
{
"bip": "192.168.1.1/24"
}
Attempt 2, using this SO accepted answer
One possible solution that is working is running:
sudo ip addr add dev docker0 192.168.1.1/24
sudo ip addr del dev docker0 172.17.0.1/16
Source: forums.docker.com
Although this is a possible solution, I have to do it after the docker service starts. Something I can't do because I lose connectivity meanwhile.
Attempt 3, following #Light.G answer
After adding the -bip to ExecStart line, trying to start docker gives (journalctl -xe):
-- Unit docker.socket has begun starting up.
Sep 11 11:13:19 PTLISLABHLC01 systemd[1]: Listening on Docker Socket for the API.
-- Subject: Unit docker.socket has finished start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit docker.socket has finished starting up.
--
-- The start-up result is done.
Sep 11 11:13:19 PTLISLABHLC01 systemd[1]: docker.service: Start request repeated too quickly.
Sep 11 11:13:19 PTLISLABHLC01 systemd[1]: Failed to start Docker Application Container Engine.
-- Subject: Unit docker.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit docker.service has failed.
--
-- The result is failed.
Sep 11 11:13:19 PTLISLABHLC01 systemd[1]: docker.socket: Unit entered failed state.
Sep 11 11:13:19 PTLISLABHLC01 polkitd(authority=local)[1062]: Unregistered Authentication Agent for unix-process:15666:32644036 (system bus name :1.56, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus)
Only error here is that you should use --bip and not -bip. Check the accepted answer!

No need extra entity:
Edit /lib/systemd/system/docker.service before start Docker. Add --bip "192.168.1.1/24" at the end of line ExecStart=/usr/bin/dockerd.
systemctl daemon-reload
systemctl start docker
Tested on Ubuntu 16.04 with Docker 17.03-ce.
Edit on 2018-09-13:
Since we might still need user-defined bridge networks, there is still a potential issue.
By default bridge is assigned one subnet from the ranges 172.[17-31].0.0/16 or 192.168.[0-240].20/20 which does not overlap with any existing interface. Unlike the default bridge network, user-defined networks supports manual IP address and subnet assignment. If an assignment is not given, then Docker’s default IPAM driver assigns the next subnet available in the private space.
Thougt they say it would not overlap with any existing interfaces on host, you still suffered such an issue. So if you need user-defined bridge networks, you’d better assign specific subnet for them. As I know, there is no parameters for customizing IPAM driver default pool.

My solution was to do it with a service that runs a shell command.
I created docker-network-setup.sh:
sudo ip addr add dev docker0 192.168.1.1/24
sudo ip addr del dev docker0 172.17.0.1/16
chmod u+x docker-network-setup.sh to ensure you can execute it.
And docker-network-setup.service:
[Unit]
Description=Change docker0 default IP
# When systemd stops or restarts the docker.service, the action is propagated to this unit
PartOf=docker.service
# Start this unit after the docker.service start
After=docker.service
[Service]
# The program will exit after running the script
Type=oneshot
# Execute the shell script
ExecStart=/bin/bash /home/user01/docker-network-setup.sh start
# This service shall be considered active after start
RemainAfterExit=yes
[Install]
# This unit should start when docker.service is starting
WantedBy=docker.service
sudo cp docker-network-setup.service /etc/systemd/system and the service is enabled!
Don't forget sudo systemctl daemon-reload if you want to test the service right away.

I struggled with AWS VPC peering connection that didn't work with my Docker containers until I found this thread.
In case you're using an AWS 172.17.x.x subnet, it might conflict with the default Docker subnet (172.17.0.1/16), so nothing will work between those subnets...
One way to fix it will be just moving to a different AWS subnet (which is not always possible due to legacy systems/configurations);
Another way will be to change the default Docker subnet with bip setup in /etc/docker/daemon.json (as described above) - something like:
{
"bip": "192.168.1.1/24"
}
Best approach will be just to avoid using 172.17.x.x subnet in AWS...

Related

How to: Podman rootless expose containers ports to the outside and see real client ip

This is my first time asking something on stackoverflow. For years I've been lurking but now I decided to finally register myself. Hence, I apologize if my question/information is not formatted nicely.
Current situation:
I'm slowly getting more and more familiar with Podman and I'm in the process of moving some of my containers over from docker (rootful) to podman (rootless). I'm using Podman 4.3.1 on Debian 11. I've managed to get some containers working and was able to externally connect to them. However, the container shows client/source ip '127.0.0.1' instead of my real client's IPv4. I was wondering whether something like the following is possible?
Ideal situation:
Assigning a specific IPv4 to the container (rootless). Using nftables/iptables to forward packets from the host's network to the containers ipv4 (e.g. 192.168.1.12). Being able to see the real client's IPv4 in the container to still be able use fail2ban etc.
As you may notice, I'm still very much in the process of learning how containerization works and specifically for networking. I don't want to use the hosts network for my container for security reasons. If something is unclear tell me and I'll try to better explain myself.
Thanks for taking your time to read this :)
When you're running Podman as a non-root user, the virtual tap device that represents the container's eth0 interface can't be attached directly to a bridge device. This means it's not possible to use netfilter rules to direct traffic into the container; instead, Podman relies on a proxy process.
There are some notes on this configuration here.
By default, Podman uses the rootlessport proxy, which replaces the source ip of the connection with an internal ip from the container namespace. You can, however, explicitly request Podman to use slirp4netns as the port handler, which will preserve the source address at the expense of some performance.
For example, if I start a container like this:
podman run --name darkhttpd --rm -p 8080:8080 docker.io/alpinelinux/darkhttpd
And then connect to this from somewhere:
curl 192.168.1.200:8080
I will see in the access log:
10.0.2.100 - - [12/Feb/2023:15:30:54 +0000] "GET / HTTP/1.1" 200 354 "" "curl/7.85.0"
Where 10.0.2.100 is in fact the address of the container:
$ podman exec darkhttpd ip a show tap0
2: tap0: <BROADCAST,UP,LOWER_UP> mtu 65520 qdisc fq_codel state UNKNOWN qlen 1000
link/ether 26:77:5b:e8:f4:6e brd ff:ff:ff:ff:ff:ff
inet 10.0.2.100/24 brd 10.0.2.255 scope global tap0
valid_lft forever preferred_lft forever
inet6 fd00::2477:5bff:fee8:f46e/64 scope global dynamic flags 100
valid_lft 86391sec preferred_lft 14391sec
inet6 fe80::2477:5bff:fee8:f46e/64 scope link
valid_lft forever preferred_lft forever
But if I explicitly request slirp4nets as the port handler:
podman run --name darkhttpd --rm -p 8080:8080 --network slirp4nets:port_handler=slirp4netns docker.io/alpinelinux/darkhttpd
Then in the access log I will see the actual source ip of the request:
192.168.1.97 - - [12/Feb/2023:15:32:17 +0000] "GET / HTTP/1.1" 200 354 "" "curl/7.74.0"
In most cases, you don't want to rely on the source ip address for authentication/authorization purposes, so the default behavior makes sense.
If you need the remote ip for logging purposes, the option presented here will work, or you can also look into running a front-end proxy in the global namespace that places the client ip into the X-Forwarded-For header and use that for your logs.
Here is an alternative solution not mentioned in the nice
answer by #larsks.
Socket activation
When using socket activation of containers, the source IP is available to the container.
Support for socket activation is not yet wide-spread but for instance the container image docker.io/library/mariadb supports socket activation. The container image docker.io/library/nginx also supports socket activation (although in a non-standard way, as nginx uses its own environment variable instead of using the standard systemd environment variable LISTEN_FDS)
I wrote a minimal demo of how to use run docker.io/library/nginx with Podman and socket activation:
https://github.com/eriksjolund/podman-nginx-socket-activation

docker-compose network creation kicks me out of ssh

I need help understanding my networking logs due to docker-compose networking.
I'm ssh'd into a VM, and I have two projects with docker-compose. The first is launched simply with docker-compose up. When I try to launch the second, my ssh session freezes, and I can no longer ssh into the VM. After lots of trial and error, and after reading this I tried to append to my 2nd project's docker-compose.yml file the following:
networks:
default:
external:
name: abcdef_default
where abcdef_default is the name of the network created by docker-compose up of the 1st project. With this, the docker-compose up on the 2nd project doesn't kick me out of the ssh session.
I tailed the logs in /var/log/*.log, and here's the output with the networks section in the docker-compose.yml file (without the timestamp prefix: Jan 19 09:13:42 hostname kernel: [420096.305357]):
aufs au_opts_verify:1597:dockerd[13813]: dirperm1 breaks the protection by the permission bits on the lower branch
device veth6a84537 entered promiscuous mode
IPv6: ADDRCONF(NETDEV_UP): veth6a84537: link is not ready
eth0: renamed from veth2480623
IPv6: ADDRCONF(NETDEV_CHANGE): veth6a84537: link becomes ready
br-fe0deb0149df: port 18(veth6a84537) entered forwarding state
br-fe0deb0149df: port 18(veth6a84537) entered forwarding state
aufs au_opts_verify:1597:dockerd[25317]: dirperm1 breaks the protection by the permission bits on the lower branch
device veth1a3c1e3 entered promiscuous mode
IPv6: ADDRCONF(NETDEV_UP): veth1a3c1e3: link is not ready
br-fe0deb0149df: port 22(veth1a3c1e3) entered forwarding state
br-fe0deb0149df: port 22(veth1a3c1e3) entered forwarding state
eth0: renamed from veth54e576d
IPv6: ADDRCONF(NETDEV_CHANGE): veth1a3c1e3: link becomes ready
br-fe0deb0149df: port 22(veth1a3c1e3) entered disabled state
veth54e576d: renamed from eth0
br-fe0deb0149df: port 22(veth1a3c1e3) entered disabled state
device veth1a3c1e3 left promiscuous mode
br-fe0deb0149df: port 22(veth1a3c1e3) entered disabled state
br-fe0deb0149df: port 18(veth6a84537) entered forwarding state
and here's the output without the networks section (i.e. when I get kicked out of the ssh session):
IPv6: ADDRCONF(NETDEV_UP): br-55349b03453a: link is not ready
aufs au_opts_verify:1597:dockerd[26982]: dirperm1 breaks the protection by the permission bits on the lower branch
aufs au_opts_verify:1597:dockerd[26982]: dirperm1 breaks the protection by the permission bits on the lower branch
aufs au_opts_verify:1597:dockerd[3051]: dirperm1 breaks the protection by the permission bits on the lower branch
device veth7a1bcde entered promiscuous mode
IPv6: ADDRCONF(NETDEV_UP): veth7a1bcde: link is not ready
br-55349b03453a: port 1(veth7a1bcde) entered forwarding state
br-55349b03453a: port 1(veth7a1bcde) entered forwarding state
br-55349b03453a: port 1(veth7a1bcde) entered disabled state
eth0: renamed from veth5d8a2ea
IPv6: ADDRCONF(NETDEV_CHANGE): veth7a1bcde: link becomes ready
br-55349b03453a: port 1(veth7a1bcde) entered forwarding state
br-55349b03453a: port 1(veth7a1bcde) entered forwarding state
IPv6: ADDRCONF(NETDEV_CHANGE): br-55349b03453a: link becomes ready
aufs au_opts_verify:1597:dockerd[13814]: dirperm1 breaks the protection by the permission bits on the lower branch
aufs au_opts_verify:1597:dockerd[13814]: dirperm1 breaks the protection by the permission bits on the lower branch
aufs au_opts_verify:1597:dockerd[13922]: dirperm1 breaks the protection by the permission bits on the lower branch
device veth3253bd4 entered promiscuous mode
IPv6: ADDRCONF(NETDEV_UP): veth3253bd4: link is not ready
br-55349b03453a: port 2(veth3253bd4) entered forwarding state
br-55349b03453a: port 2(veth3253bd4) entered forwarding state
br-55349b03453a: port 2(veth3253bd4) entered disabled state
eth0: renamed from veth9c8aaa3
IPv6: ADDRCONF(NETDEV_CHANGE): veth3253bd4: link becomes ready
br-55349b03453a: port 2(veth3253bd4) entered forwarding state
br-55349b03453a: port 2(veth3253bd4) entered forwarding state
br-55349b03453a: port 2(veth3253bd4) entered disabled state
veth9c8aaa3: renamed from eth0
br-55349b03453a: port 2(veth3253bd4) entered disabled state
device veth3253bd4 left promiscuous mode
br-55349b03453a: port 2(veth3253bd4) entered disabled state
br-55349b03453a: port 1(veth7a1bcde) entered forwarding state
br-55349b03453a: port 1(veth7a1bcde) entered disabled state
veth5d8a2ea: renamed from eth0
br-55349b03453a: port 1(veth7a1bcde) entered disabled state
device veth7a1bcde left promiscuous mode
br-55349b03453a: port 1(veth7a1bcde) entered disabled state
I don't really understand how to read these logs.
Here is my ifconfig also.
Can someone help me read the logs and figure out what the problem is?
Diagnosis
Our team is using AWS EC2 instances running Ubuntu 18.04 as devservers. We recently got reports that docker-compose broke SSH connections. Even after restarting, the devservers are still inaccessible. So I started investigation.
I was able to exclude the cause of docker-compose by reproducing using docker only.
ubuntu#ip-172-31-115-116:~$ docker network create -d bridge my-bridge-network
aca5884d60f146cef81ac55c8cccd231a43f40927d645168642d9b28c5e009a6
ubuntu#ip-172-31-115-116:~$ docker network prune
WARNING! This will remove all custom networks not used by at least one container.
Are you sure you want to continue? [y/N] y
Deleted Networks:
my-bridge-network
ubuntu#ip-172-31-115-116:~$ docker network create -d bridge my-bridge-network
f0a7a06a9627bc2de00eb60091a92010451690626d95e077f622f3058cc3a07c
ubuntu#ip-172-31-115-116:~$ docker network prune
WARNING! This will remove all custom networks not used by at least one container.
Are you sure you want to continue? [y/N] y
Deleted Networks:
my-bridge-network
ubuntu#ip-172-31-115-116:~$ docker network create -d bridge my-bridge-network
Connection reset by 172.31.115.116 port 22
Then the root cause occurred to me.
Root cause
Our docker-compose files are using the bridge network mode which will create a new bridge network by default. When docker-compose down or docker network prune is run, the bridge network will be torn down. And the next docker-compose run or docker network create will create a new bridge network.
The default IP range for the docker0 bridge adapter is 172.17.0.0/16.
When I first ran the docker network create -d bridge my-bridge-network command, it created a new bridge adapter for 172.18.0.0/16.
The second bridge adapter was created for 172.19.0.0/16.
Naturally, the 3rd bridge adapter is created for 172.20.0.0/16. However, that is our Engineering VPN IP range. Therefore the overlap caused the server unable to communicate with our laptop.
Solutions
The solution is to make sure new docker bridge networks will skip our VPN IP range.
Temp solution
If we add the skipped IP ranges to system route table, docker will automatically skip them. Therefore, we can run the below script whenever the devserver got rebooted.
sudo route add -net [our VPN IP range] netmask 255.255.0.0 gw [our gateway]
This solution is imperfect that the new routes will be discarded after restarting the machine.
Main solution
We should permanently apply the route changes to all devservers.
echo " routes:" | sudo tee -a /etc/netplan/50-cloud-init.yaml
echo " - to: [our VPN IP range]" | sudo tee -a /etc/netplan/50-cloud-init.yaml
echo " via: [our gateway]" | sudo tee -a /etc/netplan/50-cloud-init.yaml
sudo netplan apply
Docker IP changes
We also plan to modify the docker default-address-pools to redefine docker IP ranges. Refer to https://github.com/docker/compose/issues/4336#issuecomment-457326123. I would say modifying /etc/docker/daemon.json is better.
br-xxxxxxx are the bridge interfaces of Docker and vethxxxxxxx are the virtual interfaces of your containers, Docker use those veth interfaces but you do not directly interact on it, they use an IPv6 address and don't have IPv4. Docker can't create NAT interfaces, it can only create bridge and veth with IPv6 for containers. You can link your bridge to any physical or virtual interface of your host.
So it work like that:
eth0 (your interface or v-interface if you want) ↔ brxxxxx(docker bridge) ↔ vethxxxxx (v-interface of your container)
It's all I can say, I'm not sure that someone else will answer, there is not a lot of Docker experts, so I give you all informations I can to help you to understand your logs.
I finally ended up running a docker network ls. The output was a list of more than 15 networks which were very old. I ran a docker ps to make sure that nothing related to these networks was still running. One container was indeed still running (redis) and it was on a network called bridge. I stopped the container. Then I started going through all the networks with docker network rm <network name> until I was left with 4 networks: bridge, host, none, and the only network that was still working. Then I could start new networks with docker-compose up again as usual
I had the same issue, I solved it by setting the network_mode option on docker compose (see the docs here. The solution came from this thread ).
services:
my_service:
image: ...
network_mode: "host"

Wireless mesh networking on Raspberry Pi using batman-adv protocol

So I'm trying to setup a wireless mesh network using Raspberry Pi's, with the Edimax EW-7811Un WLAN Adapter and the batman-adv protocol.
I've tried following the basic setup guides from:
http://www.open-mesh.org/projects/batman-adv/wiki/Quick-start-guide
http://mindofdes.blogspot.co.uk/2013/02/raspberry-pi-raspbian-wireless-and.html
Unfortunately, when I get to the point where I need to ping one node from the other, I get
Destination Host Unreachable.
Running the batctl o command displays
'no batman nodes in range'
However, when running iwconfig, both nodes appear to be associated with the network I've setup, and when running iwlist wlan0 scan, the network I've setup appear as cells on both nodes.
I'm now at a loss as to how to proceed. I have read some articles on issues with ad-hoc support for Linux WLAN adapter drivers. My adapter is using the RTL8192CU driver. Could this be the cause of the issue?
P.S. I have looked at the following post, but this was no help, unfortunately.
Edit: contents of /etc/network/interfaces:
Both currently setup nodes have the same contents:
auto lo
iface lo inet loopback
iface eth0 inet dhcp
allow-hotplug wlan0
iface wlan0 inet manual
wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
iface default inet dhcp
Edit: contents of /etc/wpa_supplicant/wpa_supplicant.conf for both nodes:
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
Edit: ifconfig, iwconfig, and route for both nodes:
Node 1
ifconfig
wlan0 Link encap: Ethernet HWaddr 80:1f:02:9b:bc:6c
inet addr:192.168.2.1 Bcast:192.168.2.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:1 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes: 0 (0.0 B)
iwconfig
wlan0 IEEE 802.11bg ESSID:"pi-ad-hoc" Nickname:"<WIFI#REALTEK>"
Mode:Ad-Hoc Frequency:2.412 GHz Cell: 02:11:87:A1:CD:FF
Bit Rate:54 Mb/s Sensitivity:0/0
Retry:off RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=2/100 Signal level=2/100 Noise level=0/100
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.2.0 * 255.255.255.0 U 0 0 0 wlan0
Node 2
ifconfig
wlan0 Link encap:Ethernet HWaddr 80:1f:02:da:2e:ee
inet addr:192.168.2.3 Bcast:192.168.2.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
iwconfig
wlan0 IEEE 802.11bg ESSID:"pi-ad-hoc" Nickname:"<WIFI#REALTEK>"
Mode:Ad-Hoc Frequency:2.412 GHz Cell: 02:11:87:2F:D6:FF
Bit Rate:54 Mb/s Sensitivity:0/0
Retry:off RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=2/100 Signal level=2/100 Noise level=0/100
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.2.0 * 255.255.255.0 U 0 0 0 wlan0
I can confirm, that this is an issue of the latest rtl8192cu driver.
I was using an older version of that driver for edimax wlan adapters with batman working (almost) fine. But I found, that under certain circumstances (with heavy load), the connection failed.
Then I upgraded to the latest version of that driver (date: September 11th 2013) but found that batman wasn't working any longer (in the exact same configuration as with the older driver). The symptoms were exactly as you described in your post.
Edit: My post was deleted, saying that I don't give an answer to the question. I disagree with that: this IS an answer to the original post. The only question in the original post was this:
"My adapter is using the RTL8192CU driver. Could this be the cause of the issue?"
Again: I can confirm that using this (latest) driver causes the issue. This driver is incompatible with batman. The issue has nothing to do with the configuration file. Try to look for an older driver or -better - use a wlan adapter with a different chipset.
You try to setup an adhoc network. However I suggest to start with a simpler approach -- Wifi Access Point and then switch over to adhoc network.
From my point of view it is easier to connect the raspi to a wireless accesspoint. Because the accesspoint will hand over the IP adresses through DHCP. Where in adhoc mode you have to care about the IPs yourself (as far as I know).
Therefore the config for the accespoint based solution would be like
/etc/network/interfaces
auto lo
iface lo inet loopback
iface eth0 inet dhcp
allow-hotplug wlan0
iface wlan0 inet manual
wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
iface default inet dhcp
(which is by the way pretty much like yours already)
and then the /etc/wpa_supplicant/wpa_supplicant.conf which connects to a WPA2 accesspoint
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
network={
ssid="KBBL"
psk=af2a9daa6cadd3434ad96db48173a04acddb04e6a8c5adf52ae78ef13XXXX
key_mgmt=WPA-PSK
scan_ssid=1
proto=RSN
pairwise=CCMP
group=CCMP
}
Please note that the psk key needs to be generated by
$wpa_passphrase "KBBL" "YOUR_KEY"
which results in something like
network={
ssid="KBBL"
#psk="YOUR_KEY"
psk=29af596e046ad450eeddd6752432d5dbd26575960b9024e5cbb99e945cdafa4e
}
just copy and paste the psk
Then reboot! I sometimes have trouble when just changing the network wifi settings on the fly. While after reboot everything is fine. Also the wifi network takes some time. At my place something between 20-40secs.
Btw. I also had trouble when trying to setup wifi without encryption or WEP encryption so I suggest to use WPA2 or WPA. Please also note that the WPA configuration of the wpa_supplicant is much different from this of WPA2. So you might start using the above example for WPA2.
As wifi connections to your access point work fine. We assume drivers and hardware are fine. Now let's try to connect via -- Wifi ad-hoc.
I found here some pretty promising configuration without using wpa_supplicant. As already mentioned we have to use fixed IPs. So of course they need to be different on both raspis. Please note that I had to change "manual" to "static". Now it also works at my place (after reboot). Here it comes
/etc/network/interfaces
auto lo
iface lo inet loopback
iface eth0 inet dhcp
auto wlan0
iface wlan0 inet static
address 192.168.2.10
netmask 255.255.255.0
wireless-channel 4
wireless-essid pi-ad-hoc
wireless-mode ad-hoc
Please note: The chosen IPs should not be in the sub net of your wired network (eth0).
Also make sure sudo ifconfig wlan0 shows the correct IP
pi#raspberrypi ~ $ sudo ifconfig wlan0
wlan0 Link encap:Ethernet HWaddr 80:1f:02:87:77:81
inet addr:192.168.2.10 Bcast:192.168.2.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:53 errors:0 dropped:29 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:6007 (5.8 KiB) TX bytes:1042 (1.0 KiB)
and here is the sudo iwconfig wlan0
pi#raspberrypi ~ $ sudo iwconfig wlan0
wlan0 IEEE 802.11bg ESSID:"pi-ad-hoc" Nickname:"<WIFI#REALTEK>"
Mode:Ad-Hoc Frequency:2.412 GHz Cell: 02:11:87:DF:AB:FF
Bit Rate:54 Mb/s Sensitivity:0/0
Retry:off RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=2/100 Signal level=2/100 Noise level=0/100
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
I just checked your configuration with two Raspberries and the same Wifi Adapters (Edimax EW-7811Un) on Raspbian. Long story short: I get the same results as you do.
My findings are as follows
Setting up one Raspberry for adhoc as described and connecting from IPad or Notebook ... works fine
Creating an adhoc connection on the Notebook and let one Raspberry join ... works fine
Setting up one Raspbery for accesspoint and connecting from IPad or Notebook ... works fine
However when setting up two Raspberries either in adhoc mode or accesspoint mode wont connect to each other ... doesnt work!
As you figured out by this source here the available modes of these adapters (rtl8192cu) are unclear.
Other sources create adhoc connections easily with similar setup and other wifi adpater like described.
It pretty much seems like the adapters drivers won't allow this connection.
Please note: setting up an accesspoint with these adapters requires a special compiled hostapd: read here to find out how
I had problems with the Edimax EW-7811Un in combination with the Raspberry Pi A+
It became unresponsive after a few minutes. Apache and SSH were unreachable and ping did not connect.
The iwconfig program shows: "Power Management:off" but still, it goes into an idle mode.
I found a solution from MrEngman on the raspberry forums: http://www.raspberrypi.org/forums/viewtopic.php?f=28&t=61665
This might solve it:
Make a file 8192cu.conf in directory /etc/modprobe.d/ with the command:
sudo nano /etc/modprobe.d/8192cu.conf
add these lines:
# Disable power management
options 8192cu rtw_power_mgnt=0 rtw_enusbss=0
I dont have anywhere to test at the moment so sorry for the lack of screenshots :(
If you are still interested and have set up several mesh networks using batman-adv and catwoman and faced similar issues (I have done mixed devices like android phones, foneras, openwrt devices, etc, etc to work together).
First thing to check when using batman-adv is the compatibility version, check on your dmesg which one is using each node when you load de batman-adv module, it should match in both or they will not see each other even with both setup propertly! (this has given me quite some headaches in the past hehe)
If the nodes still can't see each other you need to check that you dont have any issues when changing the mode to ad-hoc.
Now, once the nodes see each other remenber that batman-adv works in layer 2, batctl has a ping tool to ping on this layer even when the nodes can't see each other.
Im not really sure why you have wpa-supplicant here, mesh networks doesnt need it, to set up your mesh just chose a channel and an ESSID; all nodes should have this same parameter, then just put the wifi interfaces in ad-hoc mode and on batctl add the interfaces to the bat0 interface.
bat0 interface? thats the actual mesh interface, not wlan0. You did put an ip on the wlan0 interfaces, but that would not work, you need to give bat0 an ip and that the one the mesh will use. By memory the command would be: batctl ifadd wlan0, but check the batctl help just in case :)
If you want to share internet connection you need to follow below steps, then on the node connected to the internet create a bridge between bat0 and the interface with internet (remenber to leave wlan0 or whatever interface is using the mesh alone) and to finish go to batctl on that node and switch the gw (gateway) mode on (batctl gw on, I think). then you can run dhcp over bat0 on all the nodes and it should work just fine.
Just in case, be sure that the batman-adv module is loaded hehe
I think I have covered all sides when it comes to setting up a batman-adv mesh. If you need any doubts I will try to help :D
Best regards and hope your mesh works fine! :)

playing with tcp/ip

I'd like to learn and play with tcp/ip libraries for python, java or c++. But I only have one computer. Is it possible to "fake" remote computers to emulate remote hosts, under NAT end everything?
The simplest way is to run both the server and client on the same computer and use the "loopback" IP address: 127.0.0.1 which always connects to the local host. I've done this many times during testing. For example, run a local webserver on port NNN and then in the browser enter http://127.0.0.1:NNN/ In fact, 127.X.Y.Z should always talk to the local machine.
If you are using linux, you can configure dummy interfaces, then bind your client / server to different dummy interfaces.
[mpenning#Bucksnort ~]$ sudo modprobe dummy
[mpenning#Bucksnort ~]$ sudo ip addr add 192.168.12.12/24 dev dummy0
[mpenning#Bucksnort ~]$ ip addr show dummy0
6: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN
link/ether b6:6c:65:01:fc:ff brd ff:ff:ff:ff:ff:ff
inet 192.168.12.12/24 scope global dummy0
[mpenning#Bucksnort ~]$ ping 192.168.12.12
PING 192.168.12.12 (192.168.12.12) 56(84) bytes of data.
64 bytes from 192.168.12.12: icmp_seq=1 ttl=64 time=0.085 ms
^C
--- 192.168.12.12 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.085/0.085/0.085/0.000 ms
[mpenning#Bucksnort ~]$ sudo modprobe dummy -o dummy1
[mpenning#Bucksnort ~]$ sudo rmmod dummy
[mpenning#Bucksnort ~]$ ip addr show dummy0
Device "dummy0" does not exist.
[mpenning#Bucksnort ~]$
You should be able to run ipchains on these interfaces just like any other.
You can start out with talking between programs on your own computer.
You can use virtual machine software such as VirtualBox, VMWare, VirtualPC, etc to create what is essentially a second machine within yours and talk to that (though the network topology may be very slightly unusual - something more to learn about)
If you want to talk to something remote, you can rent a small cloud server running linux or windows from the likes of Amazon for pennies an hour and install whatever you want on it.
Use virtual box to install OS in your system. for any networking application, this is best. You dont have to work on two different system and its easy to see whats happening at both ends
Run to server to listen on your network adapter, or localhost. Then issue requests to that same IP and Port. Logically, it will all take place within the network driver(s), but it will still behave the same way if that IP address were addressed to another machine (barring Firewall configurations, etc)

Unix: How to execute a command from one server into another server without logging in?

when we logged in one server and if we want to execute a command in some other server without logging into that server?
You can use ssh:
ssh ... [user#]hostname [command]
^^^^^^^^^
still need to use ssh keys. try slogin. slogin is one of the ssh tools, it will log you in, run your command, give you the output (if any), and drop you out back to your local systems shell.
example:
[jhorne#pd-2njg6j1FC17 ~]$ slogin remoteserver01 ifconfig bond0
CentOS release 5.8 (Final)
Kernel 2.6.18-308.8.1.el5 on an x86_64
bond0 Link encap:Ethernet HWaddr F0:4D:A2:01:C2:5A
inet addr:10.88.254.22 Bcast:10.88.254.255 Mask:255.255.255.0
inet6 addr: fe80::f24d:a2ff:fe01:c25a/64 Scope:Link
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:251815947 errors:0 dropped:8807 overruns:0 frame:0
TX packets:284849025 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:118687664470 (110.5 GiB) TX bytes:231265992006 (215.3 GiB)
[jhorne#pd-2njg6j1FC17 ~]$
use slogin -q if you want to avoid the login banner.
Set up a user that the command should be executed as (Please, do not use root!)
Use ssh-keygen -t rsa to create a public-private key pair for that user on the machine from where you want to initiate the command
Copy the public key into ~/.ssh/authorized_keys (append to the file if it already exists)
Run the command as shown by ssmir: `ssh [user#]host command
I've also used this for running automated jobs on other machines that are initiated by a cronjob on the client. For the user I set up very specific accounts that only do the job in question.
You might want to disable password login for that user, too.
It' possible to repeat the procedure for multiple client machines.
One way is to use rsh

Resources