I am trying to do a little experiment and I'm getting pretty odd results that I can't explain. I came to my University with my friend, we both brought our laptops and we connected to the same WiFi. But from some reason, our computers couldn't communicate with each other. For example, I couldn't ping him, and I when I did an ARP Scan to find all the hosts on the LAN I didn't find him. He did the same. He couldn't ping me and he didn't find my laptop when he did an ARP scan. Yet, there were many other devices on the LAN that both of us could ping and that we both found in our ARP scan. The University may be big, but we sat just next to each other.
I know that the WiFi on the university may be complex, but yet I have no explanations of what is happening. We sit next to each other, connect to the same WiFi(same Access Point MAC), we both see many same devices in our LAN, yet we can't see each other. Anyone has any idea of what may be happening? Why can't we see/ping each other while we are on the same LAN?
Thanks! :)
The wireless access point probably has a security setting of "Wireless Isolation Within SSID" turned on. This function does exactly what you describe. It allows all authenticated users to see machines on the LAN, but not other wireless machines on the same access point.
Reconfigure your router and make some settings like this
LAN DHCP=Enable
Wireless Authentication type=WPA-PSK/WPA2-PSK
Encryption=AES
After this setting delete all Wireless network of router listed in your PC. And than connect, It will works. you can ping your both PC together.
Because you are connected to an infrastructure mode access point (99% of APs), in order to send packets to another device your laptop sends the packet to the AP (to the distribution system), and then the AP sends the packet to your friend (from the distribution system). You cannot connect 'directly' to your friend.
The AP can direct whether or not wireless clients can see each other - depending on the manufacturer this can be implemented in many different ways. You could talk to your system administrator about why/how this policy works.
Related
WebRTC doesn't work with WIFI connection but works with mobile data.
When launched with a mobile date, an offer and candidates are sent, then when connected, a response and candidates are sent, and everything is connected. But when I give it through wifi, everything goes the same, but the videos do not connect.ICE connection state change: disconnected. What could be the problem?
At the same time, the problem occurs with 2 independent providers in Ukraine. For example, in the USA everything works correctly. Firewall off
ICE failed means there were no candidate pairs discovered via which peers could reach each other.
It could be caused by many different reasons.
Top-1 in my opinion is that you're behind NAT and you're not using turn server that is accessible via ipv4 from public network.
Even if you're not behind NAT it still might be an issue as browsers might restrict ICE candidates discovery. Especially if user hasn't granted access to his mic / camera (it does affects candidates gathering).
You might deploy your own turn server (see coturn), or use a cloud one, for example Xirsys. They also have a free trial.
The other reason might be that the provider is blocking UDP / WebRTC traffic. You can prove it using tcpdump on both sides of connection.
For further reading, here's a great article on how to approach debugging webrtc.
I need to create a wireless network with no Internet access with a Pi, because I need to communicate to it with an Android smartphone and a laptop, but being the RPi the highest step in the network hierarchy.
I've found -and tried- that I can do an adhoc network, but I am unable to connect to it with the smartphone. The other alternative is creating a Wi-Fi hotspot, with no NAT, but I don't really have a deep knowledge on networks so I'm really lost in which IP adresses I have to set.
I've followed this tutorial, and found it really useful. Could anyone tell me what should I modify from it to make it only local -apart from not doing the NAT?
The Rapsberry Pi 3 has built in Wi-Fi that can serve as an access point. Based on my experience, with the Pi acting as an access point, you should be able to connect to any device, be it Android or not.
The Pi will act as access point and serve as a DHCP daemon, assigning and handling IP addresses to any devices that connect to it. This will be a standalone network and will not be able to share an Internet connection unless you bridge it. Follow this tutorial up until the Internet sharing part:
https://www.raspberrypi.org/documentation/configuration/wireless/access-point.md
Also, it would be better to ask this in the Raspberry Pi stack exchange.
Okay, after surfing through the net, I can almost confirm that there is not a single site that tells me whether captive portal hinders the use of a wifi repeater or not. Due to my limited knowledge of how the Wifi protocol works, I can't help but ask several questions that may seem redundant to some. Anyway, here they are:
Assumption:
There is a Wifi with a captive portal that requires users to login on a webpage before connecting to the Internet
Q1:
If I simply extend that Wifi signal with a portable Wifi repeater, will the new extended Wifi signal work? Why or why not?
Q2:
After I pass the captive portal on a desktop, can I set the desktop as an access point to let other devices use the corresponding signal to connect to the Internet? Why or why not? (If yes, will other devices need to login once again?)
Q3:
Only if the answer is affirmative to question 2:
If the captive portal allows 10 hours of continuous connection after a successful log in, can I first connect to that Wifi via a computer and a router which then I close the computer but the router is on (using ap mode and connecting to the Wifi) and let other devices connect to the extended signal and connect to the Internet?
Super thanks to your help.
The answer to Q1 and Q2 is "no" with almost any captive portal software, which authorizes clients based on their IP and/or MAC address.
Reason is that the repeater/range extender/PC needs two interfaces to extend the range of the wifi cell, one interface in STA mode and the other in AP mode. Therefore routing (or bridging) is needed to carry data from clients on the repeater to the router, on which the captive portal runs.
In case of routing, most often NAT is used by the repeater to avoid having static routes on the wifi hotspot. So the captive portal just sees one IP, namely the one of the repeater.
But even if STA/AP interfaces are internally bridged together on the repeater to form one big IP network, the Ethernet frames from the repeater to the wifi hotspot carry only 3 MAC addresses: the source MAC address, the MAC address of the next hop and the destination MAC address. While the repeater sees the MAC address of the client connected to it as its source, it does not forward this MAC to the captive portal, but replaces it with its own MAC address (because when forwarding the repeater itself is the new source).
So the captive portal has no way to recognize any client behind the repeater and if an user logs in through the repeater, he/she actually logs in with the repeater's address (be it IP or MAC address), not with the address of the user's device. Result is that every device connected to the repeater appears as logged into the captive portal as soon as one user has logged in. Also, if one user logs out, all other users behind the repeater are logged out, too.
To overcome this, some routers can be configured to use WDS (wireless distribution system), but although WDS is contained in the 802.11 standard, the latter does not define any implementation requirements. So, several proprietary implementations are in use, which either use some sort of ARP NAT or a 4 address mode to transmit the origin's MAC address as 4th address in an (wireless) Ethernet frame. Since such WDS implementations require a common set up of the repeater and the captive portal by its admin - and in some cases even the same wifi chipsets on both devices -, I won't elaborate on that any further.
This is pure nonsense. An Ethernet packet has two MAC addresses - source and destination. Routers don't forward MAC addresses, only IP addresses. And a router doing NAT will replace the outgoing IP with it's own. Nobody can know how many hops if any are behind the device they are talking to. So there is no way for a captive portal to know if it is talking to a router doing NAT vs a single wireless client.
It's true that a wireless repeater won't work, because it tries to bridge a single IP network, but it should be entirely possible to build a wireless router that NAT routes between a captive portal and another wireless network, as long as it has some way to authenticate to the captive portal.
Is it possible to build a small wifi enabled device that broadcasts an SSID like a router but doesn't connect to the internet? I want to build a personal device that holds 16gb of memory and that when connected to shows a webpage/landingpage but doesn't connect to the internet. Are there any tutorials out there similar to this or any information on where to start?
Of course it is possible. Broadcasting SSID is not only the feature of (wireless) routers but wireless access points in general. Wireless access point can be also a router (like square is also a rectangle, but not every rectangle is square).
You can for example:
- take small computer with wireless card and make it to be access point,
- take any typical wireless router and connect your device, but not connect to the internet (it will work).
There are many options. The best option depends on what you have (device), how much you want to invest and how are your "computer skills" ;-)
I am trying to detect Apple devices connected to a wireless network. This is relatively simple using Bonjour, however I am also trying to detect what kind of device it is. Like, a MacBook Air, a MacBook Pro, a MacPro, an iPhone, iPod, or an iPad.
I have found that Bonjour requests to MacBook's and MacPros include an "ADDITIONAL SECTION" response to the query which includes the model:
;; ADDITIONAL SECTION:
Q9550._device-info._tcp.local. 10 IN TXT "model=MacPro3,1"
and
;; ADDITIONAL SECTION:
Air._device-info._tcp.local. 10 IN TXT "model=MacBookAir4,2"
From testing an iPhone (3GS and 4), an iPod touch, and an iPad2, all of the iDevices only respond with their name:
;; ANSWER SECTION:
111.1.168.192.in-addr.arpa. 10 IN PTR gmPad2.local.
Clearly, the name may not reflect the device. So, I would not like to try to extrapolate the type of device from the name. Does anyone know any other ways to detect iDevice types?
Edit: just to be clear, the command I am using is: dig #224.0.0.251 -p5353 -x 192.168.1.111 ... substituting the IP address of the Apple device
Use port 62078
The most reliable indicator I have seen is whether you can connect to IP port 62078.
Port 62078 is used for the "iphone-sync" service, and I don't think MacBooks use it. This port always appears to be open for the iPhones and iPads on our (very small) network.
Possibly (but not probably) there are messages you can send to the port to sniff out more details...
I think the official xml list of port assignements is here, although it wasn't working for me just now:
http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml
MAC address
In theory the MAC addresses might help - but probably not much use unless you can find somewhere that maintains a reliable list of ranges (e.g. a network security firm, or hardware provider). MAC addresses do depend on the actual chips used (or a flashed MAC). The database is at the organisation level (although organisations sometimes choose to use specific ranges for specific devices).
http://standards.ieee.org/develop/regauth/oui/public.html allows you to download the database of "Organizationally Unique Identifiers", or you can look up "Apple", or the first three bytes of a MAC address e.g. 00264A.
Anecdotally, the MAC lookup doesn't work... First three digits of my iPad MAC are 28-68-BA and that comes up with nothing.
User agent
Probably not useful, but if you can watch the network traffic or have an http proxy, then the user-agent string could help (see http://developer.apple.com/library/IOS/documentation/AppleApplications/Reference/SafariWebContent/OptimizingforSafarioniPhone/OptimizingforSafarioniPhone.html#//apple_ref/doc/uid/TP40006517-SW3).
Edit (added):
Apple’s Bonjour protocol relies on Multicast DNS (mDNS) operating at UDP port 5353 and sends to these reserved group addresses: IPv4 Group Address - 224.0.0.251, IPv6 Group Address - FF02::FB - reference.
This would help get push notification when Apple devices connect to a local network (link-local) by listening for multicast messages on 5353 UDP. Perhaps sniff the packet and see if it has any extra information in it :)
Although I presume that Bonjour API also allows for seeing this...
You can also use the airport utility to do this manually :
1) open AirportUtility
2) Go to "Wireless Clients" (hover mouse by the arrow and click it)
3) Go to DHCP Clients, and you will see iPad,iPhone, computer name, etc.... as the Client ID column.