Sponsor Message:
Non Aviation Forum
My Starred Topics | Profile | New Topic | Forum Index | Help | Search 
Ubuntu Routing/network Problem  
User currently offlineAirstud From United States of America, joined Nov 2000, 2638 posts, RR: 3
Posted (1 year 7 months 2 days 11 hours ago) and read 1318 times:

Here I am in my apt building lobby using the free WiFi. My Panasonic Toughbook runs Ubuntu 10.04 and has built-in Wi-Fi, my Tecra 8000 (sitting next to me, Win2K) does not. I have set up a wired Ethernet connection between the two and they can ping each other. I have manually configured a Class C subnet on the Ubuntu machine's eth0 interface, 10.1.1.0/24. The Ubuntu machine's address is .1, the Tecra's is .2. The Tecra has 10.1.1.1 configured as its default gateway. The Ubuntu WiFi is using DHCP.

Yet I doubt that any of this addressing info matters; what's driving me batty is that the WiFi on the Ubuntu box shuts down whenever the wired eth0 interface is active. I have Firefox up, "trying to connect" to google.com, and it just keeps trying. Then when I click "disconnect" on the eth0 connection on the connections, menu.... (John Madden voice) BOOM!!

I want to install OpenOffice on my Tecra. I've gone mad trying to get my Zyxel WiFi CardBus adapter to work on the blamed thing, so I figured I could just bring both boxes to this here WiFi zone, connect the Ubuntu box to the web as I so often have done, then configure a routing daemon so the Tecra could get a web connection over the ethernet link to the Ubuntu box. And I am absolutely int the wilderness as to why my Ubuntu box won't allow two connections - over TWO DIFFERENT PHYSICAL INTERFACES - to work at the same time, and how to remedy this.

Any ideas?


Pancakes are delicious.
16 replies: All unread, jump to last
 
User currently offlinemoo From Falkland Islands, joined May 2007, 3874 posts, RR: 5
Reply 1, posted (1 year 7 months 2 days 11 hours ago) and read 1316 times:

Make sure that both the wifi and eth0 networks aren't trying to set a default route, as that would cause the issue you describe.

User currently offlineAirstud From United States of America, joined Nov 2000, 2638 posts, RR: 3
Reply 2, posted (1 year 7 months 2 days 11 hours ago) and read 1311 times:

Aha... point taken

(how do I check to see if they're trying to do that?)



Pancakes are delicious.
User currently offlinedamirc From Slovenia, joined Feb 2004, 724 posts, RR: 7
Reply 3, posted (1 year 7 months 2 days 9 hours ago) and read 1286 times:

Try netstat -rn to check for default routes. (check /etc/network/interfaces and under the "eth0" stanza comment out the "gateway" directive.

You'll need to enable ip routing ( /sbin/sysctl -w net.ipv4.ip_forward=1 )

Also, you'll need to use iptables to masquerade the Tecra's traffic going outbound towards the AP (if your wireless card's interface name is different, than substitute wifi0 for the appropriate name):

iptables -t nat -A POSTROUTING -o wifi0 -j MASQUERADE

To make sure everything works (don't suggest using this full time though):

iptables -P FORWARD ACCEPT

D.


User currently offlineKlaus From Germany, joined Jul 2001, 21412 posts, RR: 54
Reply 4, posted (1 year 7 months 2 days 8 hours ago) and read 1276 times:

Quoting Airstud (Thread starter):
I have manually configured a Class C subnet on the Ubuntu machine's eth0 interface, 10.1.1.0/24

That is not a class C address!

And that may well be the cause of your problem, since the network interface cannot use the NAT router this way and it will catch all traffic and thus block any secondary interface.

The router would normally have something like 192.xxx.xxx.yyy as the class C network range, with a net mask of 255.255.255.0, where 192.xxx.xxx is effectively the ID of the class C network and yyy the individual address of your machine within that network (the first byte can actually be 192...223 to indicate a class C network, but 192 is what most networks use).

Have the machine get its address via DHCP (which will almost certainly be set up in the router) and you will see the local network range. In most cases that is also the preferred mode of operation.

Usually you should also have the router and DNS server set automatically via DHCP if the router supports that properly. Manual changes are possible, but can be a source of problems if you don't know very well what you're doing.


User currently offlinedamirc From Slovenia, joined Feb 2004, 724 posts, RR: 7
Reply 5, posted (1 year 7 months 2 days 8 hours ago) and read 1270 times:

Quoting Klaus (Reply 4):
Quoting Airstud (Thread starter):
I have manually configured a Class C subnet on the Ubuntu machine's eth0 interface, 10.1.1.0/24
That is not a class C address!

The /24 (CIDR notation) is a 255.255.255.0 subnet, so technically a so called C class   (while I agree that RFC791 does specify network 192.0.0.0/3 as a C class range a /24 subnet is usually referred to as a C class no matter where in the address space it is).

So as long as his wifi address does not overlap with 10.1.1.0/24 he's good to go.

Quoting Klaus (Reply 4):

Have the machine get its address via DHCP (which will almost certainly be set up in the router) and you will see the local network range. In most cases that is also the preferred mode of operation.

His problem is that his W2000 box does not have wifi, and he wishes to use his primary notebook as the router between the said W2000 box and the wifi segment. DHCP is out of the question here. He could technically bridge the segments on his Ubuntu computer and then DHCP would be possible and there would be no need for routing, but I find that usually people have a harder time understanding (and working with) bridges than routing (and NATing).

D.


User currently offlineKlaus From Germany, joined Jul 2001, 21412 posts, RR: 54
Reply 6, posted (1 year 7 months 2 days 7 hours ago) and read 1261 times:

Quoting damirc (Reply 5):
The /24 (CIDR notation) is a 255.255.255.0 subnet, so technically a so called C class   (while I agree that RFC791 does specify network 192.0.0.0/3 as a C class range a /24 subnet is usually referred to as a C class no matter where in the address space it is).

No, it is not a class C network. It's class A, and in this case with an incorrect net mask being set.

I've not used routing daemons under Linux so far, so he'd have to check out its particulars separately, but the network configuration is already wrong.

Remedy:

• Set up WifFi on the Ubuntu machine via DHCP and look at its network ID (for instance, it might be 192.100.1.yyy) and choose a different class C network ID for your wired connection, such as 192.100.2.zzz, both with the proper net mask of 255.255.255.0 each.

• Manually set an address in that secondary class C range for the Ubuntu machine (zzz), but set no router or DNS server on that interface, since the Ubuntu machine shall not route any of its own internet traffic through it, only its own local traffic to the Tecra.

• Set up the routing daemon on the Ubuntu machine, routing your WiFi connection to that secondary class C network interface.

• If the routing daemon provides DHCP, have the Tecra use DHCP on its wired port and it should get an address in the newly set up secondary subnet, with the Ubuntu machine set as the server and likely also as the DNS (an external internet DNS server might also be used). If the routing daemon doesn't offer DHCP configuration, you may have to set the router and DNS addresses on the Tecra manually.

The Tecra should then work normally with the Ubuntu machine with its secondary class C network being its router.

The Ubuntu machine should route its own internet traffic through its WiFi router (since that is where it sees a router itself) and the routing daemon running on it should act as a router to the Tecra box on the wired interface.

The Ubuntu machine should also see the Tecra box by its 192.100.2.aaa address and should be able to talk to it.

Depending on the capabilities of the routing daemon it may also be able to provide access to any other machines in the primary class C subnet (in the example 192.100.1.xxx) by routing that as well, but in that case you'd have to set up a second subnet interface on the Tecra for that, and configure the routing daemon accordingly.

Note: The order of the network interfaces can also matter; On the Mac you can simply drag and drop the network interfaces into the desired order in the Network control panel; Under Linux I haven't modified the order yet, so I'd have to check where that configuration is done there.

[Edited 2012-12-30 08:30:49]

User currently offlinedamirc From Slovenia, joined Feb 2004, 724 posts, RR: 7
Reply 7, posted (1 year 7 months 2 days 7 hours ago) and read 1254 times:

Quoting Klaus (Reply 6):

No, it is not a class C network. It's class A, and in this case with an incorrect net mask being set.

Klaus. You really need to get off of your high horse. Any /24 subnet is referred to as a C class, just as well as any /16 is referred to as a B class and just as any /8 is referred to as an A class - and as said. While not technically conforming to RFC791 (writtein in 1981 mind you) it's a term generally used in IT. The key is the /24 network length, not where the network space is located.

And for the rest - why the heck would he run a dynamic-routing daemon (OSPF, RIP, BGP?!) for one single box? Overengineering the solution. If you mean routing itself - that is taken care with:

/sbin/sysctl -w net.ipv4.ip_forward=1
iptables -P FORWARD ACCEPT

And while your solution seems snazzy, you're forgetting one thing. The wireless access point/router will have no way of knowing how exactly to route the traffic originating from the Tecra back to the said Tecra unless you NAT it. So the Tecra will not be able to connect to the Internet in your proposal.

D.

[Edited 2012-12-30 08:40:49]

User currently offlineKlaus From Germany, joined Jul 2001, 21412 posts, RR: 54
Reply 8, posted (1 year 7 months 2 days 6 hours ago) and read 1237 times:

Quoting damirc (Reply 7):
Klaus. You really need to get off of your high horse. Any /24 subnet is referred to as a C class, just as well as any /16 is referred to as a B class and just as any /8 is referred to as an A class - and as said. While not technically conforming to RFC791 (writtein in 1981 mind you) it's a term generally used in IT. The key is the /24 network length, not where the network space is located.

Using irregular address ranges with non-matching network classes invites address range collisions, blocked access to parts of the regular network and some mechanisms potentially not working right.

One can disagree, but I see no reason to get personal about such basic technical matters. This is risky and a source of unnecessary complications, particularly when in fact the interface does not work correctly.

The primary issue here is the interface shadowing problem which may well be connected to exactly this. It seems like this is the main problem here, and that was what I was addressing.

Why don't you address that while you're at it, instead of focusing on personal digs?

The sequence of the respective interfaces is one factor, and each interface's address range and potentially configured routers matter, since on an outgoing access the interfaces are checked in order for a match to their respective address ranges. An "earlier" interface with an incorrectly set network ID and mask can indeed catch connection attempts and shadow the other interfaces, and the exact rules of interface matching are key here.

Apparently Airstud's wired interface is configured to catch all outgoing traffic (since eth0 is by default the first interface to be checked), which appears to be one of the problems here, so why don't you help out there?

On the Mac I would simply drag the WiFi interface to first place, re-check again (it should work again) and then have another look at the wired interface's address setup. Debugging under Linux would likely work similarly, I just haven't needed it there yet.

Quoting damirc (Reply 7):
And while your solution seems snazzy, you're forgetting one thing. The wireless access point/router will have no way of knowing how exactly to route the traffic originating from the Tecra back to the said Tecra unless you NAT it. So the Tecra will not be able to connect to the Internet in your proposal.

No. I was of course referring to a proper routing daemon including NAT, because that would be the only thing making any sense in that setup.

As I've said: I have not had a need for this kind of thing yet, so I have not researched the details under Linux there.

So if you have a simpler solution that actually works, please, dish!


User currently offlinemmedford From United States of America, joined Nov 2007, 561 posts, RR: 9
Reply 9, posted (1 year 7 months 2 days 6 hours ago) and read 1236 times:

Stupid question;

Why not get a wireless bridge and just connect to the Wifi network; and provide yourself a feed?

Something from Engenius and a 10+ dbi yagi antenna should be fine.



ILS = It'll Land Somewhere
User currently offlinedamirc From Slovenia, joined Feb 2004, 724 posts, RR: 7
Reply 10, posted (1 year 7 months 2 days 6 hours ago) and read 1228 times:

Quoting Klaus (Reply 8):
One can disagree, but I see no reason to get personal about such basic technical matters.

Sorry for it sounding personal. I could've answered differently - my mistake.

Quote:
So if you have a simpler solution that actually works, please, dish!

The solution is described in post #3.

D.


User currently offlineKlaus From Germany, joined Jul 2001, 21412 posts, RR: 54
Reply 11, posted (1 year 7 months 2 days 6 hours ago) and read 1221 times:

Quoting damirc (Reply 10):
Sorry for it sounding personal. I could've answered differently - my mistake.

Okay. Resolved.

Quoting damirc (Reply 10):
The solution is described in post #3.

What exactly does it do? Does it forward the local Wifi network to all interfaces, including broadcasts and thus the main router's DHCP?

I don't see eth0 specified explicitly and although I've seen many "howto"'s of that kind, I've not yet found an actual explanation of how this specific forwarding mechanism exactly operates.

[Edited 2012-12-30 09:57:02]

User currently offlinedamirc From Slovenia, joined Feb 2004, 724 posts, RR: 7
Reply 12, posted (1 year 7 months 2 days 5 hours ago) and read 1218 times:

Quoting Klaus (Reply 11):
What exactly does it do? Does it forward the local Wifi network to all interfaces, including broadcasts and thus the main router's DHCP?
/sbin/sysctl -w net.ipv4.ip_forward=1

enables the kernel to route traffic between (all!) interfaces.

iptables -P FORWARD ACCEPT

Tells the firewall to use ACCEPT as the policy for the FORWARD chain (ie: traffic whose ingress and egress interfaces differ). I suggested this since good security policies will typically set that to DROP or DENY. If he has a firewall installed (and it would be a good idea to have one) then this will allow the traffic to pass.

iptables -t nat -A POSTROUTING -o wifi0 -j MASQUERADE

... is trickier. So when a packet arrives from eth0, the kernel would check the router to see where to send the packet next (the default route is set to the wifi0 interface). Without using this command the packet would pass normally towards wifi0, but no response to it would be received, since the AP/router has no clue where to send the return packet. So what the above command does is - once the next hop is decided for a packet, if it exists through network interface wifi0 (-o wifi0) it is masqueraded (ie: it's source address is changed to the IP address of the wifi0 interface (technically it's a source NAT) and the communication tuplet (source ip, source port, destination ip, destination port, protocol) is entered into the connection tracking table so any response packets will automatically be redirected to the correct recipient (so a destination NAT happens and the packet is automatically rewritten).

D.


User currently offlineKlaus From Germany, joined Jul 2001, 21412 posts, RR: 54
Reply 13, posted (1 year 7 months 2 days 5 hours ago) and read 1212 times:

Quoting damirc (Reply 12):
/sbin/sysctl -w net.ipv4.ip_forward=1

enables the kernel to route traffic between (all!) interfaces.

Okay; Is it possible to specify only certain interfaces? In this case it won't matter, but in others it might.

Quoting damirc (Reply 12):
iptables -t nat -A POSTROUTING -o wifi0 -j MASQUERADE

... is trickier. So when a packet arrives from eth0, the kernel would check the router to see where to send the packet next (the default route is set to the wifi0 interface). Without using this command the packet would pass normally towards wifi0, but no response to it would be received, since the AP/router has no clue where to send the return packet. So what the above command does is - once the next hop is decided for a packet, if it exists through network interface wifi0 (-o wifi0) it is masqueraded (ie: it's source address is changed to the IP address of the wifi0 interface (technically it's a source NAT) and the communication tuplet (source ip, source port, destination ip, destination port, protocol) is entered into the connection tracking table so any response packets will automatically be redirected to the correct recipient (so a destination NAT happens and the packet is automatically rewritten).

Okay, thanks so far. Doesn't look entirely different from what I've described, just with onboard facilities.

But what about address assignment on the wired interface?

Is that to be configured manually, with manual setup of the Ubuntu machine as the known router on the client machine? And what about the apparent interface shadowing problem on the Ubuntu machine itself in that case? It would appear to remain unresolved.

Or is the Wifi subnet including router information also forwarded to the client automatically? DHCP broadcasts should normally not get through to the client via the kernel router, so how is that aspect done?


User currently offlinedamirc From Slovenia, joined Feb 2004, 724 posts, RR: 7
Reply 14, posted (1 year 7 months 2 days 5 hours ago) and read 1207 times:

Quoting Klaus (Reply 13):
Okay; Is it possible to specify only certain interfaces? In this case it won't matter, but in others it might.

Unfortunately not on this level. This just tells the kernel that it is allowed to route (IPv4) packets between interfaces. You are however able to filter what exactly is forwarded with iptables.

So while the suggested solution used iptables -P FORWARD ACCEPT (which enables all forwarding on all interfaces, but is not really advisable due to security concerns) you would then limit exactly what to forward like this:

iptables -X FORWARD
iptables -P FORWARD DROP (set the policy)
iptables -A FORWARD -i eth0 -s 10.1.1.0/24 -o wifi0 -j ACCEPT
iptables -A FORWARD -i wifi0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT

What this does:
-X FORWARD : flush the FORWARD table (effectively emptying it)
-P FORWARD DROP : by default do not forward packets between interfaces (unless an explicit rule exists)
-A FORWARD -i eth0 -s 10.1.1.0/24 -o wifi0 -j ACCEPT : pass (forward) all packets incoming from eth0 with a source address of 10.1.1.0/24 and outgoing to the wifi0 interface (remember, the routing table decided what the outgoing interface will be)
- A FORWARD -i wifi0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT : pass (forward) packets incoming from wifi0 and outgoing towards eth0, but whose states are related or established. iptables effectively peeks inside packets and decided whether a certain packet is allowed to be passed based on previous communications (unfortunately as in all firewalls this can be abused for UDP firewall piercing, but alas - best you can do with limited resources and still reasonably safe unless used in a high-security scenario where different rules and different firewall types come into play ).

Quote:
But what about address assignment on the wired interface?

Well, the OP stated that on his ubuntu machine he has 10.1.1.1/24 set and the Tecra already has 10.1.1.2/24 so we need not worry about it. If we'd have to allocate address, than a dhcpd bound to eth0 would work (of course configured for the network on eth0, but that's beyond the scope of the op's question).

Quote:
And what about the apparent interface shadowing problem on the Ubuntu machine itself in that case? It would appear to remain unresolved.

I suspect we're talking about interface overlap? Well, that's the duty of the OP to ensure that the wireless router's address does not fall into the 10.1.1.0/24 range (any other range will be fine).

Quote:
Or is the Wifi subnet including router information also forwarded to the client automatically? DHCP broadcasts should normally not get through to the client via the kernel router, so how is that aspect done?

You are correct, a DHCP broadcast would not get through (and it should not, since the IP address offered would be invalid for the wired segment) - a router separates broadcast domains. So on the wired segment in this case you would either employ static addressing (as the OP described) or use a dhcpd bound to the eth0 interface.

D.


User currently offlinecmf From , joined Dec 1969, posts, RR:
Reply 15, posted (1 year 7 months 2 days 5 hours ago) and read 1201 times:

Quoting Klaus (Reply 8):
Using irregular address ranges with non-matching network classes invites address range collisions, blocked access to parts of the regular network and some mechanisms potentially not working right.

Sub-netting is standard procedures.

Quoting Klaus (Reply 8):
This is risky and a source of unnecessary complications

The only risk is if you don't understand what you're doing, and then you had no business doing it to start with.

There is absolutely no difference in using a /24 net under 10.x.x.x than using a /24 under 192.168.x.x.


User currently offlineAirstud From United States of America, joined Nov 2000, 2638 posts, RR: 3
Reply 16, posted (1 year 7 months 11 hours ago) and read 1132 times:

I have not begun to digest all of the expert info posted here by Klaus and damirc.

I just can't tell you how sorely I wish I had specified in my original post that the WiFi interface is assigned via DHCP to a 192.168.bla.bla network.

I am also sore, though a little less so, that I used the term "Class C" to refer to what is more technically a 24-bit subnet of a Class A network. Though the fact that it was a 24-bit subnet I thought was sufficiently communicated by me specifying the exact subnet mask length I had assigned to the interface.

So with eth0 on 10.1.1.0/24 and wlan0 on 192.168.1.0/24, address range overlap ain't the issue here.

I will implement damirc's suggestions and report back.

Peace, dudes.



Pancakes are delicious.
Top Of Page
Forum Index

This topic is archived and can not be replied to any more.

Printer friendly format

Similar topics:More similar topics...
Wireless Network Problem posted Sat May 20 2006 20:21:36 by Cadet57
Internet Connection Problem On Network posted Tue May 18 2010 15:41:00 by TLG
Mac Network Connection Problem posted Mon Aug 4 2008 04:12:23 by Bill142
Network Printer Problem posted Wed Mar 14 2007 19:01:17 by Cba
A Math/Logic/Geometry Problem posted Sun Dec 2 2012 15:28:30 by timz
Mac IE Problem - Help Apple Geeks! posted Sun Sep 30 2012 03:19:00 by A320ajm
AT&T To Shut Down 2G GSM/GPRS/EDGE Network In 2017 posted Fri Aug 3 2012 13:45:34 by 1337Delta764
Ubuntu 10.10 Help? posted Fri Dec 17 2010 04:13:45 by ajd1992
Strange Problem With The Iphone4 posted Sat Nov 13 2010 13:14:32 by Springbok747
Want To Try Out Ubuntu/Linux. Experiences? posted Mon Oct 25 2010 16:19:11 by Fly2HMO