I understand that IPMI is a way of communicating to the BMC onbard from an external world. And this communication is possible via IPMI which is a secure protocol to talk to these devices. But Im confused as to which OSI layer does the IPMI exactly belong to? Is it a combinataion of two or more layers? Is it restricted to some hardware?
IPMI's network functionality works on top of UDP, so it's in the OSI 5-7 range. It's a little blurry where it sits as it could be viewed as sitting a bit in all three.
It is restricted to hardware that supports IPMI.
In a nutshell - IPMI is an architecture specification covering much more than one OSI layer.
IPMI is not a single protocol it cannot be strictly classified into particular OSI layer. IPMI request and response may be transferred inside a UDP datagram so it is an application (7th) layer from the TCP/IP stack point of view. Note that TCP/IP has no 5th and 6th layer.
But IPMI can be transferred over completely different transports like I2C, PCI, KCS... IPMI standards defines bridged request / response handling and this kind of operations belong to layer 2 in OSI model.
Related
So I have a PC connected to a micro-controller via a serial cable and an Ethernet cable. Initially the PC sends a byte across the serial cable to the micro-controller. This results in the micro-controller sending back a UDP datagram via the Ethernet cable.
I want to know whether the code running on my PC should be a server or a client?
Per Wikiepdia Client/Server:
The server component provides a function or service to one or many
clients, which initiate requests for such services
And Master/Slave:
Master/slave is a model of asymmetric communication or control where
one device or process controls one or more other devices or processes
and serves as their communication hub
The above scenario looks like the Master/Slave. In the initial, 'idle' case, there is no "SERVER" that is waiting ("listening") for requests. Only when the PC activate the micro-controller they will start communication (via UDP).
You could use either term depending on what you were talking about. As other people have noted, client and server are terms used to describe how distinct parties are involved in a service. The terms can be useful in some situations (e.g. a web server and the browser as a client) but in other situations it's a less useful term (e.g. peer-to-peer protocols).
Presumably you're on stackoverflow because you're dealing with code.
In this case it's useful to be more precise and I'd suggest using terms to match whatever primitives are exposed by your language. Most will use/expose Posix sockets as their standard API, and hence you'd want to talk about/use connect or accept (potentially after binding first). Note that these calls work across TCP and UDP (except accept), but the semantics of sending and recving on the resulting connected sockets will obviously be different.
I am trying to implement a method which a client behind a NAT can reach my video/audio encoder device connected to another LAN (behind another NAT), and then my device streams Video and Audio to that client.
Is there anyone who knows how to deal with NAT issue for P2P communication?
I have read and review the UDP hole punching, STUN/TURN/ICE and a few other methods like uPnP protocol and so on. All of them either have uncertainty in transmission or it's different from NAT to NAT or it is complicated to be implemented on my device.
I am wondering if there is a simpler method to handle this thing?! Since I have to do networking things on my device, unlike PC, it is not very strong and I can't expect a lot of computation. Thus I prefer a simple method.
Thanks~
The 'easiest' way would be to have 1 device outside both NATs which both devices connect to and acts as a proxy. From the question you are asking, I think this would be an answer to your problem, AND, that you could probably implement.
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.
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 unable to understand or grasp rather; what it means to program at a lower layer in socket programming. I am used to working with tcp/udp/file system sockets. These are all wrapped around their own protocol specifications ... which as i understand would make it working at the application layer in the stack.
In the project i am on , i have seen some files which are "named" LinkLayer, TransportLayer... but i don't see any more calls other than standard socket calls....send /recv/ seletct...
Does the fact you are setting a socket options mean you are programming at a lower level ? Is it just restricted to it? Or are there other API's which grant you access at the representation in kernel ?
Typically this refers to using SOCK_RAW sockets, which requires you to assemble your own packet headers, calculate checksums, etc. You still use send/recv/etc. but now you are responsible for making sure every bit is in the right place.
You can use SOCK_RAW sockets to implement protocols other than TCP or UDP, or to do things with the Internet protocols that higher-level interfaces don't accommodate (like tweaking the TTL of your packets to implement something like traceroute).
This usually means working on a lower OSI-Layer, for example, not directly sending TCP-streams or UDP-packets, but crafting own IP or even Ethernet packets or other low-layer protocols which would - in normal case - be handled by the operating system.
This can be done done via specific socket options which enable you to receive or send data on any layer, even layer 2 (Data Link).