Re: [PLUG] Understanding Networking Components [SOLVED]
On Mon, 2 Apr 2012, Russell Johnson wrote: Nothing would be going out eth0, since it's not connected to anything, and, as per Rich's message, it's not in a running state. As I recall, the IPs Rich reported are in two different subnets, so, in theory, the IP stack should try both routes, if there are two routes in the routing table. Running 'ifconfig -a' showed routes for both eth0 and wlan0, but only the latter was RUNNING. So, as root, I ran 'ifconfig eth0 down' to remove the routes and ... voila! That was the problem. I've run linux on the previous 6 portables and did not have this issue with any of them, including my older Sony Vaio. But, this new Sony Vaio does have this issue. Now, what I'd like from you networking gurus is a script I can put in rc.local to test if wlan0 is RUNNING. And, if it is, to take down eth0. This way eth0 is taken out of the stack when the system boots and dhcpcd sees a WAP, but otherwise it is turned on and RUNNING to use the attached cable. Such a script is needed for the Sony's user because it requires no knowledge or skill to properly set up the networking interfaces. Thanks very much to all of you, Rich ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Understanding Networking Components [SOLVED]
Running 'ifconfig -a' showed routes for both eth0 and wlan0, but only the latter was RUNNING. So, as root, I ran 'ifconfig eth0 down' to remove the routes and ... voila! That was the problem. Now, what I'd like from you networking gurus is a script I can put in rc.local to test if wlan0 is RUNNING. And, if it is, to take down eth0. This way eth0 is taken out of the stack when the system boots and dhcpcd sees a WAP, but otherwise it is turned on and RUNNING to use the attached cable. I'm glad to hear you got this sorted out. If the interface is down (not running) any routes for that interface should not be included in the routing table. Which is what confused me and why I thought you had a stale route table cache entry. I cannot get my eth0 to go in / out of the running state by running ifup / ifdown, although it works with the loopback interface. Also, two default routes on the same network and I have no problems. :~# netstat -r Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 10.0.0.0* 255.255.255.0 U 0 0 0 wlan0 10.0.0.0* 255.255.255.0 U 0 0 0 eth0 default 10.0.0.10.0.0.0 UG0 0 0 eth0 default 10.0.0.10.0.0.0 UG0 0 0 wlan0 So if the only difference between your two laptops in terms of wireless, is the radio and more importantly the driver. Which you had problems with previously. I'm inclined to believe that driver is not functioning the way it should be. It shouldn't be in a running state unless there is physical connectivity and packets are flowing across the interface. As for the script idea, why not just remove the allow-hotplug eth0 statement from your /etc/network/interfaces file allow-hotplug eth0 iface eth0 inet dhcp When the Linux kernel detects the physical interface eth0, the * allow-hotplug* stanza causes ifup to bring up the interface. That should keep the interface down and trouble free. Then just plug in the cable and ifup eth0. ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Understanding Networking Components [SOLVED]
On Tue, 3 Apr 2012, Rich Shepard wrote: Now, what I'd like from you networking gurus is a script I can put in rc.local to test if wlan0 is RUNNING. And, if it is, to take down eth0. This way eth0 is taken out of the stack when the system boots and dhcpcd sees a WAP, but otherwise it is turned on and RUNNING to use the attached cable. I have a working script. It uses 'ip' to show what's on wlan0 and brings eth0 up or down depending on the results. Rich ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Understanding Networking Components [SOLVED]
On Tue, 3 Apr 2012, Mike Connors wrote: I cannot get my eth0 to go in / out of the running state by running ifup / ifdown, although it works with the loopback interface. On Slackware, using 'ifconfig eth0 up|down' I can. Also, two default routes on the same network and I have no problems. Same here with all hosts other than this one Sony Vaio. So if the only difference between your two laptops in terms of wireless, is the radio and more importantly the driver. Which you had problems with previously. I'm inclined to believe that driver is not functioning the way it should be. It shouldn't be in a running state unless there is physical connectivity and packets are flowing across the interface. The eth0 interface is not RUNNING, but the routes are there and so is the constipation. As for the script idea, why not just remove the allow-hotplug eth0 statement from your /etc/network/interfaces file 'Cause Slackware doesn't have that file. We have /etc/rc.d/rc.inet1.conf where the ethernet and wireless interfaces are configured (but the latter isn't in any case). May well be a still-immature driver since this version of the wireless chip came out only last November. I need a script to keep things simple for the user. And, I have such a script using 'ip' which I did not know existed before. Thanks, Rich ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Understanding Networking Components [SOLVED]
On Tue, Apr 3, 2012 at 1:33 PM, Rich Shepard rshep...@appl-ecosys.comwrote: On Tue, 3 Apr 2012, Mike Connors wrote: I cannot get my eth0 to go in / out of the running state by running ifup / ifdown, although it works with the loopback interface. On Slackware, using 'ifconfig eth0 up|down' I can. Also, two default routes on the same network and I have no problems. Same here with all hosts other than this one Sony Vaio. So if the only difference between your two laptops in terms of wireless, is the radio and more importantly the driver. Which you had problems with previously. I'm inclined to believe that driver is not functioning the way it should be. It shouldn't be in a running state unless there is physical connectivity and packets are flowing across the interface. The eth0 interface is not RUNNING, but the routes are there and so is the constipation. Actually you are wrong on this point. As you stated earlier today, once you 'ifconfig eth0 down' things worked. If that was truely the case then the interface was up but without a carrier. The routes would remain intact as the kernel doesn't know when or if the network carrier will return. ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Understanding Networking Components [SOLVED]
On Tue, 3 Apr 2012, Larry Brigman wrote: Actually you are wrong on this point. As you stated earlier today, once you 'ifconfig eth0 down' things worked. If that was truely the case then the interface was up but without a carrier. The routes would remain intact as the kernel doesn't know when or if the network carrier will return. Larry, I'm not a network admin so when I see that an interface is up but not running I assume it's not working. What I uderstand you tell me is that regardless of whether an interface is running, if it's up the kernel sees it. The Dell, and previous portables, have all been configured the same way and this issue never came up. Next time I have the Dell at a wifi hot spot I'll look at the routing table and see what it shows. Thanks, Rich ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Understanding Networking Components [SOLVED]
It shouldn't be in a running state unless there is physical connectivity and packets are flowing across the interface. The eth0 interface is not RUNNING, but the routes are there and so is the constipation. Actually you are wrong on this point. As you stated earlier today, once you 'ifconfig eth0 down' things worked. If that was truely the case then the interface was up but without a carrier. The routes would remain intact as the kernel doesn't know when or if the network carrier will return. Larry - I also found that statement confusing, however from my own testing I think it's behaving that way do the static ip config of eth0. With a static ip addr config for eth0 in /etc/network/interfaces, ifup / ifdown will insert and remove the default route. However, the state as shown by ifconfig never shows as running because there is no carrier. However, if there wasn't a static ip addr config for eth0 and it was up I would expect no routes for that interface to be injected in the routing table because there's nothing configured and with no carrier, the eth0 interface isn't learning any routes to propagate. ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Understanding Networking Components [SOLVED]
Yes, you are correct. A static config won't take the interface down so it won't flush the routes. On Apr 3, 2012 5:28 PM, Mike Connors mconno...@gmail.com wrote: It shouldn't be in a running state unless there is physical connectivity and packets are flowing across the interface. The eth0 interface is not RUNNING, but the routes are there and so is the constipation. Actually you are wrong on this point. As you stated earlier today, once you 'ifconfig eth0 down' things worked. If that was truely the case then the interface was up but without a carrier. The routes would remain intact as the kernel doesn't know when or if the network carrier will return. Larry - I also found that statement confusing, however from my own testing I think it's behaving that way do the static ip config of eth0. With a static ip addr config for eth0 in /etc/network/interfaces, ifup / ifdown will insert and remove the default route. However, the state as shown by ifconfig never shows as running because there is no carrier. However, if there wasn't a static ip addr config for eth0 and it was up I would expect no routes for that interface to be injected in the routing table because there's nothing configured and with no carrier, the eth0 interface isn't learning any routes to propagate. ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Understanding Networking Components
Please explain to me how the ethernet interface could interfere with the wireless interface. I must be missing something critical here because they're on different interfaces (eth0 and wlan0), and while both are UP, only one is RUNNING. Thanks, Rich There can be more than 1 default route in the routing table. This often the done in a mult-nic configuration as each ip network will have a gateway of last resort. The problem here is that your route table has cached the default route for eth0, eth0 is not connected to any network and that interface is being preferred either based on metric or just because that interface is listed in the routing table first based on alphanumeric sequence. Which when I statically configure eth0 on the same ip net as wlan0, my routing table now shows eth0 default route listed first... 0.0.0.0 10.0.0.10.0.0.0 UG0 0 0 eth0 0.0.0.0 10.0.0.10.0.0.0 UG0 0 0 wlan0 The routing table makes the decision on which interface to send packets out based on metrics. If the default route for eth0 is lower than wlan0 than that's the interface the routing table sends the packets to. I'm not sure if metrics are assigned automatically in sequential order by interface name such that eth0 would always have a lower metric than wlan0. I did some of my own testing and here's what I've discovered. 1. I added a static ip addr stanza for eth0 to /etc/network/interfaces and then brought up eth0 without it being physically connected. ~# ifconfig eth0 Link encap:Ethernet HWaddr 00:15:58:82:11:2e inet addr:192.168.1.10 Bcast:192.168.1.255 Mask:255.255.255.0 Here's the routing table w. 2 default routes on different nets with both Default Routes have a metric of 0: :~# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 10.0.0.00.0.0.0 255.255.255.0 U 0 0 0 wlan0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 00 eth0 0.0.0.0 10.0.0.10.0.0.0 UG0 0 0 wlan0 0.0.0.0 192.168.1.1 0.0.0.0 UG0 0 0 eth0 Traceroute shows packets are being routed out wlan0 interface: :~# traceroute www.google.com traceroute to www.google.com (74.125.127.104), 30 hops max, 60 byte packets 1 10.0.0.1 (10.0.0.1) 2.000 ms 1.997 ms 2.060 ms 2 * * * 3 te-0-0-0-6-ur03.troutdale.or.bverton.comcast.net (68.85.150.177) 10.373 ms 16.574 ms 17.475 ms So, it seems you have a stale route table cache entry for eth0 that is buggering up your routing. I suspect if you run a traceroute you'll see packets attempting to go via eth0? What happens if you run this command to flush the routing table cache and then connect to the wlan? ip route flush scope global type unicast Oddly enough, even with 2 default routes on the same ip net, packets are still be routed through wlan0. I didn't expect this to be the case. Maybe the superior intelligence of Debian? ;-P :~# route Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 10.0.0.0* 255.255.255.0 U 0 00 wlan0 10.0.0.0* 255.255.255.0 U 0 00 eth0 default 10.0.0.10.0.0.0 UG0 00 eth0 default 10.0.0.10.0.0.0 UG0 00 wlan0 :~# traceroute google.com traceroute to google.com (173.194.33.38), 30 hops max, 60 byte packets 1 10.0.0.1 (10.0.0.1) 0.930 ms 1.703 ms 2.005 ms 2 * * * 3 te-0-0-0-6-ur03.troutdale.or.bverton.comcast.net (68.85.150.177) 17.533 ms 17.687 ms 17.684 ms 4 be-1-ur04.troutdale.or.bverton.comcast.net (68.85.243.170) 17.422 ms ae-4-0-ar03.beaverton.or.bverton.comcast.net (68. Cheers, Mike ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Understanding Networking Components
On Sun, 1 Apr 2012, Russell Senior wrote: If they are both configured for the same network, Russell, They're not. The ethernet is configured for use here, the wireless is not donfigured for any specific network because it needs to work [any|every]where. You hand it a packet with a destination address. It says, hey, wtf? I have two interfaces that are configured to deliver to that address! I give up! or something like that. Today I'll capture the display of 'route -n' and post it here. What I saw yesterday as the default gatewey for wlan0 was 10.5.70.1 and the default gateway for eth0 was 192.168.55.4. Thanks, Rich ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Understanding Networking Components
Today I'll capture the display of 'route -n' and post it here. What I saw yesterday as the default gatewey for wlan0 was 10.5.70.1 and the default gateway for eth0 was 192.168.55.4. Try and open another term window and run tcpdump on the eth0 interface while making some connection attempts to verify if or if not traffic is traversing that interface. Also, if it was not mentioned in earlier posts, the correct way to verify iptables is iptables -L. You might also want to manually inject something like the OpenDNS public DNS servers to use in /etc/resolv.conf (*208.67.222.222 and 208.67.220.220)* ~ Jen ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Understanding Networking Components
On Apr 1, 2012, at 1:03 PM, Rich Shepard wrote: As before, cannot ping any address on the local Class A network (nor any world-addressible domain name or IP address). Trying to ping the gateway (10.5.70.1) results in 'Destination unreachable'; trying the namesever (8.8.8.8) results in 'Destination not reachable'. This is probably normal, as the network is probably configured to not allow you to connect to anything until you accept the Terms and Conditions agreement. This would include other IPs on the local network, except for the server that provides the TC. Have you verified with another patron as to what their DNS servers are set to? If you've answered this previously, I've missed the answer. Russell Johnson r...@dimstar.net ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Understanding Networking Components
On Mon, 2 Apr 2012, Russell Johnson wrote: Have you verified with another patron as to what their DNS servers are set to? If you've answered this previously, I've missed the answer. Russell, No one else with a computer when I'm there. And, I suspect they'd look completely puzzled because they have no idea what 'DNS server' means. :-) Rich ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Understanding Networking Components
On Apr 2, 2012, at 10:20 AM, Rich Shepard wrote: No one else with a computer when I'm there. And, I suspect they'd look completely puzzled because they have no idea what 'DNS server' means. :-) Well, I also noticed in a message post what I replied to that you plan on taking both the working Dell and the non-working Sony to compare. That should facilitate finding the answer to that question. I just find it highly irregular that they would specify a DNS server that is external to the network, and then give a domain name that would require a call to that DNS server, before you are allowed to pass traffic through the gateway. These networks have to have their own DNS server, or at least a proxy DNS server to redirect traffic until you've accepted the TC. Otherwise, the whole security model breaks down. And yes, I use the term security model very loosely. Russell Johnson r...@dimstar.net ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Understanding Networking Components
Russell Johnson wrote: On Apr 2, 2012, at 10:20 AM, Rich Shepard wrote: No one else with a computer when I'm there. And, I suspect they'd look completely puzzled because they have no idea what 'DNS server' means. :-) Well, I also noticed in a message post what I replied to that you plan on taking both the working Dell and the non-working Sony to compare. That should facilitate finding the answer to that question. I just find it highly irregular that they would specify a DNS server that is external to the network, and then give a domain name that would require a call to that DNS server, before you are allowed to pass traffic through the gateway. These networks have to have their own DNS server, or at least a proxy DNS server to redirect traffic until you've accepted the TC. Otherwise, the whole security model breaks down. And yes, I use the term security model very loosely. Russell Johnson r...@dimstar.net Rich, I am wondering what permissions you leave the resolv.conf file in when you create it in the rc.local for your home. Does your network manager have access to the file afterwards? Ken ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Understanding Networking Components
On 2012-04-02 09:06, jen montserrat wrote: Today I'll capture the display of 'route -n' and post it here. What I saw yesterday as the default gatewey for wlan0 was 10.5.70.1 and the default gateway for eth0 was 192.168.55.4. Try and open another term window and run tcpdump on the eth0 interface while making some connection attempts to verify if or if not traffic is traversing that interface. Also, if it was not mentioned in earlier posts, the correct way to verify iptables is iptables -L. considering his current problems `iptables -n -L` to not do hostname lookups. -- Michael Rasmussen http://www.jamhome.us/ Be Appropriate Follow Your Curiosity ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Understanding Networking Components
Mike == Mike Connors mconno...@gmail.com writes: Mike I'm curious if Russell Senior or anyone else involved with Mike Personal Telco wifi ap setup can weigh in on how the the captive Mike portal works for their WAPs and if a local DNS call is made or Mike not. We don't even know for sure that the cafe Rich is going to has a captive portal. They are fairly unusual in coffee shop scenarios these days, since small operations mostly just buy an AP and plug it in. I understand that FreeGeek is using NoCatAuth (as we do), but I have no idea about Rich's random coffee shop. I'm still leaning towards the PEBKAC theory, or some custom foot-ventilation, but without objective diagnostics, it is impossible to say. -- Russell Senior, President russ...@personaltelco.net ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Understanding Networking Components
jen == jen montserrat jen.montser...@gmail.com writes: jen [...] You might also want to manually inject something jen like the OpenDNS public DNS servers to use in /etc/resolv.conf jen (*208.67.222.222 and 208.67.220.220)* *If* the problem is related to a captive portal, you probably do *NOT* want to use public DNS servers, since access to those will be blocked until you've negotiated the captive portal. Of course, we don't know that a captive portal is even implicated here. -- Russell Senior, President russ...@personaltelco.net ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Understanding Networking Components
On Apr 2, 2012, at 12:32 PM, Mike Connors wrote: But if the first ip packets from Rich's computer go out eth0, they will never make in to the WAP DHSP server and be redirected to the captive portal. It's possible, depending on how the captive portal works and how it's configured that a call to an internal DNS server doesn't need to happen. However, the wlan0 interface IS getting a response from the DHCP server, or it would not have an IP address. Nothing would be going out eth0, since it's not connected to anything, and, as per Rich's message, it's not in a running state. As I recall, the IPs Rich reported are in two different subnets, so, in theory, the IP stack should try both routes, if there are two routes in the routing table. Rich has also stated the host name (not the IP address) of the captive portal TC page. This would require at least one call to some DNS server, to give the network stack someplace to go. My theory is that something is not setting the resolv.conf properly. This could be caused by a race condition. As I recall, Rich has a resolv.conf that gets swapped in by rc.local. If the network finishes configuring prior to rc.local running, then it's possible that rc.local is overwriting the DHCP configured resolv.conf. Then, once DNS is broken, everything appears broken. Then again, I might be all wet. Russell Johnson r...@dimstar.net ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Understanding Networking Components
But if the first ip packets from Rich's computer go out eth0, they will never make in to the WAP DHSP server and be redirected to the captive portal. It's possible, depending on how the captive portal works and how it's configured that a call to an internal DNS server doesn't need to happen. However, the wlan0 interface IS getting a response from the DHCP server, or it would not have an IP address. Nothing would be going out eth0, since it's not connected to anything, and, as per Rich's message, it's not in a running state. As I recall, the IPs Rich reported are in two different subnets, so, in theory, the IP stack should try both routes, if there are two routes in the routing table. Rich has also stated the host name (not the IP address) of the captive portal TC page. This would require at least one call to some DNS server, to give the network stack someplace to go. My theory is that something is not setting the resolv.conf properly. This could be caused by a race condition. As I recall, Rich has a resolv.conf that gets swapped in by rc.local. If the network finishes configuring prior to rc.local running, then it's possible that rc.local is overwriting the DHCP configured resolv.conf. Then, once DNS is broken, everything appears broken. Yes, the DHCP client, which sends out a DHCP broadcast on the WLAN is getting a DHCP response back in wlan0. But, if it's in fact a captive portal, then Rich's laptop will have an ip addr on a quarantined subnet that is managed by the dhcp server. He would need to then have ip connectivity back out through wlan0 to the wap/dhcp server to be redirected to the captive portal page. But I think the strongest clue that it's most likely an ip connectivity issue is the fact that he can't ping the default gateway, which is probably the WAP, dhcp server, router, captive portal all in one. This tells me his laptop is isolated from the network. Routing is done based on the routing entries in the routing table. The routing algorithm doesn't take into account whether the interface is connected. If there's an route entry defined in the routing table for a disconnected interface the routing table manager will use it in it's routing decision for a locally connected network. Dynamic, higher-end routing protocols not withstanding. In theory, the IP stack should try both routes, if there are two routes in the routing table. Routing works by way of longest match, meaning the most specific route. If there's no specific route defined for the dest ip addr, then packets are routed out via the default gateway. If you have 2 default gateways, one will take precedence. The only time that theory is true, is if it's a broadcast message, such as DHCP, where the packets are broadcasted out all the interfaces. The point of a router and routing protocols is to have some intelligence around which packets get routed out which interfaces. Otherwise, we'd just build the internet by connecting a bunch of hubs together and have one big LAN. ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Understanding Networking Components
On Mon, 2 Apr 2012, Mike Connors wrote: But I think the strongest clue that it's most likely an ip connectivity issue is the fact that he can't ping the default gateway, which is probably the WAP, dhcp server, router, captive portal all in one. This tells me his laptop is isolated from the network. Mike, Russell J, Russell S, et al.: In my naivte about the subtleties of wireless networking I'm floundering in a sea of good ideas offered by all of you. Obviously, my knowledge is but a small fraction of what's needed to resolve this issue. I am willing to bring the Sony and my Dell to any wifi hot spot in the area to meet one of you and have you work with me in figuring out the problem. It will probably take only a short time to fix with someone who knows much more than do I about wireless connectivity at the keyboard. The location is probably immaterial; the coffee shop on the corner of 242nd and Stark is where I've been. My friend tries to connect at a coffee shop in downtown Gresham. I'll drive to Portland to meet anyone willing to devote the time to work this out ... and I'll buy the coffee (or lunch). Rich ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Understanding Networking Components
The location is probably immaterial; the coffee shop on the corner of 242nd and Stark is where I've been. My friend tries to connect at a coffee shop in downtown Gresham. I'll drive to Portland to meet anyone willing to devote the time to work this out ... and I'll buy the coffee (or lunch). Rich if you want to drive to the tigard region, I'd be happy to take a shot at it. I don't know much about wireless, but I do know about network routing and that seems more the area you're having trouble with. Either way, I may be able to spot trouble that has flown under your radar. -wes ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Understanding Networking Components
On Mon, Apr 02, 2012 at 02:42:36PM -0700, Rich Shepard wrote: The location is probably immaterial; the coffee shop on the corner of 242nd and Stark is where I've been. My friend tries to connect at a coffee shop in downtown Gresham. I'll drive to Portland to meet anyone willing to devote the time to work this out ... and I'll buy the coffee (or lunch). Until Easter Belgian Abbey beer would count as lunch. At least according to the fasting monks. -- Michael Rasmussen, Portland Oregon Other Adventures: http://www.jamhome.us/ or http://westy.saunter.us/ Fortune Cookie Fortune du jour: Absence of evidence is not evidence of absence. ~ Carl Sagan ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Understanding Networking Components
Rich == Rich Shepard rshep...@appl-ecosys.com writes: RichIn my naivte about the subtleties of wireless networking I'm Rich floundering in a sea of good ideas offered by all of Rich you. Obviously, my knowledge is but a small fraction of what's Rich needed to resolve this issue. If you would only provide the little things I ask for, the verbatim output of various commands, travel might be unnecessary. E.g. if you paste these into a shell, and then email PLUG the contents of the for-plug log files: script -c 'echo ip addr ; ip addr ; echo ip route ; ip route ; echo iwconfig ; iwconfig' for-plug.log script -c 'for i in $(ip route | grep default | cut -d -f3) 4.2.2.2 ; do echo ping $i ; ping -c5 $i ; done' for-plug2.log script -c 'echo lspci ; lspci ; echo lsmod ; lsmod' for-plug3.log then someone would have some basis for guessing what your problems are. RichI am willing to bring the Sony and my Dell to any wifi hot Rich spot in the area to meet one of you and have you work with me in Rich figuring out the problem. It will probably take only a short Rich time to fix with someone who knows much more than do I about Rich wireless connectivity at the keyboard. Personal Telco has a weekly meeting on Wednesday's at 6:30 pm. I think this week we are leaning towards Beulahland on NE 28th (a block or so north of Burnside). You are welcome to show up and someone can try to help you. -- Russell Senior, President russ...@personaltelco.net ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Understanding Networking Components
On Mon, 2 Apr 2012, Russell Senior wrote: E.g. if you paste these into a shell, and then email PLUG the contents of the for-plug log files: script -c 'echo ip addr ; ip addr ; echo ip route ; ip route ; echo iwconfig ; iwconfig' for-plug.log script -c 'for i in $(ip route | grep default | cut -d -f3) 4.2.2.2 ; do echo ping $i ; ping -c5 $i ; done' for-plug2.log script -c 'echo lspci ; lspci ; echo lsmod ; lsmod' for-plug3.log then someone would have some basis for guessing what your problems are. Tomorrow morning. Thanks, Rich ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Understanding Networking Components
The location is probably immaterial; the coffee shop on the corner of 242nd and Stark is where I've been. My friend tries to connect at a coffee shop in downtown Gresham. I'll drive to Portland to meet anyone willing to devote the time to work this out ... and I'll buy the coffee (or lunch). Rich The curiosity of this problem has got this cat and it's a good excuse as any for a bike ride. I don't get out that way very much either. I could meet you tomorrow. What time is good for you? ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Understanding Networking Components
On Mon, 2 Apr 2012, Mike Connors wrote: The curiosity of this problem has got this cat and it's a good excuse as any for a bike ride. I don't get out that way very much either. I could meet you tomorrow. What time is good for you? Mike, I work from home and have enough to do to keep me busy longer than I want to work each day, so any time will work for me. My work phone is 503-667-4517, cell phone 503-730-1423; I can provide directions or meet you some place between where you are and Troutdale. Thanks, Rich ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Understanding Networking Components
On Mon, 02 Apr 2012 13:31:41 -0700 Russell Senior russ...@personaltelco.net dijo: We don't even know for sure that the cafe Rich is going to has a captive portal. They are fairly unusual in coffee shop scenarios these days, since small operations mostly just buy an AP and plug it in. I understand that FreeGeek is using NoCatAuth (as we do), but I have no idea about Rich's random coffee shop. Yet when Rich was at the last Clinic my laptop (Fedora 16) was connected to the Free Geek wireless without a problem, and nevertheless we failed to figure out how to get his to connect. And when I say mine was connected without a problem, trust me when I say that I know zero about how this stuff works. If I can get my laptop connected just by cluelessly poking at GUI stuff, then there is something indeed strange going on. I have been following this thread, albeit without understanding most of it. I do note that several command line diagnostics have been suggested. Were Rich and I at the Clinic again we could run those commands on my computer and his and see where they produced different results. This might at least give us a clue where the problem lies. I also want to thank Rich for sharing his pain with PLUG. Per aspera ad astra (through difficulties to the stars). Tough problems are learning experiences for everyone. ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Understanding Networking Components
On Sat, 31 Mar 2012, Neal wrote: The point of my question was to verify that a default gateway was set properly on the WLAN. That is, the default WLAN gateway was set to a valid address on the WLAN subnet. If it's not you won't be able to access any IP (including DNS) that's not on the WLAN subnet. Just back from another unsuccessful attempt at the coffee shop. When the system boots it connects automatically to the shop's wifi server. The ESSID is 'WEBbeans-Silk Espresso', 'ifconfig wlan0' returns the IP address 10.5.70.104, broadcast address 10.5.70.255, and netmask 255.255.255.0. The kernel routing table (displayed in response to 'netstat -r') has 2 pairs of entries (default and broadcast) for the eth0 and wlan0 interfaces. For wlan0, default 10.5.70.1 10.5.70.0 * /etc/resolv.conf -- SET BY THE WIRELESS SERVER -- shows nameserver 8.8.8.8 nameserver 8.8.4.4 These are Google's nameservers so the WEBbean.com network does not provide their own DNS servers. The access card instructions are to make the connection, then invoke a browser to enter the provided password and accept their terms and conditions of use to be allowed access to the 'Net. This is where something is broken. No Web page loads with firefox-11.0, opera-10.61, links, or lynx. Can't load the access page, www.webbeans.com, or any other page. As before, cannot ping any address on the local Class A network (nor any world-addressible domain name or IP address). Trying to ping the gateway (10.5.70.1) results in 'Destination unreachable'; trying the namesever (8.8.8.8) results in 'Destination not reachable'. With an IP address, DNS servers, and gateway all assigned by the local server, what might inhibit loading the 'Net access control page or any other web page? Rich ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Understanding Networking Components
On Sun, Apr 1, 2012 at 1:03 PM, Rich Shepard rshep...@appl-ecosys.com wrote: With an IP address, DNS servers, and gateway all assigned by the local server, what might inhibit loading the 'Net access control page or any other web page? Since it is not clear exactly what the problem is, here are some semi-wild guesses. Maybe a local dns cache is causing problems. Are you running dnsmasq or nscd on the laptop? Or how about a firewall problem. What does iptables --list show? I usually use networkmanager, not wicd. Could wicd be misconfigured? Bill ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Understanding Networking Components
rshep...@appl-ecosys.com said: When the system boots it connects automatically to the shop's wifi server. The ESSID is 'WEBbeans-Silk Espresso', 'ifconfig wlan0' returns the IP address 10.5.70.104, broadcast address 10.5.70.255, and netmask 255.255.255.0. The kernel routing table (displayed in response to 'netstat -r') has 2 pairs of entries (default and broadcast) for the eth0 and wlan0 interfaces. For wlan0, default10.5.70.1 10.5.70.0 * /etc/resolv.conf -- SET BY THE WIRELESS SERVER -- shows nameserver 8.8.8.8 nameserver 8.8.4.4 You say 'netstat -r' has TWO pairs of entries. So you're not disabling the ethernet port? What's the full output of 'netstat -r'? Most likely the ethernet port is being used as the prefered route, and so nothing that's not specifically on the wlan network is going out. Seriously, you're making life way more difficult by trying to use hard-coded addresses with interfaces. You can still have fixed addresses, just serve them up by DHCP. Then interfaces and routing will just work, no matter where you are. For instance, what happens if you take your laptop someplace where you need to jack into a wired network? Everything in my house has a fixed IP address, and corresponding entries in the bind config files. But nothing is hard-coded - it's all handled by DHCP. When I add a new system to the network all I do is find the MAC address and add it to dhcpd.conf with an IP address I've selected. I plug the system in and =poof= it has the IP address I want it to have. john- ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Understanding Networking Components
On Sun, 1 Apr 2012, Bill Barry wrote: Since it is not clear exactly what the problem is, here are some semi-wild guesses. Bill, The problem is the Sony will not connect to any network via the wireless interface. Here and at three outside 'wifi hot spots' it will be issued a dynamic IP address (by the WAP, I presume), dns nameserver IP addresses, and routes to the gateway IP address (by the WAP or the sever behind it). Maybe a local dns cache is causing problems. Are you running dnsmasq or nscd on the laptop? /usr/bin/dnsmasq is present; there is no dnsmasq in the process list and every line of /etc/dnsmasq.conf is commented. Or how about a firewall problem. The portables do not run explicit firewalls. What does iptables list show? With what option? running 'iptables' returns nothing. Could wicd be misconfigured? Not likely. The WAPs are all unsecured and wicd connects, gets an IP address, gateway address, and nameservers. I can run 'dhcpcd wlan0' from the command line and get the same results. Specific question: do WAPs provide gateway IP addresses and set nameserver IP addresses in /etc/resolv.conf? If not, those must come from a server on the other side of the WAP from the laptop, correct? If gateways and nameservers are assigned from the network server, then the laptop is communicating to the server via the WAP. In this case, what portiong of the networking stack is missing and prevents access to the 'Net or a server Web page? Rich ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Understanding Networking Components
Rich, I missed the clue that you did not get wifi access at home either. I retract my guesses and concur with John Meissen. Your ethernet configuration is probably interfering with the wifi. Is your eth0 configuration set to come up and down automatically when the ethernet cable is plugged in and out or is it always configured ethernet cable or not? Bill ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Understanding Networking Components
On Sun, 1 Apr 2012, John Meissen wrote: You say 'netstat -r' has TWO pairs of entries. So you're not disabling the ethernet port? What's the full output of 'netstat -r'? No, because there's no connection on eth0. Most likely the ethernet port is being used as the prefered route, and so nothing that's not specifically on the wlan network is going out. Without an ethernet cable attached? Are you suggesting that I'm getting a 10.0.0.0 gateway from the wireless network via the eth0 interface with no cable connecting the two? I don't understand. Seriously, you're making life way more difficult by trying to use hard-coded addresses with interfaces. Really? Let me repeat: on no portable I've had has the wireless interface be configured to use anything other than DHCP. The wired interface, eth0, is used ONLY here in the office and we run static IP addresses on the LAN. Again, there is no cable attached to the ethernet port so I have difficulty understanding how any static IP address on that port, or gateways assigned to it, could affect connections via the wlan0 interface. Then interfaces and routing will just work, no matter where you are. Feh! Not true. For instance, what happens if you take your laptop someplace where you need to jack into a wired network? Networking works. This is the situation in the hotel where I stay in Reno. I plug in their cable to the port in my Dell, run 'dhcpcd eth0' and ... get a local IP address, a re-written /etc/resolv.conf with their nameservers, and local gateways in the kernel routing table. When I return to the office I copy /etc/resolv.conf.office to /etc/resolv.conf and I'm once again connected to my LAN. I've used static IP addresses here since 1997 with a bunch of different desktop machines and 7 different portables (3 Toshibas, 1 ThinkPad, 2 Sony Vaios, and the Dell Latitude). It is only the new Sony Vaio that has wireless issues everywhere. Each of the other 6 portables connected wirelessly everywhere. I'm happy you use DHCP, but it's not a universal requirement nor even necessary in my experience. Rich ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Understanding Networking Components
On Sun, 1 Apr 2012, Bill Barry wrote: I missed the clue that you did not get wifi access at home either. I retract my guesses and concur with John Meissen. Your ethernet configuration is probably interfering with the wifi. Is your eth0 configuration set to come up and down automatically when the ethernet cable is plugged in and out or is it always configured ethernet cable or not? The ethernet interface is RUNNING only when there's a cable attached. On the Toshiba, Sony, and Dell, ifconfig shows lo, eth0, and wlan0 at all times. Only lo and EITHER eth0 or wlan0 is RUNNING depending on whether there's an ethernet cable stuck in the side. The configuration of networking on the Sony is exactly the same as it is on the Dell except for the host IP address; they're both running Slackware-13.37/x86_64 and both have /etc/rc.d/rc.inet1.conf configured the same way but for the specific host IP address. Rich ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Understanding Networking Components
rshep...@appl-ecosys.com said: The ethernet interface is RUNNING only when there's a cable attached. On the Toshiba, Sony, and Dell, ifconfig shows lo, eth0, and wlan0 at all times. Only lo and EITHER eth0 or wlan0 is RUNNING depending on whether there's an ethernet cable stuck in the side. Yes, but apparently the routing information associated with it is still in the routing tables. You said so yourself - that there were two default routes, one for wlan and one for eth0. The TC/IP routing software is going to use what it finds in the routing table. If the destination doesn't match a specific network in the table, it will look for a default route. If, for some reason, it decides to prefer the eth0 route, that's where it's going to send the packet. When it gets to the physical layer it will find out it can't actually send it, and the transmission will fail. If the metric is the same for both default routes then it's very likely it just uses the first one, which may or may not correspond to how they're listed on the netstat output. You should only ever have one default route. john- ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Understanding Networking Components
On Sun, 1 Apr 2012, Bill Barry wrote: I missed the clue that you did not get wifi access at home either. I retract my guesses and concur with John Meissen. Your ethernet configuration is probably interfering with the wifi. Is your eth0 configuration set to come up and down automatically when the ethernet cable is plugged in and out or is it always configured ethernet cable or not? Bill, Please explain to me how the ethernet interface could interfere with the wireless interface. I must be missing something critical here because they're on different interfaces (eth0 and wlan0), and while both are UP, only one is RUNNING. Thanks, Rich ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Understanding Networking Components
On Sun, 1 Apr 2012, John Meissen wrote: The TC/IP routing software is going to use what it finds in the routing table. If the destination doesn't match a specific network in the table, it will look for a default route. John, Doesn't the TC/IP software look at the RUNNING interface? In the case of the Sony, the routing table has a default gateway for wlan0. If, for some reason, it decides to prefer the eth0 route, that's where it's going to send the packet. When it gets to the physical layer it will find out it can't actually send it, and the transmission will fail. This raises the question of why it would pick the non-running eth0 when there's a default gateway for the wlan0. And, shouldn't the OS turn off the eth0 routes when the system boots without an ethernet cable attached? Tomorrow I'll trek again to the local coffee shop and bring my Dell along, too. I'll see what the routing table shows for that. Or, I'll set up my local WAP (which I set unsecured) and test things here. As far as I can tell, both the Dell and Sony have networking configured the same way. Thanks, Rich ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Understanding Networking Components
rshep...@appl-ecosys.com said: Doesn't the TC/IP software look at the RUNNING interface? In the case of the Sony, the routing table has a default gateway for wlan0. No. TCP/IP doesn't know physical interfaces. It knows IP address. How the packet gets out onto a physical wire is someone else's problem. Yes, you have a default gateway for wlan0. But you said you ALSO had one for eth0. This raises the question of why it would pick the non-running eth0 when there's a default gateway for the wlan0. Because the routing table says it's available. And either it finds that route first, or it has a lower metric... And, shouldn't the OS turn off the eth0 routes when the system boots without an ethernet cable attached? Normally I would think so, yes. ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Understanding Networking Components
On Sun, 1 Apr 2012, John Meissen wrote: Yes, you have a default gateway for wlan0. But you said you ALSO had one for eth0. Because the routing table says it's available. And either it finds that route first, or it has a lower metric... OK. That makes sense. Tomorrow I'll bring both the Dell and Sony to the coffee shop; the former has worked for me everywhere I've used it (as long as I don't inadvertently turn off the radio switch on the front edge). I'll see if I can find differences. Thanks, Rich ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Understanding Networking Components
Rich == Rich Shepard rshep...@appl-ecosys.com writes: RichPlease explain to me how the ethernet interface could Rich interfere with the wireless interface. I must be missing Rich something critical here because they're on different interfaces Rich (eth0 and wlan0), and while both are UP, only one is RUNNING. If they are both configured for the same network, the network stack doesn't know which one to use. You hand it a packet with a destination address. It says, hey, wtf? I have two interfaces that are configured to deliver to that address! I give up! or something like that. How about showing us the output of a command that would remove the PEBKAC issue? What do: $ ip addr and $ ip route show when it is and isn't working? Install the iproute2 tools if you don't have them already. -- Russell Senior, President russ...@personaltelco.net ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Understanding Networking Components
Russell == Russell Senior russ...@personaltelco.net writes: Russell How about showing us the output of a command that would Russell remove the PEBKAC issue? Russell What do: Russell $ ip addr Russell and Russell $ ip route Russell show when it is and isn't working? Install the iproute2 Russell tools if you don't have them already. Oh, and throw in: $ iwconfig as well. -- Russell Senior, President russ...@personaltelco.net ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Understanding Networking Components
On Sat, Mar 31, 2012 at 1:25 PM, Rich Shepard rshep...@appl-ecosys.com wrote: This morning I spent about an hour at a local coffee shop with the same results: wlan0 was UP and RUNNING with the IP address of 10.5.70.104 and I don't currently know enough about linux networking to solve it for you, but what are the default gateway and subnet mask? NealS ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Understanding Networking Components
On Sat, 31 Mar 2012, Neal wrote: I don't currently know enough about linux networking to solve it for you, but what are the default gateway and subnet mask? NealS, The gateway and netmask are set by the DHCP server when it assigns an IP address to the host. I don't recall what they were. On the ethernet here everything's on static IP addresses and works flawlessly. Rich ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Understanding Networking Components
Are you running NoScript? I know that at PCC and MHCC, where some additional login information is needed, that I have to temporarily disable NoScript to access the final login page. I have to do the same thing at Red and Black too. Sent via BlackBerry from T-Mobile -Original Message- From: Rich Shepard rshep...@appl-ecosys.com Sender: plug-boun...@lists.pdxlinux.org Date: Sat, 31 Mar 2012 13:25:22 To: p...@pdxlinux.org Reply-To: Rich Shepard rshep...@appl-ecosys.com, General Linux/UNIX discussion and help; civil and on-topic plug@lists.pdxlinux.org Subject: [PLUG] Understanding Networking Components At the PLUG clinic last week the Sony Vaio laptop on the wireless interface, wlan0, received an IP address, had the Free Geek server provide content in /etc/resolv.conf, but would not load the Free Geek web page to accept their terms and conditions and gain access to the 'Net. This morning I spent about an hour at a local coffee shop with the same results: wlan0 was UP and RUNNING with the IP address of 10.5.70.104 and nameservers of 8.8.8.8 and 8.8.4.4. But, firefox would not load the netbeans.com gateway Web page, 'netstat -r' showed the gateways for wlan0, but ping and traceroute failed with both domain names and IP addresses (the first showed 56 bytes sent then froze, the latter told me the newwork was unreachable). I don't understand enough about networking to figure out the source of the problem. My experiences are that a non-working ping and/or traceroute telling me that the network is unreachable means the interface cannot find a DNS server to resolve the IP address. But, in this case, /etc/resolv.conf has name servers identified and both ping and traceroute fail when fed IP addresses, too. What might be the problem here, where there's an IP address issued by the DHCP server in response to a dhcpcd request by wicd, nameservers are assigned, but there's no ability to connect to a Web server or anywhere else? Thouroughly confused, Rich ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Understanding Networking Components
On Sat, Mar 31, 2012 at 2:10 PM, Rich Shepard rshep...@appl-ecosys.com wrote: On Sat, 31 Mar 2012, Neal wrote: I don't currently know enough about linux networking to solve it for you, but what are the default gateway and subnet mask? NealS, The gateway and netmask are set by the DHCP server when it assigns an IP address to the host. I don't recall what they were. On the ethernet here everything's on static IP addresses and works flawlessly. Rich, The point of my question was to verify that a default gateway was set properly on the WLAN. That is, the default WLAN gateway was set to a valid address on the WLAN subnet. If it's not you won't be able to access any IP (including DNS) that's not on the WLAN subnet. I think eduncliffe is on the right track about something you're running on firefox blocking the redirect to get logged in/fully connected through the wireless provider. Regards, NealS ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Understanding Networking Components
On Sat, 31 Mar 2012, eduncli...@gmail.com wrote: Are you running NoScript? Nope. Have no idea what that is. Rich ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Understanding Networking Components
Rich == Rich Shepard rshep...@appl-ecosys.com writes: RichAt the PLUG clinic last week the Sony Vaio laptop on the Rich wireless interface, wlan0, received an IP address, had the Free Rich Geek server provide content in /etc/resolv.conf, but would not Rich load the Free Geek web page to accept their terms and conditions Rich and gain access to the 'Net. Just a heads-up, NoCatAuth (which I believe FreeGeek is using) typically won't let you use your own nameservers because all your traffic (with specific exceptions) is blocked until you accept the conditions. In those cases, the network is expecting you to use its DHCP supplied nameserver(s). I'm going to guess (necessary since you don't provide enough information) that your machine is not accepting the DHCP provided nameserver(s), but using your own overrides (8.8.8.8 is one of google's public DNS servers). I don't actually know how FreeGeek is configured. -- Russell Senior, President russ...@personaltelco.net ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Understanding Networking Components
On Sat, 31 Mar 2012, Neal wrote: The point of my question was to verify that a default gateway was set properly on the WLAN. That is, the default WLAN gateway was set to a valid address on the WLAN subnet. If it's not you won't be able to access any IP (including DNS) that's not on the WLAN subnet. Neal, I did see the gateway IP address in one of the files when I was at the coffee shop. I think eduncliffe is on the right track about something you're running on firefox blocking the redirect to get logged in/fully connected through the wireless provider. Interesting. Could be, I suppose. I can try links or lynx and see what happens. I'll also bring my Dell (which works wirelessly and is also running 13.37/x86_64 and firefox 11.0). Probably tomorrow. Thanks, Rich ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Understanding Networking Components
On Sat, 31 Mar 2012, Russell Senior wrote: Just a heads-up, NoCatAuth (which I believe FreeGeek is using) typically won't let you use your own nameservers because all your traffic (with specific exceptions) is blocked until you accept the conditions. In those cases, the network is expecting you to use its DHCP supplied nameserver(s). I'm going to guess (necessary since you don't provide enough information) that your machine is not accepting the DHCP provided nameserver(s), but using your own overrides (8.8.8.8 is one of google's public DNS servers). At both Free Geek and the coffee shop this morning /etc/resolv.conf was set by the local DHCP servers and showed the IP addresses for the two nameservers they provided. I wrote that this was the case; the coffee shop provided 8.8.8.8 and 8.8.4.4 that's why I used them. I am _not_ using the default resolv.conf that's set up for ethernet on the LAN, but whatever resolv.conf is set by the wifi servers at the two locales. Rich ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
