TCP ACK timeout and MTU size for high latency links (satellite)
Hi, I'm using network-manager (0.8.6 C API) with a satellite connection. The connection is not slow, but suffers from high latency. I get a lot of TCP errors, and wonder whether I can increase the TCP ACK timeout and decrease the MTU size via the C API. Thanks in advance! ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
MM 0.6.0 conflicts with USB GPS device?
Hi, ModemManager 0.6.0 (02ddf9a6732fba19c248d83cadfb56452c815091) seems to be confused, when a USB GPS device is connected. The GPS device always sends permanently data in form of ASCII strings at 4800 bps. It does not answer to any commands, such as ATI. Unfortunately it idenfies itself as a USB serial adaptor, so ModemManager rightly tries to find a modem there. But ModemManager should detect, that this is not a modem and let the device alone. Instead it tries to identify the poor device again and again, which prevents the legitimate GPS software to access it. The GPS device as shown by lsub: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port The output from MM: modem-manager.debug[1577]: [1370004683.185636] [mm-at-serial-port.c:334] debug_log(): (ttyUSB0): <-- '\0' modem-manager.debug[1577]: [1370004683.189633] [mm-at-serial-port.c:334] debug_log(): (ttyUSB0): <-- '\0' modem-manager.debug[1577]: [1370004683.214500] [mm-at-serial-port.c:334] debug_log(): (ttyUSB0): <-- '\0\0' modem-manager.debug[1577]: [1370004683.217178] [mm-at-serial-port.c:334] debug_log(): (ttyUSB0): --> 'AT+GCAP' modem-manager.debug[1577]: [1370004683.919845] [mm-at-serial-port.c:334] debug_log(): (ttyUSB0): <-- '\0\0\0\0\0\0\0' modem-manager.debug[1577]: [1370004683.945792] [mm-at-serial-port.c:334] debug_log(): (ttyUSB0): <-- '\0' modem-manager.debug[1577]: [1370004683.986895] [mm-at-serial-port.c:334] debug_log(): (ttyUSB0): <-- '\0' Does somebody have an idea how to solve the problem? Thanks in advance! ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: MM 0.6.0 conflicts with USB GPS device?
On 2013-05-31 13:53, Dan Williams wrote: > When you say "again and again", what do you mean? ModemManager sends a > sequence of AT commands like AT+GCAP, ATI, etc, then moves on to binary > QCDM commands, and if all of these fail, it will stop and leave the > device alone. That can take 10 or so seconds though. If I'm not mistaken, the whole process loops, i.e. the AT commands are send to device in an interval (of maybe 10s). I can't check right now, because I'm not in the office anymore, but I'm pretty sure. Is there maybe a condition under which MM would continue this way? ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: MM 0.6.0 conflicts with USB GPS device?
On 2013-05-31 16:44, Dan Williams wrote: > Perhaps MM is crashing and then respawning, then restarting the probing > process? I don't think so, because I started MM manually with --debug and --log-level=DEBUG. In this case there would be no automatic restart after a crash, right? > There was a bug like that which was fixed in git in late 2012, > perhaps your distro didn't pick up that specific fix? No, I used the git 0.6 branch of less than one day old. (So it was not 0.6.0, sorry.) > In any case, I > just tagged and uploaded MM 0.6.2 which shouldn't have that bug anymore. Shouldn't hurt :~) In any case, I will try to investigate further tomorrow or Monday. Is there anything I should try or some debug output I should send? ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: MM 0.6 conflicts with USB GPS device?
Quoting "Dan Williams" : Yeah, full debug output would be good then, since if MM sees that the device is not actually a modem, after probing it completely, it should never touch the device again unless the device goes away and re-appears. Here comes the normal and the debug log. You are right, that modem-manager does stop probing after some time, but this is after 55s, not 10s. The process does not respawn (PID stays the same), but does the AT+GCAP probe nine times with a distance between four and ten seconds. If there is a way to cut down the 55s more in the direction of 10s or 20s, this would be very helpful. mm.log.gz Description: GNU Zip compressed data mm-debug.log.bz2 Description: application/bzip ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: MM 0.6.0 conflicts with USB GPS device?
On 2013-06-02 19:46, Glen Turner wrote:
> As a workaround, set up a udev rule to:
> - set the group and mode on the device
> - create a non-changing symlink name to the changing device name
> - tell ModemManager not to touch the device
>
> Create a file, say /etc/udev/rules.d/99-local.rules
>
> SUBSYSTEM=="tty", ATTRS{idVendor}=="067b", ATTRS{idProduct}=="2303",
> GROUP="users", MODE="0660", SYMLINK+="gps"
> ACTION=="add|change", SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device",
> ATTRS{idVendor}=="067b", ATTRS{idProduct}=="2303",
> ENV{ID_MM_DEVICE_IGNORE}="1"
Many thanks for this idea! For me, personally, it probably is
not an option, however:
Unfortunately, a "PL2303 Serial Port" is a relatively common USB
serial adaptor which might be used both inside an USB modem or an
external adaptor for any kind of serial device. So there is no
other way than probing the device (e.g. sending AT commands at
115200 bps and hoping for a readable response, or just reading at
4800 bps and looking out for readable NMEA datagrams).
Maybe in the very distant future, MM would not probe the serial
device at all - instead I imagine a "serial detector" software
component, that does all kind of probing and only sends signals on
the DBus about the result ("modem found at /dev/ttyUSB0", "GPS
found at /dev/ttyUSB1", "voltmeter found...").
Cheers
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ANN: NetworkManager 1.0.0 released!
Quoting Dan Williams : I'm very happy to announce that after more than 10 years of development and 10 years of making the world a better place, NetworkManager 1.0 has been released! Congratulations and many thanks for this wonderful software! ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: How Embedded is NetworkManager
Quoting Richard Willis : I'm interesting in hearing if anyone has tried running NetworkManager without any GUI.. is it possible? Yes, absolutely. I'm using NM and MM in an embedded product since some years now. Not without problems, but mostly successfully. FYI, product is similar to a BeagleBone Black.. OS is a variant of Yocto, but we can run Debian Wheezy for initial experimentations. Debian Squeeze here, with possible future change to Debian Jessie. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Switch off wifi-handling?
Hi, on an embedded device, I'm using wifi with hostapd exclusively and do not want any NM interference. How can I tell NM to ignore any wifi stuff? Note: - the MAC is unknown, because different wifi pens are used - this is still NM 0.8.6 :~( Many thanks in advance for any help! Cheers ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Switch off wifi-handling?
Dan, thanks for the quick response! Quoting Dan Williams : NM 0.9.10 and later added the ability to ignore an interface by interface name. NM 0.9.10 and later also split WiFi out to a plugin, which could be removed and then the wifi interface just looks like an unmanaged generic device. I hope, that I can upgrade to > 1 some day! But since you're using a very old version, none of those work for you :( Could you try removing wpa_supplicant? Then NM will leave the device in 'unavailable' state and shouldn't touch it after initial NM startup. I removed wpasupplicant and get wlan0 as "unmanaged", not "unavailable": $ nmcli dev DEVICE TYPE STATE eth0 802-3-ethernetconnected usb0 802-3-ethernetunavailable wlan0 802-11-wireless unmanaged Is this the expected result? ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Porting dbus-glib code for NM 0.8.6 to NM 1.4.2
Hi, I need to port old non-GUI C code using the dbus-glib based API of NM 0.8.6 to whatever is the best option today. According to Dans blog post¹ some months ago, GDBus is the way to go. Is there a porting guide available? Or are there nice examples? Many thanks in advance! Cheers ¹ https://blogs.gnome.org/dcbw/2016/02/19/die-dbus-glib-die/ ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
What about the patch for USB gadgets?
Hi, there was a patch sent to the list in February: http://mail.gnome.org/archives/networkmanager-list/2011-February/msg00152.html However, I can't find any reaction on the list, neither approval nor rejection. Can someone comment on the patch or point me to existing comments, please? TIA! Cheers ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Gateway and link-local (IPv4) possible?
Hi, I am connecting two machines via a link-local IP address (169.254/16) and one machine should work as the gateway for the other. However, the NM applet does not allow setting any routes or gateways in the case of link-local. Is this a limitation of the Internet Protocol, Linux, network manager, or NM applet? (Or a limitation on my understanding of things?) Thanks in advance! ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Link-local (IPv4) as a connected state?
Hi, in case of a machine that is only connected via a link-local IP address (169.254/16), the machine is (normally) not "fully" connected to the internet nor the LAN. A well-known OS from Redmond warns the user in this case about the probably lack of connectivity, I learned today. NM seems to be happy with the link-local connection. Would it make sense for NM to distinguish here as well? This would make it easier for programs using the NM API to "know" (guess), whether the machine is really connected to a network or not. Or should this better be done in the application instead of NM? Thanks in advance! ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Gateway and link-local (IPv4) possible?
On 2011-05-20 14:41, José Queiroz wrote: > Why are you using link-local addresses? I'm connecting an embedded device to a PC, so that the PC can access the GUI (web interface) of the device. Th link local address has the advantage, that there is very little configuration necessary for the end user and no address conflict will happen with the LAN of the user. For this no routing is necessary. However, in some situations it would be a nice extra if the PC could act as a router to e.g. a software repository. I can set the gateway manually on the device and it works fine (even if not intended by the IP standards), but at least the network-manager applet lacks, it seems, any settings for this. (NM applet is not used on the embedded device, but I used it as a tool to create NM configuration files.) ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Gateway and link-local (IPv4) possible?
On 2011-05-21 17:56, José Queiroz wrote: > Can't this device work with DHCP? Yes, this would be an option, however: This embedded device is not a router, so it would make more sense, if it would get its network information from the PC. But most PCs (esp. Windows) don't act this way. If the embedded device is e.g. configured for a 192.168.x/8 network, it could clash with the configuration of the PC. Therefore I believe a link local address is suitable, even if this involves limitations of connectivity. The conclusion for network-manager is: The way it is implemented currently is fine. ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Gateway and link-local (IPv4) possible?
On 2011-05-22 16:31, Marc Luethi wrote: > Souns like a use case for a "shared to other computers" connection type > in NM. > > This fires up a DHCP server on that interface and does Route/NAPT for > the DCHP Clients. > > This would solve the address assignmet, routing, and internet > accessibility issues in one go.. This sounds like the perfect setup for the PC side. (In many cases this would be an MS-Windows PC, though.) I wonder, what is the complementary NM setup for the embedded devices side? Is there a connection type in network manager, that first tries DHCP (dhclient) and after timing out tries local link as second option? (Not sure, but I believe MS-Windows does it that way.) Cheers ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Gateway and link-local (IPv4) possible?
On 2011-05-22 17:21, Marc Luethi wrote: > Well, they call it "internet connection sharing" over at Microsoft's > place. At least that's what it used to be called in the Windows XP days. This is probably still the case, searching for ICS and Windows7 got some promising hits at MSes domain, at least. > I should think that it is "Automatic (DHCP)" with "Require IPv4 > addressing for this connection to complete" disabled. I'm not quite sure > if some other features are needed such as "zeroconf networking" or > similar, this might depend on your distribution. ... > I think that with some of the functionality from zeroconf networking > (wich provides LL-addressing for IPv4, mDNS name resolution, and service > discovery), this should be feasible. OK, many thanks, I will dig into this. (Zeroconf and mDNS is already used in my setup anyway, to there's probably not much missing.) ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
DHCP fall back to link-local? (IPv4)
Hi, there was a discussion[1] of this issue in 2009-04. I'm not sure what the outcome was, but I Dan expressed his opinion as follows: "I'm not opposed to it, I just think we do need to think through the consequences of doing something like that, because it breaks stuff including user expectations." Was there any further discussion I didn't find yet? Or should I just you dhcpcd-4 and patch NM to use it like suggested later on[2]? Is this still correct with NM 0.8.4/0.9? Thanks in advance! Background: I like to have this behaviour, because my (embedded) device should work out-of-the-box with both DHCP and link-local setups. The drawback is a relatively long timeout when waiting for non-present DHCP, but at least MS-Windows and Mac users are used to it, as their OSes work this way. Cheers [1] http://mail.gnome.org/archives/networkmanager-list/2009-April/msg00073.html [2] http://mail.gnome.org/archives/networkmanager-list/2009-April/msg00097.html ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM: Connection order for devices
Quoting "Jirka Klimes" : With mac-address you restricted Connection 2 for the MAC. However, Connection 1 is not restricted and that's why it can be activated on any compatible device. If you want only to use Connection 1 on Device 1, restrict it with MAC the same way as Connection 2. You can also disable auto connecting for a connection, if you want. I think what's missing in NM for Tom (and me) is: 1. a restriction for "device type"(?), e.g. "usbN" or "ethM" (not sure about the correct terminology) 2. a restriction like "not MAC" Especially (1.) would be very useful to me. Would that be hard to implement? ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] settings: add support for mac-blacklists for wifi and ethernet
Quoting "Jirka Klimes" : I've tested the feature. I needed to update the patches a bit. It crashed when the address matched the list ;) 'cause no error was set. I've fixed that and done other minor tweaks too. Pushed to NM_0_8 branch: ed5cd006cbe04beeabef85dbe44a7c443c7fe91a Very much appreciated, thanks! ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
How to set MAC blacklist via 0.8.x C API?
Hi, how can I set [802-3-ethernet] properties using the 0.8.x C API? Especially the mac-address-blacklist parameter... Thanks in advance! ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: How to set MAC blacklist via 0.8.x C API?
Quoting myself : how can I set [802-3-ethernet] properties using the 0.8.x C API? Especially the mac-address-blacklist parameter... It's that easy: NMSettingWired* wired; ... GSList* blacklist = NULL; blacklist = g_slist_append(blacklist, mac_addr1); ... g_object_set(G_OBJECT(wired), NM_SETTING_WIRED_MAC_ADDRESS_BLACKLIST, blacklist, NULL); g_slist_free(blacklist); Cheers ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
What does ModemManager.Modem.Simple.GetStatus() return as "band"?
Hi, the method org.freedesktop.ModemManager.Modem.Simple.GetStatus() returns a dictionary with an UInt32 as "band". This value is e.g. in my case the number 6. What does this number mean? Is it the same as the bitfield ModemManager.Modem.Gsm.MM_MODEM_GSM_BAND? TIA! ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Networkmanager and network alias interface.
Quoting "Dan Williams" : At the moment I think it's only possible via keyfile config files (/etc/NetworkManager/system-connections) because the UI in nm-connection-editor wasn't really written for advanced use-cases like this in mind. Do you (or does somebody) have an example config file ready for dual DHCP client and link-local IPv4? TIA! ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] core: add internet connectivity check
Quoting "Marcel Holtmann" : I personally would go straight for handling WISPr support and then the rest falls out of it for free. I must confess, that I didn't know about WISPr before you mentioned it earlier in this thread. The Wikipedia article[1] suggests, that it has almost nothing to do with the problem Thomas is trying to solve, but maybe I'm completely out of tune. If I understand correctly, WISPr is a WiFi- and mobile network related roaming standard, that has to be supported by the network provider. OTOH, Thomas is trying to automate a check, whether a device has an internet connection (via LAN, WiFi, modem, whatever) or not, independent of the provider or its support of a certain protocol. While WISPr might be an interesting addition to NM, I fail to see the connection to Thomas problem and solution. But maybe this is due to my limited understanding of WISPr, or the brevity of Wikipedia on the subject. [1] http://en.wikipedia.org/wiki/WISPr ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] core: add internet connectivity check
Quoting "Marcel Holtmann" : the first step is exactly the same. You need to get a well known website and then continue your decision making from there. It needs to become part of your connection state machine. I see, thanks! ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Debian Lenny - NetworkManager 0.8.1 + Dell Wireless 5530 aka Ericsson F3507g
On 2012-01-09 20:47, M2 wrote:
> I'm new to Debian (Lenny) and Linux all together so wanted to ask over here.
You are probably using Debian Squeeze (6.0), which comes with NM
0.8.1 (or 0.8.4.0, if you are using backports), not Debian Lenny
(5.0), which came with NM 0.6.6 or 0.7.3, respectively. Maybe
you should consider using Debian Wheezy ("testing", will be 7.0,
but is under permanent development), which includes NM 0.9.2.0.
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Force default gateway for a specific connection?
Quoting "Lamarque V. Souza" : Em Friday 20 January 2012, Pantelis Koukousoulas escreveu: My humble opinion is that it should be like this by default, i.e., ppp connections should have higher priority for getting the default route with the rationale being that LAN connections can be used for many things while ppp connections are more "internet-specific" in general. Is there any real advantage for LAN to have higher priority than PPP? PPP is used by mobile broadband, which is more expensive (in money sense) than the other connection types, which usually are free of charge. Besides, LAN is usually faster. Yes, both use cases make sense in different situations. There should be sth. like a "big switch": Always prefer LAN vs. always prefer mobile. ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
