[HELP] How to change boot mode to SdxR5?

[Zare]

You're just not getting it.

When you input address and netmask for network configuration for an interface, networking stack will calculate all the possible addresses that belong to that network. Meaning input 10.0.0.1/24, and OS will mark down IPs 10.0.0.1-254 as broadcast domain, hosts that are directly reachable over layer 2 without routing.

So input 192.168.0.1/8, and OS will think that all IPs DutchDaemon mentioned are directly reachable.

If you have IP 192.168.0.10 and netmask 255.255.0.0, and you try to connect to 192.1.122.17, OS will see that IP doesn't belong to the calculated reachable hosts, and forward those packets to appropriate gateway. On the other hand, if your netmask is 255.0.0.0, that IP becomes part of the whole subnet, meaning OS thinks it's directly reachable. So it won't forward packets to NAT gateway, it'll broadcast an ARP-WHOHAS over layer 2. Normally, no-one is going to answer, since that host is out of your layer 2 domain. And you've effectively severed communications between that box and 16 million Internet IPs.

This whole thing doesn't have anything to do with NAT, it's basic network addressing. Yes, your router won't send packets with private IP originators to WAN, and yes, if it does, ISP will filter them out, but those packets never reach NAT because system thinks they are inside a local network, not destined for outside.

I am sorry if I sound rude, but if you still can't grasp this, then please take two boxes, connect them via crossover cable, configure one as 192.168.0.40 / 255.255.255.0, other 192.168.0.20 / 255.255.255.224. Try to ping between them. I never had reason to do so, but I can predict that you're going to get a "no route to host" error. Because of the netmask, valid range of IPs would be 192.168.0.1 to 192.168.0.30. System will think that destined IP doesn't belong to local network and will try to route the stuff through default gateway, which in this case isn't even configured, so it won't have a route. That's the opposite example, where you cut out a LAN host because of a wrong netmask. In this case, system thinks that's somewhere out, while in original example we're talking about, system thinks that Internet destination is somewhere inside.

 

[bbzz]

You're just not getting it.

When you input address and netmask for network configuration for an interface, networking stack will calculate all the possible addresses that belong to that network. Meaning input 10.0.0.1/24, and OS will mark down IPs 10.0.0.1-254 as broadcast domain, hosts that are directly reachable over layer 2 without routing.

So input 192.168.0.1/8, and OS will think that all IPs DutchDaemon mentioned are directly reachable.

If you have IP 192.168.0.10 and netmask 255.255.0.0, and you try to connect to 192.1.122.17, OS will see that IP doesn't belong to the calculated reachable hosts, and forward those packets to appropriate gateway. On the other hand, if your netmask is 255.0.0.0, that IP becomes part of the whole subnet, meaning OS thinks it's directly reachable. So it won't forward packets to NAT gateway, it'll broadcast an ARP-WHOHAS over layer 2. Normally, no-one is going to answer, since that host is out of your layer 2 domain. And you've effectively severed communications between that box and 16 million Internet IPs.

This whole thing doesn't have anything to do with NAT, it's basic network addressing. Yes, your router won't send packets with private IP originators to WAN, and yes, if it does, ISP will filter them out, but those packets never reach NAT because system thinks they are inside a local network, not destined for outside.

I am sorry if I sound rude, but if you still can't grasp this, then please take two boxes, connect them via crossover cable, configure one as 192.168.0.40 / 255.255.255.0, other 192.168.0.20 / 255.255.255.224. Try to ping between them. I never had reason to do so, but I can predict that you're going to get a "no route to host" error. Because of the netmask, valid range of IPs would be 192.168.0.1 to 192.168.0.30. System will think that destined IP doesn't belong to local network and will try to route the stuff through default gateway, which in this case isn't even configured, so it won't have a route. That's the opposite example, where you cut out a LAN host because of a wrong netmask. In this case, system thinks that's somewhere out, while in original example we're talking about, system thinks that Internet destination is somewhere inside.

No you aren't rude, you just aren't following what I am telling you. Read my post, #19. You are reiterating what I already briefly mentioned. We are beyond simple ARPing for local MAC. I know how packet forwarding works.
Mask affects local host and what it thinks about network it is connected to. This doesn't mean that you can't make that host forward packet nonetheless to your default gateway, no matter the mask. I can have 192.168.1.0/8 on my ethernet interface and still route just fine to Internet; the packets will reach my default gateway. And yes, it's easy to make those two hosts ping over your cable. Whether or not it's best practice, silly, stupid is another issue. It's just possible. And as long as you have NAT, packet will be routed to Internet.

 

[SirDice]

Mask affects local host and what it thinks about network it is connected to. This doesn't mean that you can't make that host forward packet nonetheless to your default gateway, no matter the mask.

How?

 

[bbzz]

How?

Well now, that would be too easy wouldn't it. I'll leave you experts to try to figure it out

 

[Zare]

Please, this is not a "who's smarter" contest, this is a discussion.

This doesn't mean that you can't make that host forward packet nonetheless to your default gateway, no matter the mask. I can have 192.168.1.0/8 on my ethernet interface and still route just fine to Internet; the packets will reach my default gateway. And yes, it's easy to make those two hosts ping over your cable. Whether or not it's best practice, silly, stupid is another issue.

Most of the things you can imagine are possible. That doesn't mean they're feasible, sane, logical, or just standards-compliant best practice. Having a /8 mask on any sub-class C private network is plain wrong, in production environment. In lab, sure, if you have reason to do so, but then we're talking about experimental situations.

If I ran into situation where I need to have 192.168.0.1/8 IP on local interface and still play fair with Internet hosts, I'd either calculate remaining subnets (192.1-167 and 169 to 254) and put manual routes to gateway, or leave the routing table as is and rewrite packets via bpf or alike.

In any case, that's not how it's done. Please, do tell what you had in mind and how would you integrate this faulty network configuration in working network.

 

[usdmatt]

@bbzz

Let's go back to the original reason this all came up -

The OP had an IP of 192.168.5.100/8 on his system. Now, we can reasonably assume he's connected to the Internet - he is posting to freebsd.org after all. We can also safely assume that he probably hasn't got manual routes for all the IP's in that range that are publicly assigned.

Therefore I think everyone would agree that SirDice was completely correct to notify the OP that his configuration was incorrect. He also pointed out that only 192.168/16 is assigned for private use, usually as /24 subnets. Your response to this (Post 12) was wrong.

Yes, you don't have to use /24 with that network, you can use 16,17,18 etc, but as soon as you go bigger than /16 you are covering public addresses. I get the feeling that you didn't realize this in your first 3 posts (they read as if you didn't see any issue with his configuration) - maybe you thought 192/8 was all private. Trying to justify the possibility of using network ranges that cover public & private addresses by adding manual routes or messing with packet filtering is just ridiculous. There's absolutely no reason to not just use RFC1918 addresses and I'm pretty sure that's what the OP would rather do.

 

[bbzz]

Please, this is not a "who's smarter" contest, this is a discussion.

No it isn't but for some reason you are misinterpreting my point.

Most of the things you can imagine are possible. That doesn't mean they're feasible, sane, logical, or just standards-compliant best practice. Having a /8 mask on any sub-class C private network is plain wrong, in production environment. In lab, sure, if you have reason to do so, but then we're talking about experimental situations.

Please be so kind and point me to post where I indicated that this is the best practice? I indicated that this is purely a food for thought, a situation which can be made to work. Having /8 on C class in production? Yeah, you bet it is retarded.

If I ran into situation where I need to have 192.168.0.1/8 IP on local interface and still play fair with Internet hosts, I'd either calculate remaining subnets (192.1-167 and 169 to 254) and put manual routes to gateway, or leave the routing table as is and rewrite packets via bpf or alike.

This won't work, because the /8 mask on local interface is administratively preferred over any static route you additionally created in routing table. Thus if this is Ethernet interface you still end up ARPing for MAC. It would work for you other crosscable scenario, though.

In any case, that's not how it's done.

Right; assuming that we are past that part, and you want a glimpse of how it could be done in the vicinity of your home

1) make a list of static addresses pointing to default gateway MAC thereby avoiding need for ARP.
2) create a tunnel sourced from your /8 interface and terminating to default gateway having more precises mask.
3) have a NAT function on one of your logical interfaces where the packets are looped to, thereby rewriting the ones you need. Once overwritten, only then send to gateway.

That's a couple of ones, all tested to work. And yes, changing to /8 mask is how it should be normally done.

 

[bbzz]

Yes, you don't have to use /24 with that network, you can use 16,17,18 etc, but as soon as you go bigger than /16 you are covering public addresses. I get the feeling that you didn't realize this in your first 3 posts (they read as if you didn't see any issue with his configuration) - maybe you thought 192/8 was all private. Trying to justify the possibility of using network ranges that cover public & private addresses by adding manual routes or messing with packet filtering is just ridiculous. There's absolutely no reason to not just use RFC1918 addresses and I'm pretty sure that's what the OP would rather do.

Actually my first reply was solely designated at SirDice's remark about RFC 1918. I simply wanted to say that it is not a rule and you can make it work. In other words it's not hard coded rule that you can't use /8 mask on class C, wanting to give some food for thought. Which unfortunately ended up in everyone trying to persuade me that's not how its done.
Also for all intents and purposes, a "private" range doesn't mean you can't use any public range on your private network if you wish, as long as you try and make sure it doesn't reach Internet. Private range means that any packet sources from that range won't be routed on Internet.

 

[Zare]

No it isn't but for some reason you are misinterpreting my point.

Not in last few posts. We're talking about netmasks and routing right now, basically off-topic from OPs original question.

Please be so kind and point me to post where I indicated that this is the best practice? I indicated that this is purely a food for thought, a situation which can be made to work. Having /8 on C class in production? Yeah, you bet it is retarded.

Nowhere, you said that "Whether or not it's best practice...", I am just confirming that it's not best practice and should be avoided. Just a general conclusion.

This won't work, because the /8 mask on local interface is administratively preferred over any static route you additionally created in routing table. Thus if this is Ethernet interface you still end up ARPing for MAC. It would work for you other crosscable scenario, though.

Probably, however the local destination, unrouted destinations, are also defined in routing table. Having both types of entries in routing table equals multipath routing, and it's possible to force larger weight on the local route with hacks. However not with standard userland tools.

1) make a list of static addresses pointing to default gateway MAC thereby avoiding need for ARP.

I don't know how my computer's networking stack would function with 16 million entries in ARP table.

2) create a tunnel sourced from your /8 interface and terminating to default gateway having more precises mask.

So all packets destined from that host to LAN would travel through gateway, inducing unnecessary load.

3) have a NAT function on one of your logical interfaces where the packets are looped to, thereby rewriting the ones you need. Once overwritten, only then send to gateway.

That's what I meant with packet rewrite in bpf. Basically this is the most logical option to go for, if you'd really want that host to have /8 mask inside LAN, and retain full Internet capability.

 

[bbzz]

Probably, however the local destination, unrouted destinations, are also defined in routing table. Having both types of entries in routing table equals multipath routing...

This doesn't make sense, or I'm not getting what you really mean. It doesn't matter what you have in routing table, it's never looked in as long as you have mask covering all ranges on your interface. As for the tools your talking about, maybe, I don't know..

I don't know how my computer's networking stack would function with 16 million entries in ARP table.

Pretty damn hard. Which is why you would make a list, covering all ranges in few entries rather than individual IP.

So all packets destined from that host to LAN would travel through gateway, inducing unnecessary load.

No, because only packets destined for Internet (those are the ones that will be assigned to tunnel with tighter mask) will be routed to gateway. Physically, all packets go over your Ethernet interface; logically, only those for external network go over tunnel. Packets not matching tunnel will still do what they would normally do, ARP for MAC over Ethernet.


Look no need to beat head over this anymore really. I made mistake for not being clear enough. Shouldn't been more careful about what I was trying to initiate.
Peace and out!

 

[Beeblebrox]

I fell asleep and went somewhere happy.

So, the verdict here is that this SdxR5 thing is legit, right?

 

[wblock@]

I fell asleep and went somewhere happy.

So, the verdict here is that this SdxR5 thing is legit, right?

I still want closure on that. What was it, where did it come from?

 

[DutchDaemon]

It's a ROT-13 of HaX0R.

(no, it's not)

 

[Ricky]

WOW! Big discussion going on out here...

First of all, SdxR5, as I already mentioned, doesn't exist! It was probably just a random name.

Now, about the editing my rc.conf. My IP is 192.168.5.1 and the netmask 255.0.0.0

I don't intend to connect to anyone! Others connect to me only, and so far no problems have occurred. Is my configuration delaying something? Like more lag or anything similar?

I'm using FreeBSD 7.0 on a virtual machine and using it as a game server. Sorry for all these questions but I'm not a hacker like you

 

[usdmatt]

No that configuration will not cause any lag or other issues when used completely standalone.

However, when you say only others connect to you, what do you mean - Are these people directly connected to your LAN, or do they connect to your game server over the Internet?

Either way, I just don't see any reason to use that mask with that network address.

If you use 192.168.x.x with 255.255.0.0 your network will be a valid private network allowing you to use addresses in the range 192.168.0.1 - 192.168.255.254. If you have a real reason for having a LAN that can handle over 65 thousand hosts then you can use 10.x.x.x with 255.0.0.0, which gives you everything from 10.0.0.1 to 10.255.255.254.