How to connect openWrt (Virtualbox) to wifi? - wifi

I'm new user of openWRT I using a internet wifi in Ubuntu 16.04, I installed openWRT in VirtualBox, I tried to connect to internet but I failed, when I try to ping google.com I get this message **bad address google.com **

Just went through the same issue this morning. You have a good documentation in OpenWrt wiki for configuring your OpenWrt network when running over VirtualBox. The information below is all taken from the wiki, but I can assure that is working for a Barrier Breaker running on top of Ubuntu 16.04. The process is as follows:
With your VM off, open the VirtualBox Network tab and make the following configurations:
Configure Adapter 1 to use NAT
Configure Adapter 2 to use Bridge Adapter + Select your host machine's interface from the menu (the one that appears by using
commands as iwconfig or ifconfig). + disable promiscuous
mode
These configurations refer to the following screens (my wireless interface has the name wlx0022.., yours may be different):
Power on your VM and edit /etc/config/network. Change the two interfaces that the wiki mentions (wan and lan) and put them as it is shown below. Your interfaces may have different names before the change (in my case, the wan interface was wan6).
Your /etc/config/network file should look like this:
config 'interface' 'wan'
option 'proto' 'dhcp'
option 'ifname' 'eth0'
config 'interface' 'lan'
#option type 'bridge'
option ifname 'eth1'
#option ip6assign '60'
Just do the changes you need to in order to have your /etc/config/network file as it is shown above, but leaving the other interfaces in the file unchanged (as they are).
Then reboot OpenWrt. After that I was able to connect and ping to any site.

First,change your network connection in VirtualBox to Bridge Mode
Settings --> Network --> Adapter 1 --> Attached to --> Bridged Adapter
Second,modify /etc/config/network in OpenWRT
config interface lan
option ifname eth0
option type bridge
option proto dhcp
Restart your network by this command :
/etc/init.d/network restart
Note: make sure your host (Ubuntu 16.04) is connected to DHCP server.Then your OpenWRT-VirtualBox should get the IP address from it.

If you want to connect WiFi manually by editing file,
you need to edit mainly 3 files.
/etc/config/network
/etc/config/wireless
/etc/config/firewall
--> I would suggest adding the following portion in your network config file(/etc/config/network).
(make sure you do not have any assigned section for the wifi in the network config file)
config interface 'wifi'
option proto 'dhcp'
--> Also, you need to update the file (/etc/config/wireless)
config wifi-iface 'station1'
option device 'radio0'
option ifname 'wlan0'
option mode 'sta'
option network 'wifi'
option disabled '0'
option ssid 'name_of_the_wifi'
option key 'password_of_the_wifi'
option encryption 'encryption_of_wifi_generally_psk2'
in above setup option network 'wifi' "wifi" will be the name of the interface you defines in the /etc/config/network.[make sure if you have above section you edit the existing one. Do not add new section if you do not know what you are doing]
Here, replace "wlan0" with your wireless interface.
If you already have above section in wireless file,
you can also use uci commands as following,
uci set wireless.station1.ssid=name_of_wifi
uci set wireless.station1.key=password
uci set wireless.station1.encryption=psk2
uci commit wireless
wifi down; wifi
here, "station1" would be the name of the section.
--> In the /etc/config/firewall, find the option zone section where all the interface is defined, which looks like following
config zone
option name wan
list network 'wan'
list network 'wan6'
option input REJECT
option output ACCEPT
option forward REJECT
option masq 0
option mtu_fix 1
option conntrack 1
and add
list network 'wwan'
Command to check Wifi Connectivity: iwconfig
Refer the following link:
https://wiki.openwrt.org/doc/uci/wireless
NOTE: PLEASE READ FROM OPENWRT FORUM OR GOOGLE BEFORE DOING ANYTHING
The Wrong configuration may break the OpenWRT connection

Related

add dhcp option in openwrt system

I would like to add option 125 to the DHCP server (dnsmasq-2.85) into the OpenWrt OS.
I tried to in the /etc/config/dhcp file the following :
list dhcp_option_force '125,"Smart Hub 3A"'
list dhcp_option_force '125,"+105318+2033000160"'
list dhcp_option_force '125,"0000DB"'
but when getting the traffic of the DHCP server ACK doesn't contain the option 125.
how add this option in the dnsmasq OpenWrt package.

Unable to open port in google compute engine

I'm trying to open the port 29765 port on a VM instance in Google Compute Engine.I created a firewall rule as per below instructions and restarted the VM after creation. But it doesn't work. Can someone help me by providing some advice and if I'm supposed to do anything else ?
It's a Windows platform.
https://cloud.google.com/vpc/docs/using-firewalls
Go to cloud.google.com
Go to my Console
Choose your Project
Choose Networking > VPC network
Choose "Firewalls rules"
Choose "Create Firewall Rule"
Target: All instances of network Source : 0.0.0.0/0
To allow incoming TCP connections to port 29765, in "Protocols and Ports" entered tcp:29765
Click Create

What is the correct way to do Port Forwarding using VMWare

I have created a VM which has a server running at localhost:8675/ which I had wanted to connect to my host machine at the same port for ease of understanding. I was following these to documents for information:
https://www.virtualbox.org/manual/ch06.html
http://www.howtogeek.com/122641/how-to-forward-ports-to-a-virtual-machine-and-use-it-as-a-server/
When I was in my VMWare Workstation, I clicked on my VM, then did: Edit > Virtual Network Editor. After that, enabled Change Settings which relaunched the window in admin mode. I clicked on the Row with Type NAT and external Connection NAT and in the VMNet Information with the NAT radio button pressed, I clicked the NAT Settings Button.
I said: Add... and then did:
Host: 8675
Type: TCP
VMIP: 127.0.0.1:8675
Description: Port Foward of 8675 from Host to VM.
It looks like everything is good. I say Ok and Apply in succession. It looked like it shut down nat and restarted some services.
I confirmed in the VM, the 127.0.0.1:8675 is correct.
In the HOST, I tried to go to: http://localhost:8675/ and it says: ERR_CONNECTION_REFUSED
I figured this was all I needed to do.
I was looking up some additional information and noticed that some people have had to configure firewalls. I wasnt sure if i needed to though, as I was thinking that the HOST and VM are all in 1 actual machine, it might be entirely self contained.
Is there a critical task I am missing?
I saw this post: https://superuser.com/questions/571196/port-forwarding-to-a-vmware-workstation-virtual-machine
which told me to just adjust it to bridged and use it that way. Does this solve the issue of connecting HOST / VM Issue.
I don't want to say this is the correct answer though as the question itself is particular to NAT, but this is a valid alternative answer that does work.
This is solves the base issue at hand, but not the question.
When you use NAT, the host system and the guest boxes have completely different IP addresses on their virtual subnet, so my guess is that when from the host system you try to connect to localhost:8675 you are actually trying to connect to port 8675 of the host and not of the guest. So don't use the localhost or 127.0.0.1 syntax, but discover the real IP address of the guest and use it.
If your guest is Windows use the ipconfig command, if Linux use ifconfig.
Probably you will also have to configure the firewall on the guest side.
EDIT:
Commenting the sentence "NAT: Used to share the host's IP address.": it probably refers to the IP address of the real ethernet adapter you have on your host and that is shared by host and guests to access the internet. That's not related to the way your host and guests communicate together. For example I use VMware Workstation to run a virtual Linux box in Windows. Selecting NAT, VMware creates a virtual subnet called VMnet8. In this subnet the virtual router has address 192.168.120.0, my Windows host is assigned a virtual ethernet adapter with address 192.168.120.1 and my Linux guest has got address 192.168.120.128. So when I want to access a Samba shared folder from Windows I type "net use * \192.168.120.128" in a Windows command prompt. When I want to access a Windows shared folder from Linux I type "sudo mount.cifs //192.168.120.1/path_to_shared_folder target_folder".
I believe you actually answered your question correctly as I was following it and achieved desired outcome.
IMHO, the error: ERR_CONNECTION_REFUSED indicates that a firewall on your host OS or guest OS (your VM) or on both doesn't allow the communication through the given ports.
The easiest thing would be to try to disable firewalls on boths, your HOST and GUEST OS.
Not sure what are your OSes, but here is just a good guide for setting up firewall rules on Ubuntu

" netsh wlan start hostednetwork " command not working no matter what I try

C:\Windows\system32>netsh wlan show drivers
Interface name: Wireless Network Connection
Driver : DW1501 Wireless-N WLAN Half-Mini Card
Vendor : Broadcom
Provider : Broadcom
Date : 21/01/2010
Version : 5.60.48.35
INF file : C:\Windows\INF\oem26.inf
Files : 5 total
C:\Windows\system32\DRIVERS\BCMWL6.SYS
C:\Windows\system32\bcmihvsrv.dll
C:\Windows\system32\bcmihvui.dll
C:\Windows\system32\drivers\vwifibus.sys
C:\Windows\system32\bcmwlcoi.dll
Type : Native Wi-Fi Driver
Radio types supported : 802.11n 802.11g 802.11b
FIPS 140-2 mode supported : Yes
Hosted network supported : Yes
Authentication and cipher supported in infrastructure mode:
Open None
Open WEP
Shared None
Shared WEP
WPA2-Enterprise TKIP
WPA2-Personal TKIP
WPA2-Enterprise CCMP
WPA2-Personal CCMP
WPA2-Enterprise Vendor defined
WPA2-Enterprise Vendor defined
Vendor defined Vendor defined
Vendor defined Vendor defined
Vendor defined TKIP
Vendor defined CCMP
WPA-Enterprise TKIP
WPA-Personal TKIP
WPA-Enterprise CCMP
WPA-Personal CCMP
Authentication and cipher supported in ad-hoc mode:
WPA2-Personal CCMP
Open None
Open WEP
IHV service present : Yes
IHV adapter OUI : [00 10 18], type: [00]
IHV extensibility DLL path: C:\Windows\System32\bcmihvsrv.dll
IHV UI extensibility ClSID: {aaa6dee9-31b9-4f18-ab39-82ef9b06eb73}
IHV diagnostics CLSID : {00000000-0000-0000-0000-000000000000}
I disabled and re-enabled it many times. Still no clue whats goin wrong I always get the error saying
"C:\Windows\system32>netsh wlan start hostednetwork
The hosted network couldn't be started.
A device attached to the system is not functioning."
The commands before that are running perfectly. The virtual adapter and everything is also enabled.
netsh wlan show hostednetwork
C:\Windows\system32> netsh wlan show hostednetwork
Hosted network settings
Mode : Allowed
SSID name : "Lathiyas"
Max number of clients : 100
Authentication : WPA2-Personal
Cipher : CCMP
Hosted network status
Status : Not started
Then tried stopping the hostednetwork and tried again still the same error. I think there is some problem with the drivers. Dell N5010 Windows 7-32bit system. Please help.
First of all go to the device manager now go to View>>select Show hidden devices....Then go to network adapters and find out Microsoft Hosted network Virual Adapter ....Press right click and enable the option....
Then go to command prompt with administrative privileges and enter the following commands:
netsh wlan set hostednetwork mode=allow
netsh wlan start hostednetwork
Your Hostednetwork will work without any problems.
At first simply uninstall wifi drivers and softwares
just keep wifi drivers
+
from device manager....network adapters...remove all virtual connections
then
Press the Windows + R key combination to bring up a run box, type ncpa.cpl and hit enter.
netsh wlan set hostednetwork mode=allow ssid=”How-To Geek” key=”Pa$$w0rd”
netsh wlan start hostednetwork
netsh wlan show hostednetwork
its working for me and on others PC.
Same issue.
I solved the problem first activating (right click mouse and select activate) from control panel (network connections) and later changing to set mode to allow (by netsh command), to finally starting the hostednetwork with other netsh command, that is:
1.- Activate (Network Connections) by right click
2.- netsh wlan set hostednetwork mode=allow
3.- netsh wlan start hosted network
Good luck mate !!!
If none of the above solution worked for you, locate the Wifi adapter from "Control Panel\Network and Internet\Network Connections", right click on it, and select "Diagnose", then follow the given instructions on the screen. It worked for me.
netsh wlan set hostednetwork mode=allow ssid=dhiraj key=7870049877
If you have a wifi button or switch on your laptop make sure it is turned on! Then use the netsh commands that other people have stated
This was a real issue for me, and quite a sneaky problem to try and remedy...
The problem I had was that a module that was installed on my WiFi adapter was conflicting with the Microsoft Virtual Adapter (or whatever it's actually called).
To fix it:
Hold the Windows Key + Push R
Type: ncpa.cpl in to the box, and hit OK.
Identify the network adapter you want to use for the hostednetwork, right-click it, and select Properties.
You'll see a big box in the middle of the properties window, under the heading The connection uses the following items:. Look down the list for anything that seems out of the ordinary, and uncheck it. Hit OK.
Try running the netsh wlan start hostednetwork command again.
Repeat steps 4 and 5 as necessary.
In my case my adapter was running a module called SoftEther Lightweight Network Protocol, which I believe is used to help connect to VPN Gate VPN servers via the SoftEther software.
If literally nothing else works, then I'd suspect something similar to the problem I encountered, namely that a module on your network adapter is interfering with the hostednetwork aspect of your driver.

CUPS #LOCAL value

I got two machines. One with CUPS 1.5.0 and the other with CUPS 1.6.1. The two machines are on the same local network. I want a full discovery of the printers on the network. If i run the following command:
CUPS_DEBUG_LEVEL=2 /usr/lib/cups/backend/snmp 2>&1
on both machines i get different results. The one with CUPS 1.5.0 is the result i want from the other machine with CUPS 1.6.1 too.
I figured out the problem! There is a variable called #LOCAL in CUPS. The upper command equals with:
CUPS_DEBUG_LEVEL=2 /usr/lib/cups/backend/snmp #LOCAL 2>&1
The problem is that in the second case (CUPS 1.6.1) the value of the #LOCAL is the local IP(192.168.3.69) of the machine instead of the broadcast(192.168.3.255).
If i run the following command on machine two all works perfectly:
CUPS_DEBUG_LEVEL=2 /usr/lib/cups/backend/snmp 192.168.3.255 2>&1
Please explain me how can i configure the value of the #LOCAL variable. Or why does CUPS 1.5.0 configure it well on install and 1.6.1 don't? (I did not do anything after installing, and it worked perfectly)
First...
...let's get clear what #LOCAL means:
The #LOCAL string is not exactly a variable -- in the context of CUPS configuration (/etc/cups/cupsd.conf) it's called a macro. There are more macros that could be used: #IF, #GROUP, #ACL, #OWNER and #SYSTEM.
The #LOCAL macro was introduced into CUPS with version 1.1.15. The respective CHANGELOG entry reads:
- The Allow, Deny, BrowseAllow, BrowseDeny, and
BrowseAddress directives now support the network
interface names "#LOCAL" and "#IF(name)" for access
control and browsing based on the current interface
addresses instead of fixed names or IP addresses.
In other words: before its introduction into the CUPS code base, you had to hard-code the current IP addresses of the host into cupsd.conf. Afterwards, you had the option to just instead write #LOCAL or #IF(eth0) or #IF(wlan1) in cupsd.conf and CUPS would use the current IP address (all the local IP addresses, if the box has multiple!) even if it changed. (Addresses for PPP/dialup connections don't count as local IP addresses...)
Second...
...let's see why you may see differences:
Without access to your full CUPS and network device configuration of both of your two machines it is not possible to answer the question.
It may be the case that one server has more network interfaces and/or more different IP addresses than the other (like using the eth0:1 trick to use an additional virtual network interface).
You may also have stumbled over a bug in one of the two CUPS incarnations of you machines.

Resources