Good morning,
I would like to update you about the recent changes on the networking code. I reckon nobody already noticed.
Right at the beginning I would like to say, that I really need help to test my patches. I have done as much as I could possibly do, but this kind of code should be running very well and it's a pain in the ass when you have a box without any network connectivity.
----
* Support for DHCP, which has been requested several times at the summit, has been added and is currently working for me. I'll probably need more testers to verify the functionality, so please join.
You'll need to checkout the network git and make sure you have installed the dhcp package from unstable:
http://git.ipfire.org/?p=network.git;a=summary
dhcp-4.2.2-3.ip3: https://pakfire.ipfire.org/build/df9a43e6-8d99-4ac7-973a-239a9120211b
To enable the DHCP client on a zone type: network zone upl0 config create ipv4-dhcp
----
* Basic (!) firewalling support, which has no option to be configured, yet has been added. That means that I have been porting some of my old testing code I have written in 2009 to the network package.
It can be enabled by running "firewall start" and disabled by typing "firewall stop". Don't expect to reach the internet anymore.
The interesting part here is the structure of the chains. Have a look at "iptables -L -n -v".
----
* Hotplugging for USB devices. There has been some code, but due changes in udev and systemd it was not working anymore. This has been fixed and there has been support added for wireless devices.
Example #1: If you now plug in a USB-LAN adapter, you will automatically create a port configuration for that device which is called p0, p1, ..., pN. If you unplug the adapter, the device will disappear automatically and will be removed from the zone where it has been in. If you plug it in again and there is a zone configuration for that port, the port will automatically added to the zone (if the zone is already running).
Example #2: A wireless device is treated somewhat differently. When plugged in, there won't show up any interface (like wlan0). The reason for that is, that wireless devices can have multiple interfaces at the same time (think of multiple SSID access points). Those interfaces will be created when they are needed and automatically created when the USB device is plugged in.
When you are building a wireless access point please make sure you have at least hostapd-0.7.3-2.ip3 and iw installed: https://pakfire.ipfire.org/build/08e1b509-2198-459f-9de2-2a9c8aa5a38e
Please set up some testing hardware and check if this is working on your box as well.
----
* systemd is controlling the zones. Which enables us to them in parallel and access their status via dbus.
----
To not ask too much from you in a single email, I will stop here and we will see in about a week with what I am coming up then :D
Again my request: Please test and file bug reports against: https://bugzilla.ipfire.org/enter_bug.cgi?product=IPFire&component=netwo...
Michael
Hello Michael,
today I've tested the Teredo tunneling by using the miredo-client on a 64 Bit machine.
After some small problems, which already have been fixed and commited I got it to work and was able to ping ipv6.google.com.
[root@ipfire network]# ping6 ipv6.google.com -n PING ipv6.google.com(2a00:1450:4016:801::1013) 56 data bytes 64 bytes from 2a00:1450:4016:801::1013: icmp_seq=1 ttl=57 time=417 ms 64 bytes from 2a00:1450:4016:801::1013: icmp_seq=2 ttl=57 time=143 ms 64 bytes from 2a00:1450:4016:801::1013: icmp_seq=3 ttl=57 time=142 ms ^C --- ipv6.google.com ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2233ms rtt min/avg/max/mdev = 142.820/234.572/417.729/129.511 ms
Best regards,
Stefan
Thank you very much. The changes you sent me have been merged to the master tree.
Michael
On Sun, 2012-06-17 at 22:09 +0200, Stefan Schantl wrote:
Hello Michael,
today I've tested the Teredo tunneling by using the miredo-client on a 64 Bit machine.
After some small problems, which already have been fixed and commited I got it to work and was able to ping ipv6.google.com.
[root@ipfire network]# ping6 ipv6.google.com -n PING ipv6.google.com(2a00:1450:4016:801::1013) 56 data bytes 64 bytes from 2a00:1450:4016:801::1013: icmp_seq=1 ttl=57 time=417 ms 64 bytes from 2a00:1450:4016:801::1013: icmp_seq=2 ttl=57 time=143 ms 64 bytes from 2a00:1450:4016:801::1013: icmp_seq=3 ttl=57 time=142 ms ^C --- ipv6.google.com ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2233ms rtt min/avg/max/mdev = 142.820/234.572/417.729/129.511 ms
Best regards,
Stefan _______________________________________________ Development mailing list Development@lists.ipfire.org http://lists.ipfire.org/mailman/listinfo/development
Good evening,
it is time for another smaller status update about the patches that have been added to the networking code in the last two weeks.
There has been a bunch of fixes for bugs that have mainly been discovered by Stefan. Thanks for that.
One bigger step has been a proper output of the status of the zones. The console has often been cluttered with too much information and we needed to fix that. You will now see the same output a bit shortened and with some colours marking the most important this (zone is down or something like that). There has also been done some work for creating this output a bit faster which translates to: Not so many forks in the shell code and sourcing the hooks in a subshell without including the whole function library again.
The pppoe hook has been reworked. That means duplicate code has been consolidated and documentation has been added. The service name and access concentrator options which are present in IPFire 2 have been added. PLEASE test this. I have done everything I could, but have no access to an IPv6 enabled DSL line. I don't expect this to work right now. Information on how to use the pppoe hook is available: man 8 network-zone-pppoe
As mentioned earlier, I had no possibility to test the pppoe hook and therefore I built the pppoe-server config hook. This just listens on a zone for PPPoE packets and creates an instance of pppd for each connection. I have no idea if this is a feature that will be requested by many users, but it is quite handy for development purposes. Please give it some testing as well: man 8 network-zone-config-pppoe-server
Finally, there has been a command added to configure the local pool of DNS servers. You may add a DNS server by running "network dns add 8.8.8.8 20" where 8.8.8.8 is the IP address of the DNS server and 20 is the priority. A list of all configured DNS servers can be viewed by issuing "network dns list". Detailed information is available at the usual location: man 8 network-dns
That's all for now. Thank you for reading and testing in advance.
Michael
On Wed, 2012-06-20 at 15:36 +0200, Michael Tremer wrote:
Thank you very much. The changes you sent me have been merged to the master tree.
Michael
Hello Michael,
thanks for your latest status report, I've tested the "network dns" command and I really like it - easy to use but even powerfull.
I also tested the new pppoe-server feature, and was able to connect from a Windows XP Home ( SP 3 ) to this pppoe-server.
The only thing I wasn't able to test ist the pppoe dialin with IPFire, because my ISP doesn't support this, but hopefully some testers will provide feedback about this.
Best regards,
Stefa
Good evening,
it is time for an other report of the networking changes in the last week.
network-004 has been released which marks a milestone of the developments of June 2012. All of the features (DNS, pppoe-client and pppoe-server) are considers as stable and so they are shipped with the newly created IPFire 3 images.
The release makes testing a little bit easier because you can install it by running "pakfire update network". https://pakfire.ipfire.org/build/3f95d666-69e1-4a1c-8ab4-9aa611a95962
----
New features:
The networking code now supports connections with serial modems which will work from 56k modems over UMTS to LTE.
There is no documentation yet because the feature is not fully stable yet. There is at least one bigger bug unresolved which is apparently: systemd kills pppd for no reason. https://bugzilla.ipfire.org/show_bug.cgi?id=10174
I am sure Stefan will take care of this and that we will sort out this bug within the next week.
radvd now supports advertising DNS servers. The feature is called RDNSS. There is actually nothing to take care of but having this enabled which is the default.
Of course there have been code cleanups and minor feature enhancements, but nothing that is worth talking about. Please test.
Michael
-
Michael Tremer -
Stefan Schantl