Raspberry PI Zero with USB/Ethernet dongle - networking

I have looked and looked and looked, I can't find an answer to this problem anywhere!
I want to connect my PI zero to an ethernet cable. I have a USB/Ethernet dongle. I have 3 zero's, all have USB-HUB hats. I plug in the dongle and reboot (which is what every video I've found says is all you have to do). When it comes back up, the ethernet port is recognized, but won't get an IP address.
Here's what ifconfig says:
eth0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether 00:0e:c6:78:62:89 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)
The only hint I can find suggests I need to add this to the interfaces file:
auto eth0
allow-hotplug eth0
iface eth0 inet DHCP
But this changes nothing. It seems that the DHCP client is not running (although it works for the WiFi). But when I google 'DHCP setup raspberry pi zero' all I get it how to setup a server.

VERY Embarrassing!
The ethernet cable was not plugged in 🤦🏻‍♂️

Related

Wifi has IP by DHCP but no internet access

I have installed a new USB Wifi network card in Debian 9.
After configuring it, the router assigns me an IP via DHCP but I don't have internet access.
It is the Alpha Network AWUS036NH (Ralink RT3070 Chipset) Wifi network card.
It is on a Debian 9 without a graphical environment.
I have installed the firmware-ralink package and it is using the rt2800usb driver.
I have tried the next commands:
iwconfig
eth1 no wireless extensions.
eth0 no wireless extensions.
wlan0 IEEE 802.11 ESSID:"CAMIONES"
Mode:Managed Frequency:2.437 GHz Access Point: 74:AC:B9:21:3C:E5
Bit Rate=1 Mb/s Tx-Power=20 dBm
Retry short limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=70/70 Signal level=-37 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:1 Invalid misc:4 Missed beacon:0
lo no wireless extensions.
ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.80.4.2 netmask 255.255.255.0 broadcast 10.80.4.255
ether 4c:02:89:12:c0:be txqueuelen 1000 (Ethernet)
RX packets 5002 bytes 631414 (616.6 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 5510 bytes 882802 (862.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device memory 0xd0600000-d06fffff
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
loop txqueuelen 1 (Local Loopback)
RX packets 6146 bytes 509679 (497.7 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 6146 bytes 509679 (497.7 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.200.18 netmask 255.255.255.0 broadcast 192.168.200.255
ether 00:c0:ca:5a:00:60 txqueuelen 1000 (Ethernet)
RX packets 8 bytes 1170 (1.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 58 bytes 7704 (7.5 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.80.4.1 0.0.0.0 UG 0 0 0 eth0
10.80.4.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0
192.168.200.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
traceroute -i wlan0 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 *^C
I have tried to add a static route so that when I use wlan0 it will find its gateway:
route add default gw 192.168.200.1 dev wlan0
The rule is added but it does not work and I also lose internet access through eth0
ping -c2 -I wlan0 www.google.fr
PING www.google.fr (216.58.209.67) from 192.168.200.18 wlan0: 56(84) bytes of data.
--- www.google.fr ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1032ms
Contents of the configuration files:
/etc/resolv.conf
nameserver 80.58.61.250
nameserver 8.8.8.8
nameserver 80.58.61.254
/etc/network/interfaces.d/wlan0
allow-hotplug wlan0
iface wlan0 inet dhcp
wpa-ssid CAMIONES
wpa-psk pass
gateway 192.168.200.1
dns-nameservers 192.168.200.1
/etc/wpa_supplicant/wpa_supplicant.conf
network={
ssid="CAMIONES"
psk="pass"
}
I have tried connecting to another router and have the same problem.
What problem can I have with the configuration?
Thank you very much.
Your default route is set to go out via eth0 so all traffic will leave the eth0 interface, unless you have a specific(non default) route set to go out via wlan0.
Try this and see if you get a response:
route add -net 8.8.8.0 netmask 255.255.255.0 gw 192.168.200.1 dev wlan0
ping 8.8.8.8

Taskmanager fails to connect to Jobmanager [Could not find any IPv4 address that is not loopback or link-local. Using localhost address.]

We were previously using RHEL for our Flink machines. I'm currently working on moving them over to Ubuntu. When I start the task manager, it fails to connect to the job manager with the following message -
2020-01-16 10:54:42,777 INFO org.apache.flink.runtime.util.LeaderRetrievalUtils - Trying to select the network interface and address to use by connecting to the leading JobManager.
2020-01-16 10:54:42,778 INFO org.apache.flink.runtime.util.LeaderRetrievalUtils - TaskManager will try to connect for 10000 milliseconds before falling back to heuristics
2020-01-16 10:54:52,780 WARN org.apache.flink.runtime.net.ConnectionUtils - Could not find any IPv4 address that is not loopback or link-local. Using localhost address.
The network interface on the machine looks like this -
ens5: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9001
inet 10.16.75.30 netmask 255.255.255.128 broadcast 10.16.75.127
ether 02:f1:8b:34:75:51 txqueuelen 1000 (Ethernet)
RX packets 69370 bytes 80369110 (80.3 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 28787 bytes 2898540 (2.8 MB)
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
loop txqueuelen 1000 (Local Loopback)
RX packets 9562 bytes 1596138 (1.5 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 9562 bytes 1596138 (1.5 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Note: On RHEL, the primary network interface was eth0. Could this be the issue?
Here's the full task manager log - https://paste.ubuntu.com/p/vgh96FHzRq/
The problem was with the parameter high-availability.cluster-id. It was different on the task manager and the job manager. Updating it solved the issue.

Cannot Ping Devices Across Interfaces for Shorewall Single IP Three-interface Firewall on Debian Wheezy [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 years ago.
Improve this question
Summary
I am currently working on a three interface software firewall using Shorewall 4.5.5.3 on Debian Wheezy, and I'm having some difficulty with the loc (eth2) and dmz (eth1) interfaces. The fw (eth0) interface seems to be working just fine, but I cannot ping PCs on loc or dmz zones. There is likely something wrong with my /etc/network/interfaces setup in the network.
The fw interface runs on dhcp through my ISP, and I configured the loc and dmz interfaces and PCs inside those zones with static IPs. The configuration that I'm trying to use is the three-interface and single IP configuration. The reference document is located on the Shorewall website, "Three-Interface Firewall". I don't know what to do about a gateway on eth1 or eth2 interfaces, b/c the Shorewall docs don't explain that. I assume it would be the same gateway as eth0, but I don't know how to do that since eth0 is on dhcp.
Networking
/etc/network/interfaces for firmware node:
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet dhcp
# Secondary network interface for dmz
auto eth1
iface eth1 inet static
address 10.10.1.1/24
netmask 255.255.255.0
# Tirtirary network interface for loc
auto eth2
iface eth2 inet static
address 10.10.2.1/24
netmask 255.255.255.0
/etc/network/interfaces for dmz
# dmz network interface
auto eth0
iface eth0 inet static
address 10.10.1.2/24
netmask 255.255.255.0
gateway 10.10.1.1
Starting with just the dmz, is there something wrong with my network interfaces setup?
This is what happens when i restart my networking:
Listening on LPF/eth0/HEX:...:...
Sending on LPF/eth0/HEX:...:...
Sending on Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 6
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPOFFER from XY.IP...
DHCPACK from XY.IP...
suspect value in ^1/7078C526/res-5000-2.0 option - discarded
suspect value in ^1/FBEA1017/res-5000-2.0 option - discarded
bound to NEW.IP... -- renewal in 33594 seconds.
done.
I don't understand the "suspect .... - discarded" lines. Does this indicate a problem, or are those potential IPs that are being rejected?
These are the results of ifconfig:
eth0 Link encap:Ethernet HWaddr MAC
inet addr:DHCP.IP Bcast:DHCP.BC Mask:DHCP.M
inet6 addr: inet6.IP Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:268607 errors:0 dropped:0 overruns:0 frame:0
TX packets:89830 errors:0 dropped:0 overruns:0 carrier:7
collisions:0 txqueuelen:1000
RX bytes:25066229 (23.9 MiB) TX bytes:10734393 (10.2 MiB)
Interrupt:17
eth1 Link encap:Ethernet HWaddr c0:4a:00:03:00:04
inet addr:10.10.1.1 Bcast:10.10.1.255 Mask:255.255.255.0
inet6 addr: fe80::c24a:ff:fe03:4/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:82 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:4664 (4.5 KiB)
Interrupt:19 Base address:0xac00
eth2 Link encap:Ethernet HWaddr c0:4a:00:07:6a:31
inet addr:10.10.2.1 Bcast:10.10.2.255 Mask:255.255.255.0
inet6 addr: fe80::c24a:ff:fe07:6a31/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:48 errors:0 dropped:0 overruns:0 frame:0
TX packets:33 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2880 (2.8 KiB) TX bytes:2578 (2.5 KiB)
Interrupt:16 Base address:0xe800
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:41 errors:0 dropped:0 overruns:0 frame:0
TX packets:41 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:4592 (4.4 KiB) TX bytes:4592 (4.4 KiB)
Shorewall settings
interfaces
net eth0 tcpflags,dhcp,nosmurfs,routefilter,logmartians,sourceroute=0
dmz eth1 tcpflags,nosmurfs,routefilter,logmartians
loc eth2 tcpflags,nosmurfs,routefilter,logmartians
masq
eth0 10.10.1.0/24
eth0 10.10.2.0/24
params
ETH0_IP=$(find_first_interface_address eth0)
policy
loc net ACCEPT
net all DROP info
# THE FOLLOWING POLICY MUST BE LAST
all all REJECT info
routestopped
eth1 -
eth2 -
rules
SECTION NEW
# Don't allow connection pickup from the net
Invalid(DROP) net all
# Accept DNS connections from the firewall to the Internet
DNS(ACCEPT) $FW net
# Accept SSH connections from the local network to the firewall and DMZ
SSH(ACCEPT) loc $FW
SSH(ACCEPT) loc dmz
# DMZ DNS access to the Internet
DNS(ACCEPT) dmz net
# Drop Ping from the "bad" net zone.
Ping(DROP) net $FW
# Make ping work bi-directionally between the dmz, net, Firewall and local zone
# (assumes that the loc-> net policy is ACCEPT).
Ping(ACCEPT) loc $FW
Ping(ACCEPT) dmz $FW
Ping(ACCEPT) loc dmz
Ping(ACCEPT) dmz loc
Ping(ACCEPT) dmz net
Ping(ACCEPT) loc net
ACCEPT $FW net icmp
ACCEPT $FW loc icmp
ACCEPT $FW dmz icmp
# Allow connection to web server from loc to dmz
DNAT loc dmz:10.10.1.2 tcp - 80,443 $ETH0_IP
# Allow DNS connection to internal server from net
DNS(ACCEPT) loc dmz:10.10.1.3
DNS(ACCEPT) $FW dmz:10.10.1.3
DNS(ACCEPT) loc dmz:10.10.1.4
DNS(ACCEPT) $FW dmz:10.10.1.4
# Allow SMTPS traffic to internal server from net
SMTPS(ACCEPT) dmz:10.10.1.2 $FW
POP3S(ACCEPT) $FW dmz:10.10.1.2
# Allow SSH and SFTP on web server
SSH(ACCEPT) $FW dmz:10.10.1.2
SSH(ACCEPT) net $FW
shorewall.conf
# Only change in this file:
IP_FORWARDING=On
zones
fw firewall
net ipv4
loc ipv4
dmz ipv4
shorewall check
Checking...
Processing /etc/shorewall/params ...
Processing /etc/shorewall/shorewall.conf...
Loading Modules...
Checking /etc/shorewall/zones...
Checking /etc/shorewall/interfaces...
Determining Hosts in Zones...
Locating Action Files...
Checking /usr/share/shorewall/action.Drop for chain Drop...
Checking /usr/share/shorewall/action.Broadcast for chain Broadcast...
Checking /usr/share/shorewall/action.Invalid for chain Invalid...
Checking /usr/share/shorewall/action.NotSyn for chain NotSyn...
Checking /usr/share/shorewall/action.Reject for chain Reject...
Checking /etc/shorewall/policy...
Adding Anti-smurf Rules
Adding rules for DHCP
Checking TCP Flags filtering...
Checking Kernel Route Filtering...
Checking Martian Logging...
Checking Accept Source Routing...
Checking /etc/shorewall/masq...
Checking MAC Filtration -- Phase 1...
Checking /etc/shorewall/rules...
Checking /usr/share/shorewall/action.Invalid for chain %Invalid...
Checking MAC Filtration -- Phase 2...
Applying Policies...
Checking /etc/shorewall/routestopped...
Shorewall configuration verified
shorewall start
Compiling...
Processing /etc/shorewall/params ...
Processing /etc/shorewall/shorewall.conf...
Loading Modules...
Compiling /etc/shorewall/zones...
Compiling /etc/shorewall/interfaces...
Determining Hosts in Zones...
Locating Action Files...
Compiling /usr/share/shorewall/action.Drop for chain Drop...
Compiling /usr/share/shorewall/action.Broadcast for chain Broadcast...
Compiling /usr/share/shorewall/action.Invalid for chain Invalid...
Compiling /usr/share/shorewall/action.NotSyn for chain NotSyn...
Compiling /usr/share/shorewall/action.Reject for chain Reject...
Compiling /etc/shorewall/policy...
Adding Anti-smurf Rules
Adding rules for DHCP
Compiling TCP Flags filtering...
Compiling Kernel Route Filtering...
Compiling Martian Logging...
Compiling Accept Source Routing...
Compiling /etc/shorewall/masq...
Compiling MAC Filtration -- Phase 1...
Compiling /etc/shorewall/rules...
Compiling /usr/share/shorewall/action.Invalid for chain %Invalid...
Compiling MAC Filtration -- Phase 2...
Applying Policies...
Generating Rule Matrix...
Creating iptables-restore input...
Compiling /etc/shorewall/routestopped...
Shorewall configuration compiled to /var/lib/shorewall/.start
Starting Shorewall....
Initializing...
Setting up Route Filtering...
Setting up Martian Logging...
Setting up Accept Source Routing...
Setting up Traffic Control...
Preparing iptables-restore input...
Running /sbin/iptables-restore...
IPv4 Forwarding Enabled
done.
Ping
in fw terminal: ping 10.10.1.2
PING 10.10.1.2 (10.10.1.2) 56(84) bytes of data.
From 10.10.1.1 icmp_seq=1 Destination Host Unreachable
From 10.10.1.1 icmp_seq=2 Destination Host Unreachable
From 10.10.1.1 icmp_seq=3 Destination Host Unreachable
in dmz terminal: ping 10.10.1.1
connect: network not reachable
I don't know what is missing/wrong. Any help would be appreciated.
Solution
I found an answer to my problem, and it was the network configuration on the dmz. The dmz is on a Dell Power Edge 1950, where I'm running the hardware node on 10.10.1.2/24, and a venet0, virtual node for OpenVZ. I was not concerned about connecting to the OpenVZ nodes just yet, but could not even connect to the hardware node. After modifying the networking information and removing the CIDR addition of /24, everything fell into place. I run CentOS 6.5 on the hardware node, and I guess it doesn't like CIDR addressing.
I am now pinging the dmz from fw, so the gateway is open, happy days:
> ping 10.10.2.1
PING 10.10.2.1 (10.10.2.1) 56(84) bytes of data.
64 bytes from 10.10.2.1: icmp_req=1 ttl=64 time=0.056 ms
64 bytes from 10.10.2.1: icmp_req=2 ttl=64 time=0.027 ms
64 bytes from 10.10.2.1: icmp_req=3 ttl=64 time=0.026 ms
64 bytes from 10.10.2.1: icmp_req=4 ttl=64 time=0.025 ms
Summary
The configuration is solid, so I hope it helps someone else setting up a Shorewall interface.

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! :)

Filtering ethernet packets (ICMP, Bonjour) on a TAP interface on OSX

I'm writing a little tunneling app with layer 2 interfaces (TAP) as endpoints. In the course of testing this on OSX, I noticed I was getting all sorts of traffic I didn't expect on the tunnel, both when the tunnel was running on a single OSX machine, and when I tunneled between OSX and a Linux box. I'd like to filter this traffic out, and I'm wondering what the best way to do this is.
The tunnel looks like this (note both endpoints can be on the same machine):
tap0 -> tunnel app -> UDP tunnel -> tunnel app -> tap1
The notable traffic is Bonjour packets on destination port 5353 and ICMP/IGMP. Multicast is enabled on the TAP interface. I'd like to block this sort of traffic. My thoughts on doing this:
Turn off multicast on the interface (doesn't work on OSX, see below)
Use ebtables
Parse the packets coming off the interface inside the tunnel app and ignore them there
Is there a better/easier way to do this?
I tried turning off multicast on the OSX interface (let's call it tap0) but I get an error.
$ ifconfig tap0 -multicast
ifconfig: -multicast: bad value
EDIT: After a bit more hunting around, it appears UNIX and BSD ifconfig have different options. Is there another way to block multicast/ICMP traffic on a given interface in OSX/BSD?
here's the ifconfig output...
OSX (with osxtuntap):
$ ifconfig tap1
tap1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ether 92:d9:e6:65:5a:8c
inet 10.0.0.2 netmask 0xffffff00 broadcast 10.0.0.255
open (pid 17121)
Linux:
$ ifconfig tunX
tunX Link encap:Ethernet HWaddr 4a:29:02:e6:b0:b9
inet addr:10.0.0.1 Bcast:10.0.0.255 Mask:255.255.255.0
inet6 addr: fe80::4829:2ff:fee6:b0b9/64 Scope:Link
UP BROADCAST RUNNING 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:500
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
One possibility is to use the built-in ipfw firewall in OSX. From the terminal, we could allow only tcp traffic on a virtual network interface called tap1:
sudo ipfw add 9000 allow tcp from any to any via tap1 # allow tcp
sudo ipfw add 9001 deny ip from any to any via tap1 # block all other incoming and outboung traffic
And we can also delete the rules if we don't need them:
sudo ipfw del 9000 9001
Alternatively, it is possible to just parse the ethernet frame and convert it from ascii into hex or decimal, and then decide what to do with it there. You can very easily detect TCP/UDP packets with the below (protocol=6 for tcp, and 17 for udp).
from binascii import hexlify
...
# given some ethernet frame string data
protocol = int(hexlify(frame[23:24]), 16)
src_port = int(hexlify(frame[34:36]), 16)
dst_port = int(hexlify(frame[36:38]), 16)
For arp packets, this won't work- the packet structure is a bit different.

Resources