Is it possible to figure out what is the mac address of the switch port you are connected to?
I was looking in tcpdump, but it seems that in each ethernet packet the MAC of the sender and destination, but not of those MAC's it passing. But i'm looking for way to find out the MAC of the switch you are directly connected to.
I should be a generic solution. For example a managed CISCO switch, is not a solution (yet).
I have C/C++ at my disposal or any other language.
Read this:
http://en.wikipedia.org/wiki/Network_switch#Layer_1_.28Hubs_versus_higher-layer_switches.29
In a normal switch they don't have a MAC address. Unless what you are using is a bridge.
TCP/IP are above the switch in network layer abstractions. Specifically, they're at the Transport and Internet layers, respectively (Transport is above Internet). You need to inspect the raw Ethernet packet, for Link layer data.
Related
I am fairly new to network programming especially L2.
I am working on an implementation of LLDP(Link Layer Discovery Protocol) in C. I understand that multicasting over link layer works on directly connected LAN devices. My aim is to have it work across VLAN's (Eg: a device in 10.1.1.0 pool should be able to receive L2 multicast packets sent by a device in 192.168.1.0).
Is there a possible way to achieve this ..or am I missing something vital here?
Wireshark wiki on LLDP says:
LLDP Data Units (LLDPDUs) are sent to the destination MAC address 01:80:c2:00:00:0e. This address is defined as the "LLDP_Multicast" address. This address is defined within a range of addresses reserved by the IEEE for protocols that are to be constrained to an individual LAN. AN LLDPDU will not be forwarded by MAC bridges (e.g. switches) that conform to IEEE Std 802.1D-2004.
so does that mean that a switch or a router just ignores link layer multicast packets coming from another device in another subnet?
does multicast over link layer work only on directly connected devices?
what is the scope of a data link layer multicast address?
From your question, it seems you are mixing L2 and L3 technologies. If you are dealing L2 multicast, IP addresses have no meaning there.
As for the questions:
1) When talking about switches, you have to consider if a switch is 802.1D compliant or not. A dumb switch (a. la Generic $5 from a store next door) will treat your LLDP PDU as a broadcast frame and will distribute it to all other ports except for the one it received it from. This is because MAC address starts with 01 which indicates that the group address bit is set.
A switch which is 802.1D compliant will not forward this frame anywhere. It might process it locally to learn about a device sending it. This will happen if the switch has LLDP protocol support enabled.
A router will act in the same way as a 802.1D compliant switch. It will not forward the LLDP frame and might process it if the LLDP is enabled.
A PC will act the same was as a router.
2) Scope will depend on the endpoints of a link. Any smart device will terminate the journey of the LLDP frame. A dumb switch will treat it as a broadcast frame.
Link-local multicasts will not be propagated off a link. Because of that, the question of ignoring, or not, a link-local multicast from another link will never come up.
You will not be successful in creating an LLDP implementation which originates on one link and is received on a different link. You will need to create a completely different protocol to do what you want, and you will need to change the software on the network devices to recognize this new protocol. This will not be possible with network devices which run proprietary software.
Using C I am trying to discover the IP of a locally connected device without knowing any information about the device.
[ my box ]--eth0--------------[ unknown device ]
I can't seem to find a way to arp/broadcast to get the IP of the device. I understand that if I use multicast the device itself has to be a member of the group. When I arp or arp-scan they ask me to assign my eth0 interface an IP but I don't have one assigned, I can put one if I need to but I am unsure what it needs to be set to in order to discover anything.
Example: I have a Linksys wireless IP camera and I want to find the IP/Subnet. Without knowing its subnet/netmask I wouldn't know what to set my eth0 to.
I have written a C program to parse the arp table in Linux but I cannot seem to get the IP from the locally connected device in it. As mentioned above, I cannot use these tools without setting eth0 to something.
I think Your best chance to find something is by capturing all incoming network traffic, especially while unknown device is booting (using tcpdump, wireshark or something similar). Just filter out traffic, which is sent from my box.
Most likely You'll see DHCP requests and maybe ARP requests. If device is using DHCP, the easyest solution would be to run DHCP server on eth0 (so You can assign IP to this device).
If for some reason You need to program in C (and network capture gives expected results), libpcap may be usefull.
If evrything else fails, You can try to dicover unknown IP using fake ARP packets (so You don't need to change IP on eth0) and capturing any responses.
I believe that my question is:
Is there a simple user-mode TCP stack on PC operating systems that could be used to exchange data over a lossy serial link with a Linux-based device?
Here is more context:
I have a Linux-based device connected via a serial link to a PC. The serial link is lossy so data being sent between the two devices sometimes needs to be retransmitted. Currently the system uses a custom protocol that includes framing, addressing (for routing to different processes within the Linux device), and a not-so-robust retransmission algorithm.
On the Linux device side, it would be convenient to replace the custom protocol, implement SLIP over the serial link and use TCP for all communications. The problem is that on the PC-side, we're not sure how to use the host's TCP stack without pulling in general IP routing that we don't need. If there were a user-mode TCP stack available, it seems like I could integrate that in the PC app. The only TCP stacks that I've found so far are for microcontrollers. They could be ported, but it would be nice if there were something more ready-to-go. Or is there some special way to use the OS's built in TCP stack without needing administrative privileges or risking IP address conflicts with the real Ethernet interfaces.
Lastly, just to keep the solution focused on TCP, yes, there are other solutions to this problem such as using HDLC or just fixing our custom protocol. However, we wanted to explore the TCP route further in case it was an option.
It appears that the comments have already answered your question, but perhaps to clarify; No you can not use TCP without using IP. TCP is built on top of IP, and it isn't going to work any other way.
PPP is a good way of establishing an IP connection over a serial link, but if you do not have administrative access on both sides of the computer this could be difficult. 172.16.x, 10.x, and 192.168.x are defined as being open for local networks, so you should be able to find a set of IP addresses that does not interfere with the network operation of the local computer.
From the point of view of no configuration, no dependencies, comping up with your own framing / re-transmit protocol should not be too hard, and is probably your best choice if you don't need inter-operability. That being said kermit, {z,y,z}modem would provide both better performance and a standard to code against.
Lastly, you may be able to use something like socat to do protocol translation. I.e. connect a serial stream to a TCP port. That wouldn't address data reliability / re-transmission, but it may be the interface you are looking to program against.
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.
I have a need for some C or C++ code, compilable under Linux, to be able to take a list of IP addresses of some arbitrary number of remote hosts machines and obtain a ethernet MAC address for each one. These host machines may be on the same subnet or they could be on a different subnet behind a router. Its OK if the MAC address of some or all of the remote hosts is the address of the interface on the router. Ultimately, I want to hand off the IP address and MAC address to an FPGA who will use these pieces of information to format and send UDP/IP packets over ethernet to the hosts. Obviously, the FPGA will also be given its own MAC address and IP address to fill in the source MAC and source IP addresses in the packets.
Is there some code I can be pointed to that can create and broadcast ARP packets to these remote machines and receive back the ARP response packets such that the destination MAC addresses can be extracted?
Part of what you want to do requires some raw socket programming.
http://mixter.void.ru/rawip.html
The source for the linux arp command will give the rest of what you need. Here's a link:
http://www.comp.nus.edu.sg/~cs4236/readings/out/html/arp_8c-source.html
I recommend looking into arping which is doing a somewhat identical job. It takes IPs and MACs and tries to receive additional informationen. Or justs pings them.
http://freshmeat.net/projects/arping/