search for: udpv4

...um:]-]+$ ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ (openvpn|ovpn-[._[:alnum:]-]+)\[[0-9]+\]:( ([-_.[:alnum:]]+/)?[.[:digit:]]{7,15}:[[:digit:]]{2,5})? (Local|Expected Remote) Options hash \(VER=V[34]\): '[[:xdigit:]]+'$ -^\w{3} [ :0-9]{11} [._[:alnum:]-]+ (openvpn|ovpn-[._[:alnum:]-]+)\[[0-9]+\]: UDPv4 link (local( \(bound\))?|remote): (\[undef\]|[._[:alnum:]-]+:[0-9]+)$ +^\w{3} [ :0-9]{11} [._[:alnum:]-]+ (openvpn|ovpn-[._[:alnum:]-]+)\[[0-9]+\]: UDPv4 link (local( \(bound\))?|remote): (\[undef\]|[._[:alnum:]-]+)(:[0-9]+)?$ ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ (openvpn|ovpn-[._[:alnum:]-]+)\[[0-9...

...time. This is the approach I'm going to try: 1) detecting the right NIC at pxe.c\net_parse_dhcp(void) (as you do) 2) saving its associated MAC address. 3) at main.c\efi_create_binding() (let's consider the UDP case) LibLocateHandle() returns the handles of the devices that publish a EFI UDPv4 Service Binding Protocol GUID. Each device with a published EFI UDPv4 Service Binding Protocol GUID supports the EFI UDPv4 Protocol and may be available for use. Considering a "Device Path Protocol" is attached to device handles then I think parsing the Path Protocol of each returned han...

...~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ All traffic including tunnel traffic enters and leaves eth0. Hence I assumed this would work, even if there is lots of tun virtual interfaces. But I get the following error as soon as I apply this rule. ~~~ Aug 19 13:51:44 gw openvpn[4996]: write UDPv4 []: No buffer space available (code=105) Aug 19 13:51:44 gw openvpn[5012]: write UDPv4 []: No buffer space available (code=105) Aug 19 13:51:44 gw openvpn[5012]: write UDPv4 []: No buffer space available (code=105) Aug 19 13:51:44 gw openvpn[3017]: write UDPv4 []: No buffer space available (cod...

...ch I'm going to try: > 1) detecting the right NIC at pxe.c\net_parse_dhcp(void) (as you do) > 2) saving its associated MAC address. > 3) at main.c\efi_create_binding() (let's consider the UDP case) > LibLocateHandle() returns the handles of the devices that publish a EFI > UDPv4 Service Binding Protocol GUID. Each device with a published EFI UDPv4 > Service Binding Protocol GUID supports the EFI UDPv4 Protocol and may be available for use. > Considering a "Device Path Protocol" is attached to device handles then > I think parsing the Path Protocol of eac...

...t; > > Signed-off-by: Ben Hutchings <ben at decadent.org.uk> > > Fixes: 916e4cf46d02 ("ipv6: reuse ip6_frag_id from ip6_ufo_append_data") > > > There's something I don't understand here. I see: > > NETIF_F_UFO_BIT, /* ... UDPv4 fragmentation */ > > this comment is wrong then? Yes. > The patches drastically regress performance for UDPv4 for VMs only, but > isn't it likely many other devices based their code on this comment? There's only one hardware driver that implements UFO (s2io), and it does han...

...t; > > Signed-off-by: Ben Hutchings <ben at decadent.org.uk> > > Fixes: 916e4cf46d02 ("ipv6: reuse ip6_frag_id from ip6_ufo_append_data") > > > There's something I don't understand here. I see: > > NETIF_F_UFO_BIT, /* ... UDPv4 fragmentation */ > > this comment is wrong then? Yes. > The patches drastically regress performance for UDPv4 for VMs only, but > isn't it likely many other devices based their code on this comment? There's only one hardware driver that implements UFO (s2io), and it does han...

...provided) p1377 (EFI_UDP4_PROTOCOL.Configure()) "With different parameters in UdpConfigData, Configure() can be used to bind this instance to specified port." covers the manual case. p1376 (EFI_UDP4_PROTOCOL.GetModeData()) "StationPort" "The port number to which this EFI UDPv4 Protocol instance is bound. If a client of the EFI UDPv4 Protocol does not care about the port number, set StationPort to zero. The EFI UDPv4 Protocol driver will assign a random port number to transmitted UDP packets. Ignored if AcceptAnyPort is set to TRUE." p1385 (EFI_UDP4_PROTOCOL.Transmi...

On Thu, Nov 28, 2013 at 9:47 PM, Gene Cumm <gene.cumm at gmail.com> wrote: > On Thu, Nov 28, 2013 at 9:34 PM, Celelibi <celelibi at gmail.com> wrote: >> Without an assigned source port, Transmit function assign a random new >> source port to the packet being sent. It thus have to be set before >> calling Transmit if the source port have already been decided.

...likely didn?t understand your comment. > This driver check is before creating the skb for the received packet. > So, purpose is to not even process the packet header or prepare the skb if it not an Ethernet frame. > > It is interesting to know when we get < 60B frame. If I recall, a UDPv4 frame can easily do it since Ethernet is 14B, IP header is 20, and UDP is only 8 so that only comes to 42B if I recall correctly. Similarly I think a TCPv4 Frame can be as small as 54B if you disable all the option headers. A quick and dirty test would be to run something like a netperf UDP_RR tes...

IPv6 does not allow fragmentation by routers, so there is no fragmentation ID in the fixed header. UFO for IPv6 requires the ID to be passed separately, but there is no provision for this in the virtio net protocol. Until recently our software implementation of UFO/IPv6 generated a new ID, but this was a bug. Now we will use ID=0 for any UFO/IPv6 packet passed through a tap, which is even

IPv6 does not allow fragmentation by routers, so there is no fragmentation ID in the fixed header. UFO for IPv6 requires the ID to be passed separately, but there is no provision for this in the virtio net protocol. Until recently our software implementation of UFO/IPv6 generated a new ID, but this was a bug. Now we will use ID=0 for any UFO/IPv6 packet passed through a tap, which is even

...560p) The only solution for these is to use our own stack (likely full TCP/IP like lwIP) and connect to the Net GUID (EFI_SIMPLE_NETWORK_PROTOCOL).? Does the handle for Pxebc contain a Net?? >>> It does contain a Net but there are 2 issues with SNP: 1) The interface is different than UDPv4/TCPv4 protocols; this imply lot of code. 2) SNP has its non-blocking transmit issues ; see "Flaws in the design" at https://wiki.linaro.org/LEG/Engineering/Kernel/UEFI/UEFI_Network_Driver >>> I found out that my EFI shell on VMware VMs can also handle output redirection like:...

...ta.AcceptBroadcast = TRUE; status = uefi_call_wrapper(udp->Configure, 2, udp, &udata); if (status != EFI_SUCCESS) @@ -50,6 +49,18 @@ int core_udp_open(struct pxe_pvt_inode *socket) socket->net.efi.binding = b; + /* + * Save the random local port number that the UDPv4 Protocol + * Driver picked for us. The TFTP protocol uses the local port + * number as the TID. + */ + status = uefi_call_wrapper(udp->GetModeData, 5, udp, + &udata, NULL, NULL, NULL); + if (status != EFI_SUCCESS) + Print(L"Failed to get UDP mode data: %d\n&qu...

I did change both instances of txdata->GatewayAddress, but I think something may be wrong in my toolchain. If I extract syslinux.zip and attempt to make from there (without modifying any files), the cached DHCP packet isn't read on the same subnet. I receive "Succeed to download NBP file." twice before anything from syslinux is loaded, so I believe the duplicate request for

...the first time we do > this. > > Signed-off-by: Ben Hutchings <ben at decadent.org.uk> > Fixes: 916e4cf46d02 ("ipv6: reuse ip6_frag_id from ip6_ufo_append_data") There's something I don't understand here. I see: NETIF_F_UFO_BIT, /* ... UDPv4 fragmentation */ this comment is wrong then? The patches drastically regress performance for UDPv4 for VMs only, but isn't it likely many other devices based their code on this comment? How about we disable UFO for IPv6 globally, and put the flag back in? We can then gradually add NETIF_F_UF...

...ping from each end to the other. However, after a time the pings in each direction fail. This happens after anything from two or three pings to a couple of thousand, and is seemingly a random interval, but once they fail they stay failed until some action is taken. At the same time I get "read UDPv4 [ECONNREFUSED]: Connection refused (code=111)" errors logged on server A. No errors are logged on server B. What is odd is that restarting Shorewall on server A allows the pings to succeed. I''m struggling to find a reason why this should fail after a few seconds/minutes. Shorewall i...

...EF:66 EB:0 ET:0 EL:0 ] Tue Aug 1 23:10:57 2006 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ] Tue Aug 1 23:10:57 2006 Local Options hash (VER=V4): '504e774e' Tue Aug 1 23:10:57 2006 Expected Remote Options hash (VER=V4): '14168603' Tue Aug 1 23:10:57 2006 UDPv4 link local: [undef] Tue Aug 1 23:10:57 2006 UDPv4 link remote: xx.xx.xx.xx:1194 --->> public ip address on pix firewall Tue Aug 1 23:11:21 2006 TLS: Initial packet from xx.xx.xx.xx:1194, ---->> public ip address on pix firewall sid=7c6f6585 62ec6b5f Tue Aug 1 23:11:21 2006 VERIFY O...

Hello Gene, thanks a lot for your patch! It doesn't work yet, but I have some more information. Before the patch, the boot sequence ended with the following: NBP file download successfully. Getting cached packet My IP is 0.0.0.0 After the patch it ended with the following (note that the IP is the same as the Station IP address): NBP file download successfully. LibLocateHandle returned

On Fri, Aug 28, 2015 at 03:34:12AM -0700, Patrick Masotta via Syslinux wrote: Derrick wrote: > > More importantly: look at the actual captured text.? It does NOT > > specify a valid MAC in its entirety and leaves off the leading nibble > > (11 characters, not 12).? Handle 267 shows "065F36E00EE" not "0065F36E00EE". > > I saw that, they might even be

...memcpy(&udata.RemoteAddress, &ip, sizeof(ip)); @@ -373,6 +376,21 @@ void core_udp_sendto(struct pxe_pvt_inode *socket, const void *data, /* Reset */ cb_status = -1; + /* + * If this is the first time sending a packet, save the random local + * port number that the UDPv4 Protocol Driver picked for us. The TFTP + * protocol uses the local port number as the TID, and it needs to + * be consistent across connect()/disconnect() calls. + */ + if (!socket->net.efi.localport) { + status = uefi_call_wrapper(udp->GetModeData, 5, udp, + &udata,...