| 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 <2022> 2023 2024 2025 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 <2022> 2023 2024 2025 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: Recsync: RecCeiver Server announcement contains Broadcast address instead of server ip address |
| From: | Michael Davidsaver via Tech-talk <tech-talk at aps.anl.gov> |
| To: | Heinz Junkes <junkes at fhi-berlin.mpg.de> |
| Cc: | EPICS Tech Talk <tech-talk at aps.anl.gov> |
| Date: | Sat, 23 Apr 2022 11:57:13 -0700 |
On 4/23/22 11:17, Heinz Junkes wrote:
Unfortunately, I don't understand it. If one would stick to the intended protocol, then wouldn't it work to simply route the packet content with the server address in it into the subnet?
Yes. As long as there is a reverse route for the IP source address.
Why is the server IP address not entered in the announcement server but '\xff\xff\xff\xff'?
Preferring the source address field in the IP header works better in the presence of a firewall/router doing NAT. ...
if(ntohl(buf->serverIP)==0xffffffff) {
/* direct from the source */
self->nameserv.ia.sin_addr = peer->ia.sin_addr;
} else {
/* proxied */
self->nameserv.ia.sin_addr.s_addr = buf->serverIP;
}
... This is the logic.