Can we make NM automatically handle the need for proxy arp?
Hello,
Here are extracts from a dialog between myself and Ted Lemon.
I hope that NM can be made to automatically set up wifi connections
that are handled by Windows. Currently, I sometimes encounter
failures.
Ted isn't subscribed to the list.
---
ME:
I often find that in hotels, setting up a wifi connection is a
two-stage process under Windows XP. First, I must connect to the
access point and then, when I open a web browser, I am redirected to a
log-in/sign-up screen. Once I have paid for access, my network
requests start going through.
I often find that something breaks down in this process when I am
running Linux. Tonight I have been trying to get a wifi connection
working at a Shilo Inn Hotel, which provides free wireless, but still
redirects my first browser connection attempt to an agreement page.
Unfortunately, I had to boot Windows to get to the page. Also, when I
try to use NetworkManager in Ubuntu 6.06.1 LTS (very current NM code),
I get:
Internet Systems Consortium DHCP Client V3.0.3
Copyright 2004-2005 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/products/DHCP
Listening on LPF/eth1/00:12:f0:5e:db:2f
Sending on LPF/eth1/00:12:f0:5e:db:2f
Sending on Socket/fallback
DHCPREQUEST on eth1 to 255.255.255.255 port 67
DHCPACK from 192.168.21.254
SIOCADDRT: Network is unreachable
bound to 192.168.21.10 -- renewal in 6356 seconds.
I have: network-manager 0.6.2-0ubuntu7
After hunting about on the web, I eventually found the suggestion that
I needed to use route to add a default gateway. After some
experimentation, I found that:
route add default gw 192.168.21.254
got my connection working.
TED:
lease {
interface eth1;
fixed-address 192.168.21.10;
option subnet-mask 255.255.255.0;
option routers 205.171.3.65;
option dhcp-lease-time 14400;
option dhcp-message-type 5;
option dhcp-server-identifier 192.168.21.254;
option domain-name-servers 205.171.3.65;
renew 6 2006/8/26 07:05:42;
rebind 6 2006/8/26 08:49:46;
expire 6 2006/8/26 09:19:46;
}
Now this lease you got about three minutes after the previous lease
died. Notice that the IP address in the routers option is on a
different subnet than the IP address in the fixed-address option.
This is what's causing the SIOCADDRT error.
So I think this confirms my previous theory. The reason your WinXP
machine succeeds in using the network is because it's using something
other than DHCP to get routing working. And the reason your linux
box fails is that it's relying entirely on DHCP. So to fix the
problem, we probably need to dig deeper, which could be a problem if
you're not still at the Shiloh Inn.
If you are still there, can you get your system booted up into
Windows, start a terminal window, and type ipconfig/all and cut-and-
paste the output to me?
-
ME:
# ipconfig/all
Windows IP Configuration
Host Name . . . . . . . . . . . . : lowly
Primary Dns Suffix . . . . . . . :
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : Yes
WINS Proxy Enabled. . . . . . . . : No
Ethernet adapter IPW2200:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Intel(R) PRO/Wireless
2200BG Network Connection
Physical Address. . . . . . . . . : 00-12-F0-5E-DB-2F
Dhcp Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IP Address. . . . . . . . . . . . : 192.168.21.4
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 205.171.3.65
DHCP Server . . . . . . . . . . . : 192.168.21.254
DNS Servers . . . . . . . . . . . : 205.171.3.65
Lease Obtained. . . . . . . . . . : Sunday, August 27, 2006 8:06:49 AM
Lease Expires . . . . . . . . . . : Sunday, August 27, 2006 12:06:49 PM
Ethernet adapter Local Area Connection:
Media State . . . . . . . . . . . : Media disconnected
Description . . . . . . . . . . . : Realtek RTL8139/810x
Family Fast Ethernet NIC
Physical Address. . . . . . . . . : 00-C0-9F-95-18-1B
---
TED:
Yup, the only way that's working is with proxy ARP. And Linux isn't
trying to ARP for the router, because it's not on the right subnet.
The sad fact is that what's really going on here is that Windows is
doing something it shouldn't be doing to work around a misconfigured
DHCP server, and so the guys running the DHCP server think the DHCP
server is configured just fine. :'/
Anyhow, I would love to see us handle this broken router configuration,
since this sort of failure comes up for me often when I am trying to access
hotel WIFI networks.
Thanks,
Miles
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
Re: Can we make NM automatically handle the need for proxy arp?
I found this in the dhcpb manual: use-lease-addr-for-default-route flag; If the use-lease-addr-for-default-route parameter is true in a given scope, then instead of sending the value specified in the routers option (or sending no value at all), the IP address of the lease being assigned is sent to the client.This supposedly causes Win95 machines to ARP for all IP addresses, which can be helpful if your router is configured for proxy ARP.The use of this feature is not recom mended, because it won't work for many DHCP clients. Is this pertinent? Miles ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: A problem compiling NetworkManager.
On Fri, 2006-08-25 at 16:44 -0500, Steev Klimaszewski wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aaron Konstam wrote: snippage Glad to hear you got further. I am not sure about LEAP support, but if you are building from CVS, then I guess you should have it, but someone more familiar with CVS would have a better answer for you (I am simply a packager for Gentoo, no commit access.) As to the dbus-glib-1 - that is either dbus-0.60+ or dbus-0.91+dbus-glib-0.71 hth Well I have dbus-061 installed as well as dbus-glib-0.61. So now what am I to do? I really would like some direction on compiling this NetworkManager from the CVS. -- Aaron Konstam [EMAIL PROTECTED] ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: WPA_Supplicant doesn't seem to like WUSB54GS NDISWrapper drivers
Jouni asked me to run wpa_supplicant manually, telling it where the NM config file is, and to also capture debug output from NM. How would this be accomplished? On Sat, 26 Aug 2006 19:33:28 -0400, Jouni Malinen [EMAIL PROTECTED] wrote: On Wed, Aug 23, 2006 at 10:31:30AM -0400, Jacob wrote: WPA_Supplicant won't work at all. Sorry for being confusing. Basically, network-manager can't connect, and wpa_supplicant seems to be the cause. I'm not using WPA encryption at all (I'm using WEP) so that makes this whole thing even stranger. Can you please try to run wpa_supplicant manually with the same configuration file that NetworkManager is using? Alternatively, you could try to get debug output from NM, if it is available somehow. I have not used NM, so I don't know how to do this and would suggest asking this on the NM mailing list. -- From, Jacob ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
openvpn plugin
Hello, I tried to use the openvpn plugin with NM today. It brings up the connection successfully but NM doesn't notice that the connection is up, so I have no way to disconnect the whole thing again. See the attached file for the log output in the syslog. Christian Aug 27 16:57:05 bluelagoon NetworkManager: information^IWill activate VPN connection 'OpenVPN', service 'org.freedesktop.NetworkManager.openvpn', user_name 'christian', vpn_data 'connection-type / x509 / dev / tap / remote / xxx.xxx.xxx.xxx / proto / tcp / ca / /home/christian/.openvpn/keys/ca.crt / cert / /home/christian/.openvpn/keys/guedel.crt / key / /home/christian/.openvpn/keys/guedel.key / comp-lzo / yes / shared-key / / local-ip / / remote-ip / / username / / port / 443', route ''. Aug 27 16:57:05 bluelagoon NetworkManager: information^IVPN Activation (OpenVPN) Stage 1 of 4 (Connection Prepare) scheduled... Aug 27 16:57:05 bluelagoon NetworkManager: information^IVPN Activation (OpenVPN) Stage 1 of 4 (Connection Prepare) ran VPN service daemon org.freedesktop.NetworkManager.openvpn (PID 5106) Aug 27 16:57:05 bluelagoon NetworkManager: information^IVPN Activation (OpenVPN) Stage 1 of 4 (Connection Prepare) complete. Aug 27 16:57:05 bluelagoon NetworkManager: information^IVPN Activation (OpenVPN) Stage 2 of 4 (Connection Prepare Wait) scheduled... Aug 27 16:57:05 bluelagoon kernel: [17179675.348000] tun: Universal TUN/TAP device driver, 1.6 Aug 27 16:57:05 bluelagoon kernel: [17179675.348000] tun: (C) 1999-2004 Max Krasnyansky [EMAIL PROTECTED] Aug 27 16:57:05 bluelagoon NetworkManager: information^IVPN service 'org.freedesktop.NetworkManager.openvpn' signaled state change 1 - 6. Aug 27 16:57:05 bluelagoon NetworkManager: information^IVPN Activation (OpenVPN) Stage 2 of 4 (Connection Prepare Wait) waiting... Aug 27 16:57:05 bluelagoon NetworkManager: information^IVPN Activation (OpenVPN) Stage 2 of 4 (Connection Prepare Wait) complete. Aug 27 16:57:05 bluelagoon NetworkManager: information^IVPN Activation (OpenVPN) Stage 3 of 4 (Connect) scheduled... Aug 27 16:57:05 bluelagoon NetworkManager: information^IVPN Activation (OpenVPN) Stage 3 of 4 (Connect) sending connect request. Aug 27 16:57:05 bluelagoon NetworkManager: information^IVPN Activation (OpenVPN) Stage 3 of 4 (Connect) request sent, waiting for reply... Aug 27 16:57:05 bluelagoon NetworkManager: information^IVPN service 'org.freedesktop.NetworkManager.openvpn' signaled state change 6 - 3. Aug 27 16:57:05 bluelagoon NetworkManager: information^IVPN Activation (OpenVPN) Stage 3 of 4 (Connect) reply received. Aug 27 16:57:05 bluelagoon NetworkManager: information^IVPN Activation (OpenVPN) Stage 4 of 4 (IP Config Get) timeout scheduled... Aug 27 16:57:05 bluelagoon NetworkManager: information^IVPN Activation (OpenVPN) Stage 3 of 4 (Connect) complete, waiting for IP configuration... Aug 27 16:57:05 bluelagoon nm-openvpn[5114]: OpenVPN 2.0.6 i486-pc-linux-gnu [SSL] [LZO] [EPOLL] built on Apr 10 2006 Aug 27 16:57:05 bluelagoon nm-openvpn[5114]: LZO compression initialized Aug 27 16:57:05 bluelagoon nm-openvpn[5114]: Attempting to establish TCP connection with xxx.xxx.xxx.xxx:1194 Aug 27 16:57:05 bluelagoon nm-openvpn[5114]: TCP connection established with xxx.xxx.xxx.xxx:1194 Aug 27 16:57:05 bluelagoon nm-openvpn[5114]: TCPv4_CLIENT link local: [undef] Aug 27 16:57:05 bluelagoon nm-openvpn[5114]: TCPv4_CLIENT link remote: xxx.xxx.xxx.xxx:1194 Aug 27 16:57:07 bluelagoon nm-openvpn[5114]: [OpenVPN.org] Peer Connection Initiated with xxx.xxx.xxx.xxx:1194 Aug 27 16:57:08 bluelagoon nm-openvpn[5114]: TUN/TAP device tap0 opened Aug 27 16:57:08 bluelagoon nm-openvpn[5114]: ifconfig tap0 10.67.12.11 netmask 255.255.255.0 mtu 1500 broadcast 10.67.12.255 Aug 27 16:57:08 bluelagoon nm-openvpn[5114]: /usr/bin/nm-openvpn-service-openvpn-helper tap0 1500 1576 10.67.12.11 255.255.255.0 init Aug 27 16:57:08 bluelagoon NetworkManager: information^IVPN Activation (OpenVPN) Stage 4 of 4 (IP Config Get) reply received. Aug 27 16:57:08 bluelagoon NetworkManager: WARNING^I get_dbus_string_helper (): Error: couldn't get DNS Domain from VPN IP Config message. Aug 27 16:57:08 bluelagoon NetworkManager: WARNING^I nm_vpn_service_stage4_ip_config_get (): (VPN Service org.freedesktop.NetworkManager.openvpn): did not receive valid IP config information. Aug 27 16:57:08 bluelagoon NetworkManager: information^IVPN Activation (OpenVPN) failed. Aug 27 16:57:08 bluelagoon NetworkManager: information^IVPN service 'org.freedesktop.NetworkManager.openvpn' signaled state change 3 - 4. Aug 27 16:57:08 bluelagoon NetworkManager: information^IVPN service 'org.freedesktop.NetworkManager.openvpn' signaled state change 4 - 5. Aug 27 16:57:08 bluelagoon NetworkManager: information^IVPN service 'org.freedesktop.NetworkManager.openvpn' signaled state change 5 - 6. Aug 27 16:57:08 bluelagoon nm-openvpn[5114]: Initialization Sequence Completed Aug 27 16:57:19 bluelagoon kernel:
Re: FC5, NetworkManager, Client Certificates
The EAP configs in Network-Manager map to the same in WPA_Supplicant so man wpa_supplicant.conf would provide some information. Additionally Network-Manager isn't doing anything unusual or special so specific documentation regarding the various EAP wouldn't really be exceptionally helpful except in cases where the field names chosen don't correspond to what other supplicants have chosen but in my experience they match in most cases. I was able to configure PEAP on Network Manager as easily as I configured it on Odyssey and I suspect that in enterprise deployments the admin's will document this all for the users and not require them to guess at the fields. To answer your specific questions, I assume that you are using EAP-TLS. When you generate a cert for a user you generate a public and private key. The cert itself is the public key (the pem file). The Private key password is only needed if you created the private key with a password or passphrase (This is recommended by the way so the loss of the private key doesn't compromise anything else). So you need to private key, but not necessarily the passphrase. The private key is used to encrypt the data and the public key is passed to the server so that it can use it to decrypt the data. The reason you don't need the private key on windows is because that key is stored withing the windows certificate store. If you need more background on that specific area there is a wealth of information available on PKI and I can provide you with some great links. From then on the transaction occurs just like any other PKI transactions, the private key is used to encrypt the data and the public key is exchanged between the two to decrypt the data. This connection is used to exchange dynamic WEP or WPA keys and the Wireless connection is brought up. Does that help answer your question? On 8/26/06, Nolan Garrett [EMAIL PROTECTED] wrote: Nolan Garrett wrote: Hello! I am running FC5, and NetworkManager on the IPW2200 drivers (2915 card, actually). My wireless network uses client certificates, where it authenticates through the AP using EAP to a W2K3 DC. Each user has a certificate. I am encrypting with TKIP. How can I get NetworkManager to work? I've given it the certificate, but I don't necessarily understand what all of the fields do for WPA Enterprise mode. What's the difference between Client Certificate and Private Key? Any tips and setting this up would be great! Thanks! Nolan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list Has no one attempted 802.1x authentication via wireless with NetworkManager? Or am I just too dumb to make it work? Even a reference to a page describing how to would be fine - I just can't Google anything. Nolan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: FC5, NetworkManager, Client Certificates
Darren Albers wrote: The EAP configs in Network-Manager map to the same in WPA_Supplicant so man wpa_supplicant.conf would provide some information. Additionally Network-Manager isn't doing anything unusual or special so specific documentation regarding the various EAP wouldn't really be exceptionally helpful except in cases where the field names chosen don't correspond to what other supplicants have chosen but in my experience they match in most cases. I was able to configure PEAP on Network Manager as easily as I configured it on Odyssey and I suspect that in enterprise deployments the admin's will document this all for the users and not require them to guess at the fields. To answer your specific questions, I assume that you are using EAP-TLS. When you generate a cert for a user you generate a public and private key. The cert itself is the public key (the pem file). The Private key password is only needed if you created the private key with a password or passphrase (This is recommended by the way so the loss of the private key doesn't compromise anything else). So you need to private key, but not necessarily the passphrase. The private key is used to encrypt the data and the public key is passed to the server so that it can use it to decrypt the data. The reason you don't need the private key on windows is because that key is stored withing the windows certificate store. If you need more background on that specific area there is a wealth of information available on PKI and I can provide you with some great links. From then on the transaction occurs just like any other PKI transactions, the private key is used to encrypt the data and the public key is exchanged between the two to decrypt the data. This connection is used to exchange dynamic WEP or WPA keys and the Wireless connection is brought up. Does that help answer your question? Yes, thank you! That explains the problem I am having - I'll need to export a public key as well. I definitely think there should be a FAQ entry about this, or just a quick explanation when you hover over the fields that describes exactly what that field is for. I had the hardest time trying to Google anything useful! Thanks again! Nolan signature.asc Description: OpenPGP digital signature ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: FC5, NetworkManager, Client Certificates
On 8/27/06, Nolan Garrett [EMAIL PROTECTED] wrote: I definitely think there should be a FAQ entry about this, or just a quick explanation when you hover over the fields that describes exactly what that field is for. I had the hardest time trying to Google anything useful! I'll see if I can put something together, the biggest problem is to give the user enough information without confusing them... I might see if I can find a good EAP/PKI write-up and then just summarize what all the fields are. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: WPA_Supplicant doesn't seem to like WUSB54GS NDISWrapper drivers
On 8/27/06, Jacob [EMAIL PROTECTED] wrote: Jouni asked me to run wpa_supplicant manually, telling it where the NM config file is, and to also capture debug output from NM. How would this be accomplished? To configure wpa_supplicant manually look at this post: http://mail.gnome.org/archives/networkmanager-list/2006-August/msg00120.html That thread should also have some good info on this subject so browse through it. To capture the debug output look here: http://live.gnome.org/DarrenAlbers/NetworkManagerFAQ#head-5307e30269224aac6f7a4e83dc4c5b49386e7825 ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Can we make NM automatically handle the need for proxy arp?
On Aug 27, 2006, at 3:03 AM, Miles Lane wrote: Is this pertinent? I think the deal is that if WinXP sees an unreasonable value in the routers field, it just ARPs for everything. So it's related, in the sense that it's why your WinXP machine is working. But in itself, it's not going to solve the problem on Linux. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Can we make NM automatically handle the need for proxy arp?
I am suprised by this, I travel a lot and have never had this problem also this captive portal is operating strange, most don't do anything odd with DHCP to operate they register your mac or use some form of authentication and lets you IP pass once you authenticate otherwise it takes all your traffic and sends it to the portal page when it reaches the default gateway. It does this all without requiring any tricks. This is how the Aruba AP's that I have personal experience with work and it seems like adding strange complication to do it any other way. So just to be specific I see where the problem is with this AP, look at what information it sent you: IP Address. . . . . . . . . . . . : 192.168.21.4 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 205.171.3.65 DHCP Server . . . . . . . . . . . : 192.168.21.254 DNS Servers . . . . . . . . . . . : 205.171.3.65 How is it possible for you to have a default gateway that is not on your local subnet?! I am suprised that windows even accepts that since you can't add it manually. Here is what I think is happening, the DHCP server is misconfigured but router that is on that network has proxy-arp enabled so it is picking up all the traffic anyway. So I don't think this is a Network Manager issue but a Linux networking issue, can you run ethereal and post the output from windows and linux? ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Can we make NM automatically handle the need for proxy arp?
On 8/27/06, Darren Albers [EMAIL PROTECTED] wrote: So I don't think this is a Network Manager issue but a Linux networking issue, can you run ethereal and post the output from windows and linux? Actually I don't even think this is a linux networking issue, in retrospect letting any device running proxy-arp route your traffic seems to be a VERY bad idea. I suspect that the Linux networking stack is doing the smart thing in this case. I wonder if you just remove the default gateway will Linux let any device that is arping that it knows the route to something take the traffic? If you boot into windows and run route print does it show some strange routes in it? ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Can we make NM automatically handle the need for proxy arp?
On 8/27/06, Darren Albers [EMAIL PROTECTED] wrote: On 8/27/06, Darren Albers [EMAIL PROTECTED] wrote: So I don't think this is a Network Manager issue but a Linux networking issue, can you run ethereal and post the output from windows and linux? Actually I don't even think this is a linux networking issue, in retrospect letting any device running proxy-arp route your traffic seems to be a VERY bad idea. I suspect that the Linux networking stack is doing the smart thing in this case. I wonder if you just remove the default gateway will Linux let any device that is arping that it knows the route to something take the traffic? If you boot into windows and run route print does it show some strange routes in it? Ok I just confirmed that Windows is brain-dead in this regard, I slapped up a Cisco 2600 I have sitting in my lab and enabled proxy-arp on the directly connected interface and then setup a second interface (So the router has someplace to send traffic to). So on my windows machine I have a default gateway set to another router but windows ignored that and sent my traffic for the test network to the router. This is brain-dead, if I specify that 0.0.0.0 0.0.0.0 needs to go to 1.1.1.1 then it should not let some device arbitrarily tell my system that it has a better route to that network unless that is something I /want/ it it do. With my Linux laptop if I have a default route it ignores the router, but when I remove the default route it adds the route to my system. I personally think Linux is doing the right thing, imagine the havoc if someone plugs in a device on a public wifi that arps that it knows the way to 2.2.2.2 which also happens to be the IP that hotmail uses. They then sit there and collect all the logins ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: RFE: Connection Sharing
On Sun, 2006-08-27 at 07:51 -0400, Saikat Guha wrote: Would NM be the appropriate place to have connection sharing that just works? Having this functionality somewhere in the stack would be great, *but* setting up NAT in iptables is very dependant on existring chains/rules (where to put them etc). I don't know wether this is doable. I guess flushing all chains is not an option ;-) Nicolas ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: RFE: Connection Sharing
On 8/27/06, Saikat Guha [EMAIL PROTECTED] wrote: Would NM be the appropriate place to have connection sharing that just works? Possibly that would be up to the developers to decide but Firestarter claims to do this now if the functionality is required. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Can we make NM automatically handle the need for proxy arp?
On Aug 27, 2006, at 11:37 AM, Darren Albers wrote: Ok I just confirmed that Windows is brain-dead in this regard, I slapped up a Cisco 2600 I have sitting in my lab and enabled proxy-arp on the directly connected interface and then setup a second interface (So the router has someplace to send traffic to). So on my windows machine I have a default gateway set to another router but windows ignored that and sent my traffic for the test network to the router. This is brain-dead, if I specify that 0.0.0.0 0.0.0.0 needs to go to 1.1.1.1 then it should not let some device arbitrarily tell my system that it has a better route to that network unless that is something I /want/ it it do. So you configured a valid default route on Windows, and it used a different route instead? Or you configured an invalid default route and it didn't use it? I'm a bit puzzled by this paragraph, because my experience is that Windows isn't quite as brain-dead as you're suggesting here. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Unreliable NM wifi connection please help
A couple weeks ago I posted about the problems I was having with NetworkManager taking a long time to connect to my WPA network, or intermittenetly failing to connect altogether, where using wpa_supplicant directly always connects quickly and reliably. Dan Williams and Darren Albers very patiently worked with me through an installation of NM from CVS to see if that would fix anything. It didn't, and then the thread died. From googling around for similar problems, I don't think my situation is unique, and I don't think the problems should be hard to fix either, for someone who understands wifi protocols (easy for me to say!), so I'm asking one more time for help diagnosing the cause of this problem. Thanks in advance, -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Can we make NM automatically handle the need for proxy arp?
On 8/27/06, Ted Lemon [EMAIL PROTECTED] wrote: So you configured a valid default route on Windows, and it used a different route instead? Or you configured an invalid default route and it didn't use it? I'm a bit puzzled by this paragraph, because my experience is that Windows isn't quite as brain-dead as you're suggesting here. Correct, I configured a valid route and when I did a arp -a I saw the ip for a device on my other test network associated with the mac of the router. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: RFE: Connection Sharing
On Sun, 2006-08-27 at 20:42 +0200, Nicolas Ikke Trangez wrote: On Sun, 2006-08-27 at 07:51 -0400, Saikat Guha wrote: Would NM be the appropriate place to have connection sharing that just works? Having this functionality somewhere in the stack would be great, *but* setting up NAT in iptables is very dependant on existring chains/rules (where to put them etc). I don't know wether this is doable. I guess flushing all chains is not an option ;-) If ethX is internet-facing and ethY is to be NAT'ed, perhaps a rule at the very top of the iptables chain that whitelists all traffic initiated from someone on ethY being routed to ethX should do the trick. iptables -I FORWARDING --in-interface ethY -j ACCEPT iptables -t nat -I POSTROUTING --out-interface ethX -j ACCEPT There is probably something more clever that can be done with marking the packets and routing them through a separate table with greater security for the box running NM from hostiles on the internal (ethY) network. (vaguely from memory) ... --in-interface -j MARK 0x10 ip ro add ... If nothing else, we can likely make the assumption that if the user is requesting the device to NAT some internal network onto the internet, he trusts the internal network somewhat. The first two rules above with a warning might also be a good first stab. -- Saikat signature.asc Description: This is a digitally signed message part ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Can we make NM automatically handle the need for proxy arp?
On 8/27/06, Darren Albers [EMAIL PROTECTED] wrote: On 8/27/06, Ted Lemon [EMAIL PROTECTED] wrote: So you configured a valid default route on Windows, and it used a different route instead? Or you configured an invalid default route and it didn't use it? I'm a bit puzzled by this paragraph, because my experience is that Windows isn't quite as brain-dead as you're suggesting here. Correct, I configured a valid route and when I did a arp -a I saw the ip for a device on my other test network associated with the mac of the router. My apologies it looks like you are right, I replaced my Linksys running dd-wrt with some no name 5 year old piece of crap on wednesday when my linksys died and it looks like it is causing that behavior. I sniffed the traffic and it looks like the noname router picked up the information from the Cisco router and told my box to send traffic there. So maybe Windows isn't brain dead and it is just my router ;-) I have a new linksys sitting here and when my wife goes to bed I will swap it out and see if the behavior is correct. So the real question is (and off topic for this list since it isn't NM that is causing this) should linux networking treat a bad default gateway as no gateway and use proxy-arp? ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Can we make NM automatically handle the need for proxy arp?
On 8/27/06, Darren Albers [EMAIL PROTECTED] wrote: On 8/27/06, Darren Albers [EMAIL PROTECTED] wrote: On 8/27/06, Ted Lemon [EMAIL PROTECTED] wrote: So you configured a valid default route on Windows, and it used a different route instead? Or you configured an invalid default route and it didn't use it? I'm a bit puzzled by this paragraph, because my experience is that Windows isn't quite as brain-dead as you're suggesting here. Correct, I configured a valid route and when I did a arp -a I saw the ip for a device on my other test network associated with the mac of the router. My apologies it looks like you are right, I replaced my Linksys running dd-wrt with some no name 5 year old piece of crap on wednesday when my linksys died and it looks like it is causing that behavior. I sniffed the traffic and it looks like the noname router picked up the information from the Cisco router and told my box to send traffic there. So maybe Windows isn't brain dead and it is just my router ;-) I have a new linksys sitting here and when my wife goes to bed I will swap it out and see if the behavior is correct. So the real question is (and off topic for this list since it isn't NM that is causing this) should linux networking treat a bad default gateway as no gateway and use proxy-arp? Firstly, where should this be discussed? I understand that NM talks to dhcdbd, which talks to dhclient. What component should notice the misconfiguration and which component should then configure the connection so that it works? I certainly feel strongly that unless there is an exceptionally strong reason for not adding the default gateway route, we should do so automatically and give the user a working network connection. Miles ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: RFE: Connection Sharing
If ethX is internet-facing and ethY is to be NAT'ed, perhaps a rule at the very top of the iptables chain that whitelists all traffic initiated from someone on ethY being routed to ethX should do the trick. iptables -I FORWARDING --in-interface ethY -j ACCEPT iptables -t nat -I POSTROUTING --out-interface ethX -j ACCEPT Hmm. There is probably something more clever that can be done with marking the packets and routing them through a separate table with greater security for the box running NM from hostiles on the internal (ethY) network. (vaguely from memory) ... --in-interface -j MARK 0x10 ip ro add ... If nothing else, we can likely make the assumption that if the user is requesting the device to NAT some internal network onto the internet, he trusts the internal network somewhat. The first two rules above with a warning might also be a good first stab. I dont think you can just say 'the user will trust the internal network'. I think at least when starting network sharing, you should give a choice: open up everything, or ask before allowing connections (MAC, or even better hostname based, when possible to get this hostname. mdns might be useful). Might be usefull to only allow certain safe connections by default too, like http/https, imap/imaps, ssh, ntp,... I dont think there's any need to allow P2P and other applications by default. Nicolas ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Can we make NM automatically handle the need for proxy arp?
On 8/27/06, Miles Lane [EMAIL PROTECTED] wrote: Firstly, where should this be discussed? I understand that NM talks to dhcdbd, which talks to dhclient. What component should notice the misconfiguration and which component should then configure the connection so that it works? I certainly feel strongly that unless there is an exceptionally strong reason for not adding the default gateway route, we should do so automatically and give the user a working network connection. The problem is that in this case the network configuration from the DHCP server was completely wrong, evidently windows works around this by using proxy-arp if the default gateway is wrong or not present. So should Linux behave the same way or should it assume that the settings given to it are sane? I personally lean towards saying that there shouldn't be any heroic measures to work around a broken network since it would only mask the problem. The proper place would be with networking in the Linux kernel since Network Manager just brings up the connection. Dan/Robert, am I correct in saying that this is not something Network-Manager can or does handle? A mirror of that mailing list is available via gmane at gmane.linux.network but like most kernel mailing lists make sure you are certain about the behavior and see if you can research why the behavior is happening before posting. It is likely that using proxy-arp is simply an option that your kernel maintainer decided not to enable. Most of those mailing lists are very high traffic so non-well researched posts get passed over quickly. Also if you are certain that this is not something that is simply not enabled and there is no valid reason for it you can file a bug at http://bugzilla.kernel.org, though again a well researched bug report is important. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Can we make NM automatically handle the need for proxy arp?
On Aug 27, 2006, at 2:41 PM, Darren Albers wrote: So maybe Windows isn't brain dead and it is just my router ;-) I have a new linksys sitting here and when my wife goes to bed I will swap it out and see if the behavior is correct. So the real question is (and off topic for this list since it isn't NM that is causing this) should linux networking treat a bad default gateway as no gateway and use proxy-arp? Hm. I would argue that it actually is appropriate for NM to do it, because NM is at the UI level, and you really want this to be a controllable behavior. For example, one good UI for this would be to pop up a widget that says yo, the DHCP server is giving bad information and give the user the option of Try ignoring this server or Try to make it work anyway. Or you could make the behavior invisible to the user by having the DHCP client try to find a different DHCP server, and if it failed, only then try the workaround. You would probably want to have a configuration parameter to control it - the current ISC client gives you the option of putting a bad DHCP server on a reject list. You really want route add bogus route to print an error, and it wouldn't do that if you installed the workaround in the kernel. Then you're going to get cases where a user manually mistypes the router IP address and doesn't get any feedback, and wastes twenty minutes debugging the problem. Also, if you do the workaround in the kernel, you still need a UI to control that behavior, and NM is a fairly logical place to put it. :') Anyway, noname routers with weird DHCP implementations and weird ARP behavior are a well-known problem. We've run into problems in the past where Macs, which follow RFC2131 more closely than any of the other DHCP implementations, will see a bogus proxy arp reply from a wireless gateway and send a DHCPDECLINE. So it wouldn't surprise me if swapping out that router clears up the particular symptom you're talking about. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Can we make NM automatically handle the need for proxy arp?
Ted, I am not sure if you are subscribed to the list or not so I am ccing you. If you are subscribed let me know. On 8/27/06, Ted Lemon [EMAIL PROTECTED] wrote: Hm. I would argue that it actually is appropriate for NM to do it, because NM is at the UI level, and you really want this to be a controllable behavior. For example, one good UI for this would be to pop up a widget that says yo, the DHCP server is giving bad information and give the user the option of Try ignoring this server or Try to make it work anyway. Or you could make the behavior invisible to the user by having the DHCP client try to find a different DHCP server, and if it failed, only then try the workaround. You would probably want to have a configuration parameter to control it - the current ISC client gives you the option of putting a bad DHCP server on a reject list. I agree that the user should be informed that something is wrong, but the messages can't confuse the user. You really want route add bogus route to print an error, and it wouldn't do that if you installed the workaround in the kernel. Then you're going to get cases where a user manually mistypes the router IP address and doesn't get any feedback, and wastes twenty minutes debugging the problem. Also, if you do the workaround in the kernel, you still need a UI to control that behavior, and NM is a fairly logical place to put it. :') I suspect that when the Network Manager UI for static addresses is developed that it won't let someone enter an invalid subnet mask or default gateway. So back to the original topic, after a couple of google searches I think that the Linux networking stack will utilize ARP to discover routes if the default gateway does not exist and since dhclient will reject bad default gateways then it should just work via arp assuming that arp is enabled and arp_ignore is not set to 1. So is the real issue here that dhclient is aborting completely when it gets an invalid default route or is it accepting all the information just rejecting the bad gateway? ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: RFE: Connection Sharing
On Mon, 2006-08-28 at 00:51 +0200, Nicolas Ikke Trangez wrote: If nothing else, we can likely make the assumption that if the user is requesting the device to NAT some internal network onto the internet, he trusts the internal network somewhat. The first two rules above with a warning might also be a good first stab. I dont think you can just say 'the user will trust the internal network'. I think at least when starting network sharing, you should give a choice: open up everything, or ask before allowing connections (MAC, or even better hostname based, when possible to get this hostname. mdns might be useful). Might be usefull to only allow certain safe connections by default too, like http/https, imap/imaps, ssh, ntp,... I dont think there's any need to allow P2P and other applications by default. Agreed. Although, just to make sure we are on the same page, these restrictions are for outbound connections -- inbound connections to the internal nodes would be blocked anyway because of the NAT'ing. As for the restrictions themselves, I don't know whether NM is the best place to enforce firewalling of the internal network when it doesn't handle firewalling of the actual internet interface. IMHO, it makes more sense for NM to allow all outbound connections and let system-config-security or something (which does handle other firewalling needs) do the right thing for internal hosts. That said, if this were to be implemented, the actual security restrictions provided by NM are a secondary matter IMHO. Adding the NAT'ing/connection-sharing functionality would be more valuable -- even without enhanced security for the internal network, connection-sharing adds new functionality without compromising the security of the host running NM. 2c -- Saikat signature.asc Description: This is a digitally signed message part ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
