I have succesfully built the CoAP protocol example for ARM mbed (https://developer.mbed.org/teams/sandbox/code/coap-example/file/0681e205d0e9/) on a K64F board. It comes out of the box, except for the server name (coap.me) changed to an internal IP address.
I see that it runs correctly and connects to the network:
[EasyConnect] Using Ethernet
[EasyConnect] Connected to Network successfully
[EasyConnect] IP address 192.168.1.15
[EasyConnect] MAC address 0e:43:54:d9:7c:71
Connected to the network. Opening a socket...
Calculated message length: 11 bytes
Starting server
Sent 11 bytes to coap://192.168.1.10:5683
I have set a computer that can connect to it. It can ping correctly to the board and I see that the ARP is negotiating with the correct MAC address.
I have launched an NMAP test and I see that the port is closed:
PORT STATE SERVICE
5683/udp closed unknown
If I set a CoAP client in the computer (Copper) I see no connection in the terminal.
What I am missing?
Moving this to the answer section as well, in case someone else runs into this problem.
If you want to use an mbed OS 5 device as a UDP server, make sure to call .bind() on the socket.
Related
I have two virtual machines running on the same host and they are both in the same NAT Network. I started a fake bacnet device on one VM (say VM1) using the utility script volttron/scripts/scalability-testing/virtual-drivers/bacnet.py.
The device started up fine. Now from another VM (say VM2) on the same host and same NAT Network I ran the scan_bacnet.py but my fake device on VM1 is not getting listed.
I verified that the ip address on the BACpypes.ini file has the correct address of the host running the scan_bacnet.py script. I also changed the address in BACpypes.ini to include subnet mask (10.0.2.15/24) still no luck.
Below is the content of my BACpypes.ini on file on VM2
[BACpypes]
objectName: Betelgeuse
address: 10.0.2.15/24
objectIdentifier: 599
maxApduLengthAccepted: 1024
segmentationSupported: segmentedBoth
vendorIdentifier: 15
This is the command I ran in VM1 to start the fake bacnet device
python bacnet.py bacnet_registry.csv 10.0.2.5
I am able to ping from one VM to another and running a tcpdump on the source VM shows that the scan_bacnet.py is sending the whois request to the other VM. Running tcpdump on the destination VM shows that the machine is receiving the whois request yet the fake bacnet device isn't receiving the whois request.
What am I doing wrong?
You need to include the subnet mask in the virtual device command line:
python bacnet.py bacnet_registry.csv 10.0.2.5/24
Also you should check the firewall setting on both VMs. CentOS, for instance, defaults to blocking all incoming traffic. (You will still see it in the output tcpdump.) For BACnet you need to open udp port 47808 for all traffic (broadcast and direct).
I written a C program for sending and receiving a data on the TCP layer. I have created a socket for sending and receiving a data over a specific IP address.
Question : How to identify the free IP address and port number on the laptop ?? So that I can use it for communication.
I am using windows 7 operating system.
what is the name if the port is free (example : close wait, time wait,
established , listening ) ??
LISTENING is ports that other servers are using. The rest are usually ephemeral ports used by clients. – Barmar
I'm developing an TCP/IP stack that will run on another device connected by bluetooth.
But I want to test against an working Stack. My testing scenario would be:
MY DEVICE TCP/IP STACK --------------BLUETOOTH ----------------- WINDOWS/MAC TCP/IP Stack.
Anyone have any idea how could I write IP packets over an Bluetooth connection on Linux/Windows or mac ??
One way is you could establish a ppp connection between the device and the PC over bluetooth first. For this you will need support for ppp on the device side. Once you are able to dial-up and establish a ppp connection, tcp/ip can be run over ppp.
These links may be useful (although they are specific to linux):
http://www.daybefore.net/bluetooth_ppp.html
http://www.rpgameplace.de/blog/index.php?/archives/19-Networking-over-Bluetooth-using-BlueZPPP.html
I am trying to find out mac address of a machine in a switched environment after sending it a raw packet. I am trying to implement traceroute command . I want to know when i receive a ICMP time exceeded message how can I extract the mac address of that machine . I am a new to network programming so am confused what socket call will help me to extract the mac address.
Thanks .
No, you can not extract MAC address from ICMP reply.
You can only determine MAC addresses of linked machines next to you. In ICMP(tracert) you can just find out the IP address of target or middle machine.
If you want to detect MAC addresses, you should use ARP protcols where it's applicable in local networks not Internet.
ICMP protocol starts after IPv4 header[1] and MAC addresses is related to physical/link layer. In low level layers the MAC addresses will transparent from top level layers such as network(IP) or Transmission,...
To determining MAC addresses, you should use Raw sockets or PCAP SDKs to access lower layers of network programming. (I say again, these are not useful over Internet)
Like Masoud M said, you can only get the MAC address of machines that are on your local network. That said, you can parse the output the arp command to find the MAC address given the IP address of a machine one your local network.
In general, on internet, you don't even know the media a host is using for transmitting packets. Let's suppose a remote host is conected over a serial rs-232-C link with PPP protocol. It doesn't have a mac address. This also happens for example if the host uses a token ring interface or frame relay link. This makes determining the remote mac addresses of hosts a local issue completely. Normally, when you get a packet from a remote site over ethernet, the source mac addres you get in the packet is the one of the last router that links you to the internet, not the one of the original host that sent the IP packet. In the RFC on IP over avian carriers (rfc1149, rfc2549 and rfc6214) the media used for transmission doesn't allow to use mac addresses (the link address, if somewhat feasible on a pidgeon could be, would be its name)
If you want to read about traceroute on ethernet network of switches, perhaps you had to have a look at the IEEE802.1ag, that has an specification to do tracerouting over switches (tracelink service) but I think is far over the scope of this answer.
Please don't criticise the solution. It's not my design and yes, it sucks.
On a computer running Linux, and using C, we need to verify that a TCP connection made to a process is from the same machine. Doing it by IP address is problematic since the OS is generating two IP addresses and the process only knows one. Anyway, verifying by IP address is a bit poor.
We want to do the verification by comparing the "remote" MAC address to the local MAC address. We already get the local MAC address. All I need to know is how to get the "remote" MAC address. It's in the packet that gets sent when forming the connection (and in all subsequent ones too). How do we drag it out of the ethernet layer?
Before anyone says this again, I KNOW you cannot get the MAC address of the remote host if it's not on the same subnet/LAN. That's fine. Presumably we'll get something like 00:00:00:00:00:00 and since that is different to the local MAC address it will be different - just what we want.
--
So, to summarise, we have a TCP connection socket fd, we've received a data packet, how do we then find the MAC address of the remote host, the MAC address that was in the packet's header?
If I understand correctly, you are not trying to tell remote machines apart, but to use the idea that the source and destination MAC would match on traffic sent from a machine to itself in order to allow only local traffic.
This seems rather roundabout, and has been pointed out, insecure.
A somewhat better idea might be to have the TCP client listen only on the loopback interface (127.0.0.1) and not on INADDR_ANY. Or go a step further and use a unix-domain socket instead of a TCP one (a common method used by X servers today to prevent the possibility of remote connections)
The MAC address of a live same-subnet TCP connection will almost certainly be in the ARP cache.
On Linux, you could examine the ARP cache by looking in /proc/net/arp. Here is what it looks like on my Ubuntu box:
aix#aix:~$ cat /proc/net/arp
IP address HW type Flags HW address Mask Device
10.0.0.32 0x1 0x2 00:1e:4f:f5:be:dc * eth0
10.10.10.1 0x1 0x2 00:1f:6c:3e:02:e3 * eth0
There's probably some callable API that you could use to get to the same data if you're averse to parsing the pseudo-file.
How about configuring a firewall (internal or external) to block or MAC-filter external traffic on the port in question?
A loopback connection (whether it's over the loopback interface or some other interface) it not routed over any ethernet device and therefore does not have a MAC address associated with it.
I suggest you just use getsockname and getpeername to get the local and remote IP address and compare that they are equal. That will work without any a priori knowledge of the configured IP addresses of your system.
Further, if you want to be IPv4/v6 agnostic, you could use getnameinfo with the NI_NUMERIC flag to convert both addresses to numeric string representations and strcmp them.