Server(A) ip is 192.168.0.5 and 192.168.0.6 is ip of another server(B). uTorrent is installed at Server A, and it is not executed. uTorrent is not installed at Server B. When i look packet flow, however, there are very large bittorrent packets sent by server B. Since these packet are too big, there are many PDUs assembled. Why does server B send bittorrent packet despite it is not installed?
How can i solve this problem?
Captured packets are followed:
http://kinimage.naver.net/20141024_290/1414161623305lDgKd_JPEG/%C4%B8%C3%B3.JPG?type=w620
Related
I am working on a small linux socket project. The goal is to have multiple servers (ie. 1,2,3,4,5) that listen for send get and ACK packets from each of their respective clients. I am currently attempting to implement a routing table protocol whereby 2 servers (A, B) exchange their routing tables (vectors containing respective clients, server name, and number of hops). The issue I am having is with binding a socket to B's external address from A and vice-versa. From what I have read you do not bind to anything other than a local address except in certain cases. What I am wondering is how do I simply fire off a UDP packet from one server to another knowing the (static) IP address of each server?
What I am wondering is how do I simply fire off a UDP packet from one
server to another knowing the (static) IP address of each server?
The short answer is, you can't. At least on the Internet proper, only unicast is widely supported, which means that in order to send a UDP packet to another machine, you'll need to know its IP address (somehow).
The longer answer is: The first thing you often need to do is discover the target machines' IP addresses. That might be a matter of having the user manually enter a list of IP addresses, or if the target machines are on the same LAN, you can program a mechanism for auto-discovering them by having your program send out a broadcast or multicast UDP query packet. Make sure any instances of your program running on the same LAN receive that packet and respond to it by sending back a response UDP packet (the responses can be sent by by unicast or multicast or broadcast, your choice), and then your query-originating computer can know from the responses it receives which other IP addresses your program is presently also running on.
Note that a lot of computers and network devices run firewalls that reject incoming UDP packets by default, so if you packets don't seem to be getting through that is a likely reason why.
(edit: solved -- see below)
This is my situation:
TL-MR3020 -----ethernet----- mbed
OpenWRT C/C++ custom networking stack
192.168.2.1 192.168.2.16
TL-MR3020 is a Linux embedded router
mbed is an ARM microcontroller.
On the network I just want them to exchange messages using UDP packets on port 2225. In particular, TL-MR3020 has to periodically send packets every second to 192.168.2.16:2225, while mbed has to periodically send packets every 50ms to 192.168.2.1:2225.
Everything was good untill I removed the network stack library from mbed (lwIP, not so lightweight for me) and written a new minimal stack.
My new stacks sends 5 gratuitous ARP reply just after the ethernet link gets up, then starts sending and receiving udp packets.
Now TL-MR3020 doesn't receive any UDP packet. In particular, with ifconfig I can see packets coming, but my application can't get them.
Also, if I connect my laptop instead of the TL-MR3020, I can see the UDP packets coming, using Wireshark. There's nothing wrong, except done for my application.
I have a node.js script that has to receive the packets, but it doesn't receive nothing, but if I send UDP packets from local to local, the script receives them.
I think that my application is OK also because neither SOCAT can receive the UDP packets using socat - UDP-LISTEN:2225.
I've already checked on TL-MR3020:
arp table has the correct ip-mac assiciation
destination MAC address matches the incoming interface
destination IP address matches the incoming interface
IP checksum: wireshark says good=false, bad=false
UDP checksum: wireshark says good=false, bad=false
So, I'm asking... what are the minimum requirements for a custom networking stack to send UDP packets?
SOLVED:
You need a good checksum in the IP header.
UDP checksum, my case, can be set to zero.
tcpdump is very helpful (thanks to AndrewMcDonnell)
I have 3 host:
Client A
Client B
Server.
I have below test scenario:
Client A send raw packet to server (change source mac address to Client B's)
Server reply this packet (I use tcpdump to make sure Server have replied this packet)
Client B install one module that register hook function on netfilter pre-routing, But nothing reveived.
Does anybody know why Client B's hook function receive nothing?
Thx!
Probably because your switch has seen client B's MAC address on the port to client A and has remembered that. It will therefore send the reply on the ethernet port to client A, not to client B's erhernet port.
This seems to be a networking issue, not a programming issue. Therefore this question might be more appropriate on a different forum.
There's an ARP cache on the server side, probably it already contains an association between host A and original MAC of host A (I guess this association appears when client A establishes connection with the server).
arp -n
will show the content of the ARP table.
Each ARP table entry has some expiration timeout. When it expires, server tries to refresh the expired entry by sending ARP who-has requests to all hosts in local network. So only after cache entry of host A expires, the server absorbs updated information.
I want to remote dial from my pc using a simple non SIP client program which I wrote and wchich sends commands to a proprietary SIP client that accepts remote commands via a TCP connection. The proprietary SIP client will then dial the remote party using my PC's IP and port number in SDP for RTP. Is this possible in principle? Are there any opensource clients available that use this concept? Is there any documentation (IETF RFCs, blogs etc) that is available.
Appreciate any help in this matter.
Check out pjsip, it's an open-source cross-platform SIP client for all major platforms and with API in C and an API wrapper for python, whichever you prefer. There are also examples on their site. Link your TCP parsing code to pjsip and call its functions to initiate a call, you can find how to do it on their site
If I understand correctly, here is what you want to do:
TCP SIP/SDP/RTP
PC <===> SIP client <===========> softswitch
Actually, TCP between PC and SIP client will probably be accurate for signalling but not for media as RTP media stream is often sent over UDP.
In my opinion, the first step is to make sure that your softswitch will accept sending RTP packets to an IP address which is not the same as SIP client (I think most of them refuse for security reasons). If it accepts and if you have no NAT between your SIP client and your PC, you should be able to send RTP stream directly to your PC. In this case, you have to retrieve RTP packets, eventually rearrange them, decompress their payload and feed them to your speakers.
If your softswitch does not want to send RTP packets to an IP address different from SIP IP address, then you have to forward your RTP packets from your SIP client to your PC. But if you can't modify your SIP client to do this (and it's probably the case as it's a proprietary software), you're probably stuck.
To test whether your softswitch accepts sending RTP packets to an unintended IP address, you can use sipp and specify a remote media ip address different from SIP signalling IP address.
I have 2 linux based systems - a client with 2 interfaces (1 LAN, 1 modem) and a server.
I open 2 UDP sockets, and use setsockopt with SO_BINDTODEVICE to bind each socket to it's interface.
Then I send a message from client to server through each of those sockets.
Both of them reach server. Server socket reads them, and sends a reply to each of them.
Then I try to read server's reply on the client.
BUT, there is only 1 reply.
Also if I run tcpdump, I see that both of the replies are received on their relevant interfaces, on the same port that they left. Yet only one of them reaches socket. The other is lost?
The "lost" packet is not random, it's the "non" default one. If my routing table is empty, the modem one is lost. If I add a route to server ip from modem interface, the lost packet will be the lan one.
Yet, they always reach server, always return back, always seen in tcpdump, but 1 never reaches socket. How can that be?
There is an ipv4 network configuration parameter called rp_filter (reversed path validation filter). Basically, if the reply to a packet wouldn't go out the interface this packet came in, then this is a bogus packet and should be ignored. Which is why while I saw the packet on the tcpdump, it never reached socket. Disabling it did the trick.
sysctl -w net.ipv4.conf.all.rp_filter=0
sysctl -w net.ipv4.conf.eth0.rp_filter=0
sysctl -w net.ipv4.conf.ppp0.rp_filter=0