44net

44net@mailman.ampr.org

3196 discussions

Fwd: [Uronode] FCC serves Comcast
by Boudewijn (Bob) Tenty 07 Jun '16

07 Jun '16

I repost this from the UroNode list with permission from the author. -------- Forwarded Message -------- Subject: [Uronode] FCC serves Comcast Date: Tue, 07 Jun 2016 13:19:12 -0400 From: Brian <n1uro(a)n1uro.ampr.org> n1uro(a)n1uro.ampr.org With regards to my dealings with Comcast and the faulty firmware installed in their CPE devices, the FCC has informed me that they've officially served Comcast with a direct order to resolve this problem or respond to the complaint within 30 days of receipt of the complaint. Since Comcast has admitted to me about their firmware bugs it'll be interesting to see how this is accomplished and if it's within their 30 day window. A copy of their communication is included below. " Your Ticket No. 950514 was served on Comcast Cable Communications on Jun 7 for its review and response. Comcast Cable Communications will likely contact you in an effort to resolve your issue. A response is due to the FCC no later than 30 days from today. Comcast Cable Communications will respond to you directly by postal mail. You can view a list of frequently asked questions at: https://consumercomplaints.fcc.gov/hc/en-us/articles/205082880. We appreciate your submission and help in furthering the FCC’s mission on behalf of consumers. This email is a service from FCC Complaints. Delivered by Zendesk [NKGKWV-K6P1] " This is somewhat positive news for us on the amprnet. -- <rhetorical> Why is it linux users can install and operate *any* version of M$ Windoze but the same can't be said in reverse?</rhetorical> 73 de Brian - N1URO email: (see above) Web: http://www.n1uro.net/ Ampr1: http://n1uro.ampr.org/ Ampr2: http://nos.n1uro.ampr.org Linux Amateur Radio Services axMail-Fax & URONode http://uronode.sourceforge.net http://axmail.sourceforge.net AmprNet coordinator for: Connecticut, Delaware, Maine, Maryland, Massachusetts, New Hampshire, Pennsylvania, Rhode Island, and Vermont.

1 0

Re: [44net] Unable to Receive rip44 Datagram
by Rob Janssen 07 Jun '16

07 Jun '16

> On Tue, 2016-06-07 at 13:25 -0400, James Sharp wrote: > >/I haven't run in to 443 "filtering", but I have run into instances where /> >/the ISP will drop TCP connections that are active for more than a few /> >/minutes, forcing openvpn to restart the connection. / > Chances are your issue is the same as mine was. The CPE (router) has a > built in watchdog timer that cuts all sockets after a few minutes. Using > port 443 wouldn't make any difference. To the average web user this > isn't an issue because each time a page is opened/refreshed a new socket > is created, thus a new timer engages. The same may be said for services > such as pop3/smtp/etc. where you're engaging a new socket each time you > pop or send email. As long as the attachments aren't that big where you > may exceed the watchdog's timer you'll never notice this. So you can never download a file that takes more than a few minutes to complete? Terrible! Now I understand why some companies try to enforce a "download manager" to download a file of a measly 30 MB. So I can continue where I left off, yeah sure. Well it is clear that everyone should devise their own solution for tunneling and we should not change the global system to cater for limits that certain users encounter. There will always be a more severe limitation found by someone. It is better to solve these issues locally, where you have fellow users (victims) that can understand what is and what isn't possible. Colocated (virtual) servers with small storage capacity are very cheap today. Usually they are the entry level of server location, the hoster advertises their $3.99/mo server and knows that "everyone" will upgrade to more storage and pay a lot extra. But for a gateway these are perfectly usable, you can perfectly run it with 512MB RAM and 8GB disk. Put it in the IPIP mesh with the usual tunl0 and ampr-ripd, and then everyone in the area can make their VPN connection to there. Without NAT problems, and working round nasty ISPs. (you can make a VPN over almost anything if you wish) Rob

2 1

Re: [44net] Unable to Receive rip44 Datagram
by Rob Janssen 07 Jun '16

07 Jun '16

> Ok... all important points to understand and we absolutely rely and > appreciate all your help on running the current AMPRGW solution. Before > even jumping to conclusion, we'd need to know if GRE really would be > more successful than IPIP. In Brian, N1URO's situation, I'm curious if > a Comcast "Business" class service would remove some of these > intentional filtering issues. I don't think it will be an appreciable improvement. I have experimented with GRE as the tunneling protocol (chosen exactly for this reason) to connect local stations to our Dutch gateway, and at first the results looked promising, but it did not take long before I got to the first case where plain GRE would not work over a consumer NAT router. I think it is (at least here) never caused by intentional ISP filtering, it is just caused by limitations of NAT routers that were only designed for typical outgoing TCP and UDP connections only. In the mentioned case the router was not even provided by the ISP, making malice even less likely. I then changed setup to GRE over IPsec which works fine until now when in NAT-T mode, but of course this is only suitable for use in a star configuration with connections initiated from the users to some gateway. Not a replacement for the tunnel mesh. I heard in Germany L2TP is used, I'm not sure if it is over IPsec or not. Anyway, I use L2TP over IPsec (sometimes over NAT-T) at work, it works over any connection but here as well it is a star topology. We also offer OpenVPN connectivity at our gateway, in UDP mode only, and this too is problem-free w.r.t. ISP routers. I don't believe a provider would (or even can?) filter OpenVPN, certainly not when it would be run in TCP mode on port 443. However, what is common in all these solutions is the star topology where the user behind the crippled router connects outward to a well-connected system. Of course we don't want to make the entire network into a star, but it could be an idea to deploy more regional gateways like our national gateway, that are interconnected by IPIP tunnels and optionally are BGP-routed on internet, and that offer services like mentioned above and discussed before in this thread to regional users who for some reason cannot run IPIP. It works well here. It is possible to deploy these on virtual servers that are quite inexpensive these days, certainly when not doing BGP (not all those hosters will offer BGP of a /16 or similar network via their routers, at an affordable price) In my experience it is possible (although not for "I am not a programmer" types) to get this working well on a Linux box. Setting up the VPN services and routing is quite well described. Setting up a firewall requires some thought and monitoring, see the recent incident with portmap. But this list is available for exchange of such information. Rob

5 4

Suggestions for the portal and the wiki
by Miguel Bahi 07 Jun '16

07 Jun '16

Thanks Brian, for your update. Yes, the Portugese hamnet site is still under construcction. I notice you when this is up and running for update the link. 73’s EB5JEQ Message: 5 Date: Mon, 6 Jun 2016 09:22:08 -0700 From: Brian Kantor <Brian(a)UCSD.Edu> To: AMPRNet working group <44net(a)hamradio.ucsd.edu> Subject: Re: [44net] Suggestions for the portal and the wiki Message-ID: <20160606162208.GA28893(a)UCSD.Edu> Content-Type: text/plain; charset=us-ascii On Mon, Jun 06, 2016 at 02:31:39PM +0200, Miguel Bahi wrote: > Please , I suggest add in this paragraf > http://www.ampr.org/publications/ > add : Spanish hamnet www.hamnet.es I have added the Spanish HAMNET to the list of links on the publications page of www.ampr.org. There is a link on the Spanish hamnet page to the Portuguese hamnet page, but that site is still under construction so I did not add that link to the link list on www.ampr.org. - Brian

1 0

Re: [44net] Unable to Receive rip44 Datagram
by Rob Janssen 07 Jun '16

07 Jun '16

> A possible option could be SSTP, which works over regular TCP connections > on port 443. But this is not well supported by the Linux world. > Marius, YO2LOJ SSTP is a star as well. In the open world there is OpenVPN over TCP port 443 when you want to run a VPN over TCP (I would not want that, but that is another topic). However what it seems to come down to is that these issues can be solved locally. A local Linux server or (e.g. MikroTik) router can be configured to be part of the IPIP mesh and possibly be BGP routed, and then it can serve as a VPN server for local users using whatever protocol(s) is or are locally preferred due to local situation w.r.t. internet routers and/or filtering. Rob

1 0

Re: [44net] Unable to Receive rip44 Datagram
by lleachii＠aol.com 06 Jun '16

06 Jun '16

I concur with Bob. I've had Comcast before (though, I always used my own device - connecting to a DOCSIS-to-Ethernet bridge/Cable Modem). I've never had success using a consumer-grade router, unless it had DD-WRT or OpenWRT installed, or I used a Linux server. Some D-Link devices permit forwarding of protocols other than TCP/UDP, select the 'Other' option, and place the number 4 in the box for IPENCAP. Otherwise, most DMZ settings on consumer routers only forward TCP and UDP traffic. Since 44net (including RIP44) packets are encapsulated within IPENCAP (IP Protocol No. 4), you must forward that protocol. The Iptables Firewall is the same as on other *nix devices. If you are NATing to a device inside your LAN, the commands are similar to: # iptables -t filter -I INPUT -p 4 -i eth0 -j ACCEPT # iptables -t nat -I PREROUTING -p 4 -j DNAT --to-destination 192.0.2.8 Ensure that you are in fact seeing IPENCAP traffic entering your Local Network at your device (e.g. the to-destination address specified). Within the IPENCAP packets, you should see the password. I should also note, that I currently use Verizon FiOS; and I noticed when using their router as my border gateway, that the IPENCAP entry I make is administratively removed (Verizon has a back-door into their routers on tcp/4567) from upstream at intermittent times (I've been told this is because it's 'hard' for the carrier to track and/or rate-limit non TCP/UDP traffic). So be certain that your carrier it not removing firewall entires, especially if you were successful in the past. 73, - Lynwood KB3VWG

5 11

Re: [44net] Unable to Receive rip44d Datagram
by Rob Janssen 06 Jun '16

06 Jun '16

> Subject: > Re: [44net] Unable to Receive rip44d Datagram > From: > "Boudewijn (Bob) Tenty" <bobtenty(a)gmail.com> > Date: > 06/06/2016 08:23 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > He can check or dd-wrt or OpenWrt firmware is available for his router as these > can forward ipip or can can be set in bridge mode (dd-wrt and OpenWrt are linux based) > and much more. Well, dd-wrt is available for some commercial ethernet/wifi routers but I don't think it exists for any combo-modem-router as is normally used by cable or dsl providers. The dd-wrt people don't have the drivers/software for the modem chips used in those modem-routers. So in this case (a DOCSIS cable provider) it can only be done when he is already using a separate modem and router. > > Some firmwares in these consumer routers even don't allow to be put in bridge mode at > all. The tabs for it are just missing or they don't have an option for it in their menu. Sometimes the ISP can switch the modem-router into modem mode (bridge) from their central management system on user request. It will probably have some strings attached like "no helpdesk support for network problems". After the switchover, the internal ethernet interface will be plain ethernet or PPPoE or PPTP. So you will need an extra router that indeed can be running dd-wrt. However, with today's internet speeds on cable and dsl you also have to consider the router performance. The typical WRT54 routers from the days dd-wrt was created cannot keep up with the internet speeds of today. Rob

1 0

Re: [44net] Unable to Receive rip44d Datagram
by Rob Janssen 06 Jun '16

06 Jun '16

> I have a strong suspicion that my ISP (Charter Communications) has implemented > some kind of filtering on my home cable-based (DOCSIS) internet connection. My > reception of the RIP44d table broadcase has all but ceased. ip-ip tunnel > communication to a friend's machine in a neighboring county only seems to work > for a limited time, and only AFTER I initiate a connection from my end. It's > as if they're using some kind of NAT or port knocking filter, and only opening > the gate for incoming proto 4 traffic for a limited time after I initiate an > outgoing request to a specific host. It is, as Brian N1URO also wrote, an issue in your home router. Other routers have shown this phenomenon for some time. Even when you set a "DMZ" (meaning: forward all unknown traffic to this host), there still is a stateful firewall in place for all protocols except TCP and UDP, requiring you to send outgoing traffic before incoming traffic is accepted. You will need to have the router put in bridge mode (making it only a modem) and install a better router in front of that. With a suitable router, it can also do the IPIP encapsulation. A Linux system of course is a suitable router as well. Rob

2 1

Unable to Receive rip44d Datagram
by kd4cbm＠charter.net 06 Jun '16

06 Jun '16

Good Morning Guys: I have been working to get my chunk of .44 active for a little while now. I've become quite familiar with the concepts of how the network is set up etc. That being said, no matter what I do I cannot seem to get the RIP password that is supposed to be broadcasted from 44.0.0.1. I have go as far as to monitor, log, and filter every packet coming in the cable modem from anything AMPRNet to verify it is arriving. It just seems like the packet is never making it to my public IP. I've gone through all the basics - protocol 4(IPIP) forwarding, UDP port 520 forwarding etc. Like I said, I've even captured all packets pre firewall and I'm not seeing anything AMPRNet. Is it possible that even though my gateway/public IP is registered, the packets aren't being sent out? The last portion of getting this going is that elusive RIP pass. Any suggestions? Thanks, Jason - KD4CBM '73

4 3

disappearing ip alias ?
by Niall Parker 06 Jun '16

06 Jun '16

Has anyone else noted problems with the ethernet alias functionality in recent Linux kernels ? I've just done an update on my tunnel server (pogoplug E02 running Debian 8 with kernel 4.4.0-kirkwood) and within a day or so the 44net alias disappears. Nothing I can see in any of the logs. Replacing the alias via 'ip addr add 44.135.190.17/32 dev eth0:1' is enough to fix it, might have to hack into a cron job :-/ 44 net tunnels are being setup via a script from KB3VNW/LX1DUC, I suspect a few people out there would be using it ... Ideas ? ... Niall

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net