[OpenWrt-Devel] UDAP-Protocol Broadcast-Handling with Relayd

Dierk Modrow dkmod01 at hotmail.com
Fri Jan 30 05:42:51 EST 2015




	
	
	
	


I try to implement an UDAP
configuration server (legacy protocol to replace an old embedded
wireless client bridge) for a wireless client bridge based on a
Gateworks Ventana board running OpenWrt trunk with ATH9K WLAN nic.
The Openwrt solution uses relayd for
pseudo bridging between WLAN and LAN because true transparent
bridging between WLAN (in infrastructure mode) and ethernet interface
is only possible with 4 address mode of MAC80211 which is not
standardized in IEEE802.11 (can only be used with certain access
points)



Problem is now emulating a real
bridging behaviour for incoming broadcasts with destination port of
UDAP protocol. The server should respond with bridge's own source IP
to global broadcast address on both interfaces LAN & WLAN. For
the relayd solution this should be the WLAN interface's IP.



IP settings: Wlan0 has
192.168.2.100/24, eth0 has 192.168.254.254/24



Short description:
The UDAP protocol uses UDP frames
	with server destination port 17784.
	The UDAP client can send frames to
	IP address of the server. Reply is done with unicast frame
	The UDAP client can send frames to
	general broadcast address (255.255.255.255). The server should also
	reply to the general broadcast address. So UDAP protocol can also be
	used to scan a client bridge or change it's IP configuration if it's
	IP resides in another subnet then the UDAP client.
	UDAP client (a Windows PC, PLC,
	etc.) may reside either on the LAN or the WLAN side of the bridge.
	On both sides only one Wlan0-IP should be visible.




Results of my test implementation of
UDAP on OpenWRT using a simple AFINET UDP socket:



Using the IP unicast destination
	address of the server IP-Wlan0 works fine for both UDAP client
	locations (LAN / WLAN)
	Sending to general broadcast
	server address from WLAN side ->request is received but reply to
	global broadcast address by calling sendto is denied with
	ENETUNREACH.
Reply to the broadcast address 192.168.2.255 worked
	fine but violates requirement 3.
Next trial was using setsockopt
	with option SOL_SOCKET,SO_BINDTODEVICE to temporarily bind to wlan0
	interface before sendto to general broadcast address → This worked
	fine
	Sending to general broadcast
	server address from LAN side ->request is received but reply to
	global broadcast address by calling sendto is denied with
	ENETUNREACH.
Reply to the broadcast address 192.168.254.255
	worked fine but violates requirement 3.
Next trial was using
	setsockopt with option SOL_SOCKET,SO_BINDTODEVICE to temporarily
	bind to eth0 interface before sendto to general broadcast address →
	This worked but the source address of the response frame is
	192.168.254.254 (eth0's IP). Therefore the UDAP client on LAN side
	sees another IP address than a UDAP client on WLAN side.
Next I
	tried to source NAT with iptables to transform the source address to
	wlan0's IP:

iptables -t nat -A POSTROUTING -p udp –sport
	17784 -o eth0 -s 192.168.254.254 -j SNAT –to-source 192.168.2.100 
	




The source address is changed but
	unfortunately the source port of the frame was changed to 1024, then
	I changed the switch –to-source 192.168.2.100:17784 → No source
	natting occurred!  Is there any chance to configure iptables to only
	change the source IP and keeping the UDP source port?


	
So I have no idea howto achieve the
desired behaviour. Any help is appreciated!!
Regards,Dierk


 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20150130/2f61e40a/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


More information about the openwrt-devel mailing list