On linux kernerl version 3.2.48.
As an udp server in kernel mod, skb_tail_pointer(skb) is not correct, it point the udp header tail, lossing the payload size. udphdr->len is right.
It is strange.
it is possible that tail and data pointer points to the same location. skb_tail_pointer() return the starting tail address.
Related
I am debugging OpenSSH code where it seems multiple channels have been allocated on single SSH session (single connected child server).
My queries could be naive here:
Under what conditions can multiple channels be opened?
What are the SSH message flows which lead to multiple channels? A message flow chart will be very helpful.
Is it correct to free channels[0] in the case below?
(gdb) p channels[0]
$1 = (Channel *) 0xb0f33e20
(gdb) p channels[0]->rfd
$2 = 0xd
(gdb) p channels[0]->efd
$3 = 0xffffffff
(gdb) p channels[0]->wfd
$4 = 0xffffffff
(gdb) p channels[1]->wfd
$5 = 0x9
(gdb) p channels[1]->efd
$6 = 0xffffffff
(gdb) p channels[1]->rfd
$7 = 0x9
Under what conditions can multiple channels be opened?
Every channel is either X11 forwarding, TCP port forwarding (there might be more types), UNIX domain socket forwarding (or ssh-agent socket) or MUX proxy. Consulting source code describing the types is a good start. They are opened, if the client requests them using command-line options (-X, -L, -R, -D, -A, ...) which are described in the manual page for ssh.
What are the SSH message flows which lead to multiple channels? A message flow chart will be very helpful.
If you will run the OpenSSH client and/or server in debug mode (LogLevel DEBUG3), you will get a lot of useful information what messages are being exchanged for various use cases.
Is it correct to free channels[0] in the case below?
Most probably not, but it is not clear what you ask here and what is the context. That is obviously valid channel with read file descriptor pointing to FD 0x0D so you might expect there will be something to read at some point.
I want to send UDP from Node Red to Pure Data. In NR, I have a UDP output node set to 127.0.0.1:3001 and a Pd netreceive object set to 3001 1 (the 1 sets the object to UDP rather than TCP). No message is received in the Pd patch.
To thicken the plot, a Node Red UDP output node set to 127.0.0.1:1881 does successfully send to Node Red UDP input node set to 1881. Also, a TCP object set to 127.0.0.1:3000 does connect with d netreceive object set to 3000, reported by the Pd console as "EOF on socket 12".
As the Node Red UDP output node is sending within the flow and Pd can report a TCP connection, I suspect there's something I have to do to format the message for PD. Any ideas?
netreceive expects messages to be FUDI-formatted. Basically, this means messages are terminated with a semicolon. Until a ';' is received, [netreceive] won't output anything.
Read more here: https://en.wikipedia.org/wiki/FUDI
Please check out my git repo for a solution.
https://github.com/sylatupa/Digital-Culture-Sound-Client/issues/1
Node Red was used to receive MQTT on particular topics.
I route the topics to the appropriate shell command that runs the locally installed pdsend executable.
I take the MQTT payload and pipe '|' two strings to the pdsend executable.
Left 3 is relieved by the execution of pdsend
The puredata patch receives and routes the 'Left 3' message
Node-Red is running on a raspberry pi, along side the mqtt broker.
I am testing with a MQTT client written in python.
See the github for the code and pure data patch, and maybe the node-red flow if that can be exported.
What is lacking is more complex messages, json encoded strings, and larger hierarchy topics, /pi/sensor1.
How should i go about reading value from TAR register in msp430. I wnat to see the values, like we have serial monitor to do so in Arduino. I know we do not have anything like that in msp(except energia of course).I am coding in CCS 5.5.0.
The registers for the MSP430 processors are defined in standard headers and can then just be accessed as variables, they are just memory locations after all. There is a gotcha with the TAR and TBR registers in that they can sometimes return an intermediate value if they are in the process of being updated as a clock count increments the register contents so I have always used the following code to guard against this problem.
uint16_t Timer_Value ;
Timer_Value = TAR ;
while ( Timer_Value != TAR )
{
Timer_Value = TAR ;
}
I am wondering that how to generate massive packet-in messages to the controller to test the response time of SDN controller in the environment of Mininet.
Can you give me some advice on it?
You could use iperf to send packets, like this:
$ iperf -c -F
You could specify the amount of time:
$IPERF_TIME (-t, --time)
The time in seconds to transmit for. Iperf normally works by repeatedly sending an array of len bytes for time seconds. Default is 10 seconds. See also the -l and -n options.
Here is a nice reference for iperf: https://iperf.fr/.
If you would like to use Scapy, try this:
from scapy.all import IP, TCP, send
data = "University of Network blah blah"
a = IP(dst="129.132.2.21")/TCP()/data
send(a)
I have a wireshark capture that contains an RTP multicast stream (plus some other incidental data).
Using a Tshark command like the following, I can produce a CSV of the RTP timestamp compared with the packet capture time:
tshark.exe -r "capture.pcap" -Eseparator=, -Tfields -e rtp.timestamp -e frame.time_epoch -d udp.port==5000,rtp
This decodes the UDP packets as RTP, and successfully prints out the two fields as expected.
Now, my question: The payload of the RTP stream is an MPEG2 Transport Stream, and I also want to print the PCR value (if there is one) alongside the packet and RTP timestamps.
In wireshark, I can see the PCR being decoded correctly, however using a command like the following:
tshark.exe -r "HBO HD CZ.pcap" -Eseparator=,-Tfields -e rtp.timestamp -e frame.time_epoch -e mp2t.af.pcr -d udp.port==5000,mp2t
...only prints out a "1" if there is a PCR oresent, not the actual value. I have also checked the .pcr_flag to confirm that these two are not exchanged, but still I see the same result.
The documentation seems to call mp2t.af.pcr a "Label", does this mean that Tshark is not able to use it as a field? Is there a way to generate a CSV with these values?
(What part of the documentation calls it a "Label"? That's a somewhat odd description of a named field.)
The problem is that the value that Wireshark displays after "base(XXX)*300 + ext(YYY)" is calculated and displayed, but the field itself isn't given an integral type and is instead given a type that doesn't have a value. Arguably, it should be an FT_UINT64 field and should be given a value, so that you can filter on it and can print the value in TShark.
Please file an enhancement request for this on the Wireshark Bugzilla.