Packet analyzers like Wireshark, and Fiddler allows for low-level packet dump, and appears to be the recommended way to debug binary websocket frames. Major problems of this approach includes secure websocket layers, complexity, friction in the development process, amongst others.
Other than Wireshark, what browser native, or extension tools are available to see at least a hex dump of binary frames exchanged via Websockets?
edit: as of Chrome 56.0, only frames of textual websocket connections can be watched (by going debug console (F12) -> Network -> Selecting the websocket connection (to identify: it has 101 HTTP status code) -> Frames panel); binary packets still show up as "binary frame (Opcode 2)
In Firefox you use Web Socket Monitor extension to get hex dump for binary packets.
Related
I am trying to work out what could be causing a strange issue I have been observing when testing a system.
The system under test recieves HTTP requests via UDP from an external source. For testing I have mocked out this source using Python sending the UDP packets over a local network for testing I send 1, 20, 133 and 1000 messages.
When I run the test on my local windows machine I regularily get a drop out of UDP packets with sometimes even the single message failing to be recieved. however when I create a virtual Linux Box (Centos) using Virtual Box and run the same tests from there I get 100% success rate 100% of the time.
Are there any know issues with sending UDP messages from Windows, any strange buffering differences between Windows and Linux I could adjust for on my machine?
UDP stacks of operating systems usually drops a received UDP packet, if the incoming packet does not fit to receive buffer. The receive buffer may be 'full', if the receiving application does not read it (=socket) fast enough.
Default size of receive buffer of your Windows may be smaller than in the Linux.
For handling bursts of incoming UDP packets better, you could increase size of the receiving buffer:
sock.setsockopt(socket.SOL_SOCKET, socket.SO_RCVBUF, 65536)
You can also use getsockopt for checking the size.
having researched and investigated it seems that despite my efforts to try and prove otherwise the answer is, it's just Windows. Windows Network Buffering is causing the problem. As fixing this is outside the remit of this question i will close this and if necessary open a new question, thanks for your help.
I have a Client and Server programs communicating on TCP, implementing IEC-60870-5-104 protocol on the application layer. I am sniffing a copy of all traffic between them,
How do I exactly replicate the IP and TCP layer functionalities on packets sniffed from libpcap in C ?. like IP-reassembly, Managing out-of-order segments, re-transmission, and duplicate TCP segments and separating PDUs, such that I get the same packet as if I was sniffing on the application layer at the Server. (Also please suggest any Frame-works which helps to do this).
This is a very difficult and involved task. It's what network intrusion detection / deep packet inspection systems do and AFAIK there is no drop-in library that handles it.
Your best bet is to build on an existing system such as Bro or Suricata (or maybe wireshark internals) that is already doing the session tracking, state management, re-assembly, re-ordering, duplicate detection, etc. You can then add your own application layer decoding to operate on the re-assembled data stream provided.
I would like to create a demo with the following topology:
... --->[switch] <---> [Host]
DEMO: A switch sends a packet to a monitoring Host (The packets original destination is not this Host, yet switch will send to it via a mirror port). The monitor-Host is to capture that packet, do something with it (e.g., just dump the L2-L4 header fields into some log file), and then send the original packet back towards the switch.
Host Environment: Ubuntu 12.04 Linux.
Dilemma: What's the simplest way I can capture the packet in Host and send back the original packet to the switch?
Possibilities to Explore:
Create a packet sniffer program in C (looks complex ... libpcap, AF_Packet sockets etc.).
Try to use python scapy (don't know how complex this will be).
Try to install some open source proxy server of some kind to which I can write a plugin that will examine the captured packets.
Question: Any better recommendations (if I can avoid going the programming route, it would be preferred. Is there any simple scripting method to do this?). Looking for a quick-and-dirty method here. Thanks.
well, you can use packets sniffers available such as wireshark, ettercap which will capture all network packets (using promisc mode) and dump them in readable format.
Or, you can preety much easily code sniffer for yourself in python, linux which is not so much complex to understand..
I'm developing chat application using app.js which is webkit+node.js framework.
So i have node.js plus bridged web browser environment on both sides.
I want to make file transfer feature somewhat similar to Skype one.
So, initial idea is to:
1.connect clients to main server.
2.Each client gets ip of oposite ones.
3.Start socket or websocket server on both clients and connect to each other.
4.Sender reads the file and transmits it to the reciver.
Question are:
1.Im not really sure that one client can "see" the other.
2.file is a binary data, but websockets are made for text messages so i need some kind of coding/decoding stuff. I thought about base 64 but it has 30% of "overhead" information. So i need something more effitient (base 128?).
3.If it is not efficient to use websocket should i use TCP sockets instead? What problems can appear if i decide to use them?
Yeah i know about node2node and BinaryJS, i just dont know should i use them or not. And i really what to do something myself.
OK, with your communication looking like this:
(C->N)<->N<->(N->C)
(...) is installed on one client's machine. N's are node servers, C's are web clients.
This is out of your control. Some file sharing apps send test packets from the central server to clients, to check whether ports are open and NAT rules are configured correctly, etc. Your clients will start their own servers on some port, your master server can potentially create a test connection to these servers to see whether they're started correctly and open to the web, BEFORE telling other clients that they can send files.
Websockets are great for status messages from your servers to the web GUIs and general client-to-client communication. For the actual file transfers, I would use TCP sockets, see the next answer. On the other hand base64 encoding is really not a slow process, play with it and benchmark its performance, then decide with some data to back up your decision.
You could use a combination: websockets from your servers to the web GUIs, but TCP communication between the servers themselves. TCP servers (and streams) aren't hard to set up in Node, I see no disadvantages. It might actually be less complicated than installing node2node on those servers, since TCP is already built-in.
I need an EXPERT opinion please, and sorry if my question itself is a confused question.
I was reading around about structure of VOIP applications (Client/Server). And mostly UDP is recommended for voice streams. I also checked some voicechat applications like paltalk and inspeak and their sites mention they use udp voice stream which dont seem correct for below reasons.
I examined the traffic/ports used by paltalk and inspeak. They have UDP and TCP ports open and using a packet sniffer i can see there is not much UDP communication but mostly it is the TCP communication going on.
Also as far as i know, In UDP Protocol server can not send data to a client behind NAT (DSL Router). And "UDP Braodcast" is not an option for "internet" based voice chat applications. THATS WHY YAHOO HAVE MENTIONED in their documentation that yahoo messenger switch to tcp if udp communication is not possible.
So my question is ....
Am i understanding something wrong in my above statements ?
If UDP is not possible then those chat applications use TCP Stream for voice ?
Since i have experienced that TCP voice streams create delay, No voice breaking but Delay in voice, so what should be the best structure for a voice chat server/client communication ?
So far i think that , if Client send data as udp packets to server and server distribute the packets to clients over TCP streams, is this a proper solution ? I mean is this what commercial voicechat applications do ?
Thanks your answer will help me and a lot of other programmers .
JF
UDP has less overhead (in terms of total packet size), so you can squeeze more audio into the channel's bandwidth.
UDP is also unreliable - packets sent may never be received or could be received out of order - which is actually OK for voice applications, since you can tolerate some loss of signal quality and keep going. a small amount of lost packets can be tolerated (as opposed to downloading a file, where every byte counts).
can you use TCP? sure, why not... it's slightly more overhead, but that may not matter.
SIP is a voice/media standard that supports UDP and TCP. most deployments use UDP because of the lower overhead.
The Skype protocol prefers UDP where possible, and falls back to TCP.
in SIP situations, the NAT problem is solved by using a nat keep-alive packet (any request/response data) to keep the channel up and open, and by exploiting the fact that most NATs will accept replies on the same source port the connection was opened from... this isn't foolproof, and often requires a proxy server mediating the connection between 2 nat'd peers, but it's used in many deployments.
STUN, TURN, and ICE are additional methods that help with NAT scenarios, and especially in p2p (serverless) situations.
info regarding NAT issues and media:
http://www.voip-info.org/wiki/view/NAT+and+VOIP
http://en.wikipedia.org/wiki/UDP_hole_punching
http://www.h-online.com/security/features/How-Skype-Co-get-round-firewalls-747197.html
if you're implementing a voice service of some kind, a system like FreeSwitch provides most of the tools you need to deliver media to distributed clients:
http://www.freeswitch.org/
I see the question is 3 years overdue, but I see no answer accepted, so I'll take a shot at it
1- your statements are correct
2- correct, TCP or UDP can be used for audio stream.
3- Combining tcp and udp for the audio stream is not useful. If UDP is working for transmission to the server, it will work for reception, that's how all NAT firewalls work, i.e they send datagram received from internal host to remote host after they change the ip header to make the packet seem coming from them, and when they receive response, they forward it back to internal host. The difference between NAT firewalls is for how long the NAT tunnel will remain alive, but this does not matter for the audio part of the call, as there is constant flow of audio in both way during a call. This would matter more for the signalling part of the call, which uses the SIP protocol. So I would recommend using TCP for SIP as the TCP session has a default timeout of 900s, making the keep alive messages less frequently needed.
Now some applications you mentioned do not use SIP for session initiation, and hence have proprietary ways of signalling.
Other applications take advantage of something called 'hole punching' to allow client-to-client direct communication (or peer-to-peer) such as Skype. The advantage of these is that the server does not stay in the middle of the voice stream, and this can effectively reduce latency, making TCP a potential choice for the audio stream.
The guys behind development of Asterisk, the famous opensource PBX, have realized the problems in SIP which require having lots of ports open, and they have developed their own protocol, called IAX, to transmit signalling and media over one port. I would encourage you to consider implementing IAX for your client/server, because it ensures that if a client is able to connect (through signalling), then it's able to make calls.