rmedvedev / grpcdump Goto Github PK

protocol buffer descriptor set is a special type of protocol buffer message-it is contains a description of all message/grpc-service definitions compiled by protoc.

For users working with a bunch of .proto files, it's much more practical to supply grpc definitions with a single descriptoset file, instead of a directory of .proto files. And other grpc related tool like grpccurl is able to read grpc service definitions from a descriptor set file too, with a cli option --protoset.

@rmedvedev I will be happy to contribute a PR for this feature if you are ok with that.

FYI:

go run cmd/grpcdump/main.go

internal/app/packetprovider/ethernetprovider.go:12:11: undefined: pcapgo.EthernetHandle
internal/app/packetprovider/ethernetprovider.go:17:18: undefined: pcapgo.NewEthernetHandle

I realize this is not your fault; github.com/google/gopacket/pcapgo uses // +build linux,go1.9 directives. Maybe a note in the doc to save others from going down this route.

Here is the error message, it seems that line 84: stream.MetaHeaders[key] = value is the root casue.

[root@udp1 ~]# ./main -p 5700 -proto-path /root -proto-files ucore.proto
INFO[0000] Starting sniff ethernet packets at interface eth0 on port 5700
panic: assignment to entry in nil map

goroutine 52 [running]:
github.com/rmedvedev/grpcdump/internal/app/framereader.(*FrameReader).Read(0xc00011cef0, 0xc00012a080)
	/root/grpcdump/internal/app/framereader/framereader.go:84 +0x62d
github.com/rmedvedev/grpcdump/internal/app/httpparser.tryReadHttp2(0xc00012a080?, {0xc00011cdb0?, 0x4?}, 0x18614ac?, 0x0?)
	/root/grpcdump/internal/app/httpparser/httpparser.go:148 +0x86
github.com/rmedvedev/grpcdump/internal/app/httpparser.(*httpStream).run(0xc000112180)
	/root/grpcdump/internal/app/httpparser/httpparser.go:201 +0x81b
created by github.com/rmedvedev/grpcdump/internal/app/httpparser.(*httpStreamFactory).New
	/root/grpcdump/internal/app/httpparser/httpparser.go:60 +0x22a

So I'm about to fix it.

Hi, thanks for the nice tool. Is there an easy way to log the timestamps for packets alongside the rest of the information?

hi,

how can you use this Proto file? https://github.com/tensorflow/serving/blob/master/tensorflow_serving/apis/inference.proto

it includes multiple files. so can you tool use multiple files as well?

With the header grpc-status (usually happened when an application or runtime error occurs during an RPC), the frame will be marked as isTrailer = true in L77, and fall into condition branch in L82. But there is no guarantee that stream.MetaHeaders map in L84 has been initiated, and such carelessness would cause panic.

I was wondering if it's a good idea to add a flag -output-request-as-grpcurl, which will serve as the similar function to Chrome's copy as cURL.

I believe this may well help developers further more, but there is a concern about defying of Unix philosophy "Make each program do one thing well"...

For you reference, grpcurl is grpc's version of cURL, allowing us to send grpc requests from command line, and here's a typical use case:

grpcurl -plaintext  -proto rpc/gen/core.proto -d '{"name":"eru"}'   localhost:5001 pb.CoreRPC/GetPod

I looked into grpcdump -h but failed to figure out how to print messages after trying -log-level debug -assembly_debug_log, could you please share some insights?

What I want is just like tcpdump -A that prints every byte in ascii; since grpc uses structural messages instead of bytes I feel like capturing all messages.

hey there,
we're running grpcdump in a k8s sidecar (docker container) to sniff grpc traffic. it works well when we run the container as root, but we get FATA[0000] Error to create packet providercouldn't open packet socket: operation not permitted when trying to run grpcdump without root, only with CAP_NET_RAW and CAP_NET_ADMIN linux capabilities. (as for the linux ) according linux docs, the NET_RAW capability should allow sending raw packets.

would love to hear your opinion on this. would love to also contribute.. if you need help with gopacket etc.

cheers

Hi dear maintainer,
I launch grpcdump like this "./grpcdump -i vethwepl4d3ead1 -p 5678 -proto-files deploy.proto -proto-path /home/george/protodir/ -assembly_debug_log -json " , then launch a grpc client and invoke a grpc call ,but request/response can't dumped to the console,only print "waiting for start, storing into connection".

INFO[0000] Starting sniff ethernet packets at interface vethwepl4d3ead1 on port 5678
2023/01/19 09:33:42 ignoring useless packet
2023/01/19 09:33:42 ignoring useless packet
2023/01/19 09:33:43 ignoring useless packet
2023/01/19 09:33:43 ignoring useless packet
2023/01/19 09:33:43 ignoring useless packet
2023/01/19 09:33:43 ignoring useless packet
2023/01/19 09:33:46 [10.20.128.0->10.20.192.5 40607->5678] waiting for start, storing into connection
2023/01/19 09:33:46 ignoring useless packet
2023/01/19 09:33:46 [10.20.192.5->10.20.128.0 5678->40607] waiting for start, storing into connection
2023/01/19 09:33:46 [10.20.128.0->10.20.192.5 40607->5678] waiting for start, storing into connection
2023/01/19 09:33:46 [10.20.192.5->10.20.128.0 5678->40607] waiting for start, storing into connection
2023/01/19 09:33:46 [10.20.128.0->10.20.192.5 40607->5678] waiting for start, storing into connection
2023/01/19 09:33:46 ignoring useless packet
2023/01/19 09:33:57 ignoring useless packet
2023/01/19 09:33:57 ignoring useless packet
2023/01/19 09:33:58 ignoring useless packet
2023/01/19 09:33:58 ignoring useless packet
2023/01/19 09:33:58 ignoring useless packet
2023/01/19 09:33:58 ignoring useless packet

Hi,

Instead of sniffing from a port, can we sniff from a socket file used for grpc communication

Hi dear maintainer,
My experiment shows the following 2 cases:

1. launch grpcdump, then launch a grpc client and invoke a grpc call -> The request/response is dumped to the console.
2. launch a grpc client and invoking grpc calls(unary call) regularly, then launch grpcdump -> No request/response is dumped to the console.

so the question in this issue title arises. If the answer is negative, is it possible to support sniff established connections in the future?