I'm running a new instance of the Apache Ignite 3 beta on Windows and am hoping someone might recognize the error reading the MAGIC_BYTES I'm seeing trying to run the examples.
The cluster starts successfully and I can connect via the CLI; e.g.: 'node status' shows [name: defaultNode, state: started]
However, when I attempt to run any of the examples, such as SqlJdbcExample, it fails in ClientMessageDecoder.readMagic(). In there it is attempting to read the 4 MAGIC_BYTES (representing the 4 ASCII characters 'INGI').
What I see instead are the bytes 0x01, 0x00, 0x03, 0x00
This ultimately results in an IgniteException:
IGN-CMN-65535 TraceId:xxxx Invalid magic header in thin client connection. Expected 'IGNI', but was '▯▯'.
(Note: in debug, if I read more bytes out of the buffer I can see those 4 bytes are followed by an ASCII newline character (0x12) then the ASCII 'defaultNode'.)
In the SqlJdbcExample when it is initializing the JDBC connection, I can see that is has called socket.send() with those MAGIC_BYTES IN TcpClientChannel.handshakeReq().
I am running the examples with no change to any configuration files and have set up the environment as per the documentation.
Set up Apache Ignite 3 beta and ran samples. They failed with
IgniteException: IGN-CMN-65535 TraceId:xxxx Invalid magic header in thin client connection. Expected 'IGNI', but was '▯▯'.
Verified as best I can that everything is configured correctly, but can't determine why I'm not picking up these bytes.
Ignite examples use port 10800 by default. Looks like something else is using that port on your machine, so Ignite server is on a different port.
Look into the log file in ignite3-db-3.0.0-beta1 directory (ignite3db-0.log file name), and search for Thin client protocol started successfully[port=10800] line. The port is likely different. Copy the port number and update the connection string in the example accordingly
I am trying to stream a raw video to ethernet via RTP Protocol (RFC4175), using Gstreamer 1.0 in Windows.
I don't want my data to be compressed, so I use rtpvrawpay element
I have the following gstreamer line
gst-launch-1.0 -v filesrc location=%FILENAME% ! videoparse width=%WIDTH% height=%HEIGHT% framerate=50/1 format=GST_VIDEO_FORMAT_GRAY16_BE ! videoconvert ! video/x-raw,media=(string)video,encoding-name=(string)RAW,sampling=(string)YCbCr-4:2:2,witdh=640,height=512 ! rtpvrawpay pt=96 ! udpsink async=true host=%HOST% port=%PORT%
I have another system decoding this rtp video. However, that system is restricted to process 1 line of video for each UDP packet. Morever, the system eliminates any packet has a length different than 1342 bytes.
(1 line: 640(width)x2 bytes + 20 bytes of RTP Header + 42 bytes of UDP header)
So, I have to tell the gstreamer pipe to send 1 line at a packet. My first attempt was to set "mtu" property of the rtpvrawdepay element. When I set mtu to 1300, my UDP packets are 1400 bytes of length (?)
Then I set it to 1302, UDP packets are 1403 bytes. There has to be a way to tell gstreamer never use any packet as a continuation packet in RTP.
some things to d0: first, upload the video to an FTP. Then, in JavaScript/html:
<embed src="myftpsie/mycoolvideo.mp4"></embed>
make sure its in a format the html can comprehend
I am stuck in a situation , my application needs to connect to a server using TCP . For connection request it needs to send a packet with following configuration:
8bits - Protocol - value - 01
8bits - Command - value - 01
16bits - Data length
32bits - Data
8bits- Reserve Bit
I am using .Net Tcp Client to send the data. I don't know how to send the data in binary mode
I am coding a stop and wait UDP file transfer.
Everytime i send a packet, ill start a timeout timer and wait for acks. If i recv an ack, ill transmit the next packet. If i recv a nack or did not recv acks, once my timeout expires, ill retransfer the packet.
For the receivers end, whenever i recv a packet, ill transmit a ack when checksum and seq number tallies. Else a nack.
This is my school assignment, to code a udp file transfer with error detection.
So dont ask me to use tcp.
The problem is when i want to end the connection. Once the last packet has been sent, ill now send a EOF message to the receiver, signalling the end of file transfer. So i send the EOF message, and start the timer. The reciver, receives the EOF message, sends back an ACK message and shutsdown. However, if this ACK message gets discarded, the sender is gonna timeout and will repeatedly resend the EOF message. How do i go about preventing this?
I have two programs:
server ... it generates UDP traffic on a chosen multicast
listener ... it prints UDP traffic on a chosen multicast
(it subscribes to a multicast and prints
whatever it receives).
When I run the server on one machine and listeners on some (other) machine(s), the listener sees UDP traffic and prints it correctly. So these programs should be in a good shape.
However, when I try to capture the traffic, on whatever machine, with tcpdump:
sudo tcpdump -i eth0 'dst 233.65.120.153' -w 0.pcap
and when I later try to replay it, on whatever machine, with tcpreplay:
sudo tcpreplay -i eth0 0.pcap
none of the listeners sees those captured packets:
09:38:40.975604 IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto UDP (17), length 32)
172.27.6.176.53507 > 233.65.120.153.64968: [udp sum ok] UDP, length 4
0x0000: 4500 0020 0000 4000 0111 6527 ac1b 06b0 E.....#...e'....
0x0010: e941 7899 d103 fdc8 000c 579c 6162 6364 .Ax.......W.abcd
0x0020: 0000 0000 0000 0000 0000 0000 0000 ..............
09:38:41.975709 IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto UDP (17), length 32)
172.27.6.176.53507 > 233.65.120.153.64968: [udp sum ok] UDP, length 4
0x0000: 4500 0020 0000 4000 0111 6527 ac1b 06b0 E.....#...e'....
0x0010: e941 7899 d103 fdc8 000c 579c 6162 6364 .Ax.......W.abcd
0x0020: 0000 0000 0000 0000 0000 0000 0000 ..............
09:38:42.975810 IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto UDP (17), length 32)
172.27.6.176.53507 > 233.65.120.153.64968: [udp sum ok] UDP, length 4
0x0000: 4500 0020 0000 4000 0111 6527 ac1b 06b0 E.....#...e'....
0x0010: e941 7899 d103 fdc8 000c 579c 6162 6364 .Ax.......W.abcd
0x0020: 0000 0000 0000 0000 0000 0000 0000 ..............
Note that even though none of the listeners sees UDP multicast traffic, I am still able to see it, on whatever machine, with tcpdump:
sudo tcpdump -i eth0 'dst 233.65.120.153' -X
My question: What should I do (differently) if I want to tcpreplay the UDP multicast traffic I am creating so that I can see it on application level (e.g. my listener program), not only by tcpdump?
$ cat sender.c
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <time.h>
#include <string.h>
#include <stdio.h>
#include <stdlib.h>
#define PORT 64968
#define GROUP "233.65.120.153"
main(int argc, char *argv[])
{
struct sockaddr_in addr;
int fd, cnt;
struct ip_mreq mreq;
char *message="abcd";
/* Create what looks like an ordinary UDP socket:
AF_INET ... IPv4
SOCK_DGRAM ... UDP
0 ... required constant
*/
if ((fd=socket(AF_INET, SOCK_DGRAM, 0)) < 0) {
perror("socket");
exit(1);
}
/* Set up destination address:
AF_INET ... IPv4
GROUP ... the IP-address of the multicast group
to which we want to multicast
PORT ... the UDP port that on which we want to multicast
*/
memset(&addr, 0, sizeof(addr));
addr.sin_family=AF_INET;
addr.sin_addr.s_addr=inet_addr(GROUP);
addr.sin_port=htons(PORT);
/* now just sendto() our destination! */
while (1) {
if (sendto(fd, message, strlen(message), 0, (struct sockaddr *) &addr, sizeof(addr)) < 0) {
perror("sendto");
exit(1);
}
sleep(1);
}
}
$ cat listener.c
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <time.h>
#include <string.h>
#include <stdio.h>
#include <stdlib.h>
#define PORT 64968
#define GROUP "233.65.120.153"
#define MSGBUFSIZE 1000000
char msgbuf[MSGBUFSIZE];
main(int argc, char *argv[])
{
struct sockaddr_in addr;
int fd, nbytes,addrlen;
struct ip_mreq mreq;
u_int yes=1;
/* Create what looks like an ordinary UDP socket:
AF_INET ... IPv4
SOCK_DGRAM ... UDP
0 ... required constant
*/
if ((fd=socket(AF_INET, SOCK_DGRAM, 0)) < 0) {
perror("socket");
exit(1);
}
/* Allow multiple sockets to use the same PORT number:
SOL_SOCKET ... manipulate properties of the socket API itself
SO_REUSEADDR ... Allow reuse of local addresses for bind
*/
if (setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, &yes, sizeof(yes)) < 0) {
perror("Reusing ADDR failed");
exit(1);
}
/* set up destination address */
memset(&addr,0,sizeof(addr));
addr.sin_family=AF_INET;
addr.sin_addr.s_addr=htonl(INADDR_ANY); /* N.B.: differs from sender */
addr.sin_port=htons(PORT);
/* bind to receive address */
if (bind(fd,(struct sockaddr *) &addr,sizeof(addr)) < 0) {
perror("bind");
exit(1);
}
/* use setsockopt() to request that the kernel join a multicast group */
mreq.imr_multiaddr.s_addr=inet_addr(GROUP);
mreq.imr_interface.s_addr=htonl(INADDR_ANY);
if (setsockopt(fd,IPPROTO_IP,IP_ADD_MEMBERSHIP,&mreq,sizeof(mreq)) < 0) {
perror("setsockopt");
exit(1);
}
/* now just enter a read-print loop */
while (1) {
addrlen=sizeof(addr);
memset(msgbuf, 0, MSGBUFSIZE);
if ((nbytes=recvfrom(fd, msgbuf, MSGBUFSIZE,0,
(struct sockaddr *) &addr, &addrlen)) < 0) {
perror("recvfrom");
exit(1);
}
printf("Incoming message size = %d\n", nbytes);
int i;
for (i=0; i < nbytes; i++)
printf("%02x ", ((unsigned char) msgbuf[i]));
printf("\n");
}
}
We had the same problem. With tcpdump we saw the data; however, the multicast client/listener was not picking up the data. Then we realized that the Reverse Path Filter (rp_filter) was rejecting the packets.
After disabling the rp-filter, the client/listener application started picking up the packets. Use the below command to disable rp_filter:
echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
In the above, replace 'eth0' with the interface receiving the multicast if other than eth0
To my knowledge, you can't do this on the same box ,tcpreplay bypasses the host's
routing table and sends traffic out the interface.
you have to start your listener on a different box. and make sure multicast is enabled. because by default, switch discards multicast traffic.
In my case I needed to adjust the pcap file by setting the correct destination MAC address. Also the checksum should be recalculated. And yes, 2 hosts are required for "tcpreplay". Without these I was fighting for a long time but only "tcpdump" showed the replayed stream, not my multicast listening app :(
This is just a theory, but it might be that the packets are discarded by the receiving side due to their checksums being wrong.
That could happen if the machine where you run tcpdump has IP or UDP checksum offloading enabled. That means the packages you capture locally haven't their checksums calculated yet, which the hardware does before sending them out. When you then tcpreplay those packets, the checksums are not calculated, as tcpreplay works on a lower level than the socket API you used to generate the packets.
In order to verify the correctness of the checksums (both those of the dump file as well as those of the packets spit out by the subsequent tcpreplay), tcpdump -v ... will warn you about wrong checksums. wireshark also colors wrongly checksummed frames differently (unless turned off in the wireshark settings).
Did you try to tcpdump the packets only on the sending host, or also on the receiving host? The latter would remove the checksum errors, if that is indeed your problem.
In Windows (I write it because in topic name you not specify that is not Windows) there is problem like this with different programs. But this program works fine Colasoft Packet Player. First time you should start it with administrative privileges.
OR (for all possible systems) you can try check this list.
Can I join the party?
Now, it is mentioned clearly on the FAQ page.
https://tcpreplay.appneta.com/wiki/faq.html#can-i-send-packets-on-the-same-computer-running-tcpreplay
Q: Can I send packets on the same computer running tcpreplay?
Generally speaking no. When tcpreplay sends packets, it injects them
between the TCP/IP stack of the system and the device driver of the
network card. The result is the TCP/IP stack system running tcpreplay
never sees the packets.
One suggestion that has been made is using something like VMWare,
Parallels or Xen. Running tcpreplay in the virtual machine (guest)
would allow packets to be seen by the host operating system.