[Olsr-users] Multi-hop Pinging
akshay mithyantha
(spam-protected)
Wed Dec 10 15:03:45 CET 2014
Thanks,
I'll try it and update later..
On Wed, Dec 10, 2014 at 7:27 PM, Henning Rogge <(spam-protected)> wrote:
> Hi,
>
> the configuration looks okay...
>
> can you validate three things for me?
>
> 1.) the running olsrd programs send out UDP packets on port 698 (validate
> with tcpdump).
> 2.) you can see incoming UDP packets from your neighbors (validate with
> tcpdump)
> 3.) there is no firewall in place (ebtables/iptables) to block these
> packets from reaching olsrd
>
> Henning
>
>
>
> On Wed, Dec 10, 2014 at 2:31 PM, akshay mithyantha <
> (spam-protected)> wrote:
>
>> Hello,
>> Sorry for late reply.. Here is the olsrd configuration file..
>>
>> OLSR.org routing daemon config file
>>
>>
>>
>> #
>>
>>
>>
>> # Lines starting with a # are discarded
>>
>>
>>
>> #
>>
>>
>>
>>
>>
>>
>>
>> # Debug level(0-9)
>>
>>
>>
>> # If set to 0 the daemon runs in the background
>>
>>
>>
>>
>>
>>
>>
>> DebugLevel 1
>>
>>
>>
>>
>>
>>
>>
>> # IP version to use (4 or 6)
>>
>>
>>
>>
>>
>>
>>
>> IpVersion 4
>>
>>
>>
>>
>>
>>
>>
>> # FIBMetric ("flat", "correct", or "approx")
>>
>>
>>
>> # Just use "flat", the others don't work very well
>>
>>
>>
>>
>>
>>
>>
>> # FIBMetric "flat"
>>
>>
>>
>>
>>
>>
>>
>> # Clear the screen each time the internal state changes
>>
>>
>>
>>
>>
>>
>>
>> # ClearScreen yes
>>
>>
>>
>> # HNA IPv4 routes
>>
>>
>>
>> # syntax: netaddr netmask
>>
>>
>>
>> # Example Internet gateway:
>>
>>
>>
>> # 0.0.0.0 0.0.0.0
>>
>>
>>
>>
>>
>>
>>
>> Hna4
>>
>>
>>
>> {
>>
>>
>>
>> # Internet gateway
>>
>>
>>
>> # 0.0.0.0 0.0.0.0
>>
>>
>>
>>
>>
>>
>>
>> # specific small networks reachable through this node
>>
>>
>>
>> # 15.15.0.0 255.255.255.0
>>
>>
>>
>> # 15.16.0.0 255.255.255.0
>>
>>
>>
>> }
>>
>>
>>
>>
>>
>>
>>
>> # HNA IPv6 routes
>>
>>
>>
>> # syntax: netaddr prefix
>>
>>
>>
>> # Example Internet gateway:
>>
>>
>>
>> #Hna6
>>
>>
>>
>> #{
>>
>>
>>
>> # Internet gateway
>>
>>
>>
>> # :: 0
>>
>>
>>
>>
>>
>>
>>
>> # specific small networks reachable through this node
>>
>>
>>
>> # fec0:2200:106:0:0:0:0:0 48
>>
>>
>>
>> #}
>>
>>
>>
>>
>>
>>
>>
>> # Specify the routing Table olsr uses
>>
>>
>>
>> # currently only implemented in linux versions, (bsd planned)
>>
>>
>>
>> # useful for policyrouting, to ensure that olsr can use
>>
>>
>>
>> # the table a policy rule with priority 65536 is auto-installed
>>
>>
>>
>> # by olsrd if an value < 253 ist specified!
>>
>>
>>
>> # value defaults to 253 (main table)
>>
>>
>>
>> # valid values are 1 .. 254
>>
>>
>>
>> # (freifunkfirmware uses 111 for its policy routing)
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> #you may specify another table for the default route only
>>
>>
>>
>> #if used no policy route will get auto-installed for this table,
>>
>>
>>
>> #but the default route gets also inserted into table 254
>>
>>
>>
>> #(the last table used in default linux policy routing)
>>
>>
>>
>> #valid tables are the same as for RtTable
>>
>>
>>
>>
>>
>>
>>
>>
>> # Specify the proto tag to be used for routes olsr inserts into kernel
>>
>>
>>
>> # currently only implemented for linux, defaults to 0 which gets replaced
>>
>>
>>
>> # by an OS-specific default value under linux 3 (BOOT) gets used as
>> default
>>
>>
>>
>> # (for backward compatibility)
>>
>>
>>
>> # valid values under linux are 1 .. 254
>>
>>
>>
>> # 1 gets remapped by olsrd to 0 UNSPECIFIED (1 is reserved for ICMP
>> redirects)
>>
>>
>>
>> # 2 KERNEL routes (not very wise to use)
>>
>>
>>
>> # 3 BOOT (should in fact not be used by routing daemons)
>>
>>
>>
>> # 4 STATIC
>>
>>
>>
>> # 8 .. 15 various routing daemons (gated, zebra, bird, & co)
>>
>>
>>
>>
>>
>>
>>
>> # RtProto 0
>>
>>
>>
>>
>>
>>
>>
>> # For testing purposes it may be nice to use another port for olsrd
>>
>>
>>
>> # for using another port than the IANA assigned one
>>
>>
>>
>> # for a production network, there should be a good reason!!
>>
>>
>>
>> # defaults to 698 (IANA assigned olsr-port)
>>
>>
>>
>> # valid values are 698 or > 1000
>>
>>
>>
>>
>>
>>
>>
>> # OlsrPort 698
>>
>>
>>
>>
>>
>>
>>
>> # Should olsrd keep on running even if there are
>>
>>
>>
>> # no interfaces available? This is a good idea
>>
>>
>>
>> # for a PCMCIA/USB hotswap environment.
>>
>>
>>
>> # "yes" OR "no"
>>
>>
>>
>>
>>
>>
>>
>> # AllowNoInt yes
>>
>>
>>
>>
>>
>>
>>
>> # TOS(type of service) value for
>>
>>
>>
>> # the IP header of control traffic.
>>
>>
>>
>> # If not set it will default to 16
>>
>>
>>
>>
>>
>>
>>
>> #TosValue 16
>>
>>
>>
>>
>>
>>
>>
>> # The fixed willingness to use(0-7)
>>
>>
>>
>> # If not set willingness will be calculated
>>
>>
>>
>> # dynammically based on battery/power status
>>
>>
>>
>>
>>
>>
>>
>> # Willingness 3
>>
>>
>>
>>
>>
>>
>>
>> # Allow processes like the GUI front-end
>>
>>
>>
>> # to connect to the daemon.
>>
>>
>>
>>
>>
>>
>>
>> IpcConnect
>>
>>
>>
>> {
>>
>>
>>
>> # Determines how many simultaneously
>>
>>
>>
>> # IPC connections that will be allowed
>>
>>
>>
>> # Setting this to 0 disables IPC
>>
>>
>>
>>
>>
>>
>>
>> # MaxConnections 0
>>
>>
>>
>>
>>
>>
>>
>> # By default only 127.0.0.1 is allowed
>>
>>
>>
>> # to connect. Here allowed hosts can
>>
>>
>>
>> # be added
>>
>>
>>
>> # Host 127.0.0.1
>>
>>
>>
>> # Host 10.0.0.5
>>
>>
>>
>>
>>
>>
>>
>> # Specify entire net-ranges that are
>>
>>
>>
>> # allowed to connect
>>
>>
>>
>>
>>
>>
>>
>> # Net 192.168.1.0 255.255.255.0
>>
>>
>>
>> }
>>
>>
>>
>>
>>
>>
>>
>> # Link quality level
>>
>>
>>
>> # 0 = do not use link quality
>>
>>
>>
>> # 1 = use link quality for MPR selection
>>
>>
>>
>> # 2 = use link quality for MPR selection and routing
>>
>>
>>
>> # Defaults to 2
>>
>>
>>
>>
>>
>>
>>
>> #LinkQualityLevel 2
>>
>>
>>
>>
>>
>>
>>
>> # Link quality algorithm (only for lq level 1 or 2)
>>
>>
>>
>> # Defaults to "etx_ff", a etx variant developed at Freifunk
>>
>>
>>
>>
>>
>>
>>
>> # LinkQualityAlgorithm "etx_ff"
>>
>>
>>
>> # Link quality aging factor
>>
>>
>>
>> # Defaults to 0.05, smaller values mean larger LQ window size
>>
>>
>>
>> # Link quality aging does only apply to lq level 1 and 2
>>
>>
>>
>> # This parameter is not used for etx_ff
>>
>>
>>
>>
>>
>>
>>
>> # LinkQualityAging 0.1
>>
>>
>>
>>
>>
>>
>>
>> # Fisheye mechanism for TC messages 0=off, 1=on
>>
>>
>>
>> # default is 1
>>
>>
>>
>>
>>
>>
>>
>> LinkQualityFishEye 0
>>
>>
>>
>>
>>
>>
>>
>> # Wether to use hysteresis or not
>>
>>
>>
>> # Hysteresis adds more robustness to the
>>
>>
>>
>> # link sensing but delays neighbor registration.
>>
>>
>>
>> # Used by default. 'yes' or 'no'
>>
>>
>>
>>
>>
>>
>>
>> # UseHysteresis no
>>
>>
>>
>>
>>
>>
>>
>> # Hysteresis parameters
>>
>>
>>
>> # Do not alter these unless you know
>>
>>
>>
>> # what you are doing!
>>
>>
>>
>> # Set to auto by default. Allowed
>>
>>
>>
>> # values are floating point values
>>
>>
>>
>> # in the interval 0,1
>>
>>
>>
>> # THR_LOW must always be lower than
>>
>>
>>
>> # THR_HIGH!!
>>
>>
>>
>>
>>
>>
>>
>> #HystScaling 0.50
>>
>>
>>
>> #HystThrHigh 0.80
>>
>>
>>
>> #HystThrLow 0.30
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> # Polling rate in seconds(float).
>>
>>
>>
>> # Default value 0.05 sec
>>
>>
>>
>>
>>
>>
>>
>> # Pollrate 0.05
>>
>>
>>
>>
>>
>>
>>
>> # Interval to poll network interfaces for configuration
>>
>>
>>
>> # changes. Defaults to 2.5 seconds
>>
>>
>>
>>
>>
>>
>>
>> # NicChgsPollInt 2.5
>>
>>
>>
>> # TC redundancy
>>
>>
>>
>> # Specifies how much neighbor info should
>>
>>
>>
>> # be sent in TC messages
>>
>>
>>
>> # Possible values are:
>>
>>
>>
>> # 0 - only send MPR selectors
>>
>>
>>
>> # 1 - send MPR selectors and MPRs
>>
>>
>>
>> # 2 - send all neighbors
>>
>>
>>
>> #
>>
>>
>>
>> # defaults to 2
>>
>>
>>
>>
>>
>>
>>
>> # TcRedundancy 2
>>
>>
>>
>>
>>
>>
>>
>> #
>>
>>
>>
>> # NatThreshold
>>
>>
>>
>> #
>>
>>
>>
>> # (currently this is only in the freifunk firmware)
>>
>>
>>
>> # If the NAT-Endpoint (the preferred 0/0 HNA
>>
>>
>>
>> # emitting node) is to be changed, the ETX value of the current 0/0 is
>>
>>
>>
>> # compared to the new one. If the ETX difference is too small, the default
>>
>>
>>
>> # route isn't changed. defaults to 1.0
>>
>>
>>
>> # The configured route gets multiplied by the treshhold,
>>
>>
>>
>> # before comparing which route is better
>>
>>
>>
>>
>>
>>
>>
>> # NatThreshold 0.5
>>
>>
>>
>>
>>
>>
>>
>> #
>>
>>
>>
>> # MPR coverage
>>
>>
>>
>> # Specifies how many MPRs a node should
>>
>>
>>
>> # try select to reach every 2 hop neighbor
>>
>>
>>
>> #
>>
>>
>>
>> # Can be set to any integer >0
>>
>>
>>
>> #
>>
>>
>>
>> # MPR selection is broken at the moment, just keep 7
>>
>>
>>
>>
>>
>>
>>
>> # MprCoverage 7
>>
>>
>>
>> # Olsrd plugins to load
>>
>>
>>
>> # This must be the absolute path to the file
>>
>>
>>
>> # or the loader will use the following scheme:
>>
>>
>>
>> # - Try the paths in the LD_LIBRARY_PATH
>>
>>
>>
>> # environment variable.
>>
>>
>>
>> # - The list of libraries cached in /etc/ld.so.cache
>>
>>
>>
>> # - /lib, followed by /usr/lib
>>
>>
>>
>> #
>>
>>
>>
>> # the examples in this list are for linux, so check if the plugin is
>>
>>
>>
>> # available if you use windows/BSD.
>>
>>
>>
>>
>>
>>
>>
>> # LoadPlugin "olsrd_httpinfo.dll"
>>
>>
>>
>> #LoadPlugin "olsrd_httpinfo.so.0.1"
>>
>>
>>
>> #{
>>
>>
>>
>> # port number the httpinfo plugin will be listening, default 1978
>>
>>
>>
>> # PlParam "port" "8000"
>>
>>
>>
>>
>>
>>
>>
>> # ip address that can access the plugin, use "0.0.0.0"
>>
>>
>>
>> # to allow everyone
>>
>>
>>
>> # PlParam "Host" "127.0.0.1"
>>
>>
>>
>> # PlParam "Host" "80.23.53.22"
>>
>>
>>
>>
>>
>>
>>
>> # networks that can access the plugin (ip/netmask)
>>
>>
>>
>> # careful with 0.0.0.0/0, makes (ddos) attacks poss.
>>
>>
>>
>> # PlParam "Net" "0.0.0.0 0.0.0.0"
>>
>>
>>
>> # PlParam "Net" "104.0.0.0 255.255.0.0"
>>
>>
>>
>> # PlParam "Net" "192.168.0.0 255.255.0.0"
>>
>>
>>
>> #}
>>
>>
>>
>>
>>
>>
>>
>> # LoadPlugin "olsrd_txtinfo.dll"
>>
>>
>>
>> #LoadPlugin "olsrd_txtinfo.so.0.1"
>>
>>
>>
>> #{
>>
>>
>>
>> # port number the txtinfo plugin will be listening, default 2006
>>
>>
>>
>> # PlParam "port" "81"
>>
>>
>>
>> # ip address that can access the plugin, use "0.0.0.0"
>>
>>
>>
>> # to allow everyone
>>
>>
>>
>> # PlParam "Accept" "127.0.0.1"
>>
>>
>>
>> #}
>>
>>
>>
>>
>>
>>
>>
>> #LoadPlugin "olsrd_secure.so.0.3"
>>
>>
>>
>> #{
>>
>>
>>
>> # define source of keyfile for secure plugin
>>
>>
>>
>> # see lib/secure/README_SECURE for more information
>>
>>
>>
>>
>>
>>
>>
>> # PlParam "Keyfile" "/etc/olsr-keyfile.txt"
>>
>>
>>
>> #}
>>
>>
>>
>>
>>
>>
>>
>> #LoadPlugin "olsrd_dyn_gw.so.0.4"
>>
>>
>>
>> #{
>>
>>
>>
>> # Here parameters are set to be sent to the
>>
>>
>>
>> # plugin. Theese are on the form "key" "value".
>>
>>
>>
>> # Parameters ofcause, differs from plugin to plugin.
>>
>>
>>
>> # Consult the documentation of your plugin for details.
>>
>>
>>
>>
>>
>>
>>
>> # Example: dyn_gw params
>>
>>
>>
>>
>>
>>
>>
>> # how often to check for Internet connectivity
>>
>>
>>
>> # defaults to 5 secs
>>
>>
>>
>> # PlParam "Interval" "40"
>>
>>
>>
>>
>>
>>
>>
>> # if one or more IPv4 addresses are given, do a ping on these in
>>
>>
>>
>> # descending order to validate that there is not only an entry in
>>
>>
>>
>> # routing table, but also a real internet connection. If any of
>>
>>
>>
>> # these addresses could be pinged successfully, the test was
>>
>>
>>
>> # succesful, i.e. if the ping on the 1st address was successful,the
>>
>>
>>
>> # 2nd won't be pinged
>>
>>
>>
>> # PlParam "Ping" "141.1.1.1"
>>
>>
>>
>> # PlParam "Ping" "194.25.2.129"
>>
>>
>>
>> #}
>>
>>
>>
>>
>>
>>
>>
>> # olsrd_dyn_gw_plain.so.0.4
>>
>>
>>
>> # {
>>
>>
>>
>> # }
>>
>>
>>
>>
>>
>>
>>
>> # Interfaces and their rules
>>
>>
>>
>> # Omitted options will be set to the
>>
>>
>>
>> # default values.
>>
>>
>>
>> # multiple interfaces can be speicified
>>
>>
>>
>> Interface "wlan0"
>>
>>
>>
>> {
>>
>>
>>
>> # Interface Mode is used to prevent unnecessary
>>
>>
>>
>> # packet forwarding on switched ethernet interfaces
>>
>>
>>
>> # valid Modes are "mesh" and "ether"
>>
>>
>>
>> # The default value is mesh!
>>
>>
>>
>>
>>
>>
>>
>> # Mode "mesh"
>>
>>
>>
>>
>>
>>
>>
>> # IPv4 broadcast address to use. The
>>
>>
>>
>> # one usefull example would be 255.255.255.255
>>
>>
>>
>> # If not defined the broadcastaddress
>>
>>
>>
>> # every card is configured with is used
>>
>>
>>
>> # The second useful value would be to
>>
>>
>>
>> # specify the peer adress of an ptp-tunnel.
>>
>>
>>
>> # another name of this parameter is "IPv4Multicast"
>>
>>
>>
>>
>>
>>
>>
>> # Ip4Broadcast 0.0.0.0 (use interface broadcast)
>>
>>
>>
>>
>>
>>
>>
>> # IPv6 multicast address
>>
>>
>>
>> # If not defined, FF02::1 is used
>>
>>
>>
>> # IPv6Multicast FF02::1
>>
>>
>>
>>
>>
>>
>>
>> # IPv4 src address
>>
>>
>>
>> # If not defined (0.0.0.0), the interface IP is used
>>
>>
>>
>>
>>
>>
>>
>> # IPv4Src 0.0.0.0
>>
>>
>>
>>
>>
>>
>>
>> # IPv6 src prefix.
>>
>>
>>
>> # If not defined (::/0), a not-linklocal interface IP is
>> used
>>
>>
>>
>>
>>
>>
>>
>> # IPv6Src ::/0
>>
>>
>>
>>
>>
>>
>>
>> # Emission intervals.
>>
>>
>>
>> # If not defined, RFC proposed values will
>>
>>
>>
>> # be used in most cases.
>>
>>
>>
>>
>>
>>
>>
>> # Hello interval in seconds(float)
>>
>>
>>
>> # HelloInterval 2.0
>>
>>
>>
>>
>>
>>
>>
>> # HELLO validity time
>>
>>
>>
>> # HelloValidityTime 20.0
>>
>>
>>
>>
>>
>>
>>
>> # TC interval in seconds(float)
>>
>>
>>
>> # TcInterval 5.0
>>
>>
>>
>>
>>
>>
>>
>> # TC validity time
>>
>>
>>
>> # TcValidityTime 300.0
>>
>>
>>
>>
>>
>>
>>
>> # MID interval in seconds(float)
>>
>>
>>
>> # MidInterval 5.0
>>
>>
>>
>>
>>
>>
>>
>> # MID validity time
>>
>>
>>
>> # MidValidityTime 300.0
>>
>>
>>
>>
>>
>>
>>
>> # HNA interval in seconds(float)
>>
>>
>>
>> # HnaInterval 5.0
>>
>>
>>
>>
>>
>>
>>
>> # HNA validity time
>>
>>
>>
>> # HnaValidityTime 300.0
>>
>>
>>
>>
>>
>>
>>
>> # When multiple links exist between hosts
>>
>>
>>
>> # the weight of interface is used to determine
>>
>>
>>
>> # the link to use. Normally the weight is
>>
>>
>>
>> # automatically calculated by olsrd based
>>
>>
>>
>> # on the characteristics of the interface,
>>
>>
>>
>> # but here you can specify a fixed value.
>>
>>
>>
>> # Olsrd will choose links with the lowest value.
>>
>>
>>
>> # Note:
>>
>>
>>
>> # Interface weight is used only when LinkQualityLevel is set to 0.
>>
>>
>>
>> # For any other value of LinkQualityLevel, the interface ETX
>>
>>
>>
>> # value is used instead.
>>
>>
>>
>> # Weight 0
>>
>>
>>
>> # If a certain route should be preferred
>>
>>
>>
>> # or ignored by the mesh, the Link Quality
>>
>>
>>
>> # value of a node can be multiplied with a factor
>>
>>
>>
>> # entered here. In the example the route
>>
>>
>>
>> # using 192.168.0.1 would rather be ignored.
>>
>>
>>
>> # A multiplier of 0.5 will result in a small
>>
>>
>>
>> # (bad) LinkQuality value and a high (bad)
>>
>>
>>
>> # ETX value.
>>
>>
>>
>> # Note:
>>
>>
>>
>> # Link quality multiplier is used only when
>>
>>
>>
>> # LinkQualityLevel is > 0.
>>
>>
>>
>>
>>
>>
>>
>> # Example 1: LinkQualityMult 192.168.0.1 0.5
>>
>>
>>
>>
>>
>>
>>
>> # This multiplier applies to all other nodes
>>
>>
>>
>> # Example 2: LinkQualityMult default 0.8
>>
>>
>>
>> }
>>
>>
>>
>>
>>
>>
>>
>> # another Interface (with different configs)
>>
>>
>>
>> #Interface "eth1"
>>
>>
>>
>> #{
>>
>>
>>
>> # IPv4 broadcast address to use.
>>
>>
>>
>> # One usefull example would be 255.255.255.255
>>
>>
>>
>> # If not defined the broadcastaddress of
>>
>>
>>
>> # every interface which has one configured gets used
>>
>>
>>
>> # The second useful value would be to
>>
>>
>>
>> # specify the peer adress of an ptp-tunnel
>>
>>
>>
>>
>>
>>
>>
>> # IPv4Multicast 192.168.255.255
>>
>>
>>
>>
>>
>>
>>
>> # Interface Mode is used to prevent unnecessary
>>
>>
>>
>> # packet forwardin on switched ethernet interfaces
>>
>>
>>
>> # valid Modes are "mesh" and "ether"
>>
>>
>>
>> # The default value is mesh!
>>
>>
>>
>>
>>
>>
>>
>> # Mode "ether"
>>
>>
>>
>> #}
>>
>>
>> Thanks in advance..
>>
>> On Wed, Dec 3, 2014 at 2:01 PM, Henning Rogge <(spam-protected)> wrote:
>>
>>> Hi,
>>>
>>> have you tried to run olsrd with minimal configuration?
>>>
>>> (just set the interfaces olsrd should run on, nothing else)
>>>
>>> Henning
>>>
>>> On Tue, Dec 2, 2014 at 4:16 PM, akshay mithyantha <
>>> (spam-protected)> wrote:
>>>
>>>> Hello,
>>>> I am using TP Link 1043ND routers to create a mesh network for a
>>>> project. For the network purposes I have considered 3 routers say R1, R2
>>>> and R3.
>>>> The routers are kept on different floors such that topology R1 <--> R2
>>>> <--> R3 is created.
>>>> R1 can only ping R2,
>>>> R2 can ping both R1 and R3 and
>>>> R3 can ping only R2.
>>>>
>>>
>>> Good, that means IP connectivity works.
>>>
>>>
>>>> When I try to ping R3 from R1, it can't ping.
>>>> After running OLSRD and using traceroute from R1 to R3, I get the IP of
>>>> the same router and I don't see any other routes. I have also enabled
>>>> forwarding by using the following command:
>>>> echo "1" > /proc/sys/net/ipv4/ip_forward
>>>>
>>>
>>> olsrd sets this flag automatically during startup.
>>>
>>>
>>>> In the same topology if I replace R1 by a laptop L, the laptop can ping
>>>> R3 via R2 which can be clearly seen when traceroute is used.
>>>> So can anyone please help me with this problem?
>>>>
>>>
>>> Laptop also runs olsrd?
>>>
>>> Okay, my guess would be the configuration is somehow wrong, lets have a
>>> look. Just send your olsrd configuration file (not the UCI one) to the
>>> list... in case of OpenWRT you will find it somewhere in /tmp.
>>>
>>> Henning
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20141210/6db91590/attachment.html>
More information about the Olsr-users
mailing list