search for: datagrams

...VMCI_SUCCESS; + } + +exit: + return retval; +} + +/** + * vmci_datagram_create_handle_priv() - Create host context datagram endpoint + * @resource_id: The resource ID. + * @flags: Datagram Flags. + * @priv_flags: Privilege Flags. + * @recv_cb: Callback when receiving datagrams. + * @client_data: Pointer for a datagram_entry struct + * @out_handle: vmci_handle that is populated as a result of this function. + * + * Creates a host context datagram endpoint and returns a handle to it. + */ +int vmci_datagram_create_handle_priv(u32 resource_id, +...

...VMCI_SUCCESS; + } + +exit: + return retval; +} + +/** + * vmci_datagram_create_handle_priv() - Create host context datagram endpoint + * @resource_id: The resource ID. + * @flags: Datagram Flags. + * @priv_flags: Privilege Flags. + * @recv_cb: Callback when receiving datagrams. + * @client_data: Pointer for a datagram_entry struct + * @out_handle: vmci_handle that is populated as a result of this function. + * + * Creates a host context datagram endpoint and returns a handle to it. + */ +int vmci_datagram_create_handle_priv(u32 resource_id, +...

On Sat, Sep 02, 2023 at 04:56:42AM +0000, Bobby Eshleman wrote: > On Fri, Sep 01, 2023 at 02:45:14PM +0200, Stefano Garzarella wrote: > > On Tue, Aug 29, 2023 at 09:29:45PM +0000, Bobby Eshleman wrote: > > > This adds support for datagrams to the virtio-vsock device. > > > > > > virtio-vsock already supports stream and seqpacket types. The existing > > > message types and header fields are extended to support datagrams. > > > Semantic differences between the flow types are stated, as well as any &...

On Sat, Sep 02, 2023 at 04:56:42AM +0000, Bobby Eshleman wrote: > On Fri, Sep 01, 2023 at 02:45:14PM +0200, Stefano Garzarella wrote: > > On Tue, Aug 29, 2023 at 09:29:45PM +0000, Bobby Eshleman wrote: > > > This adds support for datagrams to the virtio-vsock device. > > > > > > virtio-vsock already supports stream and seqpacket types. The existing > > > message types and header fields are extended to support datagrams. > > > Semantic differences between the flow types are stated, as well as any &...

...rkin wrote: > > On Wed, Aug 30, 2023 at 12:43:03AM +0000, Bobby Eshleman wrote: > > > On Tue, Aug 29, 2023 at 06:21:35PM -0400, Michael S. Tsirkin wrote: > > > > On Tue, Aug 29, 2023 at 09:29:45PM +0000, Bobby Eshleman wrote: > > > > > This adds support for datagrams to the virtio-vsock device. > > > > > > > > > > virtio-vsock already supports stream and seqpacket types. The existing > > > > > message types and header fields are extended to support datagrams. > > > > > Semantic differences between the...

...rkin wrote: > > On Wed, Aug 30, 2023 at 12:43:03AM +0000, Bobby Eshleman wrote: > > > On Tue, Aug 29, 2023 at 06:21:35PM -0400, Michael S. Tsirkin wrote: > > > > On Tue, Aug 29, 2023 at 09:29:45PM +0000, Bobby Eshleman wrote: > > > > > This adds support for datagrams to the virtio-vsock device. > > > > > > > > > > virtio-vsock already supports stream and seqpacket types. The existing > > > > > message types and header fields are extended to support datagrams. > > > > > Semantic differences between the...

...Aug 30, 2023 at 12:43:03AM +0000, Bobby Eshleman wrote: > > > > > On Tue, Aug 29, 2023 at 06:21:35PM -0400, Michael S. Tsirkin wrote: > > > > > > On Tue, Aug 29, 2023 at 09:29:45PM +0000, Bobby Eshleman wrote: > > > > > > > This adds support for datagrams to the virtio-vsock device. > > > > > > > > > > > > > > virtio-vsock already supports stream and seqpacket types. The existing > > > > > > > message types and header fields are extended to support datagrams. > > > > > &g...

Aug 6 11:21:44 linux nmbd[2193]: [2014/08/06 11:21:44.614859, 0] ../source3/nmbd/nmbd_packets.c:1174(process_lanman_packet) Aug 6 11:21:44 linux nmbd[2193]: process_lanman_packet: Discarding datagram from IP 192.168.1.6. Source name LINUX<00> is one of our names ! Aug 6 11:22:50 linux nmbd[2193]: [2014/08/06 11:22:50.279516, 0]

Hi I have a bunch of FreeNAS servers and a TrueNAS HA server all spamming the logs with these messages every minute about their own source name (examples below). These boxes are on two physically separate networks, and I find it unlikely both networks should have some sort of undetected loop. Any ideas on how to debug this? Samba version is 4.1.18. FreeNAS box on network A " Jan 5

There appears to be a problem with sending 0-length (UDP) datagrams. I have a little UDP server running on port 1392, and when I execute the following client code the server does not receive anything. However if I change it to data="x", the server receives it just fine. EM::run { conn = EM::open_datagram_socket( "", 0 ) data = "&...

Hi, Looking at some udp stuff on snv_57, and I noticed that mib:::udpInDatagrams no longer exists, has this been superceded by mib:::udpHCInDatagrams? From my understanding they represent the same counter, but I''m asking in case this is a bug. I noticed that there is still a reference to udpInDatagrams in the DTrace testsuite. - Fintan

I'm trying to get Samba up and running and having a terrible time. It says that I should be able to run nmap and see that 137 and 139 are open - which they are not. I have not added any restrictions in smb.conf, do not have a firewall running and I have increased the log level to 5 to see all of the messages. It says that it is talking on 137 but it kind of looks like it's not talking

On Tue, Jan 05, 2016 at 11:48:32PM +0100, Torkil Svensgaard wrote: > Hi > > I have a bunch of FreeNAS servers and a TrueNAS HA server all > spamming the logs with these messages every minute about their own > source name (examples below). > > These boxes are on two physically separate networks, and I find it > unlikely both networks should have some sort of undetected

Hello All, I have recently switched back over from using the MySQL backend to the standard smbpasswd file in an effort to make our implementation of Samba better.\ I am still having a great problem with getting messages from the nmbd daemon saying that ------------------------ [2005/09/10 14:53:43, 0] nmbd/nmbd_packets.c:process_browse_packet(1050) process_browse_packet: Discarding

Hi, after quite some testing I do now have my Samba4 setup in production use. The setup mainly consists of an AD-Controller and an AD Member Server which provides file shares to about 20 Windows 7 clients. Everything is working well so far except for two somewhat 'special' clients. For these I observe the following: 1) On the AD Member Server periodically (every hour) appears a message in

Ensure that the size filled in by userland in the datagram header matches the size of the buffer passed down in the IOCTL. Note that we account for the size of the header itself in the check. Acked-by: Jorgen Hansen <jhansen at vmware.com> Acked-by: Aditya Sarwade <asarwade at vmware.com> Signed-off-by: Andy King <acking at vmware.com> Reported-by: David Ramos <daramos at

Ensure that the size filled in by userland in the datagram header matches the size of the buffer passed down in the IOCTL. Note that we account for the size of the header itself in the check. Acked-by: Jorgen Hansen <jhansen at vmware.com> Acked-by: Aditya Sarwade <asarwade at vmware.com> Signed-off-by: Andy King <acking at vmware.com> Reported-by: David Ramos <daramos at

On 01/06/2016 01:23 AM, Jeremy Allison wrote: >> Jan 5 23:17:32 storage4 nmbd[34068]: [2016/01/05 23:17:32.086480, >> 0] ../source3/nmbd/nmbd_packets.c:1174(process_lanman_packet) >> Jan 5 23:17:32 storage4 nmbd[34068]: process_lanman_packet: >> Discarding datagram from IP 172.21.140.17. Source name STORAGE4<00> >> is one of our names ! >> " >

Hi guys, I'm having a little problem I would ask your help. I have followed the log of my samba (log.nmbd) and several times I see the message: process_dgram: ignoring malformed3 (datasize = X, len = Y, off = Z) datagram packet sent to name DOMAIN <00> from IP XXX,XXX,XXX,XXX Is there any way to fix this problem? I'm using Samba 3.5.6 integrated with LDAP server on a Debian

I am utilizing an openssh tunnel between two Linux boxes. On the client box I issue the following commands to set up the tunnel; - ssh -w0:0 root at x.x.x.x -v where x.x.x.x is the IP address of the Linux system running sshd - ip addr add 10.0.5.1/32 peer 10.0.5.2 dev tun0 - ip link set tun0 up On the box running sshd I issue the following commands: - ip addr add 10.0.5.2/32 peer 10.0.5.1 dev