[RFC] Proposed changes to broadcast usage

37 views
Skip to first unread message

Dan Smith

unread,
Jun 20, 2011, 5:46:46 PM6/20/11
to fd...@googlegroups.com
Hi all,

I'm planning to use FDLog this field day. I'm glad I found it recently
because it's definitely more well-behaved than other solutions and being
cross-platform makes it a winner. Python is just icing on the cake :)

We'll have a mixed Windows and Linux environment. As several people have
noted, the current FDLog code has some issues (maybe, quirks) when
running on Linux. I set out to tweak the code to account for these and I
think I made it more universally plug-n-play along the way.

First, on Linux you had to find the IP on the network you're using and
change your /etc/hosts' entry for your hostname to match. I believe that
this could also hang up Windows users if they had more than one
interface active in the field.

Second, on any 10. network, a class-A broadcast address is assumed. The
default network that NetworkManager (in Linux) creates for an Ad-Hoc
setup is a class-C chunk of 10., which resulted in breakage.

My changes make the receive socket bound on 0.0.0.0 so that packets from
any interface are received. I also changed the code to use the global
broadcast address of 255.255.255.255 instead of attempting to calculate
the proper one for the network in use, which is error-prone and
platform-specific. Finally, I made receiving stations use the actual
source address of a packet as the remote node address instead of
requiring the sender to know and embed the proper address. This should
improve the "just works" nature by ensuring that the address used is the
one by which packets were actually received previously.

I didn't entirely remove the "my_addr" bit, but rather marked it as
"(unused)" since this is just an RFC. I believe, however, that if this
approach is liked, that we could remove that part entirely.

I tested this with two stations, one on Linux and one on Windows. I
haven't used the time sync functionality yet, but as far as I can tell,
all the other network communication works as designed, and on any
network configuration I can throw at it.

The patch is generated on top of 1.147 and is in UNIX EOL format. I have
been keeping my changes in a mercurial tree, which I posted here if
anyone is interested in the fine-grained changes:

http://d-rats.com/hg/hgwebdir.cgi/fdlog.hg

Comments and test reports would be appreciated. Thanks!

--
Dan Smith
www.danplanet.com
KK7DS

kk7ds_changes.patch

Alan Biocca

unread,
Jun 20, 2011, 7:12:19 PM6/20/11
to fd...@googlegroups.com
This sounds really good, Dan.

-- Alan

Blair Shock

unread,
Jun 24, 2011, 8:47:22 PM6/24/11
to FDLog
Dan,

Our group has been using this software for several years. We always
have one or two running linux. We will throw everything at it and see
how it flys!

Blair
KD0AFL

Dan Smith

unread,
Jun 27, 2011, 10:36:55 AM6/27/11
to fd...@googlegroups.com
> Our group has been using this software for several years. We always
> have one or two running linux. We will throw everything at it and see
> how it flys!

Cool, we used it (with my changes) this weekend with great success. One
Linux toughbook and one Windows netbook on an Ad-Hoc wifi network.

Great stuff!

Blair Shock

unread,
Jun 29, 2011, 10:20:35 PM6/29/11
to HS-FDLog
We did as well. We used a mobile hotspot as an access point. It worked
flawlessly.

Blair
Reply all
Reply to author
Forward
0 new messages