Root (admin) vs Regular user and packet socket

Using Aravis
1

Hi all,

I am running aravis using the Arch AUR (AUR (en) - aravis), which is 0.8.31. I am finding that if I run as root, packet socket is enabled, including a call to set_socket_filter, and I can receive camera data.

[15:41:32.062] 🅸 device> [GvDevice::auto_packet_size] Current packet size check successfull (1400 bytes)
[15:41:32.067] 🅸 stream> [GvStream::stream_new] Stream channel = 0
[15:41:32.069] 🅸 stream> [GvStream::stream_new] Packet size = 1400 byte(s)
[15:41:32.073] 🅸 stream> [GvStream::stream_new] Destination stream port = 39261
[15:41:32.073] 🅸 stream> [GvStream::stream_new] Source stream port = 49153
[15:41:32.114] 🅸 stream> [GvStream::loop] Packet socket method
[15:41:32.224] 🅸 stream-thread> [GvStream::set_socket_filter] source ip = 0xc0a80651 - port = 49153 - dest ip = 0xc0a80650 - port 39261
[15:41:32.900] 🅳 device> [GvDevice::Heartbeat] Ack value = 2
[15:41:33.901] 🅳 device> [GvDevice::Heartbeat] Ack value = 2

As a user with no special privileges, I’m seeing the standard socket method, but never actual receiving data.

[15:41:07.472] 🅸 device> [GvDevice::auto_packet_size] Current packet size check successfull (1400 bytes)
[15:41:07.476] 🅸 stream> [GvStream::stream_new] Stream channel = 0
[15:41:07.479] 🅸 stream> [GvStream::stream_new] Packet size = 1400 byte(s)
[15:41:07.483] 🅸 stream> [GvStream::stream_new] Destination stream port = 56308
[15:41:07.483] 🅸 stream> [GvStream::stream_new] Source stream port = 49153
[15:41:07.483] 🅸 stream> [GvStream::loop] Standard socket method
[15:41:08.301] 🅳 device> [GvDevice::Heartbeat] Ack value = 2

This is on top of neither method finding the increased MTU size for the interface (9014). I’d love some idea on how to explain this, or if I just need a user that has security rights to install filters.

Thanks!

2

Hi,

Could you attach the streaming statistics obtained by setting ARV_DEBUG=all when running your test ?

Emmanuel.

3

I’m now getting camera data with both methods, so I am assuming I had something else wrong there. But neither is picking up MTU changes, either way. The statistics look good on everything right now.

I am not sure if I should just call this issue cleaned up for now, or instead say that I should further debug the MTU issue.

Apologies for not coming back around to this and updating it as (generally) working

4

Thanks for the follow up.

Cheers,

Emmanuel.