Wrong broadcast address

[virgiledelplace]

Hello community,

i got a problem with the IPAddress lib, i dont know if it's a bug, or just a mistake from me.

I have this address ' 46.17.68.76/31 ', i want to have the broadcast addess, then i make :

network = "46.17.68.76/31"
@ip     = IPAddress.parse(network)
puts @ip.broadcast 

the output : @address="255.255.255.255"

but for me the broadcast address for ' 46.17.68.76/31 ' is : 46.17.68.77

Thank's for your help!

[crosson]

The broadcast actually should be 255.255.255.255 on /31 links. The library is correct and I think I asked this same question some time back and a kind gentlemen pointed this out.

Checkout and search for section section 4.3.3.9,

[virgiledelplace]

The broadcast actually should be 255.255.255.255 on /31 links. The library is correct and I think I asked this same question some time back and a kind gentlemen pointed this out.

Checkout and search for section section 4.3.3.9,

I don't find your question, can you give me the link pls ?

[crossonST]

Yes I looked earlier today. I could be wrong on memory. It was a very long time ago.

At any rate it looks be behaving correctly in line with rfc3021.

[virgiledelplace]

Yes I looked earlier today. I could be wrong on memory. It was a very long time ago.

At any rate it looks be behaving correctly in line with rfc3021.

Yes i look this rules, but i dont understand how, it's work for /30 -> output : 46.17.68.79
But with /31, he output 255.255.255.255 ...

[crosson]

Are you curious where this is done in the library? Or curious why /30 behaves differently? A /30 has 4 addresses so you have an address for a network, two hosts, and a broadcast. It doesn't have the problem defined inrfc3021. So yes /31 and /30 behave differently as they should.

[msimkins]

Typically a /31 is a point to point network in either a VPN tunnel or a TDM (non Ethernet) Network, so there is really no concept of a broadcast address

…

Sent from my iPhone

On 28 Nov 2018, at 17:54, crosson ***@***.***> wrote: Are you curious where this is done in the library? Or curious why /30 behaves differently? A /30 has 4 addresses so you have an address for a network, two hosts, and a broadcast. It doesn't have the problem defined inrfc3021. So yes /31 and /30 behave differently as they should. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[virgiledelplace]

Hello guys,

thank's for your feedback.

Following your response, I discussed it with our network expert.

We use the / 31s with nat IP addresses, and the library works with direct ip addresses if I understood correctly.

So the library just does not work with how we use our IP addresses, I will try to modify the library to respond our needs, I will fork if it can serve.

Thank you.

[crossonST]

IDK if this helps at all but instead of using the broadcast object to get the last IP you could use the entries method.

Instead of
net.broadcast.address

Use

irb(main):014:0> net = IPAddress "192.168.1.0/31"
=> #<IPAddress::IPv4:0x00000000b30498 @address="192.168.1.0", @prefix=31, @octets=[192, 168, 1, 0], @u32=3232235776>
irb(main):015:0> net.entries.first.address
=> "192.168.1.0"
irb(main):016:0> net.entries.last.address
=> "192.168.1.1"
irb(main):017:0> net.entries
=> [#<IPAddress::IPv4:0x00000000b07f48 @address="192.168.1.0", @prefix=31, @octets=[192, 168, 1, 0], @u32=3232235776>, #<IPAddress::IPv4:0x00000000b07430 @address="192.168.1.1", @prefix=31, @octets=[192, 168, 1, 1], @u32=3232235777>]
irb(main):019:0> addresses = net.collect { |o| o.address }
=> ["192.168.1.0", "192.168.1.1"]
irb(main):020:0>

Which will return each object in your network inside an array which you can iterate over.