Change wlan0 MAC Address RTL8188CUS Device Raspbian - wifi

I was creating a router with the Raspberry Pi running Raspbian. I have successfully created the router, but I wanted to change the MAC Address on wlan0. I bought the Miniature WiFi Module from ADAFruit (http://www.adafruit.com/products/814) and was wondering if it is possible to change the MAC address associated with it. I have tried using the following code:
sudo ifdown wlan0
sudo ifconfig wlan0 hw ether 00:11:22:33:44:55
sudo ifup wlan0
or
sudo ifdown wlan0
sudo macchanger -r wlan0
sudo ifup wlan0*
or by adding a line in /etc/network/interfaces
hwaddress ether 00:11:22:33:44:55
and various other combinations and attempts.
When using lsusb the device shows up as "Realtek Semiconductor Corp. RTL8188CUS 802.11n WLAN Adapter". In /etc/hostapd/hostapd.conf, driver=rtl1871xdrv. I am running ISC DHCP Server. Raspbian on Raspberry Pi model B.
The device works otherwise. I just want to be able to change the MAC address. I don't know if this is the problem with the device or my settings or something completely different. Anyone have any ideas?

Try
ifconfig wlan0 down #Bring wifi down
macchanger -r wlan0 #Randomly generate new MAC address
ifconfig wlan0 up #Bring wifi back up
ifconfig | grep 'inet addr:'| grep -v '127.0.0.1' | cut -d: -f2 | sort | awk ' {print "Ip: "$1}' #Displays ip address
Use ifconfig to make sure that wlan0 is the adapter. If you put this in a script, you won't need to use sudo; other than to run the script.

Related

Unnecessary Network Commands

I'm running a virtual machine on GCE and Centos 7. I've configured the machine with two network interfaces. When doing so, the user is required to enter the following commands to configure eth1 (every interface except eth0 requires this approach). On my machine, eth1's gateway is 10.140.0.1.
sudo ifconfig eth1 10.140.0.2 netmask 255.255.255.255 broadcast 10.140.0.2 mtu 1430
sudo echo "1 rt1" | sudo tee -a /etc/iproute2/rt_tables # (sudo su - first if permission denied)
sudo ip route add 10.140.0.1 src 10.140.0.2 dev eth1
sudo ip route add default via 10.140.0.1 dev eth1 table rt1
sudo ip rule add from 10.140.0.2/20 table rt1
sudo ip rule add to 10.140.0.2/20 table rt1
I have used the above with success, but the configuration is not persistent. I know it's possible to do so, but I first need to fully understand what the above is actually doing (breaking my problem into smaller parts).
sudo ifconfig eth1 10.140.0.2 netmask 255.255.255.255 broadcast 10.140.0.2 mtu 1430
This command seems to be telling eth1 at 10.140.0.2 to broadcast on the same internal IP. It's also setting MTU to 1430, which is strange because the other interfaces are set to 1460. Is this command really needed?
sudo echo "1 rt1" | sudo tee -a /etc/iproute2/rt_tables # (sudo su - first if permission denied)
From what I read, this command is appending "1 rt1" to the file rt_tables. If this is run once, does it need to be run each time the network comes up? Seems like it only needs to be run once.
sudo ip route add 10.140.0.1 src 10.140.0.2 dev eth1
sudo ip route add default via 10.140.0.1 dev eth1 table rt1
sudo ip rule add from 10.140.0.2/20 table rt1
sudo ip rule add to 10.140.0.2/20 table rt1
I know these commands add non-persistent rules and routes to the network configuration. Once I know the answers to the above, I will come back to the approach of making this persistent.
Referring to your question on Google group thread, as I had mentioned in the post:
IP routes and IP rules needs to be persistent routes to avoid the routes being lost after VM reboot or network services restart. Depending upon the operating system configuration files required to make the routes persistent can be different. Here is a stackexchange thread for CentOS 7, mentioning files: "/etc/sysconfig/network-scripts/route-ethX" and "/etc/sysconfig/network/scripts/rule-ethX" to keep the IP route and rule peristent. Here is the CentOS documentation for the persistent static routes.

Hit a service running on localhost from inside a docker image

I'm on mac os, I have a service running on my machine on localhost:8000
now I want to launch a docker image and hit this service from here.
I did a docker bridge and I use it from inside, but it is not working.
Here are my steps:
My host ip:
ifconfig
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ether 98:01:a7:b0:2b:41
inet 192.168.0.70 netmask 0xffffff00 broadcast 192.168.0.255
media: autoselect
status: active
I hit my service from host:
curl localhost:8000 #this is working!
I create a bridge and I use it:
docker network create -d bridge --subnet 192.168.0.0/24 --gateway 192.168.0.1 dockernet
docker run --rm -it -v "$(pwd):/src" --network=dockernet qatests /bin/bash
from inside docker, I do a curl but it is not working:
curl 192.168.0.1:8000 #it's not working :-(
any ideas?
You dont need to create a new network. You can use the default one (bridge).
Just check which ip is associated to the docker0 interface in your host with ip or ifconfig (in my case is 172.17.42.1), and use that ip from inside the container:
$ curl 172.17.42.1:8000
In the end, I've discovered that if I ping my pc ip, I can see it even from the docker image.
For convenience, I did a lounch script witch get my current IP and launch the docker image making my ip accessible under "mymac" address
So what i did is lunching
MY_IP=$(ifconfig en0 | grep inet | grep -v inet6 | awk '{print $2}')
docker run --rm -it -v "$(pwd):/src" --add-host=mymac:$MY_IP qatests
/bin/bash
inside docker I can now lunch:
curl mymac:8000 #it works! now mymac is my pc outside docker

Wifi connection of a target device not connecting in linux through terminal?

I am trying to up wifi on broadcom BCM4334 chip .
I tried to connect with an open wifi network with following steps
ifconfig wlan0 up
iwconfig wlan0 essid beast_test
udhcpc wlan0
After this I get following error
udhcpc: SIOCGIFINDEX: No such device
I also tried to assign static IP
ifconfig wlan0 192.168.2.125
Then when I ping my router
ping 192.168.2.1
There is no response from it and ping fails.
Can you suggest me what may be the cause and how can I further debug it ?

Testing an iOS app's SSL/TLS certificate validation using a transparent mitmproxy on OSX

As part of a security test of an iOS app I'm developing, I'd like to verify that it correctly validates SSL/TLS certificates when connecting to various APIs. I installed mitmproxy on my Mac and configured it as a transparent proxy, then configured the WiFi based on this transparent proxy iOS WiFi screenshot. The iPhone takes a very long time to show that it's connected to WiFi, and after it does, it can't access the network. Nothing at all shows up in mitmproxy, including in its event log:
Details of the mitmproxy configuration
I installed mitmproxy 0.11.3 in my system python (and renamed the outdated pyOpenSSL that ships with OSX, so that it uses pyOpenSSL 0.14 as installed with mitmproxy by pip).
I'm using the following script to configure and start pf and mitmproxy:
#!/bin/bash -x
sudo sysctl -w net.inet.ip.forwarding=1
# sudo sysctl -w net.inet.ip.scopedroute=0
## OSX can't change the net.inet.ip.scopedroute kernel flag in user space so I used:
## sudo defaults write "/Library/Preferences/SystemConfiguration/com.apple.Boot" "Kernel Flags" "net.inet.ip.scopedroute=0
## and then rebooted
sudo defaults read /Library/Preferences/SystemConfiguration/com.apple.Boot
cat > pf.conf << _EOF_
rdr on en0 inet proto tcp to any port 80 -> 127.0.0.1 port 8080
rdr on en0 inet proto tcp to any port 443 -> 127.0.0.1 port 8080
_EOF_
cat pf.conf
sudo pfctl -d
sudo pfctl -f pf.conf
sudo pfctl -e
mitmproxy -T --host
Interface en0 is my Mac's WiFi connection.
The output from that script (visible after stopping mitmproxy with control-C) looks like this:
$ ./transparent.sh
+ sudo sysctl -w net.inet.ip.forwarding=1
net.inet.ip.forwarding: 1 -> 1
+ sudo defaults read /Library/Preferences/SystemConfiguration/com.apple.Boot
{
"Kernel Flags" = "net.inet.ip.scopedroute=0";
}
+ cat
+ cat pf.conf
rdr on en0 inet proto tcp to any port 80 -> 127.0.0.1 port 8080
rdr on en0 inet proto tcp to any port 443 -> 127.0.0.1 port 8080
+ sudo pfctl -d
No ALTQ support in kernel
ALTQ related functions disabled
pf disabled
+ sudo pfctl -f pf.conf
pfctl: Use of -f option, could result in flushing of rules
present in the main ruleset added by the system at startup.
See /etc/pf.conf for further details.
No ALTQ support in kernel
ALTQ related functions disabled
+ sudo pfctl -e
No ALTQ support in kernel
ALTQ related functions disabled
pf enabled
+ mitmproxy -T --host
Details of the iOS configuration
I'm using a physical iPhone5s on iOS 8.1 and connecting to the same WiFi network as the Mac. My WiFi configuration looks like this:
I've used 192.168.20.118 because that is the IP address of my Mac on the same WiFi network, which I found using ifconfig:
$ ifconfig
[...]
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ether xx:xx:xx:xx:xx:xx
inet6 fe80::22c9:d0ff:fe84:983b%en0 prefixlen 64 scopeid 0x4
inet 192.168.20.118 netmask 0xffffff00 broadcast 192.168.20.255
nd6 options=1<PERFORMNUD>
media: autoselect
status: active
[...]
I got the same problem. In my case, i turn off Mac OS Firewall in Setting panel. It works and i can use mitmproxy as a transparent proxy.
i occur the same problem today .and i solve it only set the dns.and i think the mitmproxy did not provide dns

tshark with rpcap also captures its own interfaces

Platform : Fedora 13, 32-bit machine
I am running tshark in my client and rpcapd in my remote machine.
Here is an example:-
Remote machine :- IP Address 192.168.100.100 (say) and Interface name - eth1 (say)
bash$:- sudo ./rpcapd -n
Client side :- IP Address 192.168.100.200
bash$:- sudo tshark -w output.pcap -i rpcap://192.168.100.100/eth6 -f "ip proto 132"
Packet Capture is running successfully and packets are also being captured.
But it also captures the packets to and from own machine's interfaces which are not related to remote machine's interface.
Please help me out to understand this..
You can exclude traffic to your capture host by adding a filter:
tshark -f '(host not 192.168.100.200) and (ip proto 132)'
The problem occurred due to promiscuous mode.
I tried this :
$sudo tshark -p -w output.pcap -i rpcap://192.168.100.100/eth6 -f "ip proto 132"
and it worked !!
The option -p signifies that the interface will not be put on promiscuous mode.
Here are the details :-
https://www.wireshark.org/docs/man-pages/tshark.html

Resources