[BUG] loopback is not working #1179
Comments
One thing for sure, there are
It should be possible to do that your self, using mDNS or LLMNR, and the Could you show two pieces of your code:
|
|
Hi @htibosch, thank to point the mistake on the mask for loopback. i implemented xApplicationDNSQueryHook_Multi(), but if i try to do a but ok, it is not my main pb here. Here is my init code (a little bit cleaned) what do you mean for the 2nd point ? here the code i use to send ping (from example) (again little bit cleaned) i checked the events received, |
|
Hello @htibosch I also see something strange in the TCP source.. but i see nowhere a loop or something similar to add the 4 frames... i continue to investiguate why 1st ping request is not sent |
|
Hi @rickou, Thank you. |
|
Hello @ActoryOu, @htibosch i understand that my pb is not linked to the loopback interface, but linked to the stack itself.. I understand, but that's mean all 1st ping for a target were lost ? In this case, how the application could be notified of this ? Another issue, seems to be linked: 2nd time, the resolution works as expected so, to summarize, each time a frame is sent to whatever ipaddress, that is not in the ARP table, will be dropped ?! I can't agree with this (bad) behavior, but do you know a way to handle this at application side ? |
|
related to my original post (loopback interface pb) It start just after boot. (the loopback interface MAC is 11:22:33:44:55:66, IP is 127.0.0.1/255.0.0.0) as you can see, the ARP table contains an entry, but with a strange MAC address.. (changing at each update) |
|
Hi @rickou, if( ( uxGetNumberOfFreeNetworkBuffers() >= 4U ) &&
( uxNumberOfBytesToSend >= 1U ) &&
( xEnoughSpace != pdFALSE ) )
{
// send a ping request
}The value #define SEND_ICMP_ONLY_WHEN_MINIMAL_N_BUFFERS_AVAILABLE 4 |
|
Hi @htibosch , Regarding the UDP packet replaced by ARP request, could it be possible to store the original UDP request waiting the ARP reply ? and then automatically send it after the reply ? ex: on the local network we want to ping a server by its name.. maybe i need to do ping in another way, but at this time i don't know how to do better. (i use an example) |
Only the number is called magic, not the algorithm.
Yes for sure! In fact we already have such a mechanism. Look at the identifier
I can imagine, it is. Sometimes it is handy to explicitly send an ARP request: /* Send an ARP request and wait 500 ms for an answer. */
BaseType_t xARPWaitResolution( FreeRTOS_inet_addr_quick( 192, 168, 2, 1 ), pdMS_TO_TICKS( 500U ) ) |
|
I just tested sending PING messages just after start-up. I am attaching a source file that contains my testing code which I used on an STM32F4. I have used these endpoints: It calls 'arp_ping_test()` two times, once to ping a loopback node, and once to ping my laptop. It does not find the correct MAC-address for the loopback interface. I will check that later. I think we'll need two changes; In source/portable/NetworkInterface/loopback/loopbackNetworkInterface.c around line 166: if( pxDescriptor != NULL )
{
IPStackEvent_t xRxEvent;
xRxEvent.eEventType = eNetworkRxEvent;
xRxEvent.pvData = ( void * ) pxDescriptor;
+
+ pxDescriptor->pxInterface = xLoopbackInterface;
+ pxDescriptor->pxEndPoint = FreeRTOS_MatchingEndpoint( xLoopbackInterface, pxDescriptor->pucEthernetBuffer );
- if( xSendEventStructToIPTask( &xRxEvent, 0u ) != pdTRUE )
+ if( ( pxDescriptor->pxEndPoint == NULL ) || ( xSendEventStructToIPTask( &xRxEvent, 0u ) != pdTRUE ) )
{
vReleaseNetworkBufferAndDescriptor( pxDescriptor );
iptraceETHERNET_RX_EVENT_LOST();
FreeRTOS_printf( ( "prvLoopback_Output: Can not queue return packet!\n" ) );
}
}In source/FreeRTOS_DNS_Callback.c near line 70 : vTaskSuspendAll();
{
for( pxIterator = ( const ListItem_t * ) listGET_NEXT( xEnd );
pxIterator != ( const ListItem_t * ) xEnd;
pxIterator = ( const ListItem_t * ) listGET_NEXT( pxIterator ) )
{
BaseType_t xMatching;
DNSCallback_t * pxCallback = ( ( DNSCallback_t * ) listGET_LIST_ITEM_OWNER( pxIterator ) );
#if ( ipconfigUSE_MDNS == 1 )
/* mDNS port 5353. */
- if( pxSet->usPortNumber == FreeRTOS_htons( ipMDNS_PORT ) )
+ if( pxSet->usPortNumber == ipMDNS_PORT )
{
/* In mDNS, the query ID field is ignored and the
* hostname will be compared with outstanding requests. */But as said, I will come back to this. |
|
Thank you @htibosch for your testing ! Do I (or you?) need to change the post subject ? (not only related to loopback now..) At my side, i added the coreSNTP lib to my project..
for the 2nd step, i suspect it is also linked to the UDP packet replacement.. but i need to check deeply what's happen. |
|
Calling this: /* Send an ARP request and wait 500 ms for an answer. */
uint32_t uxGateWay = xxx;
BaseType_t xARPWaitResolution( uxGateWay ), pdMS_TO_TICKS( 500U ) )should make it a bit faster because the gateway has been resolved.
No problem. Other people might google for the exact title: "loopback not working" and find answers here. The last time I tested, UDP and TCP worked well with the loopback interface. But today I saw that ARP is not working in a transparent way. This will stop it: else if( ( ipFIRST_LOOPBACK_IPv4 <= ( FreeRTOS_ntohl( ulSenderProtocolAddress ) ) ) &&
( ( FreeRTOS_ntohl( ulSenderProtocolAddress ) ) < ipLAST_LOOPBACK_IPv4 ) )
{
/* The local loopback addresses must never appear outside a host. See RFC 1122
* section 3.2.1.3. */
iptraceDROPPED_INVALID_ARP_PACKET( pxARPHeader );
}Beside that, when ARP receives a packet from 127.0.0.1 to 127.0.0.1, it will decide that this is an IP collision. I rather think of resolve loopback addresses in the same way as we do multicast addresses. See the call to pxEndPoint = FreeRTOS_FindEndPointOnIP_IPv4( ulAddressToLookup, 0 );
if( xIsIPv4Loopback( ulAddressToLookup ) != 0 )
{
if( pxEndPoint != NULL )
{
/* For multi-cast, use the first IPv4 end-point. */
memcpy( pxMACAddress->ucBytes, pxEndPoint->xMACAddress.ucBytes, sizeof( pxMACAddress->ucBytes ) );
*( ppxEndPoint ) = pxEndPoint;
eReturn = eARPCacheHit;
//FreeRTOS_printf( ( "eARPGetCacheEntry: loopback found\n" ) );
}
} |
|
OK, all loopback problems seem to be solved. I will attach a ZIP file with these 2 files:
You can apply the patch with: If it works for you too, we can turn it into a pull request. |
|
Hello @htibosch Thank for the patch, but it fail applying to the LTS version I checked manually, but the file FreeRTOS_ARP.c is very different as the one expected in your patch.. |
|
Here are the adapted sources: source_v4.2.2_with_patch.zip These sources files have changed:
Will that work? When I have a commercial project, I also use the latest LTS release. For my Open Source work, I must use today's main branch. |
|
Yes it works ! thank for this patch. |
|
Just seen another strange behavior, if i ping my own IP (using a normal interface), i never get a reply.. even if i made multiple tries.
for me the correct behavior should be to get an ping reply even for our own IP address |
|
When you ping The IP-task will recognise the ICMP packet, and send an answer back to the IP task, also through an We just saw that it works, and fast! Now if you send a ping message to your local-LAN IP address, say Suppose we do know the MAC-address, which is stored in the endpoint, we still won't get a reply. For the sake of simplicity, I would recommend to leave it this way. |
Hum, I do not understand why we can't get a ping reply.. but ok, it is not important, just for me it is not a correct behavior. |
In short: the costs will be higher than the profits. We want to keep the +TCP library as clear and clean as possible. When you turn each end-point into a possible peer, every endpoint will become a sort of "loopback device". You don't want to change the NetworkInterface for this, because that would imply that all interfaces much be adapted. I do not see a simple way to do this. It would give a lot of work, and also we'd have to be aware of potential security risks. All protocol tests (compliance to RFC) and all unit-testing will need a new round of changes. |
Describe the bug
i can't get the loopback interface to work at all.
I'm starting implementing the FreeRTOS+TCP to my project. Because i need to write my own interface for ENC424J600, before i would like to do some tests using the provided loopback interface.
I setup the loopback interface with IP 127.0.0.1/255.255.255.255
and try to send ping to 127.0.0.1 (it seems, it is not possible to resolve "localhost")
packet is send to the interface and it is put directly on the RxQueue by the interface.
but at the RxEvent, the packet is dropped because pxNetworkBuffer->pxInterface == NULL (in prvProcessEthernetPacket)
i'm using the ip stack v4.2.2
i'm not sure it is a bug, maybe only a mis-use..
The text was updated successfully, but these errors were encountered: