Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 2 years ago.
Improve this question
There seem to be some other people who have similar questions to mine, but I think they're particularly specific. I think I may be running into a general problem.
I have a TAP device in Linux (created in C) that is connected to another network, and I want my computer to be able to communicate to the other network through this TAP device.
I can see arp packets coming in clearly with wireshark, but my kernel will not respond to them. I have tried configuring a bridge and setting the bridge's IP address to no avail. I've also tried bridging to physical hardware and for some reason, Linux doesn't seem to pass the data through to the other nic.
If I set up static ARP routes, it seems that this Linux box doesn't respond to pings to devices on it.
# ifconfig tap0 up
# brctl addbr br0
# brctl addif br0 tap0
# brctl addif br0 eth9
# ifconfig br0 up
I can try setting br0, eth9, or tap0 to an IP, but none reply to pings or arps. Even if I destroy the bridge, no nothing.
I feel like what I want is a "pretend" interface. Like "this is a fake ethernet card" and to talk over that. I feel like that should be possible with tap.
Similar issues:
Linux TUN/TAP: Unable to read data back from TAP devices
Why aren't ARP or ICMPv6 packets processed by a Linux TAP device
I regret that this was unrelated to the way tap/tun devices work in Linux. In fact, this mechanism will work.
The issue was in that I was using "send" and "recv" to talk to the raw tap device. Wireshark can't tell the difference, but the Linux OS will refuse to use the data coming from the socket.
Use this guy's example: http://www.cis.syr.edu/~wedu/seed/Labs/VPN/files/simpletun.c
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 1 year ago.
Improve this question
In embedded systems, we often use UART to transmit data to a serial console on a PC, and these days with a USB-to-uart serial converter showing up as a virtual com port. Why has UART become the go-to for this instead of other serial interfaces like I2C and SPI?
Because is simple, was designed to be used on longer distances (I mean meters not kilometers :)), very standard and every uC has it.
I2C & SPI are not designed to be used outside the PCB (I know that people use them on longer distances). Those interfaces are used do connect other ICs to your microcontroller.
Maximum distance of RS232 can be a few meter, I2C and SPI doesn't work well with distances longer than about 200 - 500mm (depending on pullups, speed, collector current, ...).
SPI and I2C need a master and slave(s), there is no such difference between 2 UART hosts.
You need fewer pins than SPI (when pins like DTR, DSR, RTS are omitted) or a parallel port.
You don't need to worry about where to put a pullup-resistor.
Both hosts can start a transmission asynchronous, with I2C and SPI the master needs to poll the slave before he can transmit data.
A host doesn't need to answer immediately. This can be important on a PC under load where the reaction time can be very high (50ms or so). Try to write a program for a PC that can reliable answer in less than 1ms.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I have an embedded system with an UART that I communicate with over an USB to RS485 cable. I can read and write data to flash by sending serial commands. The software on the device is written in C++.
I would like to implement a file-system that my computer would recognize when I plug in the USB, and would let me browse the files on the embedded devices' flash.
How would I go about doing this?
From the PC's view the "device" is the cable, not your board. Logically the USB<->RS485 converter adds an RS485 interface to your PC rather then a USB interface to your board - even if the USB/485 chip were on your board that would be logically if not physically true. Therefore it cannot appear as a USB mass-storage device, because it is explicitly a USB CDC/ACM device.
For your board to appear as a true USB mass storage device, you would need to use a USB Device controller - some (but not all) Blackfin devices have an on-chip USB controller, and analogue devices provide a USB device stack library for that. In that case you would need to implement and use a USB interface on your board rather that a serial adaptor cable.
If you lack a USB controller or only wish to use the serial interface, then it may be simplest perhaps to implement a TCP/IP stack with PPP and use FTP. That would make the serial link far more flexible in any case (can then support Telnet and other protocols simultaneously). Using PPP in Linux is relatively straightforward, in Windows it is possible but it is tied up in the dial-up connection support, so is not particularly intuitive for a direct cable connection. In this case you'd need to use an FTP client on your PC as it would not appear as a direct file-system device to the PC.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 9 years ago.
Improve this question
Here is my configuration
my PC IP :192.168.1.57 subnetmask : 255.255.255.0
my device IP :73.83.1.57 subnetmask : 255.255.255.0
i am successfully able to send packet from my pc to device but not able to send packet from device to pc (have checked in wire shark but it show only PC->device packet transmission flow )
Now i have added one more IP like device ip family in PC (73.83.1.60) then successfully able to two way communication.same works in reverse order means i have set my device IP as 192.168.1.58.
So is there any rules like both IP must belongs to same IP family?
because sub net mask in both are same. so issue is IP.
Any one have idea? is it correct network behavior? can i solve it without making same IP family.?
If you are using both IPs on the same LAN they should be on the same subnet ex:
11.1.1.1/24 can ping 11.1.1.44/24 but it can't ping 11.1.2.2/24 ( different subnets)
In WAN not necessary, for example 192.168.1.1 can ping 72.1.1.1 ,, but 72.1.1.1 can't ping 192.168.1.1 because this ip is private and when it leaves the LAN it becomes real ip because of NAT (Network Address Translation)
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I've been dying to implement a chat server in C and Winsock for a long time now, but I haven't taken the time. Partly, because I'm still unsure of some of the conceptual ideas about building a server on Windows OS'es for something like chat.
Here are some of the issues I've been thinking about :
How will user x connect to my server over a generic LAN
without me relying on them to type in a network address( e.g. address
could be invalid, redirected to a different server, etc. )
If I use broadcasting to solve the above problem, will that be reliable enough for chat?
Will that potentially DDos a LAN since the packets will be be forcibly handled on every machine and may take a lot of bandwidth if enough people join?
What is the difference between multicasting and broadcasting? Is multicasting truly superior?
Etc.
Per request, my definition of reliability would be that I can get most of the data consistently in sent packets. In other words, I don't mind a few dropped packets, but I do mind if the data gets messed up quite a lot along the way.
Currently, I have a lot more questions than answers, but the main point I'm getting at is this :
What is the safest and most reliable way of implementing a chat over a LAN in C and Winsock?
How will user x connect to my server over a generic LAN without me relying
on them to type in a network address( e.g. address could be
invalid, redirected to a different server, etc. )
Use a closed list of known servers, or use some broadcast based autodiscovery system.
If I use broadcasting to solve the above problem, will that be reliable
enough for chat?
Define your requirements for reliability.
Will that potentially DDos a LAN since the packets will be be forcibly
handled on every machine and may take a lot of bandwidth if enough
people join?
It's a chat... the amount of generated packets will be comparatively short and small.
What is the difference between multicasting and broadcasting? Is
multicasting truly superior?
Search the web. There are lots of resources and information about multicasting, most precisely, IP multicasting. In short:
Broadcast delivers to all hosts on a broadcast domain. Multicast delivers to all hosts that have explicity joined a multicast group, which may not be in the same broadcast domain (see last point).
Broadcast forces a switch to forward broadcast packets to all its interfaces. Intelligent switches can benefit from peeking at IGMP packets to know which interfaces multicast packets have to be forwarded to.
Broadcast cannot treepass a broadcast domain. Multicast packets can traverse a router, if it's configured to route multicast (search for M-bone)
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.