*** Answering a msg posted in area 'European sysop's talks. '.
Wednesday January 13 2016 12:02, Wilfred van Velzen wrote to Benny Pedersen:

I don't know why this happens. Maybe it's a problem in binkd, maybe
it's a problem in a linux library...

Well, this is interesting:

ping 0.0.0.0
PING 0.0.0.0: 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0. time=0. ms
64 bytes from 192.168.1.21: icmp_seq=0. time=10. ms
64 bytes from 127.0.0.1: icmp_seq=1. time=0. ms
64 bytes from 192.168.1.21: icmp_seq=1. time=10. ms
64 bytes from 127.0.0.1: icmp_seq=2. time=0. ms
64 bytes from 192.168.1.21: icmp_seq=2. time=0. ms

My OS/2 computer has only one ip: 192.168.1.2.

192.168.1.21 is the address of my switch.
192.168.1.12 is the address of the router to the internet.

'Tommi

---
* Origin: ---------------------------------->> (2:221/6)

Hello Tommi!

13 Jan 16 13:20, you wrote to Wilfred van Velzen:

Well, this is interesting:

ping 0.0.0.0
PING 0.0.0.0: 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0. time=0. ms
64 bytes from 192.168.1.21: icmp_seq=0. time=10. ms
64 bytes from 127.0.0.1: icmp_seq=1. time=0. ms
64 bytes from 192.168.1.21: icmp_seq=1. time=10. ms
64 bytes from 127.0.0.1: icmp_seq=2. time=0. ms
64 bytes from 192.168.1.21: icmp_seq=2. time=0. ms

My OS/2 computer has only one ip: 192.168.1.2.

192.168.1.21 is the address of my switch.
192.168.1.12 is the address of the router to the internet.

0.0.0.0 is the broadcast address, so every interface on the same network
segment answers, this is what should happen by design.

Kees

--- GoldED+/LNX 1.1.5
* Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)

Hi Tommi,

On 2016-01-13 13:20:11, you wrote to me:

Well, this is interesting:

ping 0.0.0.0
PING 0.0.0.0: 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0. time=0. ms
64 bytes from 192.168.1.21: icmp_seq=0. time=10. ms
64 bytes from 127.0.0.1: icmp_seq=1. time=0. ms
64 bytes from 192.168.1.21: icmp_seq=1. time=10. ms
64 bytes from 127.0.0.1: icmp_seq=2. time=0. ms
64 bytes from 192.168.1.21: icmp_seq=2. time=0. ms

My OS/2 computer has only one ip: 192.168.1.2.

192.168.1.21 is the address of my switch.
192.168.1.12 is the address of the router to the internet.

On 3 different versions of openSUSE I get the same result:

# ping 0.0.0.0
PING 0.0.0.0 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.026 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.017 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.018 ms
64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.014 ms
^C
-+- 0.0.0.0 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2999ms
rtt min/avg/max/mdev = 0.014/0.018/0.026/0.006 ms

On Windows 7 I get:

ping 0.0.0.0

Pinging 0.0.0.0 with 32 bytes of data:
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.

Ping statistics for 0.0.0.0:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

So it doesn't treat it special, and is trying to ping the address...


There is a wiki page for the 0.0.0.0 IPv4 address:

https://en.wikipedia.org/wiki/0.0.0.0

And I think binkd should treat it in the meaning of: "A way to explicitly specify that the target is unavailable.", when it's occuring for outbound connections.

Bye, Wilfred.

--- FMail-W32-1.69.12.144-B20160109
* Origin: FMail development HQ (2:280/464)

On 13.1.2016 14:23, Wilfred van Velzen - Tommi Koivula wrote:

And I think binkd should treat it in the meaning of: "A way to
explicitly specify that the target is unavailable.", when it's
occuring for outbound connections.

Maybe we need a blacklist option in binkd config, where the "0.0.0.0"
should be entered by default...

'Tommi

---
* Origin: *** nntp://fidonews.mine.nu *** Finland *** (2:221/6.0)

Hi,

On 2016-01-13 18:05:56, Tommi Koivula wrote to Wilfred van Velzen:
about: "0.0.0.0":

And I think binkd should treat it in the meaning of: "A way to
explicitly specify that the target is unavailable.", when it's
occuring for outbound connections.

Maybe we need a blacklist option in binkd config, where the "0.0.0.0" should be entered by default...

A blacklist is a job for a firewall, you don't have to complicate binkd with that...

Bye, Wilfred.


--- FMail-W32-1.69.12.144-B20160109
* Origin: Native IPv6 connectable node (2:280/464)

Hi Wilfred.

13 Jan 16 17:39, you wrote to me:

Maybe we need a blacklist option in binkd config, where the
"0.0.0.0" should be entered by default...

A blacklist is a job for a firewall,

Sure it is.

But how do you block outbound tcp to 0.0.0.0 ?

'Tommi

--- GoldED+/W64-MSVC 1.1.5-b20151130
* Origin: ====================================== (2:221/1.1)

Hi,

On 2016-01-13 19:59:10, Tommi Koivula wrote to Wilfred van Velzen:
about: "0.0.0.0":

Maybe we need a blacklist option in binkd config, where the
"0.0.0.0" should be entered by default...

A blacklist is a job for a firewall,

Sure it is.

But how do you block outbound tcp to 0.0.0.0 ?

It would be trivial to "hard" code that into binkd...

Bye, Wilfred.


--- FMail-W32-1.69.12.144-B20160109
* Origin: Native IPv6 connectable node (2:280/464)

On 13.1.2016 20:08, Wilfred van Velzen - Tommi Koivula wrote:

But how do you block outbound tcp to 0.0.0.0 ?

It would be trivial to "hard" code that into binkd...

That was my first idea, but I don't like hardcodings...

'Tommi

---
* Origin: *** nntp://fidonews.mine.nu *** Finland *** (2:221/6.0)

Hi,

On 2016-01-13 20:33:00, Tommi Koivula wrote to Wilfred van Velzen:
about: "0.0.0.0":

But how do you block outbound tcp to 0.0.0.0 ?

It would be trivial to "hard" code that into binkd...

That was my first idea, but I don't like hardcodings...

0.0.0.0 is like a returned error code. You should always hard code checks for those...

Bye, Wilfred.


--- FMail-W32-1.69.12.144-B20160109
* Origin: Native IPv6 connectable node (2:280/464)

Hi Wilfred.

13 Jan 16 19:58, you wrote to me:

But how do you block outbound tcp to 0.0.0.0 ?

It would be trivial to "hard" code that into binkd...

That was my first idea, but I don't like hardcodings...

0.0.0.0 is like a returned error code.

Yes.

Also 127.0.0.x other than 127.0.0.1 may be a special case which shouldn't be called..

If you set a host offline at dyndns.com, it will get address 216.146.38.125. There's no binkd answering so it wont cause any harm. Maybe some other dynamic dns provider may use 0.0.0.0 when the host is marked offline?

Anyway, a list of undialable ip's might be useful in some cases.

'Tommi

---
* Origin: 2001:470:1f15:cb0:f1d0:2:221:6 (2:221/6)

Hi Tommi,

On 2016-01-14 10:21:26, you wrote to me:

0.0.0.0 is like a returned error code.

Yes.

Also 127.0.0.x other than 127.0.0.1 may be a special case which shouldn't be called..

That could be intentional for testing purposes!

Maybe the broadcast address(es) should be blocked:

https://en.wikipedia.org/wiki/Broadcast_address

But you wouldn't get those from DNS, unless someone is specificly f*cking with it...

If you set a host offline at dyndns.com, it will get address 216.146.38.125. There's no binkd answering so it wont cause any harm.

Maybe

some other dynamic dns provider may use 0.0.0.0 when the host is marked offline?

Probably.

Anyway, a list of undialable ip's might be useful in some cases.

I still think the firewall should take care of those!

Bye, Wilfred.

--- FMail-W32-1.69.12.144-B20160109
* Origin: FMail development HQ (2:280/464)

On 14.1.2016 11:46, Wilfred van Velzen - Tommi Koivula wrote:

But you wouldn't get those from DNS, unless someone is specificly
f*cking with it...

Which is exactly where this whole discussion started. ;)

'Tommi

---
* Origin: *** nntp://fidonews.mine.nu *** Finland *** (2:221/6.0)

Hi Tommi,

On 2016-01-14 12:07:04, you wrote to me:

But you wouldn't get those from DNS, unless someone is specificly
f*cking with it...

Which is exactly where this whole discussion started. ;)

It started with 0.0.0.0. That doesn't seem to be intentional f*cking, but maybe
a documented way of saying "server unavailable"? ;)

Bye, Wilfred.

--- FMail-W32-1.69.12.144-B20160109
* Origin: FMail development HQ (2:280/464)

Hello Wilfred,

On Thursday January 14 2016 10:46, you wrote to Tommi Koivula:

Anyway, a list of undialable ip's might be useful in some cases.

I still think the firewall should take care of those!

If the firewall takes care of it, binkd will keep trying until the sysop interferes. If a number is in the binkd blacklist, binkd could deal with it in a more intelligent way...


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20130111
* Origin: http://www.vlist.eu (2:280/5555)

Hello Wilfred,

On Thursday January 14 2016 11:11, you wrote to Tommi Koivula:

Which is exactly where this whole discussion started. ;)

It started with 0.0.0.0. That doesn't seem to be intentional f*cking,
but maybe a documented way of saying "server unavailable"? ;)

In this context, it probably means indeed just that. But it does not always:

https://en.wikipedia.org/wiki/0.0.0.0

So hard coding 0.0.0.0 als "target unavailable" may block more than intended.


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20130111
* Origin: http://www.vlist.eu (2:280/5555)

Hi Michiel,

On 14 Jan 16 11:25, Michiel van der Vlist wrote to Wilfred van Velzen:
about: "0.0.0.0":

Which is exactly where this whole discussion started. ;)

It started with 0.0.0.0. That doesn't seem to be intentional f*cking,
but maybe a documented way of saying "server unavailable"? ;)

MvdV> In this context, it probably means indeed just that. But it does not
MvdV> always:

MvdV> https://en.wikipedia.org/wiki/0.0.0.0

MvdV> So hard coding 0.0.0.0 als "target unavailable" may block more than
MvdV> intended.

Like what?

Wilfred.

--- FMail-W32-1.69.10.141-B20151003
* Origin: point@work (2:280/464.112)

Hello Wilfred,

On Thursday January 14 2016 11:40, you wrote to me:

MvdV>> https://en.wikipedia.org/wiki/0.0.0.0

MvdV>> So hard coding 0.0.0.0 als "target unavailable" may block more
MvdV>> than intended.

Like what?

I don't know. The Wiki article mentions five possible uses:


1 The address a host claims as its own when it has not yet been assigned an address. Such as when sending the initial DHCPDISCOVER packet when using DHCP.

2 The address a host assigns to itself when address request via DHCP has failed, provided the host's IP stack supports this. This usage has been replaced with the APIPA mechanism in modern operating systems.

3 A way to specify "any IPv4-host at all". It is used in this way when specifying a default route.

4 A way to explicitly specify that the target is unavailable.[1]

5 A way to specify "any IPv4 address at all". It is used in this way when configuring servers (i.e. when binding listening sockets). This is known to TCP
programmers as INADDR_ANY. (bind(2) binds to addresses, not interfaces


Only # 4 is what I would suggest for unconditional blocking. All the others... I am not in favour of hard coded unconditional unmaskable blocking without knowing exactly what I block.



Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20130111
* Origin: http://www.vlist.eu (2:280/5555)

Hi Michiel,

On 2016-01-14 12:48:22, you wrote to me:

MvdV>>> https://en.wikipedia.org/wiki/0.0.0.0

MvdV>>> So hard coding 0.0.0.0 als "target unavailable" may block more
MvdV>>> than intended.

Like what?

MvdV> I don't know. The Wiki article mentions five possible uses:


MvdV> 1 The address a host claims as its own when it has not yet been assigned
an
MvdV> address. Such as when sending the initial DHCPDISCOVER packet when using
MvdV> DHCP.

MvdV> 2 The address a host assigns to itself when address request via DHCP has
MvdV> failed, provided the host's IP stack supports this. This usage has been
MvdV> replaced with the APIPA mechanism in modern operating systems.

MvdV> 3 A way to specify "any IPv4-host at all". It is used in this way when
MvdV> specifying a default route.

MvdV> 4 A way to explicitly specify that the target is unavailable.[1]

MvdV> 5 A way to specify "any IPv4 address at all". It is used in this way when
MvdV> configuring servers (i.e. when binding listening sockets). This is known
to
MvdV> TCP programmers as INADDR_ANY. (bind(2) binds to addresses, not interfaces


MvdV> Only # 4 is what I would suggest for unconditional blocking. All the
MvdV> others... I am not in favour of hard coded unconditional unmaskable
MvdV> blocking without knowing exactly what I block.

Only 4 seems applicable when it's returned in a DNS query...

Bye, Wilfred.

--- FMail-W32-1.69.12.144-B20160109
* Origin: FMail development HQ (2:280/464)

Hello Tommi!

13 Jan 2016 13:20, Tommi Koivula wrote to Wilfred van Velzen:

*** Answering a msg posted in area 'European sysop's talks. '.
Wednesday January 13 2016 12:02, Wilfred van Velzen wrote to Benny Pedersen:

I don't know why this happens. Maybe it's a problem in binkd, maybe
it's a problem in a linux library...

Well, this is interesting:

ping 0.0.0.0
PING 0.0.0.0: 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0. time=0. ms
64 bytes from 192.168.1.21: icmp_seq=0. time=10. ms
64 bytes from 127.0.0.1: icmp_seq=1. time=0. ms
64 bytes from 192.168.1.21: icmp_seq=1. time=10. ms
64 bytes from 127.0.0.1: icmp_seq=2. time=0. ms
64 bytes from 192.168.1.21: icmp_seq=2. time=0. ms

My OS/2 computer has only one ip: 192.168.1.2.

192.168.1.21 is the address of my switch.
192.168.1.12 is the address of the router to the internet.

thanks now its know that binkd should NOT dial broadcast addresses


Regards Benny

... there can only be one way of life, and it works :)

--- Msged/LNX 6.2.0 (Linux/4.4.0-gentoo (i686))
* Origin: openvpn on its way here (2:230/0)

Hello Kees!

13 Jan 2016 12:56, Kees van Eeten wrote to Tommi Koivula:

0.0.0.0 is the broadcast address, so every interface on the same
network segment answers, this is what should happen by design.

indeed, questions came from when i /etc/init.d/noip stop one whole day, and my dynamic host returned 0.0.0.0, this should in binkd term be signaling do not call, but all users here on my host started asking me to solve there problem of
dial broadcasting

hmp


Regards Benny

... there can only be one way of life, and it works :)

--- Msged/LNX 6.2.0 (Linux/4.4.0-gentoo (i686))
* Origin: openvpn on its way here (2:230/0)

Hello Tommi!

13 Jan 2016 18:05, Tommi Koivula wrote to Wilfred van Velzen:

Maybe we need a blacklist option in binkd config, where the "0.0.0.0" should be entered by default...

plaese add it would be a very usefull patch to binkd sources :=)


Regards Benny

... there can only be one way of life, and it works :)

--- Msged/LNX 6.2.0 (Linux/4.4.0-gentoo (i686))
* Origin: openvpn on its way here (2:230/0)

Hello Wilfred!

13 Jan 2016 17:39, Wilfred van Velzen wrote to Tommi Koivula:

A blacklist is a job for a firewall, you don't have to complicate
binkd with that...

ignorant

you showed me that firewall on windows do another ping then linux, so firewalls
is not diffrent either ?

correct fixing is to code binkd to skip dial when its broadcasting ip, not just
0.0.0.0

hopefully it can be more geek then me

rfc 1918 is nice aswell btw
rfc 1700 oh :=)

lets solve it in firewalls, lol


Regards Benny

... there can only be one way of life, and it works :)

--- Msged/LNX 6.2.0 (Linux/4.4.0-gentoo (i686))
* Origin: openvpn on its way here (2:230/0)

Hello Tommi!

13 Jan 2016 20:33, Tommi Koivula wrote to Wilfred van Velzen:

That was my first idea, but I don't like hardcodings...

so dial until some get the code done


Regards Benny

... there can only be one way of life, and it works :)

--- Msged/LNX 6.2.0 (Linux/4.4.0-gentoo (i686))
* Origin: openvpn on its way here (2:230/0)

Hello Wilfred!

13 Jan 2016 19:58, Wilfred van Velzen wrote to Tommi Koivula:

0.0.0.0 is like a returned error code. You should always hard code checks for those...

bravo, who will make ipv6 work ? :=)


Regards Benny

... there can only be one way of life, and it works :)

--- Msged/LNX 6.2.0 (Linux/4.4.0-gentoo (i686))
* Origin: openvpn on its way here (2:230/0)

Hello Michiel!

14 Jan 2016 11:25, Michiel van der Vlist wrote to Wilfred van Velzen:

MvdV> So hard coding 0.0.0.0 als "target unavailable" may block more than
MvdV> intended.

http://0.0.0.0:80/

if you see it works, tell me :)

ipv6 variant is welcommed


Regards Benny

... there can only be one way of life, and it works :)

--- Msged/LNX 6.2.0 (Linux/4.4.0-gentoo (i686))
* Origin: openvpn on its way here (2:230/0)

Hi,

On 2016-02-13 08:38:08, Benny Pedersen wrote to Kees van Eeten:
about: "0.0.0.0":

indeed, questions came from when i /etc/init.d/noip stop one whole
day, and my dynamic host returned 0.0.0.0, this should in binkd term
be signaling do not call, but all users here on my host started asking
me to solve there problem of dial broadcasting

Yes, you're not crazy, the rest of the world is! ;)

But you should read all new messages before you start replying to old ones! This has been announced 3 weeks ago:

revision: 1.569; date: 2016-01-19 13:22:16+00; committed by git; lines: +4 -0
Log message:
Auto increase patchlevel, set 1.1a-76
Check for "illegal" IP nrs 0.0.0.0 and [::] before trying to make a connection

Bye, Wilfred.


--- FMail-W32-1.69.13.147-B20160213
* Origin: Native IPv6 connectable node (2:280/464)

Hello Benny!

13 Feb 16 08:48, you wrote to Wilfred van Velzen:

0.0.0.0 is like a returned error code. You should always hard code
checks for those...

bravo, who will make ipv6 work ? :=)

What is wrong with IPv6, there are currently 42 systems using IPv6 and
nearly all of them use Binkd.

Kees

--- GoldED+/LNX 1.1.5
* Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)

Hello Wilfred!

13 Feb 2016 11:56, Wilfred van Velzen wrote to Benny Pedersen:

Log message:
Auto increase patchlevel, set 1.1a-76
Check for "illegal" IP nrs 0.0.0.0 and [::] before trying to make a connection

there is imho nothing illegal in 0.0.0.0

but nice to see a irex patch :=)


Regards Benny

... there can only be one way of life, and it works :)

--- Msged/LNX 6.2.0 (Linux/4.4.0-gentoo (i686))
* Origin: openvpn on its way here (2:230/0)

Hello Kees!

13 Feb 2016 13:28, Kees van Eeten wrote to Benny Pedersen:

What is wrong with IPv6, there are currently 42 systems using IPv6
and nearly all of them use Binkd.

i just wish i had it at home

and still miss qico updates :(

if binkd porting the ncurses queue manager then i can drop the qico problem


Regards Benny

... there can only be one way of life, and it works :)

--- Msged/LNX 6.2.0 (Linux/4.4.0-gentoo (i686))
* Origin: openvpn on its way here (2:230/0)

Hello Benny!

13 Feb 16 15:14, you wrote to me:

i just wish i had it at home

Move out of your little corner on Fyn.

and still miss qico updates :(

if binkd porting the ncurses queue manager then i can drop the qico problem

If the queue managers gets its information from the files in the BSO
directories, it should be possible.

Can't you just fillout the configuration file and run the queue manager.
If the queue manager also activates qico, the you have to be creative. ;)

I use ifstat from ifcico/ifmail and some
reformatting with sed in a timed loop by watch as a queue monitor.

qico supports protocols that binkd does not.

Kees

--- GoldED+/LNX 1.1.5
* Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)

Hello Kees!

13 Feb 2016 15:29, Kees van Eeten wrote to Benny Pedersen:

i just wish i had it at home

Move out of your little corner on Fyn.

+1

and still miss qico updates :(

if binkd porting the ncurses queue manager then i can drop the qico
problem

If the queue managers gets its information from the files in the BSO directories, it should be possible.

it opensource so i see no problem on merge best of 2 worlds ?

Can't you just fillout the configuration file and run the queue
manager.

?

If the queue manager also activates qico, the you have to be
creative. ;)

no qcc does not need to run to get gico daemon work

I use ifstat from ifcico/ifmail and some
reformatting with sed in a timed loop by watch as a queue monitor.

anoter problem :=)

qico supports protocols that binkd does not.

if binkd would extend with emsi, then amiga is more supported :=)

on the other hands qico miss zlib bzib2


Regards Benny

... there can only be one way of life, and it works :)

--- Msged/LNX 6.2.0 (Linux/4.4.0-gentoo (i686))
* Origin: openvpn on its way here (2:230/0)

13 Feb 16 08:38, you wrote to Kees van Eeten:

0.0.0.0 is the broadcast address, so every interface on the same
network segment answers, this is what should happen by design.

indeed, questions came from when i /etc/init.d/noip stop one whole day,

and

my dynamic host returned 0.0.0.0,

that's a fault in your dynamic host... they should have returned NXDOMAIN...

this should in binkd term be signaling do not call, but all users here
on my host started asking me to solve there problem of dial
broadcasting

fix your dynamic host ;)

)\/(ark

Always Mount a Scratch Monkey

... All warfare is based on deception. - Sun Tzu, The Art of War.
---
* Origin: (1:3634/12.73)

Hello Benny!

13 Feb 16 16:31, you wrote to me:

qico supports protocols that binkd does not.

if binkd would extend with emsi, then amiga is more supported :=)

Ik think binkd was developed, because the developer did not like emsi over
IP, so it is not going to happen. Amiga is history just as DOS and OS/2.
It is like vitage cars, there ane not going to be any new ones.

on the other hands qico miss zlib bzib2

The compression is in the modem protocols it is written for.

Kees

--- GoldED+/LNX 1.1.5
* Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)

Hello mark!

13 Feb 2016 09:34, mark lewis wrote to Benny Pedersen:

that's a fault in your dynamic host... they should have returned NXDOMAIN...

no

fix your dynamic host ;)

possible just hide a TPB ip in there while i am offline


Regards Benny

... there can only be one way of life, and it works :)

--- Msged/LNX 6.2.0 (Linux/4.4.0-gentoo (i686))
* Origin: openvpn on its way here (2:230/0)

Hello Kees!

13 Feb 2016 19:12, Kees van Eeten wrote to Benny Pedersen:

Ik think binkd was developed, because the developer did not like
emsi over IP, so it is not going to happen. Amiga is history just as DOS

and

OS/2. It is like vitage cars, there ane not going to be any new ones.

sadly so much incompitable software out there in the name of "upgrades"

on the other hands qico miss zlib bzib2

The compression is in the modem protocols it is written for.

note qico handle binkp protocol aswell as emsi ?


Regards Benny

... there can only be one way of life, and it works :)

--- Msged/LNX 6.2.0 (Linux/4.4.0-gentoo (i686))
* Origin: openvpn on its way here (2:230/0)