qwantic

Thanks, yes. I just realized I was misinterpreting what the subnet mask is actually there for. It's not supposed to filter out source ips that don't match the masked IP4!

Hi, I noticed that if I set a static IP4 address for FNET, say 192.168.2.1, with a subnetmask of 255.255.255.0, I still receive data from ip addresses with a different 3rd ip address octet like 192.168.5.6. Looking through the code, I don't see where the subnet mask comes into play for incoming frames (I was looking especially in fnet_ip_input_low() where it seems the check would be if anywhere). Just wondering what you thought, or if I missed something. thanks!

Hi, I was wondering about the feasibilty of adding DHCPv6 client support to FNET. Was Abhilash's code useful for DHCPv6? Or are there any other plans to add this at some point? thanks

Hi, I have done a bit more testing. If I add the linger option and set it to 0 for the socket than everything works fine. I didn't realize that a socket could linger, so that's what threw me off. I was running into a socket_conflict with the lingering socket. thanks for your help.

Hi Andrey, I think may have found a slight issue with the fnet stack: Basically, once the last tcp socket is removed via fnet_socket_close(), the head pointer in the tcp item in the fnet_prot_if_list[] (fnet_tcp_prot_if), doesn't get reset to 0. It still points to the last fnet_socket_if_t. This causes issues in my test where I add a tcp socket, remove it, and then add one again. (because the socket prev points to a non-existent socket that was saved in the fnet_tcp_prot_if head pointer). In my tests...

Great, thanks!

OK, thanks Andrey. I will try to not send large packets. I am just writing some general tests at the moment. One other thing I noticed is that the reassembly of fragments in the function fnet_ip_reassembly() can fail if the incoming fragment packets are out of order. Just FYI. thanks

Hi, I'm doing a simple test by creating a raw socket and sending an ip packet large enough to be fragmented. For argument's sake it's a 4000 byte packet that gets split into 3x fragments (MTU 1500). If the destination mac address is not in the arp cache, then what seems to happen is the fnet stack sends out an arp request for each fragment. Then, when the arp response finally comes in, only the last fragment is sent out. Obviously, if prior to sending out the large packet, a smaller packet was sent...