Re: [GSoC] Dual-stack ping command

[Christopher Bailey]

Jamie Landeg-Jones (ja...@catflap.org) wrote:
> That's something that's bugged me too.. I'm going to be cheeky now, and ask 
> if you've
> thought of doing traceroute/traceroute6 too?

Yes, I have. It was listed on the project ideas wiki page as a
separate project, but I wouldn’t mind combining the two (or working on
traceroute as a stretch goal).
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: [GSoC] Dual-stack ping command

[Jamie Landeg-Jones]

Christopher Bailey  wrote:

> I’m an undergraduate computer science student at the University of
> Alaska Fairbanks. I’m interested in unifying ping and ping6 into a
> single command, because it’s one of the suggested ideas on the wiki,
> it’s something that’s mildly irritated me in the past, and I believe I
> have the necessary skills to accomplish it.

Hello!
That's something that's bugged me too.. I'm going to be cheeky now, and ask if 
you've
thought of doing traceroute/traceroute6 too?

:-)

Cheers, Jamie
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[GSoC] Dual-stack ping command

[Christopher Bailey]

Hello,

I’m an undergraduate computer science student at the University of
Alaska Fairbanks. I’m interested in unifying ping and ping6 into a
single command, because it’s one of the suggested ideas on the wiki,
it’s something that’s mildly irritated me in the past, and I believe I
have the necessary skills to accomplish it.

From looking at the source code to the two existing commands, this
project looks pretty straightforward. There could be some
complications I’m missing though, so I’d be interested to hear from
more experienced developers if there are.

Also, apologies if I did anything wrong in sending this email. I’ve
been following the FreeBSD lists for a while, but this is the first
time I’ve sent a message myself, so I’m new to the experience.

Thanks,
Chris Bailey
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Incorrect route interface

[Grzegorz Junka]

On 12/03/2018 20:13, Rodney W. Grimes wrote:

On 12/03/2018 18:04, Rodney W. Grimes wrote:

On 11/03/2018 20:57, Marek Zarychta wrote:

On Sun, Mar 11, 2018 at 05:46:52PM +, Grzegorz Junka wrote:

On 11/03/2018 06:04, Eugene Grosbein wrote:

11.03.2018 7:01, Grzegorz Junka wrote:


Just do not assign addresses from same network 10.20.0.0/16 to different 
network interfaces
and you will be fine. Assign them all to right interface:

ifconfig_em0="inet 10.20.2.14 netmask 255.255.0.0"
ifconfig_em0_alias0="inet 10.20.2.15/32"
ifconfig_igb0_alias0="inet 10.20.2.16/32"

Interfaces meant to be all equal, last line should be:

ifconfig_em0_alias1="inet 10.20.2.16/32"


OK, I see. So this is in case I want many IPs assigned to the same
interface. What if I want one IP assigned to multiple interfaces (i.e.
so that the additional igb0-3 effectively work as a 4-port switch)?


Please consider bonding all NICs as one bridge(4) interface. Then
multiple IPs could be assigned to such interface.


Many thanks Eugene and Marek for your suggestions. I will now need to
decide if I want to fragment the network into subnets or bridge the
interfaces.
GregJ

I believe some of the problem you are experincing is addressed
in this differential:
https://reviews.freebsd.org/D14547

Your original configuration was(is) valid, just not common,
and I have not seen this done in more than a decade, but it
seems as if rstone@ also has someone doing this "multiple IP's
into same subnet on seperate interfaces".


Thanks for the link. That's interesting. According to this post that
configuration shouldn't be valid:

https://forums.freenas.org/index.php?threads/multiple-network-interfaces-on-a-single-subnet.20204/

I'll disagree with the claims it is not valid.  I shall however support
the claims that it is non-standard, and non-trivial to understand just
what it is that occurs in *BSD when you do this.  I have seen this
"claimed to be invalid" coniguration in use several times over the
past 30 years.

Where people seem to get this "invalid" from is expecting the traffic
to be bound to an IP to go both in and OUT that interface is what is
not invalid, but a wrong assertion.  Traffic WELL come in that interface,
as that is how ethernet macs, arp's an IP work.  However it WELL go
out the interface that is selected by the routing table.  If you
can seperate in your mind that this is how IN and OUT interfaces
are decided the rest becomes simply mechanical.

Simple typical *BSD installs end up with all traffic going out just
one of the interfaces, but I can write route rules that change that
artifact.  And this is where the usage of this odd configuration
sometimes comes about.

With modern implimentations of *BSD that now have multiple fib's,
and things like netgraph, and ipfw one can get very creative in
what actually happens.  And none of it is invalid, just often
miss understood.  I can actually casue that traffic bound to
a specific IP to go in and out that specific interface.  Ipfw's
ability to cause a packet to use an alternate fib is how.

ipfw add allow ip from ${ip_of_nicX} to any setfib ${fib_for_nicX}


I don't know much about the network stack in FreeBSD but I would assume 
that I should be able to configure specific traffic (based on the 
destination subnet, so nothing fancy) to go out of a specific interface. 
Not only I wasn't able to do that, I was told my approach was wrong. So 
I think I agree with you.

GregJ

___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Incorrect route interface

[Rodney W. Grimes]

> On 12/03/2018 18:04, Rodney W. Grimes wrote:
> >> On 11/03/2018 20:57, Marek Zarychta wrote:
> >>> On Sun, Mar 11, 2018 at 05:46:52PM +, Grzegorz Junka wrote:
>  On 11/03/2018 06:04, Eugene Grosbein wrote:
> > 11.03.2018 7:01, Grzegorz Junka wrote:
> >
> >>> Just do not assign addresses from same network 10.20.0.0/16 to 
> >>> different network interfaces
> >>> and you will be fine. Assign them all to right interface:
> >>>
> >>> ifconfig_em0="inet 10.20.2.14 netmask 255.255.0.0"
> >>> ifconfig_em0_alias0="inet 10.20.2.15/32"
> >>> ifconfig_igb0_alias0="inet 10.20.2.16/32"
> > Interfaces meant to be all equal, last line should be:
> >
> > ifconfig_em0_alias1="inet 10.20.2.16/32"
> >
>  OK, I see. So this is in case I want many IPs assigned to the same
>  interface. What if I want one IP assigned to multiple interfaces (i.e.
>  so that the additional igb0-3 effectively work as a 4-port switch)?
> 
> >>> Please consider bonding all NICs as one bridge(4) interface. Then
> >>> multiple IPs could be assigned to such interface.
> >>>
> >> Many thanks Eugene and Marek for your suggestions. I will now need to
> >> decide if I want to fragment the network into subnets or bridge the
> >> interfaces.
> >> GregJ
> > I believe some of the problem you are experincing is addressed
> > in this differential:
> > https://reviews.freebsd.org/D14547
> >
> > Your original configuration was(is) valid, just not common,
> > and I have not seen this done in more than a decade, but it
> > seems as if rstone@ also has someone doing this "multiple IP's
> > into same subnet on seperate interfaces".
> >
> 
> Thanks for the link. That's interesting. According to this post that 
> configuration shouldn't be valid:
> 
> https://forums.freenas.org/index.php?threads/multiple-network-interfaces-on-a-single-subnet.20204/

I'll disagree with the claims it is not valid.  I shall however support
the claims that it is non-standard, and non-trivial to understand just
what it is that occurs in *BSD when you do this.  I have seen this
"claimed to be invalid" coniguration in use several times over the
past 30 years.

Where people seem to get this "invalid" from is expecting the traffic
to be bound to an IP to go both in and OUT that interface is what is
not invalid, but a wrong assertion.  Traffic WELL come in that interface,
as that is how ethernet macs, arp's an IP work.  However it WELL go
out the interface that is selected by the routing table.  If you
can seperate in your mind that this is how IN and OUT interfaces
are decided the rest becomes simply mechanical.

Simple typical *BSD installs end up with all traffic going out just
one of the interfaces, but I can write route rules that change that
artifact.  And this is where the usage of this odd configuration
sometimes comes about.

With modern implimentations of *BSD that now have multiple fib's,
and things like netgraph, and ipfw one can get very creative in
what actually happens.  And none of it is invalid, just often
miss understood.  I can actually casue that traffic bound to
a specific IP to go in and out that specific interface.  Ipfw's
ability to cause a packet to use an alternate fib is how.

ipfw add allow ip from ${ip_of_nicX} to any setfib ${fib_for_nicX}

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Incorrect route interface

[Grzegorz Junka]

On 12/03/2018 18:04, Rodney W. Grimes wrote:

On 11/03/2018 20:57, Marek Zarychta wrote:

On Sun, Mar 11, 2018 at 05:46:52PM +, Grzegorz Junka wrote:

On 11/03/2018 06:04, Eugene Grosbein wrote:

11.03.2018 7:01, Grzegorz Junka wrote:


Just do not assign addresses from same network 10.20.0.0/16 to different 
network interfaces
and you will be fine. Assign them all to right interface:

ifconfig_em0="inet 10.20.2.14 netmask 255.255.0.0"
ifconfig_em0_alias0="inet 10.20.2.15/32"
ifconfig_igb0_alias0="inet 10.20.2.16/32"

Interfaces meant to be all equal, last line should be:

ifconfig_em0_alias1="inet 10.20.2.16/32"


OK, I see. So this is in case I want many IPs assigned to the same
interface. What if I want one IP assigned to multiple interfaces (i.e.
so that the additional igb0-3 effectively work as a 4-port switch)?


Please consider bonding all NICs as one bridge(4) interface. Then
multiple IPs could be assigned to such interface.


Many thanks Eugene and Marek for your suggestions. I will now need to
decide if I want to fragment the network into subnets or bridge the
interfaces.
GregJ

I believe some of the problem you are experincing is addressed
in this differential:
https://reviews.freebsd.org/D14547

Your original configuration was(is) valid, just not common,
and I have not seen this done in more than a decade, but it
seems as if rstone@ also has someone doing this "multiple IP's
into same subnet on seperate interfaces".



Thanks for the link. That's interesting. According to this post that 
configuration shouldn't be valid:


https://forums.freenas.org/index.php?threads/multiple-network-interfaces-on-a-single-subnet.20204/

___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Incorrect route interface

[Rodney W. Grimes]

> 
> On 11/03/2018 20:57, Marek Zarychta wrote:
> > On Sun, Mar 11, 2018 at 05:46:52PM +, Grzegorz Junka wrote:
> >> On 11/03/2018 06:04, Eugene Grosbein wrote:
> >>> 11.03.2018 7:01, Grzegorz Junka wrote:
> >>>
> > Just do not assign addresses from same network 10.20.0.0/16 to 
> > different network interfaces
> > and you will be fine. Assign them all to right interface:
> >
> > ifconfig_em0="inet 10.20.2.14 netmask 255.255.0.0"
> > ifconfig_em0_alias0="inet 10.20.2.15/32"
> > ifconfig_igb0_alias0="inet 10.20.2.16/32"
> >>> Interfaces meant to be all equal, last line should be:
> >>>
> >>> ifconfig_em0_alias1="inet 10.20.2.16/32"
> >>>
> >> OK, I see. So this is in case I want many IPs assigned to the same
> >> interface. What if I want one IP assigned to multiple interfaces (i.e.
> >> so that the additional igb0-3 effectively work as a 4-port switch)?
> >>
> > Please consider bonding all NICs as one bridge(4) interface. Then
> > multiple IPs could be assigned to such interface.
> >
> 
> Many thanks Eugene and Marek for your suggestions. I will now need to 
> decide if I want to fragment the network into subnets or bridge the 
> interfaces.
> GregJ

I believe some of the problem you are experincing is addressed
in this differential:
https://reviews.freebsd.org/D14547

Your original configuration was(is) valid, just not common,
and I have not seen this done in more than a decade, but it
seems as if rstone@ also has someone doing this "multiple IP's
into same subnet on seperate interfaces".


-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 218517] ppp fails adding route with error Value too large to be stored in data type

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218517

--- Comment #33 from commit-h...@freebsd.org ---
A commit references this bug:

Author: eugen
Date: Mon Mar 12 17:37:39 UTC 2018
New revision: 330805
URL: https://svnweb.freebsd.org/changeset/base/330805

Log:
  MFC r329105: ppp(8): fix code producing debugging logs

ppp(8): fix code producing debugging logs

Fix several cases when long buffer is copied to shorter one
using snprintf that results in contents truncation and
clobbering unsaved errno value and creation of misleading logs.

  PR:   218517
  Approved by:  mav (mentor)

Changes:
_U  stable/10/
  stable/10/usr.sbin/ppp/defs.h
  stable/10/usr.sbin/ppp/iface.c
  stable/10/usr.sbin/ppp/ip.c
  stable/10/usr.sbin/ppp/ipv6cp.c
  stable/10/usr.sbin/ppp/ncpaddr.c
  stable/10/usr.sbin/ppp/route.c

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 218517] ppp fails adding route with error Value too large to be stored in data type

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218517

--- Comment #32 from commit-h...@freebsd.org ---
A commit references this bug:

Author: eugen
Date: Mon Mar 12 17:36:37 UTC 2018
New revision: 330804
URL: https://svnweb.freebsd.org/changeset/base/330804

Log:
  MFC r329105: ppp(8): fix code producing debugging logs

ppp(8): fix code producing debugging logs

Fix several cases when long buffer is copied to shorter one
using snprintf that results in contents truncation and
clobbering unsaved errno value and creation of misleading logs.

  PR:   218517
  Approved by:  mav (mentor)

Changes:
_U  stable/11/
  stable/11/usr.sbin/ppp/defs.h
  stable/11/usr.sbin/ppp/iface.c
  stable/11/usr.sbin/ppp/ip.c
  stable/11/usr.sbin/ppp/ipv6cp.c
  stable/11/usr.sbin/ppp/ncpaddr.c
  stable/11/usr.sbin/ppp/route.c

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 218517] ppp fails adding route with error Value too large to be stored in data type

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218517

Eugene Grosbein  changed:

   What|Removed |Added

 Status|Open|In Progress

--- Comment #31 from Eugene Grosbein  ---
(In reply to emikulic from comment #9)

Note that https://bugs.freebsd.org/bugzilla/attachment.cgi?id=190932 has
already been merged to stable/10 with r329913. Please test and respond.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"