记折腾4K IPTV的周末给自己带来的新知识
上个月家里宽带升级了200M, 顺带看到可以免费享受一路4K的IPTV.
其实一直都知道电信的宽带可以免费申请IPTV, 但是一直都没弄, 主要原因是一直都没找到合适的办法去只用一根网线来解决我上网出口跟IPTV的问题..曾经看到一些方案但是都觉得不合适或者说不够理想, 而在几周前,在Chiphell毒坛看到了一个近乎完美的解决方案https://www.chiphell.com/thread-1421026-1-1.html, 这样一来4K的IPTV自然就可以顺理成章的入住了.
申请过程很简单, 直接找电信客服提供信息就可以安排安装了, 连个合同都没其实, 但是却要求1年的锁定期…电信也是可以…
在电信安排安装之前的一周里, 我先对自己内网做了一个简单的调整来保证新的IPTV实现方案的基础.
简单描述一下原来的网络结构:
电信光猫—-ERL3路由(PPPoE拨号+DHCP+DNS+SS…)—HP 2910al交换机—终端
基本上结构无论是逻辑还是单一方向的, 物理接线也是光猫出来的线直接进入路由器再从路由器进交换机.
在调整完以后:
电信光猫—HP交换机(WAN VLAN+IPTV VLAN)—ERL3—HP交换机(LAN VLAN)—终端
盗用一下Chiphell上作者的解释图:
从物理连接上就变得复杂了, 光猫出来的线路先进交换机, 脱标以后的WAN数据进如路由器, 打标的IPTV 组播数据会直接通过VLAN trunk去跟IPTV做交互.
所以整个方案的核心就在于:
- 需要交换机使用Trunk线路来同时承载上网数据跟IPTV数据
- 在交换机中将2类数据分离开来并且送到需要去的地方
- 路由器的DHCP能为IPTV提供需要的配置参数.
所以折腾的点就变成了:
- 交换机的VLAN配置
- 路由器的DHCP Option
事实上交换机的VLAN配置并没有什么大的挑战, 因为我自己之前的环境内本身就是多VLAN的, 所以无论是设备的支持与否以及能做到什么程度都很清楚.
所以其实只是在交换机上多加了4条VLAN:
- VLAN for WAN, 专门的2个口用作光猫LAN口跟路由WAN的连接, 目的就是让光猫到交换机的线路变成Trunk状态可以同时承载多VLAN的数据.然后从另外一个出口把脱标的上网数据送给路由器做拨号. 而打标的IPTV组播会从trunk线中的其他VLAN回去到光猫. 这个就实现了我们需要实现的关键功能第一跟第二个核心点
- VLAN for IPTV, 这个是我专门给IPTV开的一个VLAN, 实际是可以不用的, 可以使用之前已经存在的LAN VLAN来代替. 不过考虑到IPTV需要特殊的DHCP option 参数, 所以我特地开了一个独立的VLAN出来接IPTV, IPTV的公网接口就是从这个VLAN出来再从路由的接口出去的.
- VLAN 85 跟 VLAN 51, 这两个是IPTV专网使用的组播VLAN, 用来承载电视数据, IPTV会通过这个VLAN直接跟光猫通信跳过路由器. 所以实现第二核心点的重点就是VLAN的划分
到这步为止, IPTV需要的在交换机上的准备就完成了.
剩下的事情就是DHCP的问题了…
因为没用过以前的IPTV所以我不确定是什么情况, 据说比较新的版本是只要能上网就能用了.
而新的4K IPTV是需要所谓的跨越AB面认证的, 从我的认识上来说, 就是先要拿到Internet的access, 再通过VLAN 85拿到专网的IP.
公网access的IP简单, 常规DHCP的配置就行. VLAN85的配置, 根据众多前辈抓包对比以及查阅《中国电信家庭网关总体技术要求》说得到的信息来说，就是需要在第一步的公网IP的DHCP过程中，携带上Option 125的信息,
option 125中的信息会告诉Client VLAN85的存在.
具体请参考这里:http://koolshare.cn/thread-43568-1-1.html
所以我就需要给IPTV VLAN的DHCP server必须要可以发送Option 125出去.
然后重点就来了.
我本来天真的以为只要配置上了DHCP Option 125, 那么Client来申请的时候option会被附加上, 然而事实证明我还是太弱鸡了.
不过既然这么想了, 肯定先要把option 125这个配置能正常生成了才行.
所以我去爬了一下Ubnt的国内外论坛, 了解了自定义DHCP option的配置方式, 相对来说还是比较容易实现的.
set service dhcp-server global-parameters “option option-125 code 125 = string;”
set service dhcp-server shared-network-name VLAN_50 subnet 192.168.5.0/24 subnet-parameters “option option-125 00:00:00:00:14:02:06:48:47:57:2d:43:54:0a:02:20:00:0b:02:00:55:0d:02:00:2e;”
2条命令就能在ERL3里面自定义出来一个option 125来..不得不说Ubnt的货实在是自由度高到没边啊…
然后我就用Windows上DHCP test去做测试了..
这是个很小的带抓包功能的测试工具, 基本功能就是检测网卡通信中的DHCP包并且抓取下来, 以及模拟一块新的网卡去discover DHCP.
DHCPtest出来的结果很令人振奋呢, 可以直接看到Option 125在offer包里呢!
所以我就很放心的去等IPTV的安装了…
然而事实证明一帆风顺总是小概率事件, IPTV在完成安装以后直接就跳了认证失败, 网络信息显示公网正常专网拿不到IP地址.
这时候我就觉得这怎么可能..
回头再用DHCTest测试, 明明是有的啊…这时候我都怀疑是不是Option 125给的raw data是否会错了…不过考虑到以及被很多人实现过额, 所以code出错的概率其实很小.
所以, 这时候只能启用交换机的镜像端口去抓IPTV说产生的DHCP包, 结果令我诧异的是根本没有Option 125的数据被附加上去.
这时候我才意识到, 前辈们使用DHCP-option-Force的参数给Dnsmasq来添加Option 125的意义, 就是为了强制把option 125推送除去啊…
然而我不想换Dnsmasq啊, 因为ERL3的web页面管理使用dhcpd来实现的, 很清楚很好用啊…
这时候我已经再想要不要把raspiberry给翻出来专门给IPTV作为DHCP sever来服务了, 因为手头能尝试的办法跟能查询到资料已经大多过了一遍了, 对于EdgeOS的系统上如何实现强制option完全没有涉及.
不过天无绝人之路, 在再次搜索查看信息的时候, 注意到了Linux 的DHCP Man Page里对于Option 55的描述是如下的:
“option dhcp-parameter-request-list uint16 [, uint16… ];This option, when sent by the client, specifies which options the client wishes the server to return. Normally, in the ISC DHCP client, this is done using the request statement. If this option is not specified by the client, the DHCP server will normally return every option that is valid in scope and that fits into the reply. When this option is specified on the server, the server returns the specified options. This can be used to force a client to take options that it hasn’t requested, and it can also be used to tailor the response of the DHCP server for clients that may need a more limited set of options than those the server would normally return.”
也就说, 只要能给服务器定义出这样一个option, 服务器就会自动根据配置的option list强制给client发送option 信息, 这不就是我要的嘛.
然后赶紧去查Ubnt怎么配置类似的参数, 还真给找到一个:
于是就有个如下的2个配置:
set service dhcp-server global-parameters “option option-55 code 55 = array of unsigned integer 16;”
set service dhcp-server shared-network-name VLAN_50 subnet 192.168.5.0/24 subnet-parameters “option option-55 3,6,58,59,125;”
第一行是定义一个option 125的参数名字, option code以及数据类型
第二行是在对应的子网下, 定义出需要强制发送的Option List.
这里需要注意的是, 在有了55以后, 很多以前被认为理所应当会被DHCP server发送的option就不发了, 比如option 3的网关信息, Option 6的DNS server 信息等等.. 所以无法偷懒只写一个125.
然后就是享受HD IPTV的时间了…
总的来说, 整个过程因为前人的大量实践, 所以并不是特别曲折, 只是因为设备本身的配置以及功能区别的问题, 所以给了我一个去深入理解DHCP以及Option的契机, 在几天时间内大量的翻阅跟DHCP option相关的文档以及配置案例, 对整个体系的理解有了一个新的认识.
所以说, 在实践出真知啊!! 人生不折腾还有什么意义呢?
限制滴滴们的背后
今天, 因为网约车新政而导致的滴滴相关的讨论大量出现在了各个热门的社区以及各种圈子内…滴滴涨价的说法也甚嚣尘上..
从各地的政策上,统一口径的就是收紧对于网约车平台的监管, 增大对于车辆的准入限制以及司机资格的限制.
魔都跟帝都就更绝一点..直接导入了户籍制度作为撒手锏.
我们不能否认滴滴快递们为出行市场做出的贡献…至少让很多人有了方便快捷的出行方式.
滴滴们的出现让我们能方便的叫到需要的车辆,比以前傻等要容易的多,也不需要给出租公司付电调费用.
红包和补贴的存在又大幅度拉低了费用, 提供经济上巨大的利益.
然而同样的,滴滴的出现, 直接导致了曾经作为魔都一大招牌的出租车已经完全沦陷..各种拒载挑客等在魔都原本几乎不会出现的情况在有了滴滴等打车软件以后层出不穷, 最大的问题就是司机不愿意拉小单,以前要是不拉就要在马路上转.现在完全可以在手机上等着, 所以近距离的出行反而变得麻烦了.我想很多人都有在风雨天叫车不加价根本没车接单的尴尬情况把.
其次就是, 现在已经没有黑车这个概念了…以前交警还要费力整治的黑车已经通过滴滴等完全洗白…变成了专车快车顺风车, 所以黑车已经成为历史…然而这些曾经被认为是不安全隐患的黑车是消失了还是变好了?都不是…只是他们套上滴滴们的合法外套, 不再需要在地铁站单纯的等待…而是可以用手机直接解决客源问题了而已. 所以说, 一个软件就解决了曾经整个社会都谈之色变的安全问题了?
我曾经认为滴滴们的崛起会是倒逼出租车改革的一大动力, 然而在滴滴完成了事实垄断, 价格逐渐太高以后, 我觉得滴滴本身反而变成了需要改革的对象, 因为本身共享经济特性所提供的价格优势不再, 服务水平不会比传统出租更高,而安全监管水平差的多的网约车, 凭什么跟每个月交着份子钱的出租车在一个价格水平上?
如果说滴滴大幅度的解决了市场需要的运力问题, 那我可以说, 黑车也解决了这个问题, 而且还便宜…请问2者有什么本质的区别吗?
那么我们回到这次的限制政策上, 大部分的政策的情况就是要造成滴滴网约车必须要提供差异化服务, 车子要好要新,服务要好.
这也就意味着,把大量廉价的黑车级别的车辆运力淘汰出市场. 至少我是觉得如果真是为了安全舒适考虑的话没什么不好的.
至于户籍限制, 除了魔都帝都应该都没太大意义….至于2个超级城市, 我想住这里的都能理解这个户籍背后给人带来的种种标签意义.
我并不认为增加司机的户籍限制是个合理的行为, 不过如果说要为了限制比亚迪秦这种可以直接拿沪牌的车, 那么剩下的招数也着实不多了, 我估计真要说要求房产证什么的做证据那抵制的声音可能比现在说歧视的声音来得更大吧.
从另外一个角度去想, 很多原本靠着滴滴过日子的司机师傅, 可能因为这样的变故, 直接就回老家了. 我不得不想着, 这应该也是政府人口导流的一个措施吧..毕竟魔都跟帝都都是指定了人口限制计划的地方, 基本上不会再考虑外来人口的舒适度了, 这已经是既定方针, 既然这样, 出台这种政策也就没撒大惊小怪的了.
至于滴滴一直在呼吁的运力大幅度下降的情况, 我预期一定时期内确实会存在, 不过只要需求在, 市场在, 那么必然会有解决的办法…以前的黑车后来的滴滴, 哪个是原本就有的东西?
或许为了吸引新的司机队伍, 滴滴就不得不加大补贴的力度了呢?
至于提价…我相信会消费者始终都会用自己的脚来投票的…如果滴滴不想要这块市场, 那么我觉得别人会很乐意看到的,比如摩拜单车也许哪天就变成摩拜租车了…
当然受伤最深的应该就是现在的专职滴滴司机了….如果直接被扫地出门的话, 他们这些近年来完全依靠滴滴生存的人可能直接就没有了立足的根本了.
不得不说, 无论是滴滴还是快递公司们, 他们间接的解决了大量的剩余劳动力, 也解决了中国这个巨大市场的最终末梢的流通环节.
所以, 怎么解决这些人的出路, 可能会是一个不大不小的课题….希望, 能有个妥善的办法吧…
整个事情的背后, 尤其是滴滴的回应, 给人的感觉更像是拿着消费者跟司机们去跟政府讨价还价…多少有点给人一种垄断要挟的感觉.
我不清楚政府制定政策的人是站在什么角度去权衡的, 但是, 从我的角度去考虑, 保护坐车人的安全是第一位的, 其次才是司机跟消费者的经济利益.
所以滴滴只谈经济问题, 不谈监管问题多少有点避实就虚.
而政府政策的收紧, 我看不清楚目的跟动机是什么, 所以多少有点矫枉过正的感觉, 所以引起的反弹确实有点大..
只能希望市场本身能给出一个相对合理的解读然后做成适当的反应, 去解决这个长期困扰各大城市的民生问题了.