Problèmes de signature de paquets / Ubuntu / APT

Les signatures suivantes n'ont pas pu être vérifiées car la clé publique n'est pas disponible : NO_PUBKEY 8771ADB0816950D8


Les signatures suivantes n'ont pas pu être vérifiées car la clé publique n'est pas disponible : NO_PUBKEY 386400DFB4C4219E

Solution :

apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 8771ADB0816950D8

Capturing with dumpcap for viewing with Wireshark

Dumpcap is a network traffic dump tool. It captures packet data from a live network and writes the packets to a file. Dumpcap's native capture file format is libpcap format, which is also the format used by Wireshark, tcpdump and various other tools.
Without any options set it will use the pcap library to capture traffic from the first available network interface and write the received raw packet data, along with the packets' time stamps into a libpcap file.
Packet capturing is performed with the pcap library. The capture filter syntax follows the rules of the pcap library.

Example  Help information available from dumpcap

dumpcap -h
Dumpcap 1.4.0
Capture network packets and dump them into a libpcap file.
See http://www.wireshark.org for more information.

Usage: dumpcap [options] ...

Capture interface:
  -i <interface>           name or idx of interface (def: first non-loopback)
  -f <capture filter>      packet filter in libpcap filter syntax
  -s <snaplen>             packet snapshot length (def: 65535)
  -p                       don't capture in promiscuous mode
  -B <buffer size>         size of kernel buffer (def: 1MB)
  -y <link type>           link layer type (def: first appropriate)
  -D                       print list of interfaces and exit
  -L                       print list of link-layer types of iface and exit
  -S                       print statistics for each interface once every second
  -M                       for -D, -L, and -S produce machine-readable output

Stop conditions:
  -c <packet count>        stop after n packets (def: infinite)
  -a <autostop cond.> ...  duration:NUM - stop after NUM seconds
                           filesize:NUM - stop this file after NUM KB
                              files:NUM - stop after NUM files
Output (files):
  -w <filename>            name of file to save (def: tempfile)
  -b <ringbuffer opt.> ... duration:NUM - switch to next file after NUM secs
                           filesize:NUM - switch to next file after NUM KB
                              files:NUM - ringbuffer: replace after NUM files
  -n                       use pcapng format instead of pcap
Miscellaneous:
  -q                       don't report packet capture counts
  -v                       print version information and exit
  -h                       display this help and exit

Example: dumpcap -i eth0 -a duration:60 -w output.pcap
"Capture network packets from interface eth0 until 60s passed into output.pcap"

Use Ctrl-C to stop capturing at any time.
      

Capturing with tcpdump for viewing with Wireshark

There are occasions when you want to capture packets using tcpdump rather than wireshark, especially when you want to do a remote capture and do not want the network load associated with running Wireshark remotely (not to mention all the X traffic polluting your capture).
However, the default tcpdump parameters result in a capture file where each packet is truncated, because most versions of tcpdump, will, by default, only capture the first 68 or 96 bytes of each packet.
To ensure that you capture complete packets, use the following command:

tcpdump -i <interface> -s 65535 -w <some-file>
      

You will have to specify the correct interface and the name of a file to save into. In addition, you will have to terminate the capture with ^C when you believe you have captured enough packets.

	Note!
	tcpdump is not part of the Wireshark distribution. You can get it from: http://www.tcpdump.org for various platforms.

Mediaroom Troubleshooting Tools: Client Trace Log Viewer

by Warren Johns

During my previous blog posts we have discussed what Microsoft Mediaroom is and some of its features which help differentiate it from standard television providers. In my next set of posts we’ll discuss some of the tools that Mediaroom support personnel can use to troubleshoot various aspects of the Mediaroom environment. Over the last couple of months, I’ve had occasion to work with a customer that is new to the Mediaroom environment, and the one tool that we are constantly using is called the Client Trace Log Viewer, so I figured it would be a great place to start our Mediaroom tools discussions.
Often times, we are asked to investigate why end user set top boxes (STBs) are not performing as expected; slow performance, missing guide information, VOD playback, etc. All of these issues are visible to the end users eye but are hard to quantify without any real data from the components themselves, this is where the Client Trace Log Viewer (CTL Viewer) comes into play. In the next couple of sections we’ll discuss CTLs features and how to configure, view, and filter the captured events.

Features

The CTL Viewer allows support personnel to gather real-time debugging information from any STB in the Mediaroom environment. We can easily enable CTL viewing on any specific STB we choose. This ability to drill down to individual devices is particularly useful as often times end users have multiple units. Once CTL viewing is enabled, it changes the logging state of the STB and tells the device to start collecting trace logging of the actions it performs and to pass this information to the Mediaroom servers. Nothing is physically connected to the STB nor is there any additional tracing software needed (all logging is implemented server-side). This means that the operator can have multiple sinks and filters running without fear of performance impact.

Configuring Client Trace Log Viewer

The first step is to configure the CTL Viewer (generally the executable will be located in the Mediaroom Resource Kit)

1. Run ClientTraceLogViewer.exe
2. Select Connection > Open Serverlayout
3. Navigate to the serverlayout.xml file (the path C:\Program Files\Microsoft IPTV Services\config\serverLayout.xml)

Enabling Logging

1. From the Menu bar, select Connection > Set Client Log State
2. You uniquely identify the STB using the external client ID. This information can found in the Branch SMT
3. Select the length of time for the STB to log
4. Click “Client Filter”. You can set up your filters based on the type of event as well as the severity of the event
5. Click OK twice. Now select the “Start Retrieving Events” icon. The STB will begin logging the events and push them forward to the server

6. To stop logging, select the “Stop Retrieving Events” icon from the Menu bar.
7. If you wish to save the events for future viewing, click the Save button from the Menu bar

Viewing Events

1. If you saved the events as per Step 7 above, they can be viewed as a text file. Otherwise you can use the CTL Viewer to review the events captured
2. Select Events > Retrieve Events
3. Ensure the information in the Connect dialog box is correct and select OK
4. If you wish to further filter the information, choose View > Options
5. Select the Filters tab, filter based upon your needs
6. In the CTL Viewer, all information in the left pane represents Web Service calls and TV2 events. The right pane is for logging message. If you select an individual message, the details will be presented Details pane in the bottom third of the viewer

Hopefully this overview gives you at least a basic understanding of the Client Trace Log Viewer and its usage. In the following months we’ll continue to investigate more troubleshooting tools and how they relate to Mediaroom. If you wish to learn more about the Mediaroom platform, please visit http://www.microsoft.com/Mediaroom/

Thansk to  Warren Johns from http://www.opsvault.com/mediaroom-troubleshooting-tools-client-trace-log-viewer/